Мелочь, а приятно! Давно хотел добавить цветовую дифференциацию штанов осей координат. Мне очень нравилось как это сделано в блендере. Теперь такие оси есть и в моем редакторе. Так-же потратил какую-то прорву времени на исправление отображения редактора графов. Теперь масштабирование будет работать корректно.

Давненько меня раздражал баг с антиалиясингом. Изображения получались с одной стороны зубастыми. Теперь это в прошлом. Слева "До" и справа "После". В будущем можно еще попробовать поиграться с под пиксельными значениями.

Прошло уже больше месяца с момента моего последнего поста. Все это время я работал над пока не анонсированном крупным обновлением. Такого рода большие изменения, обычно, тянут за собой множество различных изменений поменьше, в самых разных местах. Итак, короткий дайджест изменений за прошлый месяц:
- Добавлен CheckBox виджет в UI модуль.
- Добавлен Foldout виджет в UI модуль.
- Немного переработан Frame виджет в UI модуле. Теперь он использует стандартный меш Plane для своей отрисовки (раньше каждый раз создавался отдельный меш)
- Глобальный рефакторинг модели данных отвечающих за отображения свойств объектов на сцене.
- Крупный рефакторинг редактора графов. Теперь нодам позволено определять как они будут выглядеть.
- Так-же доработана система сериализации графов. Теперь ноды сами определяют какую информацию они хотят сохранить.
- Наконец исправил проблему с рандомным крашем связанным с двойной попыткой блокировки мьютекса в базовом Object

To be continued...

Eще, я бы хотел остановиться на одной баге чуточку подробней. Я давно пытался победить низкое качество рендеринга текста у себя. Я работаю с SDF атласами глифов для отображения текста. На больших символах проблема незаметна, проблемы начинались когда текст должен быть мелким. Теперь, мне кажется, мне удалось немного улучшить ситуацию. На скрине До и После. Размер шрифта здесь 6px для строчной.

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

Итак представляю вашему вниманию обновленную и переработанную систему частиц. 🔥
В чем же ее отличие спросите вы? Если коротко, она полностью переделана!

Итак расскажу как было раньше:
1. Система частиц хранилась в специальном ресурсе ParticleEffect.
2. У каждого ParticleEffect был список модификаторов определяющий поведение частиц. (Цвет, Скорость, Положение)
3. Так-же был ParticleRender компонент отвечающий за отрисовку инстанса ParticleEffect.
4. Еще был редактор похожий на анрыловский Cascade написанный на QML.

Вроде выглядит все не плохо? В целом да, но есть проблема в расширении возможностей поведения частиц!
Каждый раз когда мне необходимо добавить новый паттерн поведения, мне нужно лезть в код что-бы:
1. Добавить новый модификатор.
2. Добавить сериализацию для нового модификатора.
3. Добавить поддержку модификатора в редактор.

Так-же были определенные проблемы с перфом т.к. объект Модификатора применялся для каждой частицы.
Ну и т.к. я решил постепенно отказываться от QML, мне необходимо было перетащить редактор на что-то другое.

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

Итак, я описал систему в текущей версии движка. В следующем посте я опишу обновленную систему и то, как я решил текущие ограничения.

А теперь расскажу, что было сделано в новой системе.

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

Как уже было сказано ранее, данные частицы хранились в отдельной структуре, которая была довольно неповоротлива в обслуживании и расширении.
Что, если мне не нужны какие то данные для эффекта или мне нужно добавить новые поля для хранения?
Я обратил внимание на то, что структура по своей сути состоит из набора float и vec различной размерности (vec2, vec3, vec4).
И тут меня осенило! А что если сделать плоский буфер float значений. У этого подхода есть ряд очевидных плюсов:
1. Структура может быть подвижной! Мы можем не задумываться какие данные мы хотим там хранить!
2. Очень плотное выравнивание! Нет больше проблем с выравниванием памяти в структуре. Все данные будут храниться очень плотно, что положительно скажется на потреблении и скорости доступа к данным.
3. Буфер передаваемый в GPU тоже состоит из набора float'ов, а значит все это можно унифицировать.

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

А дальше Остапа понесло! В следующем посте я расскажу, как переделал систему модификаторов исходя из новой формы хранения данных.

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

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

Ранее изменение атрибутов производилось с помощью специальных сущностей "ParticleModificator". Теперь их больше нет. Долой теранию Модификаторов! Всю власть Операторам!

