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

#thunderengine

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

#thunderengine

Вот, наконец и подошел момент релиза версии 2025.3. В этой версии, я сфокусировался на исправлении, найденных мной, ошибок в различных редакторах ассетов (в основном UI Editor). Так-же я постарался улучшить пользовательский опыт (Copy/Paste), при использовании редактора. Новых фичей я завез совсем немного и они, по большей части, касаются низкого уровня. С полным списком изменений вы можете ознакомится здесь: https://github.com/thunder-engine/thunder/releases/tag/2025.3

#thunderengine

Продолжаю делать глобальные рефакторинги. Сегодня у нас на очереди работа со строками. Раньше я использовал std::string тип, для взаимодействия с текстовыми данными. Но он не всегда удобен, когда нужно сделать более сложные вещи, типа разделения, поиска или замены. Я решил написать аналог QString и не стал сильно заморачиваться, назвав его просто String. У него пока не так много фичей, как у оригинала, но на первое время хватит. Самое муторное было заменить все строки движка с std::string на String. Уверен, что баги вылавливать буду еще некоторое время. Но это глобальное изменение давно назрело.

#thunderengine

Пока занимался рефакторингом редактора, связанным с постепенным отказом от Qt. Я обратил внимание, что цикл, в котором происходит динамическое объединение объектов в группы, для последующей отрисовки, делает это каждый раз при вызове функции PipelineContext::drawRenderers. А это происходит несколько раз за кадр. Что приводит к многократному, бесполезному копированию, одних и тех-же данных. Надо бы этот момент оптимизировать. Чем я и займусь далее.

#thunderengine

Хотел ответить в комментариях, но решил сделать отдельным постом.
На самом деле там назрел небольшой рефакторинг, т.к. технический долг начинает давить. Некоторые моменты я просто решил убрать. К примеру у Actor больше не будет понятия "Слой" он переехал в Material. т.к, по большому счету, он использовался только там. И у Renderable может быть больше одного материала со своими личными настройками. Так-же, теперь, Renderable компонента может возвращать больше одного меша для отрисовки. Теперь каждому материалу можно будет назначить свой, индивидуальный меш, что позволит делать более сложные компоненты. Первый кандидат на это EffectRender.

#thunderengine

🌍 Куда делся ландшафт в Thunder Engine?

Если вы работали с Thunder Engine, то наверняка заметили: в нём нет поддержки ландшафта. "Как так?!" — спросите вы. Ведь даже в простых движках он есть!

И будете правы — когда-то он и у меня был. Но 5 лет назад, во время большого переписывания, Terrain просто… не попал в список поддерживаемых компонентов.

Почему? Потому что я хотел реализовать масштабные пространства — а без чанкинга тут не обойтись.

Иногда я снова задумываюсь о добавлении этой системы, но каждый раз упираюсь в сложности:
🔹 Обработка и хранение чанков
🔹 Удобство работы в редакторе
🔹 Формат данных, который пока далёк от идеала

Я изучил, как с этим справляются Unreal Engine и Unity, и понял: работы — целая гора.

Вопрос в другом: а нужно ли это вам? Стоит ли тратить время на ландшафты, или лучше сфокусироваться на других фичах?

Пишите в комментариях! 🚀

#thunderengine

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

Люблю проактивность. 🚀

#thunderengine

🔥 Частицы в Thunder Engine стали ещё круче!

Сегодняшние улучшения принесли две мощные фичи:

✨ Поддержка SubUV
✨ Анимация SubUV

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

Что ещё улучшено:
🔹 Исправлены баги в системе частиц
🔹 Пофикшены несколько крэшей
🔹 Полностью переработан вершинный шейдер Billboard

Теперь для анимации из атласов достаточно всего одного vec3 из инстанс-буфера!

Эти изменения сделают ваши визуальные эффекты более живыми и гибкими. Как вам такие апдейты? 💬

#thunderengine #GameDev #VFX

💭 Немного размышлений на тему визуальных эффектов.

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

На данный момент есть 2 класса отвечающие за визуальные эффекты в движке:
🔹 VisualEffect - это ресурс, в котором находятся все параметры и команды, отвечающие за поведение ваших частиц на сцене.
🔹 EffectRender - это компонент, который отвечает за проигрывание эффекта, его можно разместить непосредственно на сцене и назначить ему VisualEffect.

Итак мы разобрались с вводными.

А вот теперь, вам, предположим, нужно создать эффект костра. В котором должны быть:
1. Пламя
2. Дым
3. Искры (опционально)
4. Можно еще дисторшен от температуры добавить (опционально)

Совершенно очевидно, что это все разные эффекты, объединённые в одну систему.

Возникает закономерный архитектурный вопрос. Если у нас 4 разных эффекта, может объединить их в одну систему?

Вариант 1: Единая система

Можно переименовать:
VisualEffect → EffectEmitter (отвечает за отдельные эффекты)
Создать новый VisualEffect как контейнер для нескольких синхронизированных эмиттеров

Плюсы:
✔️ Есть центральный ресурс объединяющий разные эмиттеры и даже возможно их синхронизирующий.

Минусы:
⚠️ Предстоит рефакторинг с переименованием, что может привести к поломке существующих ассетов.
⚠️ Если мы захотим новую комбинацию эффектов, нам придется создать новый отдельный VisualEffect. Если помним, то EffectEmitter все еще хранится отдельно.
⚠️ Если в VisualEffect будет содержать всего один EffectEmitter, это все еще 2 ресурса к загрузке.

Вариант 2: Оставить как есть

Просто размещать несколько компонентов EffectRender и объединять их в префаб

Плюсы:
✔️ Не надо ничего менять, все работает как сейчас.

Минусы:
⚠️ Нам придется объединить наш пресловутый костер в префаб.
⚠️ Возможно нужно будет как-то синхронизировать состояния эмиттеров с помощью дополнительных компонент.

Какой вариант вам кажется более удобным?

#thunderengine #GameDev #VFX