Давненько не радовал вас апдейтами. Все дело в том, что я обнаружил целую россыпь багов, появившуюся после недавнего рефакторинга системы учёта ID объектов.

Проблемы в основном были связаны с жизненным циклом префабов и сцен. Сейчас система стала стабильней. Все известные мне баги связанные с ней я поправил. Но, вероятно, могут оставаться "неизвестные".

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

Как и обещал, рассказываю о новой фиче. Теперь разработчикам доступны Сплайны!

Слышны звуки бурных оваций с переходом к всеобщему ликованию!

Зачем нужны сплайны? Сплайны на сценах могут быть использованы с различными целями. Можно генерировать пути по которым двигаются ваши NPC или объекты. Можно генерировать различную геометрию с использованием сплайнов в качестве основы.

Короче супер полезная штука для ваших игр!

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

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

Чувствуешь это запах? Это запах рефакторинга сынок. Обожаю запах рефакторинга по утру.

1. Я добавил возможность инструментам (EditorTool) определять с какой компонентой они могут работать. Теперь при выборе актора редактор сам определяет список инструментов и показывает их кнопки над вьюпортом.
2. Теперь инструменты могут иметь свои дополнительные настройки и кнопки! Смотрите скриншот. Для этого я немного изменил расположение основных контролов, сдвинув их вправо.
3. Некоторую логику работы с акторами пришлось изолировать в старые, базовые инструменты. Что бы попытка удалить точку на сплайне не приводила к удалению всего объекта целиком. То-же самое касается и выбора других объектов.
Очень доволен модификацией. Получилось супер гибко и расширяемо!

Астрологи объявили неделю Вулкана. Количество ошибок валидации увеличилось вдвое.

Пока работал над вулкановским рендером, столкнулся с необходимостью пересмотреть некоторые свои концепты хранения инстансов, а так же необходимость инвалидировать некоторые ресурсы.

Процесс этот будет не быстрым. За неделю не управиться. Откладываю релиз вулкана еще на некоторое время. Постепенно буду менять пайплайн, что-бы соответствовать.

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

Дамы и господа! Я завез вулкан рендер в качестве developer preview фичи.🔥

Вот список известных мне проблем:
- GPU Инстансинг иногда приводит к крешу, связанному с обновлением общего буфера для юниформ переменных
- Иконки не рендерятся
- Shader Graph материал выдает ошибки для Visibility шейдера
- Возможны другие ошибки валидации

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

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

#thunderengine

Еще одна визуальная фича заезжает в графический пайплайн.

Корректировка яркости - позволяет преобразовать HDR цветовое пространство в LDR. Без ее использования расширенный цветовой диапазон отрезается до диапазона 0-1 (0-255) и могут потеряться некоторые детали. Тонмапинг немного сжимает диапазон позволяя сохранить больше деталей.

Так-же теперь движок поддерживает базовую цветокоррекцию основанную на Color Grading LUT. Данная фича позволяет художнику контролировать и подстраивать цветовое пространство и настроение сцены под свои нужды. Пример вы можете наблюдать на скриншоте.

#thunderengine

Внезапное прозрение. Формат текстур RGB10A2, который, как я думал, является HDR форматом, оказывается, таковым не является. Хотите хранить значения больше пространства 0...1 используйте форматы с плавающей точкой. К примеру RGBA16Float, который теперь будет использоваться у меня для Emissive буфера.

#thunderengine

Вот уже как пару недель я продолжаю ковырять графический пайплайн. Сегодня у нас на очереди эффект Depth of Field. Другими словами Глубина Резкости.

Этот эффект симулирует поведение камеры при максимально открытой диафрагме. Либо человека с очень плохим зрением.

Обратите внимание, что присутствует даже эффект Боке на источниках освещения. Радует то, что удалось все это запихнуть в один фрагментный шейдер. А значит оно будет доступно даже на простых устройствах (возможно с некоторыми изменениями в шейдере).

#thunderengine

Некоторое время назад, перебирая графический пайплайн, я заметил у себя одну закономерность. Очистка Render Target практически всегда идет за подключением этого самого Render Target.

Примерно так:

buffer->setRenderTarget(shadowTarget);
buffer->clearRenderTarget();

Более того, я помню, что в Vulkan можно было очищать буфер в момент его подключения. Без необходимости вызова дополнительных команд. И тут возникла мысль добавить в класс RenderTarget опции, определяющие поведение при его подключении. Посмотрел в UE5 и понял, что они делают примерно то-же самое.

Значит и мне нужен подобный рефакторинг. Сегодня, потратив совсем немного времени, запилил это удобство к себе. Теперь стратегия очистки определяется на стадии инициализации с помощью метода RenderTarget::setClearFlags. Так-же добавлена возможность определять регион очистки с помощью RenderTarget::setClearRegion (возможно переименую потом в setDrawRegion).

#thunderengine

Важнейшей новостью уходящей недели, по моему мнению, является новость о том, что VK передает разработку NauEngine в руки "сообщества". Курировать разработку будет Университет ИТМО.

Новость максимально странная, хоть и не неожиданная. Движок NauEngine был выложен в открытый доступ в конце прошлого года. С тех пор он ни разу не обновлялся в публичном репозитории. Работа с комьюнити так-же не осуществлялась. За это время был принят всего ОДИН Pull Request. Связанный с исправлением ошибок в Readme файле.

