Итак, продолжим разговоры о графене. Как и обещал, поговорим Forward и Differed rendering. Изначально весь рендеринг был forward. Но что это значит? Это значит, что для рисуемого объекта сразу просчитываются эффекты и освещение. В ранних версия OpenGL (в до шейдерную эпоху) источники освещения задавались прямо из API. OpenGL поддерживал до 8 источников на экране. Но, что делать, если нужно больше? И нужны более гибкие настройки источников? Вот тут мудрые разработчики и придумали Deferred Shading (навел справки: 1988 год). Смысл подхода заключается, в дополнительном проходе формирующим Geometry Buffer (G-Buffer) в котором содержится вся необходимая информация. А свет просчитывает Отложено в экранном пространстве учитывая информацию из G-Buffer. Таким образом мы получаем поддержку огромного количества источников света. Возможность делать пост обработку на типа SSLR и SSAO. Однако, у этого метода есть один существенный минус. Если мы рисуем полу прозрачную поверхность. В G-Buffer не поместится (адекватно) информация о поверхности, находящейся под прозрачной. Так же не работает дефолтный антиалиясинг. Плюс, G-Buffer занимает дополнительную память (уже не так критично сейчас). Проблему полупрозрачных поверхностей решили третьим проходом. На первом проходе рисуются непрозрачные объекты. Потом накладывается свет. А потом, через Forward Pass, рисуются полупрозрачные объекты с ограниченным количеством источников света, влияющих на них.

В для каких случаев подходит Forard, а для каких Deferred? Все очень просто. Если у вас мало динамических источников света (2D игры или простенькие 3Д игры со стилизованной графикой и малым количеством источников). Оптимальней использовать Forward если вы хотите море света то Deferred ваш выбор. Есть еще более продвинутые техники. Может быть когда-нибудь поговорим и о них.

