TehnoMagEG

Рано обрадовался, работы (не по движку) пока еще довольно много + духота по мозгам долбит. Ползу медленней, чем обычно, поэтому решил пока бросить приоритет на отладку и производительность того, что уже сделано, чем на добавление нового функционала.
Как всегда больше всего проблем вылезает в Linux сборке - ведро как-то более либерально ко всему относится (причем настолько, что я ему уже не доверяю). Есть проблемы с крэшами сборки из-за Сборщика мусора при удалении объектов из разных потоков (происходит из-за состояния гонки [Родитель приходит к состоянию очистки памяти раньше, чем дочерние, что не есть правильно]), и кроме того, как полностью разделить деревья и вынести триггеры сборщика в отдельные не связанные сущности решения похоже нет (При этом такое поведение наблюдатся исключительно в Linux; Windows как-то пофиг на это, что добавляет отдельно батхерта). Хотя, возможно надо было так изначально делать, т.к. из-за кросс потоковых деревьев приходится паузить треды на тике Сборщика. Если деревья будут разделены, то этого делать будет уже не нужно, а следовательно и производительность несколько увеличится (в прочем там могут другие проблемы вылезти).

Так-же наконец-то добрался до света и pbr. Базовый (очень базовый) шейдер уже написал, теперь нужно прописать логику для юниформов (std140, естно) и работой со светом через ++. Думаю, сначала поэкспериментирую на DirectionalLight (как самом простом варианте), потом добавлю уже остальные по готовому шаблону. Финальным аккордом по теме глобального света должна стать реализация объемного источника света (нужен для реализации физически корректного света от звезд)

Мир определяется рут объектом GameWorld, который хранит все объекты сцены, камеры итд.
Камер у сцен может быть сколь угодно много, но активной одномоментно (во всем движке) может быть только одна (дальше будет сделано исключение для RenderTarget камер, но это отдельно). При этом, сцена без активной камеры продолжит свою работу в фоне. Она продолжит тикать, обновляется, пересчитывается. Просто не будет выводится на экран.

Переключение камер происходит функцией Activate соответствующего Юнита.

При этом, если камера принадлежит другой сцене, то сцена так-же переключится.

Для закрытии самой темы материалов осталось реализовать только вставки пользовательского кода в скрипт материала. Думаю, завтра/послезавтра уже сделаю. SPIR-V контейнеры отложим в долгий ящик. Сейчас это явно не приоритет.

Следующий этап - класс камеры и юниты источников света (чтобы можно было начать полноценную работу над PBR)

Во первых: UBO требует в шейдере макетной структуры, и поля в ней не могут иметь инициализаторов, поэтому пришлось написать довольно массивный парсер параметров с утилизацией variant и type_identity

Во вторых: эта структура требует выравнивая данных, поэтому, уже на стороне движка пришлось делать особую уличную магию перегоняя сырой буфер в выровненный cогласно стандарту

В третьих: чтобы не пересоздавать UBO буфер каждый раз, пришлось высчитывать офсеты юниформов и хранить их отдельно в виде пары офсет-размер. Таким образом при изменении одного параметра, в GPU отправится только он.

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

В общем снова на очереди вычитка, удаление старого кода, правка нового. Что-то упростить можно, структуры собрать в одном месте, чтобы не были раскиданы по юнитам. Возможно, выбросить нафиг union, ибо от него сейчас пользы никакой уже, но зато сильно меньше удобства при обновлении переменной юниформа, или обертку над ним хотя бы сделать удобства для.

• При отрисовке, если на юнит выставлен инстанс, а не сам материал, проверяет в таблице инстанса по текстовой (!) метке наличие установленного параметра.

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

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

Но зато даже в таком виде оно работает.

Простенький примерчик:

Готовлю движок для внедрения инстансов материалов, чтобы максимально сократить кол-во переключений контекста шейдера (материал == шейдер). Возможно еще проведу оптимизацию по vao - собирая определенные меши в один длинный буфер (сейчас один буфер - один меш + лоды). Однако там есть нюанс с динамической выгрузкой сеток и пересчетом индексов и вообще там не все так очевидно, да и прирост по кадрам не то чтобы прямо большой. Я бы даже сказал не заметный. Т.ч. возможно это того и не стоит, т.к. функция glBindVertexArray всего-лишь перещёлкивает указатель на уже загруженный в GPU буфер. Подумаю, в общем, ибо сейчас это не горит.

Инстанс Материала

Особый класс, который можно создать как вручную, так и загрузив через заранее подготовленный ассет. Содержит перечень переменных со значениями для передачи через uniform шейдера. Привязывается к Материалу(шейдеру) и используется как надстройка над материалом для ускорения процедуры отрисовки.