Разработчики не отвечали на создаваемые сообществом issues. Рост сообщества так же, на мой взгляд, был медленным. Всего порядка 320 звезд на момент публикации в репозитории и 45 форков.

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

Я подозреваю, что передача проекта в руки сообщества, означает сворачивание финансирования разработки со стороны VK. Развитие сообщества вокруг проекта с открытым исходным кодом, является важнейшей частью развития этого проекта. Работы с сообществом нет, развития тоже не будет.

Одно радует, это подтверждение мысли о том, что не все можно залить деньгами.

#nauengine

Сегодня наконец замержил довольно старый Pull Request добавляющий возможность собирать редактор с использованием библиотеки Qt6. В новой, мажорной версии Qt были убраны различные методы и классы с пометкой Deprecated, что привело к необходимости доработать код на своей стороне.

Зато теперь редактор собирается и запускается на MacOS с процессором ARM (M серии). Картинку правда пока не выдает, т.к. Apple остановили поддержку OpenGL на версии 4.3 если не ошибаюсь. Для картинки теперь нужна поддержка Metal, над которой я работаю время от времени.

Когда я только начинал изучать Metal (графический API от Apple), я виден много общего с Vulkan. И мне это нравилось. Местами он был проще в использовании чем Vulkan.

Спустя некоторое время, я начал замечать некоторые странности в API. Вот пример из жизни (сильно упрощенный):

MTL::RenderPipelineDescriptor* renderPipelineDescriptor;
....
renderPipelineDescriptor->colorAttachments()->object(0)->setPixelFormat(pixelFormat);

Класс RenderPipelineDescriptor используется для создания RenderPipelineState. Главного объекта отвечающего за отрисовку конкретного меша. Именно к нему крепятся шейдеры и различные настройки графического конвейера.
Совершенно не понятно зачем мне крепить к нему pixel format для аттачментов отдельно для каждого. В Vulkan я просто отдавал сам VkRenderPass ему и он там сам разбирался с форматом пикселеля.
Но с этим еще можно жить. Самый треш начался с вершинными атрибутами...

Продолжаем нытье про Metal. Итак, RenderPipelineState должен иметь представление о поступающих вершинных атрибутах, что в общем-то логично. Ведь пайплайн должен знать оффсеты и индексы буферов в которых содержатся данные о вершинах рисуемой модели. Разработчик может хранить атрибуты разными способами. Есть несколько типичных схем:
1. Буфер < Позиция, UV, Normals; Позиция, UV, Normals; Позиция, UV, Normals и так далее
2. Буфер < Позиция, Позиция, Позиция; UV, UV, UV; Normals, Normals, Normals
3. Вариант похож на второй только каждый атрибут храним в отдельном буфере.

Я всегда предпочитал второй вариант. По причине того, что желательно хранить позицию отдельно от остальных атрибутов, на случай если вам понадобится построить BVH. Такой способ был ОК в Vulkan т.к. офсеты атрибутов можно передавать отдельно, не связывая его с пайплайном. Таким образом, можно отделять саму геометрию от пайплайна который ее рисует. Можно поменять рисуемый меш прямо на рантайме. В Metal можно тоже поменять. Но офсеты нужно подать заранее,при создании пайплайна. А в случае второго варианта, вам, для вычисления офсетов, обязательно знать количество вершин в буфере. В этом заключается основное неудобство, над котором мне предстоит подумать.

Каждый раз когда я начинаю работать над поддержкой нового графического API, я начинаю с простейшей задачи. Что может быть проще прямоугольника с наложенным шейдером? Так и сегодня я наконец вывел требуемый прямоугольник с использованием Metal API и стал на один шаг ближе к возвращению поддержки MacOS. Еще предстоит многое сделать и, возможно, переделать, но начало положено!

#thunderengine

Следующими двумя шагами в портировании графического пайплайна на Metal, были добавление поддержки текстур и добавление поддержки параметров для Материалов. На скриншоте вы можете видеть работу шейдера, который окрасил текстуру в красный цвет (цвет задается из параметра) и со сдвигом UV координат, на основе таймера. Еще 2 маленьких шага на пути к мировому господству в тайне от санитаров!

#thunderengine

Немного о том, какие шаги еще предстоит сделать, что-бы выпустить поддержку metal в релиз?
1. Поддержка рендер таргетов - это буферы в которые производится отрисовка промежуточных результатов.
2. Поддержка рендеринг стейтов (настройки смешивания, теста глубины и пр.)
3. Чтение из GPU текстур в CPU память - нужно что бы можно было выделять объекты и рендерить иконки в редакторе
4. Проверка работы рендера в других окнах отличных от главного (редактор материалов как пример)

После этого поддержку Metal можно будет выпускать в Draft Release и править возможные баги

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

Но как обстоят дела на MacOS. Все очень не просто. У разработчика нет внешнего инструментария позволяющего подключиться к процессу и "тормознуть кадр" для отладки.

Однако, не все так плохо, купертиновцы позаботились об API профилировщка внутри самого Metal. Условно говоря, вы вызываете специальные функции в начале и в конце профилируемого кадра, а Metal записывает все в специальный буфер и позволяет сохранить дамп на диск. Далее с помощью XCode можно открыть дамп и проанализировать что происходило во время отрисовки. Пример вы можете видеть на скриншоте.

Удобно ли оно? В целом да! Глючно ли оно? Тоже да! Но это точно лучше чем ничего!

#thunderengine