Серия «Relict Engine»

В общем, как я не старался, но все равно поломал почти все при переключении. Сейчас движок практически полностью работает на новой кодобазе ядра (и под работает я имею ввиду компилируется под платформы и запускается). Есть шероховатости, дебажу потихоньку. Например, после переключения на метаклассы, выстрелило то, чего я боялся в старой кодобазе - а именно нарушилась очередь создания объектов, в результате чего объект мог запросить метаинформацию раньше, чем она была создана в ядре (что любопытно, поймать это удалось только в gcc).

Но это поправил, хоть и не совсем, как мне кажется, красиво и видимо все-таки нужно будет в следующем обновлении ядра (начало след. года, видимо) подумать про глобальную сущность, которая будет хранить все ранние делегаты, чтобы вызывать их не из глобальной части кода, а после того, как все шаблоны раскрылись и инициализировались во всех модулях. И дергать из функции инициализации уже.

Миграция все еще в процессе и займет довольно продолжительное кол-во времени. Благо в начале Февраля начинается отпуск. Там, думаю, дела пойдут веселее и в Марте переключусь уже непосредственно на графоний, чтобы не отставать от намеченного плана.

Касательно структур, решил сделать чуть иначе, чем в концепт-коде, приведенном в пред. посте: Relict Engine: Начало сезона 2026
Вместо некрасивого нагромождения различных скобок в шаблоне (который еще и очень не нравится IDE, несмотря на то, что стандарт допускает такое использование) вынес их отдельно. Теперь это выглядит вот так:

Так-же, подобные структуры позволят нам реализовать ряд интересных вещей. Например, после реализации мета классов, они позволят нам связать создание одного объекта с другим объектом (Например класс RenderObject с SceneUnit) для более прозрачной работы конвейера.

Остальные улучшения

Вторым крупным улучшением (которое уже внедрено и работает), стало замена тикера Сборщика мусора на событийную модель. Это сильно повысило производительность, т.к. я избавился от цикла перебора всех созданных движком объектов. И, смотря на перспективу, возможно, сборщик мусора будет объеден с глобальным хранилищем объектов, ибо уже сейчас бессмысленно ее держать отдельно. Но это уже потом; узелок на память завязал.

Третьим улучшением, которое частично будет реализовано сейчас, а частично очень потом - это внедрение мета классов аналогов UClass в Unreal Engine, для хранения константных проинициализированных структур инициализаторов и мета методов для работы с Lua. Что позволит нам сильно упростить работу с скрипт подсистемой. Которая, возможно, перейдет из состояния подсистемы в ядро (но это не точно, поэтому и откладываю на потом). А так-же избавит от необходимости таскать в дефолтном конструкторе Initializer. И в дополнение, они позволят нам избавится от такого рудимента, как DefaultObject (он используется для проверки Флагов в хранилище объектов).

Что мы тут видим:
Директива using
Она определяет компоновку с сырыми шейдерами. Определяет домен, модель смешивания альфы и модель освещения (не путать с моделью затенения из пред. поста).
Нейминг был взят из Unreal Engine, потом, возможно, поменяю на немного более логичные.

Директива in
Она определяет входные переменные для материала, используя типы GLSL

Директива include
Эта директива говорит комбайну, что следует обратится к функции, определенной в файле MaterialFunctions/getColor (Content/MaterialFunctions/getColor.minc проекта). Что важно, сам файл как самостоятельный ассет не будет использоваться, но его контент будет вставлен заместо директивы include при первичной компоновке.

Директива function
Директива означает, что следующий текст является функцией. Сама функция должна быть написана на языке GLSL. В прочем, возможно, логичнее будет определить блоковую директиву, в которой код будет интерпретироваться как есть.

Директива set
Эта директива передает конкретные значения в параметры "сырых" шейдеров. Иными словами, это и есть сам материал.

Шейдер это программа, написанная на одном из специализированных языков программирования, например GLSL, и выполняемая на GPU.
Шейдеры бывают разных видов: вершинные, фрагментные, геометрические и компьют. Каждый создан для своей задачи и работают чуть по разному.
Например, вершинный шейдер работает исключительно с вершинами (или набором точек) 3д модели, а фрагментный (или, как его еще называют, пиксельный), только с пикселями экрана или текстуры.

Для вывода графики на экран нам нужен как минимум вершинный и фрагментный шейдеры. Они будут исполнятся на каждый отдельно взятый объект. В случае вершинного для каждой вершины модели; в случае фрагментного для каждого пикселя экрана, занятого объемом результата вершинного шейдера.

А так-же есть две модели шейдинга (шейдинг ("затенение") - процесс в компьютерной графике, который придает объектам реалистичный вид, определяя их цвет и внешний вид в зависимости от освещения, текстур и материалов):
Forward (или прямое затенение) - при этой модели каждый отдельный объект обрабатывается самостоятельно. Свет и тени будут считаться отдельно для каждого объекта.
Deffered (или отложенное затенение) - отрисовка сцены происходит в несколько проходов с сохранением промежуточных данных в специальные текстуры, которые имеют общее название G-Buffer. А потом, отдельным проходом, единоразово будет просчитан свет и тень.

