Серия «Relict Engine»

Что мы тут видим:
Директива 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. Сказать о нем мало что можно, кроме того, что он является проксей уже непосредственно в графическое апи, а так-же содержит вход в процедуру отрисовки.

В ближайшее время буду думать в сторону промежуточных объектов, связывающих графический пайп с игровым фреймворком. Скорее всего нужно будет навести один/два дополнительных реликта (модуля) для этого дела, да вынести отрисовку туда. Так-же нужно перепривязать эти объекты с RenderUnit на непосредственно Asset. А то сейчас получается, что один и тот-же меш будет иметь столько VAO, сколько RenderUnit на сцене, даже если они несут один и тот-же объект - это не порядок. В идеале должно быть так, чтобы был один VAO на один ассет, чтобы не напрягать GPU лишними переключениями контекста, да и в видео памяти получается по несколько раз одно и тоже лежит, что тоже есть очень не хорошо.
Правда в этом случае вылезет проблема с переключением LOD, т.к. на данный момент для переключения в VAO меняется буффер вершин. В случае, если VAO будет привязан к ассету, то переключать лоды для конкретного объекта не выйдет (только если все LOD в графическую память сразу отдавать). В общем, еще есть над чем подумать.

А пока что результат на сегодняшний день:

Лоды

И результат работы этого кода.

Пока как-то так. Да, это все-еще не похоже на движок, однако маленькую вешку считаю достигнутой )

Похоже пора баг треккер включать. Начинаю путаться в адресованных и исправленных ошибках.

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