Некоторое время назад, перебирая графический пайплайн, я заметил у себя одну закономерность. Очистка 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

Докладываю недельный прогресс, по добавлению поддержки Metal.
1. Добавил поддержку рендер таргетов.
2. Рендеринг стейты тоже теперь доступны.
3. Рендер так-же работает в других окнах.

Итого 3 из 4 основных задач готовы.

Однако, в процессе работы вскрылись некоторые проблемы, которые предстоит починить:
- Смена размеров окна приводит к потере картинки (подозреваю, что это связано с инвалидацией текстур в рендер таргетах)
- Текст рисуется тоже странно - полагаю, что это так-же связано с изменением размера текстур.
- Не рисуются Frame объекты из UI пакета
- В отличии от BottomLeft координат, Metal использует TopLeft систему координат, что накладывает проблемы с ориентацией в рендер таргетах (некоторые слои рисуются перевернутыми)

Ну и все еще предстоит добавить чтение из текстур.

Очень надеюсь, что успею все починить к концу месяца.

#thunderengine

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

В API Metal их нет! Совсем нет. В принципе, когда я их добавлял в движок, я знал что они считаются устаревшими. Вместо них предлагается использовать Mesh шейдеры. Но их нет в старых версиях OpenGL которые используются в веб. Дилемма!

С другой стороны у меня пока нет юзкейсов на их использование. А у вас?

Небольшая рекомендация при работе с функциями dFdx и dFdy. Если вы используете их, для различных вычислений в экранном пространстве. Крайне рекомендую оборачивать их в abs функцию, что бы потом не чесать затылок как я. Эти функции могут возвращать отрицательные значения!

После разговора, с моим хорошим знакомым из студии FIFTYTWO, последние 2 недели обдумываю позиционирование своего движка в этом конкурентном мире.
Так-же размышляю о причинах провала "первого отечественного игрового движка NauEngine". На данный момент, я склоняюсь к мысли, что он был неправильно позиционирован, не нашел своего пользователя и благополучно слит во время финансовой оптимизации VK.

