⚙️Log #21

Изучаю потихоньку OpenGL, вникаю в системы рендеринга.

Вот основной список документаций, которые штудирую:
1. OpenTK Learn
2. OpenGL Core
3. OpenGL GLSLang Spec

🟢 Ещё глубже разобрался, как работают атрибуты и юниформы. Всё оказалось гораздо проще, чем я себе представлял. Если условно, то атрибут используется для каждой вершины в вершинном шейдере, а юниформа — глобально для всех шейдеров. Очень удобно их применять на разных этапах рендеринга. Например, атрибут может спокойно принимать целый буфер разных данных в одном массиве. Потом мы просто для атрибута конкретной вершины определяем смещение в байтах и настраиваем офсет. Таким образом, массив становится своеобразной инструкцией для всех вершин. Атрибут можно использовать, например, для настройки градиента для спрайта, указания позиций вершин, нормалей для освещения или тех же UV-координат для наложения текстур.

Если брать юниформу, то она очень полезна для глобальных значений. Например, можно задать цвет материала, настроить металличность, указать индекс текстуры, загруженной в GPU, или, скажем, передать матрицу преобразования.

🟢 Помимо этого, ещё почитал документацию о VBO — это вершинный буфер, который, собственно, принимает в себя данные для загрузки на GPU. Потом углубился в VAO — это некоторая настройка для атрибутов, через которую можно задавать правила чтения этого буфера. Важный момент: я понял, что привязка VAO происходит к текущему привязанному VBO. Это важно учитывать. Если VBO не был привязан или привязался другой, то VAO будет привязан к последнему или выбросит ошибку, потому что нет буфера, с которым он работает.

🟢 Потом познакомился с оптимизацией для работы с вершинами. Условно, мы можем для отрисовки спрайта использовать 6 вершин, что не очень эффективно, потому что в двух местах будет дубликат вершин из-за наложения двух треугольников. Либо же мы можем использовать только 4 вершины, что будет правильнее, и переиспользовать для создания треугольника уже известную вершину. Для этого нам поможет EBO — это буфер элементов, в который мы передаём индексы вершин, загруженные в VBO и определённые при помощи VAO. Здесь, кстати, тоже есть важный момент: EBO нужно привязывать к привязанной VAO, потому что он работает с ней, так как ему нужно понимать индексы вершин.

🟢 Ну и по мелочи: ещё поигрался с настройками OpenGL, например, с включением смешивания.

🟡 Дальше планирую по-прежнему работать над рендерингом. Нужно разобраться более подробно с фундаментом.

⚙️Log #22

Начал писать парсер под wavefront формат (.obj) и мне райдер предложил поставить расширение.

Неожиданное и приятно был удивлен, что меш можно осматривать прям в IDE, еще и подсвечивает данные + можно поиграться с разными настройками.

⚙️Log #23

Давно не ощущал такой свободы в разработке...

За последние два года устал заниматься Unity-like мобильной дрочильней. Единственной отдушиной был веб-стек, который пришлось осваивать из-за очередного бума HTML5-игр. Но и там всё переросло в рутину, потому что задачи в той или иной степени повторяются.

А сейчас пишу свой движок, и здесь, чтобы что-то реализовать, приходится изучать тонны информации. Даже этот простенький парсер .obj-моделей заставляет изучить его структуру, почитать историю создания формата, параллельно залезть в документацию по работе с шейдингом. Потом увидел, что модель может быть не триангулирована, и нужно как-то обрабатывать этот кейс. Пошел смотреть, как такое делают на примере уже готовой библиотеки, хочу потом написать свой триангулятор просто потому, что хочу.

Вот оно, запах инди! Многое здесь создается только потому, что «Хочу!»

⚙️Log #24

Сезон страданий открылся...

Вчера потратил больше 6 часов на поиск решения проблемы. Изначально я написал логику втупую для работы с буферами, потом решил сделать для них обёртки, чтобы было удобно с этим работать и не писать кучу одинакового низкоуровневого кода.

