Продолжаю улучшать редактор UI. Давненько хотел добавить возможность, выравнивания виджетов друг, относительно друга. Я называю эту фичу Snap Solver. На манер Решателей из CAD систем. Это не совсем оно конечно, но очень похоже. Технически, при перемещении виджета, или при изменении его размера, инструмент смотрит на соседние виджеты в иерархии и "примагничивает" границы по X и Y осям других виджетов, если таковые найдутся. Сейчас инструмент учитывает границу соседнего в иерархии виджета и его геометрический центр. В будущем, можно будет сделать еще и учет расстояния, выстраивая виджеты "паровозиком". Хотя для таких целей лучше подходят лэйауты, которые уже поддерживаются.

#thunderengine

Пару недель назад, я увлекся улучшение редактора графов. И как-то очень сильно у меня зашло это дело, что текущие изменения затронули уже порядка 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