Когда пишешь кроссплатформенный игровой движок. Всегда приходится смотреть на то, как поддерживается та, или иная фича графического API. Особенно это касается мобильных платформ. OpenGL ES очень аскетичен в этом плане. Вот так и сегодня. Только я хотел добавить поддержку Geometry Shaders. Как выяснилось, что они доступны только в ES 3.2. А это значит, что iOS платформа идет лесом. Так-же потенциально WebGL (когда-нибудь я до нее доберусь!). Похожая ситуация была и Shader Storage Buffer Objects на прошлой неделе. Похоже что, миграция на новые API становится все более актуальной =(

Простите. что давно ничего не писал. На данный момент я занят переработкой формата описания графов в редакторе. Хочу его сделать более читаемым для человеков. Так-же решил попробовать поучаствовать в Ludum Dare джеме с использованием своего движка. Надеюсь он не подкачает. Цель, сделать простенькую игру и выявить проблемные места.

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

Fixed:
Editor: "Local" property in particle editor is not saving #728
Editor: Add actor/component menu is not working in prefab #727
Editor: Areas on a Sprite are not saving #726
Editor: Infinite loading when import .wav file #725

ГОСПОДИ! Я сейчас поймал, наверное, самый странный баг, в своей жизни! Я убил добрых 2 часа на попытки понять, в чем же дело! В какой-то момент, у меня просто перестал загружаться один из плагинов редактора. Повторная сборка проекта с нуля не помогла. Откат на более старую версию кода тоже не помогал. Я проверил все зависимости библиотек. Проверил на срабатывания системы безопасности, которая могла блокировать загрузку. НИ-ЧЕ-ГО! Я уже начал сомневаться в своей адекватности и вере в человечество. И чисто, в приступе отчаяния, я убрал все Brake Point в дебагере. И оно ЗАРАБОТАЛО! Я не понимаю, как бряка роняла динамическую загрузку библиотеки! Но это факт!

Fixed:
Editor: Color constant is resetting in material editor #734
Editor: Deletion of Node in the MaterialEdit leads to crash #736
Audio: Sounds are not playing in the editor or in the game #738
Editor: Crash after relocating project assets #741
Editor: Project is not opening after creating new AngelBehaviour asset #744
Editor: Prefab window is not reopening after being closed #748

Выходные + понедельник выдались очень жаркими. Участвовал в составе команды в Ludum Dare гейм джеме. К сожалению, в последний момент, пришлось отказаться от использования собственного движка, из-за найденных проблем. Решили использовать Unity. Была проделана титаническая работа за эти 3 дня. Результат вы можете посмотреть тут.

Целую неделю работал над рефакторингом того, как рисуются объекты в движке. Инстансинг был у меня и ранее, но он был не удобен в поддержке, того как уникальные данные передавались в шейдер. Мне известны 3 относительно честных способа передать эти данные. 1. Через вершинные атрибуты (так было раньше). 2. Через Uniform буфер. (ограничение на размер). 3. Через текстуру (Требует большое количество семплов, что может замедлить работу). В конечном итоге я пошел по пути Uniform буферов. Этот метод используется в том числе и крупными движками. Ограничения в UBO 65536 байт на буфер. Если использовать минимум параметров в шейдере этого хватит на 1024 объекта на 1 вызов отрисовки (это максимум). Если параметров у шейдера будет больше, то это количество снизится. (в будущем при использовании SSBO на тех платформах которые его поддерживают это ограничение можно существенно увеличить). Была проведена колоссальная работа по рефакторингу. Переделан подход того, как в целом рисуется объект. Генератор шейдеров так-же, в очередной раз, был доработан. Теперь стало намного понятней как организовать автоматический инстансинг в игре!

После замечательного рефакторинга инстансинга в движке, наконец сложился пазл на счет поддержки автоматического инстансинга. Итак, сегодня я сделал первую версию поиска и группировки объектов, подходящих для объединения. Так-же вчера успел добавить поддержку SSBO буферов для десктоп платформ. В целом очень продуктивные выдались выходные!

Ох давненько я ничего сюда не писал. Все дело в том, что я последнее время занимался игровым проектом который мы вместе с ребятами продолжали делать после Людума. Времени на движок практически не оставалось. К сожалению в сутках слишком мало часов. Но вот я поехал в отпуск и решил позаниматься движком по грею брюхо. Купил себе макбук и наконец решил позаниматься его поддержкой.

Оказалось, что Qt поддерживает Apple Silicon только с 6 версии. И я потратил кучу времени на поддержку этой версии библиотеки. Я планировал в будущем отказаться полностью от Qt, но на данный момент, это не представляется возможным. Слишком много на него сейчас завязано. В связи с этим, эта работа кажется немного бесполезной. Хотя, вероятно, полный отказ займет год, минимум. Так, что, возможно Qt еще поживет в каком-то виде. От чего я действительно избавлюсь в первую очередь, так это от QML. Ненавижу блять QML

Основная проблема с портом на мак, это уставшая версия OpenGL. Современных штук в ней нет и рендер просто не инициализируются. Поэтому я пошел с козырей, и решил замахнутся на Metal. Сейчас я только пытаюсь его инициализировать и показать особо нечего. По первому впечатлению, он показался мне немного дружелюбней чем Vulkan. Странно что metal-cpp прослойка отказалась собираться в Qt Creator но прекрасно собирается в Xcode связано это было с типом шаблона класса по умолчанию. не кушал его Шланг. Возможно какие-то возможно надо было опции активировать было. Но я решил в лоб проблему просто явно прописав тип в исходниках

Кстати, как-то совсем буднично, прошла очень важная точка развития проекта. На GitHub количество звезд у репозитория перевалило за 500. Если вы когда нибудь пробовали развивать OSS, вы наверняка оценили это маленькое достижение! Cледующая цель 1000 звездочек.

Первые впечатления по Metal API. Вот уже с неделю в легком режиме изучаю этот RHI по вечерам. Готов поделится своими субьективными впечатлениями на его счет. В целом Metal хорош. Спасибо!

Теперь конкретней. Разумеется он заточен под Swift однако у него есть официальная обертка для работы из cpp называется cpp-metal. Собрал я ее с дополнительными приседаниями. Но возможно это проблема компилятора или Qbs которую я использую для сборки проектов.

Порог входа субъективно у него ниже чем в OpenGL. И он существенно проще в использовании чем Vulkan. Я правда еще не завел рендер на нем. Но портирование продвигается неплохо.

Пока немного коробит язык шейдеров в нем. Вершинные атрибуты передаются на манер dx в аргументах к main функции. Так же Apple напихали любимых ими квадратных скобок в синтаксис. Еще показалась странной возможность настроить семплинг из кода шейдера. Не привычно и скорее всего не буду использовать. Код шейдеров написанных мной на glsl был транслирован через spirv cross. На сколько качественно еще предстоит выяснить.

Но в целом мне нравится ООП подход в Metal.

Вот и подоспел новый релиз. К сожалению успел далеко не все, что запланировал по фичам, однако новый релиз содержит множество исправлений
https://github.com/thunder-engine/thunder/releases/tag/2024.3