Всё шло прекрасно до одного нюанса. Приложение начало крашиться, когда я делал два раза подряд привязку одного и того же буфера или вершинного массива. Раньше можно было привязывать сколько угодно раз, а теперь — нет. В рендере начиналась дичь в момент привязки указателей на данные атрибутов. Я хотел сделать лаяут, который автоматически сдвигал бы offset и определял stride для вершинных атрибутов.

По идее всё должно было работать чётко, но приложение падало с access violation. Решения на форумах я не нашёл, а официальная документация утверждала, что привязку можно делать сколько угодно раз. Так в чём же была проблема?

Оказалось, что я создавал буферы в автоматическом свойстве через лямбду:

public int Id => GL.GenBuffer();

Из-за того, что GL.GenBuffer() — unsafe-метод, при каждом обращении к свойству генерировался новый буфер, а старый терялся, создавая утечку памяти. Решение было простым — вынести создание в конструктор:

public int Id { get; private set; }

public ArrayBuffer()
{
    Id = GL.GenBuffer();
}

Теперь буфер создаётся только один раз и больше не вызывает падений при повторных привязках.

P.S. Дипсик и GPT-чат вообще не справляются с низкоуровневой разработкой. Да, они знают многое, и полезно с ними сверяться по каким-то нюансам, но они очень жестко теряются и постоянно выдают невалидную информацию. Она иногда даже не сходится с официальной документацией. А такие нюансы, как порядок привязки буферов — вообще жопа для них. Да, они в курсе, что должен быть какой-то порядок, но какой именно — им пофиг. В каждом ответе всегда рандомный порядок и бессмысленные биндинги и т.д.

⚙️Log #25

🟢 Начал разработку системы проектов для движка. Её основой станет лаунчер, в котором будет отображаться список всех проектов пользователя, их настройки и другие параметры.

При выборе проекта в лаунчере он будет открываться в изолированной рабочей директории. Эта папка будет содержать только файлы, относящиеся к данному проекту, а также служебные метафайлы для работы редактора и движка.

🟢 Решил реализовать эту систему на раннем этапе, чтобы заложить основу для её дальнейшего развития.

На текущий момент наметил принцип работы:
- Для каждого проекта автоматически генерируется решение (.sln) под .NET 8.0, а также его первый проект (.csproj).
- Параметры сборки для всех проектов определяются на уровне решения. В нём прописаны ссылки на собранные DLL-библиотеки движка.
- Пока что путь к этим DLL читается из переменных окружения компьютера. В будущем этот механизм может быть изменён — возможно, путь будет генерироваться динамически при запуске редактора. Решение через переменные окружения было выбрано как наиболее стандартное на первом этапе.

🟢 Движок можно будет установить прямо из лаунчера. Он загрузится в виде архива, распакуется в указанную пользователем папку и начнется процесс установки, после чего путь к нему будет автоматически добавлен в переменные окружения системы. Это позволит использовать движок как в процессе сборки проектов, так и напрямую из терминала.

🟢 Каждый проект будет содержать главный файл .project с информацией о нём: название, описание и т.д.

Также в этом файле указывается тип проекта:
- Игра — конечный продукт, разрабатываемый на движке. Собирается в исполняемый .exe-файл вместе с контентом. Может иметь зависимости в виде библиотек и пакетов.
- Библиотека — проект, состоящий в основном из кода, без контента. Представляет собой обычные .dll-файлы, которые могут использоваться в играх или других пакетах. Библиотеки могут быть одиночными или представлять собой группу взаимозависимых проектов.
- Пакет — reusable-компонент, который можно легко переиспользовать в разных проектах. Это аналог Packages в Unity, но адаптированный под нужды данного движка. Пакет может содержать как код, так и контент. Он может зависеть от других проектов, но только от библиотек или других пакетов.

🟡 В качестве теста я начал делать в этой системе игру Flappy Bird. Пока что всё работает отлично: процесс удобен и не требует дополнительных манипуляций с файлами проекта.