Thunder Engine Development
35 subscribers
19 photos
13 links
Записки разработчика игрового движка. Чат канала @thunderengine_chat
Download Telegram
Пока занимался рефакторингом редактора, связанным с постепенным отказом от Qt. Я обратил внимание, что цикл, в котором происходит динамическое объединение объектов в группы, для последующей отрисовки, делает это каждый раз при вызове функции PipelineContext::drawRenderers. А это происходит несколько раз за кадр. Что приводит к многократному, бесполезному копированию, одних и тех-же данных. Надо бы этот момент оптимизировать. Чем я и займусь далее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Теперь вы можете:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#thunderengine #GameDev #VFX
1