И у первой и у второй модели затенения есть свои плюсы и минусы. Так например, для разряженной сцены, где много "пустых" мест быстрее будет работать прямое затенение. Когда как для нагруженной сцены, особенно если есть много перекрывающихся объектов, отложенное наоборот покажет себя лучше.

Шейдеры в Relict Engine

Таким образом, в первую очередь нам нужно выбрать, какую модель затенения использовать в движке. Т.к. проект, для которого Relict Engine создается, связан с космосом, то логично предположить, что прямое затенение даст больше производительности, нежели отложенное. И это будет верно, пока мы говорим о "сферическом космосе в вакууме". Как только появляются туманности, низкие орбиты и нагруженные космопорты на этих орбитах, все становится менее очевидно. Поэтому, несмотря на кажущуюся простоту этого вопроса , ответить на него не так уж и просто.

Следующие вопросы, который надо решить, и которые не связаны с моделью затенения напрямую, а больше относятся к архитектуре движка, является: А как хранить шейдеры? Как передавать в них параметры?

В спецификации OpenGL 4.5 появилась возможность использовать бинарные шейдеры Spir-V, которые являются основным форматом шейдеров для Vulkan. И это удобно, мы сможем использовать один и тот-же шейдер как для OpenGL, так и для Vulkan без модификации. Но это касается "статичных" шейдеров. Их нельзя изменять, можно добавить только заранее известные переменные, которые можно будет передать в шейдер через функции движка или скрипта, а если мы хотим чего-то более сложного? Например передать не текстуру, а некую математическую функцию, которая будет определять цвет пикселя по своим собственным законам?

Таким образом, нам понадобится система, которая будет компоновать наши кастомные навороты, а так-же вводные данные, в виде переданных параметров с набором функций базовых шейдеров в некую отдельную сущность, которая будет представлять из-себя скомпонованный шейдер из множества отдельно взятых функций и точки входа. И желательно, все это все равно сохранить в Spir-V формат для удобства дальнейшего перехода на Vulkan.
Более того, в зависимости от выбранной модели затенения, выходной результат так-же должен отличаться. Так например, если мы для Основного цвета (Diffuse Color) не будем использовать текстуру, а некую мат. функцию, то нам нужно будет скомпоновать эту функцию с шейдером G-Buffer, в случае использования отложенного затенения, когда как в случае прямого затенения, с итоговым фрагментным шейдером.

Иными словами только для подготовки шейдера к компиляции в кэш нам потребуется целый промежуточный комбайн. Этот комбайн будет работать с текстом, компонуя и генерируя исходный glsl код из пред написанных сниппетов и нашего материала. А на выходе должен быть Asset, уже в формате Spir-V, который и будет использоваться для компиляции уже в машинный код и исполнения на GPU.

Но немного подытожу, что у меня получилось с пайпом. А получилась довольно интересная загогулина.

Итак, первое, что у нас есть это Renderer. И как не странно, эта сущность не занимается обработкой графики. Она используется как загрузчик уже непосредственно самого класса отрисовки, а так-же как прокси к нему.

Второе, что у нас есть это RenderUnit. Производный от SceneUnit это объект игровой сцены, который может иметь что-либо связанное с выводом на экран (Меш, скелет, систему частиц, итд)

Третье что у нас есть это интерфейс IRenderObject и производные к нему. Это и есть те классы, которые занимаются непосредственно отрисовкой, т.е. сбором всех контекстов и вызовом команды графического апи на отрисовку. Примечательно то, что эти классы на прямую связаны с RenderUnit таким образом, что каждому RenderUnit соответствует свой RenderObject

Четвертое - VertexArrayObject. Название взято из спецификации OpenGL, и служит он ровно для той же цели, что и объекты VAO в спецификации. Он хранит вершины модели, индексы и их атрибуты, и прокидывает их в видеопамять. Связан с IAsset производными, но управляется из RenderObject (т.к. заполнение может быть специфическим, в зависимости от типа юнита). Но тем не менее хранит набор из ссылок на RenderObject'ы, юниты которых используют ассет, к которому привязан данный VertexArrayObject (сложна!). Почему именно так: А все просто. Чтобы максимально ускорить процедуру рендера я решил сократить издержки на переключение буферов на GPU. А для этого, мы переворачиваем порядок вызовов на отрисовке (если создаются таким образом: RenderUnit -> RenderObject->VertexArrayObject, то при вызове на отрисовку порядок переворачивается: VertexArrayObject -> RenderObject->RenderUnit). И заодно организовываем сортировку объектов по этому же VAO. Таким образом, если у нас на сцене есть, допустим 3 куба, 2 шара и одна пирамида, то отрисовано будет сначала именно 3 куба, потом 2 шара, и в конце пирамида. Таким образом, на 6 объектов, у нас придется только 3 переключения контекста (про инстансинг помню, но он отдельно и не для этого).

Ну и пятое, чем мне в ближайшее время предстоит заняться - это шейдеры. До последнего момента я использовал залипушный шейдер, вкомпиленный прямо в код (чтоб хоть что-нить показать можно было), однако пришло время сделать все по уму. С кэшами, с инклудами подмодулей, итд.

Ах да, забыл. Собственно класс графического модуля. Он-же драйвер, который загружает Renderer. Сказать о нем мало что можно, кроме того, что он является проксей уже непосредственно в графическое апи, а так-же содержит вход в процедуру отрисовки.