Но сколько таких проектов на просторах интернета? Очень много! Если вы откроете Гитхаб (https://github.com/topics/game-engine), то просто офигеете от их количества, разной степени популярности.
Как же не потонуть среди такого потока проектов? Ответ один, правильное позиционирование и поиск своей ниши!

Сейчас я пытаюсь анализировать (между подходами к портированию на MacOS) что отличает успешные проекты, от провальных. Что привлекает людей?
Я заметил, что многие провальные проекты слишком увлекаются графикой. Они бесконечно тратят время на совершенствование выдаваемой картинки. Некоторые даже упарываются в рейтрейсинг, забывая про основной аспект игрового движка...

Инструментарий! Если кто не знает, я пишу движок уже очень давно. Когда давно потухшие звезды были еще молодыми. Ладно не настолько. С самого начала я мечтал сделать успешный коммерческий движок, но потом Unreal Engine 4 вышел в OpenSource и просто покрыл весь мир.
Пришлось подстраиваться и тоже выпустить движок в открытое плавание. Но этого оказалось недостаточно. Нельзя построить стадион и ожидать что люди подтянуться (не помню откуда это). Поэтому я продолжаю думать о вероятной нише.

Что совершенно точно я не собираюсь делать, так это зацикливаться на графике. Много прекрасных игр, сделаны с достаточно примитивными моделями освещения. Маленькие студии (а я целюсь в маленьких). Не могут позволить себе высококлассный контент. Т.к. он стоит очень дорого. Графика уровня Super Mario Odyssey вполне меня устроит. Поэтому я фокусируюсь на удобстве инструментария и пытаюсь привлечь, кого-то для сотрудничества. Людей привлекают реализованные на движке игры!

#thunderengine

Продолжаю держать вас в курсе делиться с Вами впечатлениями от использования Metal.

Вот уже 3 недели я активно разрабатываю с использованием Metal. После определённых неудобств в использовании, связанных скорее с недостатком опыта работы, я могу с уверенностью сказать, что это прекрасный API для работы с графикой!

Metal по своей сути очень похож на Vulkan, только с меньшим количеством заморочек с управлением памятью. Я бы поместил Metal по сложности освоения между OpenGL и Vulkan.

Столь стремительное портирование функционала на Metal, мне обеспечила база написанная на Vulkan. Получился очень похожий код, только компактней и стабильней.

Могу ли я рекомендовать Metal для освоения? Если вы работаете с MacOS или iOS однозначно да! Так-же, это прекрасным стартом, для работы с современной графикой!

#thunderengine

Я долго к этому шел и наконец это случалось. Дамы и господа, MacOS вернулся в поддерживаемые платформы.

Теперь рендер использует Metal API для отрисовки картинки!

К сожалению, с иконками возникла заминка, но она скорее связана с необходимостью переделки механизма создания иконок, чем с проблемами с Metal.

#thunderengine

Решил немного расслабиться на этой неделе и практически не писал код движка.

Однако, это не означает что я его совсем не писал. Сейчас я перерабатываю макросы, для работы с интроспекцией. A_REGISTER и A_OVERRIDE макросы будут убраны на этой неделе.

Вместо них можно будет будет использовать A_OBJECT и A_OBJECT_OVERRIDE. Сделано это с одной простой целью, сделать различие между классами основанными на классе Object и другими классами.

Да да я хочу добавить возможность делать интроспекцию и для классов не основанных на классе Object. Макрос для таких классов будет называться A_GENERIC. Так-же хочу попробовать сделать возможность добавлять в интроспекцию, конструкторы с параметрами.

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

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

Дамы и господа представляю вашему вниманию сетевой модуль! Пока модуль очень простой и содержит в себе всего одну сущность.

WebRequest - это по сути http запрос, который позволяет разработчику обратиться к web серверу для приема и отправки абстрактных данных. WebRequest поддерживает пока только get запрос, но у меня есть в планах, добавить и post запросы если будет спрос на них. Так-же модуль поддерживает SSL соединения, так, что можно обращаться по протоколу https.

Продуктивные выдались выходные.

#thunderengine

Я давненько присматриваю замену QBS для компиляции игровых бинарный файлов. Текущая ситуация меня не страивает по нескольким причинам:

1. Я регулярно сталкиваюсь с тем, что QBS отказывается строиться из исходников на CI. Сейчас я вообще вынужден убрать его из релизов (в замен предлагается использовать QBS из более старых релизов).
2. Сам QBS довольно избыточен, для построения простых игровых бинарей. Он как швейцарский нож, очень многое умеет, но на финальной стадии постройки используется очень ограниченный функционал.
3. Исходя из второго пункта, QBS тащит за собой огромное количество разных вспомогательных файлов, что противоречит моей идеологии о компактности, раздувая редактор дополнительным мусором, который не используется, но требуется "на всякий случай".

Относительно давно я положил глаз на Ninja. Это компактная система сборки состоящая всего из одного бинарного файла. Из его плюсов:
1. Компактный.
2. Кроссплатформенный (Windows, Linux, MacOS)
3. Довольно простой файл для сборки

Однако есть и один минус! В отличии от QBS в Ninja нет генератора проектов для IDE. Но это в принципе решаемо, написанием своего генератора проектов. Нужно будет выделить время в след цикле разработки на исследование этого инструмента.

#thunderengine

Скоро конец квартала, а это значит, что настает пора релизов.

Встречайте новый релиз Thunder Engine!

В этом релизе добавилось много интересных штук, таких как:
- Поддержка HTML5 платформы. Теперь вы можете делать игры под веб.
- Вернулась поддержка MacOS.
- Улучшен графический пайплайн. Графика стала лучше! Хотя казалось бы куда уже лучше? =)
- Добавлена возможность обращаться к Web серверу (пока только для десктоп платформ)

Полный список вы можете найти тут.

#thunderengine

С момента релиза прошло уже больше месяца. И все это время я не делал новых постов. Каюсь!

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

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

Я никуда не пропал. Работа над движком продолжается.