Дорожная карта разработки HollowEngine 🗺 | День 67

Наверное давно пора было это сделать, расписать планы на разработку движка. Что планируется добавить и в каком порядке. На текущий момент есть 5 больших глобальных обновлений: Релиз, Скриптинг, Катсцены, Геймплей, Модпаки и Визуал/Оптимизация.
Подпробнее про каждый из них расписал на сайте, советую ознакомиться!

Но если коротко:
2.0 = "Я могу поставить Виталика и помахать рукой".
2.1 = "Я могу написать код, чтобы Виталик прыгал".
2.2 = "Я могу снять кино про этого Виталика".
2.3 = "Виталик теперь может дать мне квест и набить морду".
2.4 = "Я могу сделать 100 уникальных Виталиков и построить для них город".

Вероятно, в будущем планы ещё могут меняться и перемещаться, но первые 2 блока и сами задачи уже определены 👀

Всё ещё работаю над синхронизацией компонентов 🍓| День 69

Пока что прогресс достаточно медленный, поскольку есть очень много моментов, которые стоит учесть:
1) Есть несколько разных подходов к синхронизации и я пока не могу определиться, какой будет эффективнее при большом количестве сущностей
2) В идеале мне нужно использовать подход, при котором компоненты можно будет добавлять через скрипты и без перезапусков
3) Эту систему нужно связать с другой системой из поста выше. Причём прикол в том, что через редактор ведь можно менять все компоненты, а не только синхронизируемые с клиентом 🙃
4) В будущем компоненты будут не только частью нпс или мобов, но смогут быть применены и для блоков с предметами, так что лучше сразу это учесть

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

Синхронизация компонентов теперь работает 🪨 | День 70

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

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

Синхронизация компонентов между измерениями ⌨️ | День 71

Доработал вчерашние проблемы, добавил синхронизацию и трекинг сущностей, теперь вроде всё работает как надо, осталось прикрутить сам редактор и префабы 👀

Думаю со дня на день уже новый билд в сообщество для тестирования отправлю 🙃

Оптимизация Minecraft или "Почему лагает даже на RTX 5090"? | День 73

Недавно я начал углубляться в тему рендеринга Vulkan (да и OpenGL), а также изучил подходы к рендерингу в популярных движках вроде Unity или Unreal Engine 5. В связи с этим хочу рассказать про подход Minecraft (да и Hytale в том числе). Пост большой и отношения к HollowEngine практически не имеет, но возможно кому-то будет интересно почитать :)

Думаю все заметили, что при 32 чанках уже начинаются просадки FPS, причём даже на топовом железе, которое легко тянет киберпанк в 165 fps, но Minecraft без теней, отражений, реалистичной воды едва-едва вывозит 80 кадров, но почему?
Прежде всего, при прогрузке мира все чанки упаковываются в уникальные VAO - это что-то вроде большого массива с вершинами, координатами текстур, цветом, освещением и т.п. После чего для каждого чанка вызваются команды вроде "Установить текущий VAO" и "Нарисовать текущий VAO". Вроде бы всё просто и логично? - Но в этом и заключается проблема, когда таких чанков 100-200 штук, это не так уж и страшно, но на деле их тысячи. И проблема даже не в том, что железо слабое. Проблема в том, что эти команды идут примерно по следующему пути: Java (JNI) -> OpenGL -> CPU -> GPU, то есть для каждого чанка приходится постоянно спамить от процессора к видеокарте по одной команде: "Нарисуй этот чанк". И даже если у тебя видеокарта легко справится с сотнями миллионов вершин, ей эти данные будут поступать такими маленькими группами, грубо говоря забивая шину.

И что же с этим делать и почему в других играх такой проблемы нет? - Прежде всего, в других играх всё куда проще, если в Minecraft нужно зарендерить город, видеокарта получает условные 500 команд "Нарисуй этот чанк", а в большинстве других игр это просто 1 команда "Нарисуй мне город целиком". Логично было бы сделать также в Minecraft, но тут возникает нюанс: в Minecraft вы легко можете сломать любой блок в мире, а в других играх - нет, максимум только некоторые допустимые объекты, вроде тех же деревьев. А после ломания блока придётся целиком обновить всю карту и отправить новую на GPU.

Но решения тут всё же есть, по сути их 2: LOD'ы и Indirect-рендеринг. Плюс их можно комбинировать между собой.
Про LOD'ы расскажу лишь кратко: они просто упрощают и объединяют те чанки, что находятся далеко от игрока, тем самым вместо того, чтобы рисовать 9 чанков, может быть нарисован всего один, но упрощённый. Игрок всё равно не заметит разницы, ведь он сильно далеко, но у такого подхода есть 2 больших минуса. Он требует очень много оперативки, ведь нужно хранить геометрию не только для обычных чанков, к тому же и сам мир приходится прогружать на тысячи блоков вперёд. А ещё перестраивать эти LOD'ы очень дорого, поскольку обычно есть где-то 6-8 уровней детализации и объединения нескольких чанков и получается - игрок сломал блок, и теперь придётся все эти LOD'ы строить заново. Тут конечно много хитрых ходов, огромные БД, генерация чанков на GPU и т.п. Но я сам в это дело пока не лез, так что строить теорий не буду.
Второй метод, Indirect-рендеринг, на деле куда интереснее: Вместо того, чтобы делать отдельный VAO под каждый чанк, создаётся один большой массив для всех прогруженных чанков и в этом массиве размечается пространство (грубо говоря, каждые 1024 байта - новый чанк), при добавлении новых чанков они записываются в этот массив и сохраняется индекс этого чанка в массиве, а при удалении этот индекс просто удаляется (при этом сам чанк может и дальше висеть в памяти, со временем его просто заменят другие чанки), а вместо 500 команд "Нарисуй мне этот чанк", создаётся всего одна: "Нарисуй мне объекты из {массив} с индексами [0, 1, 3, 6, 7, ...]".
Появляется логичный вопрос - моджанг нанимают на работу говнокодеров почему в Minecraft сразу так не сделали? А всё просто, такие возможности появились только в OpenGL 4.0, а Minecraft держит совместимость c 3.2 (он вышел в 2009), поэтому никакой оптимизации под современное железо там и не делают.
Разве что с одним уточнением - Sodium использует схожий подход, но с небольшими упрощениями (опять же, для совместимости).

Шейдеры и эффекты переходов между локациями ☂️| День 74

Пока тестировал систему шейдеров Kool сделал несколько интересных эффектов 👀
Думаю довольно интересно будет подобное использовать во всяких синематиках, правда придётся для подобных штук конфиги писать, но как будто не так страшно 🤔
Уже не просто затемнение экрана, как в Legacy, не так ли?)

https://www.youtube.com/watch?v=Swl5So71zYM