Настало время подумать, над чем мне работать дальше. Вариантов очень много, а руки всего две.

1. Хотелось бы наконец позаниматься портированием рендара на Metal, что-бы вернуть в строй поддержку MacOS
2. Раз уж заговорили про RHI (Render Hardware Interface) было бы круто закрыть гештальт по Vulkan рендеру, который пылиться на отдельном бранче.
3. Есть мыслишки по расширению возможностей редактора и возможностям добавления различных визуальных инструментов для редактирования отдельных компонент (к примеру редактор кривых на сцене). Хотелось бы сделать что-то похожее на UX блендера где при нажатии на Tab, мы входим в режим редактирования объекта.
4. Хочу еще сделать вращалку вьюпорта как в блендере или как в 3dsMax (первый немного проще вроде)
5. Продолжить работать над VFX редактором (добавить новые модули/компоненты)
6. Очень интересна тема с процедурной генерацией контента
7. Хочется поддерживать блендшейпы и SkinnedSpriteRender (привет гештальт по Spine2D)

Пока хватит. Тем более пальцы на руке закончились!

Вчера, когда работал над интеграцией AngelScript для платформы HTML5, заметил, что скрипты довольно часто пользуются моей системой мета объектов. В частности, поиском мета объекта по его сигнатуре.

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

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

Сегодня я сделал этот маленький фикс. Вот такая маленькая история одного ченжа. Хэши это наше все!

Закрыл еще одну залежавшуюся фичу/рефакторинг.

Это новый способ менеджмента и поиска объектов по их ID.

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

Определенно, сегодня получился продуктивный день!

Сегодня закончил первую фичу из списка "хотелок" опубликованного ранее.

Представляю вашему вниманию навигационный кубик. Он поможет вам не заплутать в 3D пространстве ваших миров.

Давненько не радовал вас апдейтами. Все дело в том, что я обнаружил целую россыпь багов, появившуюся после недавнего рефакторинга системы учёта 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