Что-же сейчас происходит с движком? Хороший вопрос. Изначально я хотел поработать над редактором эффектов. Увести его из QML для начала. Однако, такая переработка потянула за собой другие зависимости. Стало очевидно, что необходимо доработать редактор графов. Что-бы показывать UI элементы в самих нодах. Это очень полезное нововведение, которое пригодиться не только в эффектах, но и в других редакторах. В процессе этого рефакторинга выяснилось что у UIKit, который в движке отвечает за весь игровой UI, и который и использую для некоторых редакторов, есть различные проблемы связанные с позиционированием некоторых виджетов в иерархии других виджетов. Исправление найденных проблем заняло практически 2 недели. И теперь я практически закончил рефакторинг редактора графов! Следующая остановка это редактор эффектов.

Отличная новость. Я наконец получил возможность подписывать свои релизы благодаря SignPath и их программе для программного обеспечения с открытым исходным кодом. Осталось только разобраться как встроить его в свой CI

Провел выходные за участием в Ludum Dare 56 на своем движке. Хакатон на данный момент еще не завершен. В месте с @tnnv_gamedev решили попробовать простенький проект в стиле Tower Defense. Он рисует, а я пишу код. В процессе работы над проектом, всплыло множество проблем. Некоторые удалось решить оперативно. А другие пополнили бэклог для решения в будущем. В целом, считаю опыт успешным. Такие мероприятия помогают взглянуть по новому на свой продукт. Я планирую закончить проект в любом случае, не зависимо от того уложимся мы или нет, и выложить его в свою библиотеку сэмплов.

Отличная новость. Я наконец прошел все проверки для возможности подписывать свои релизы. Теперь мой проект в ходит в список поддерживаемых компанией SignPath.
https://signpath.org/projects

Итак, сегодня замечательный повод, подвести итог эксперименту, по написанию игры для Ludum Dare джема. Да да я знаю что он прошел 3 недели назад =) но я не торопился. Для меня важно было зафиксировать как можно больше найденных проблем. Теперь-же делюсь небольшим видео игрового процесса. Игра в стиле Tower Defense. В целом эксперимент считаю удачным. Такие активности позволяют взглянуть на движок совершенно с другого ракурса. И выявить проблемы и найти новые идеи для работы.

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

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

Прошло уже больше месяца с момента моего последнего поста. Все это время я работал над пока не анонсированном крупным обновлением. Такого рода большие изменения, обычно, тянут за собой множество различных изменений поменьше, в самых разных местах. Итак, короткий дайджест изменений за прошлый месяц:
- Добавлен 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 для этой платформы. Я все еще ожидаю некоторых багов, которые буду оперативно чинить, но, в целом, все готово к использованию.

Я молодец! 💪