Так стоп! Скажите вы, "Что за Операторы? И в чем разница?" Все очень просто!

Раньше как выглядел пайплайн. Мы передавали структуру частицы в каскад модификаторов. Модификатор, как правило, производил очень простую операцию.
Скажем:

position += velocity * deltaTime

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

Теперь же сама суть действия:

position += velocity * deltaTime

Может быть разделена на 2 операции:

1. local = velocity * deltaTime
2. position = position + local

Эти 2 операции легко сериализуются как:
1. Тип операции
2. Набор из двух аргументов над которыми будет произведена операция (тут могут быть разные области откуда берутся данные для аргументов)
3. И оффсет куда нужно положить результат.

Вот и все! Почти ассемблерные инструкции! Редактор формирует цепочки таких Операторов на исполнение и сериализует его в новый вид ресурса VisualEffect бывший ParticleEffect.

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

Самое интересное, что этот подход позволяет обновлять состояние не только частиц но и самого эмиттера, а так-же формировать компактные буферы для отправления на GPU

Так-же, очень приятным бонусом будет возможность без проблем сформировать Compute Shader, что позволит, в будущем, делать симуляцию частиц на GPU (там где это возможно).

Итак, это последний пост из серии, посвященной обновленной системе частиц.

В этой части я бы хотел поговорить о редакторе. Как я уже говорил ранее, я отказываюсь от QML. Поэтому я решил попробовать свой UI Framework для этой цели. Благо, у меня уже был опыт по созданию редактора графов на нем.

За основу был взят UI/UX редактора эффектов Niagara из UE5. Разумеется, их редактор имеет гораздо больше возможностей, чем мой на старте. Однако, я пока только в начале пути.

Формат хранения ассета это переработанный и дополненный формат хранения графов. XML формат обеспечивает компактное и VCS friendly представление.

Так-же как и в редакторе материалов, в редакторе эффектов есть возможность создавать кастомные блоки для добавления в редактор (То-же XML).

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

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

Ни для кого не секрет, что поиск по хэшу происходит намного быстрей. Соответственно очень важна консистентность. Бага заключалась в том, что я при конвертации ассетов на Windows сохранял хэши в файл, а потом их загружал в webassembly.

Потом же я обращался к кэшу через хэширование строки уже на стороне webassembly. Из за различий в реализации функции хэширования, значения созданные на Windows не совпадали со значениями созданными на Webassembly, из за этого движок не мог найти нужный ресурс.

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

Обнаружил довольно большой пласт проблем связанный с мобильными платформами. Постараюсь решить все найденные проблемы до релиза.

Как считаете, следует ли рассказывать о багах в этом канале?

Друзья! Итак, свершилось. Новый и по совместительству первый релиз в этом году!
https://github.com/thunder-engine/thunder/releases/tag/2025.1

Когда работаешь с несколькими платформами, неизбежно возникают различные несовместимости в пользовательском опыте.

Для работы с мобильными устройства я давно использую библиотеку GLFM. Она облегчает рутинные задачи, типа создания окна, обработку ввода пользователя и некоторые другие полезности.

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

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

А еще хорошая новость в том, что звук на html5 платформе завелся из коробки. И даже не пришлось ничего дописывать!

По факту платформа очень близка в драфт релизу. И скорее всего войдет в релиз 2025,2

Итак, сегодня закончилась (практически) эпопея с одним из старейших тикетов #18 аж от 2018 года!

Целых 7 лет назад я принципиально решил добавить поддержку платформы HTML5. Эта поддержка откладывалась множество раз, т.к. требовала внедрения иной билд процедуры, на основе CMake. И вот в прошлом году я наконец добавил CMake скрипты, что позволило начать портировать движок на HTML5.

Я потратил на это около двух недель. И, в целом, доволен результатом! Рендер работает, физика, музыка и логика тоже работают штатно!

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

На текущий момент платформа находится в драфт версии. Это значит что билд с ее поддержкой можно скачать с CI/CD. Позже она появится в уже официальных релизах начиная с 2025.2 версии.

Вот и подошла к концу эпопея, связанная с HTML5/WebGL (до сих пор не определился как ее называть).

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

Я молодец! 💪

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

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 или объекты. Можно генерировать различную геометрию с использованием сплайнов в качестве основы.

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

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