Ну вот, пришло время написать первый пост по игре, над которой я работаю уже достаточно много времени.
Что за игра, в каком жанре, чем отличается и многие другие моменты будут описаны чуточку позже. А пока, делюсь результатами по первой фиче, которую вообще можно показать (а не только рассказать про код, технологии и фреймворки 😄).
Я наконец-то реализовала возможность изменять ландшафт, что позволяет, например, вырыть пещерку (ура! 💃)

Комментарии открыла, должно работать, но к старым постам это не относится :( Но можете и под этим оставить 💃

Также присоединяйтесь к чату этой группы https://t.me/+P2tyt0x2ccI4M2Zi (в шапке канала ссылка на чат также есть). Там можно в том числе и мне задавать вопросы 🥔

Меня в комментариях спрашивали, на чем базируется копание ландшафта, поэтому я решила немного рассказать о своем фреймворке прежде, чем начну вести сами дневники разработки по текущим задачам.

Я не использую уже готовые решения по той причине, что они или медленные или совсем не гибкие, а для реализации моих идей нужно и то и то) Я также не использую стандартный ландшафт от Unity, так как это совсем не про бесконечную бесшовную генерацию. По этой причине я решила написать свое решение.

С самого начала я определилась с некоторыми технологиями, которые буду использовать - Jobs + Burst. Эта связка дает слишком много, чтобы не быть использованной. Но, по ходу моих постов, вы скорее всего задатитесь вопрос: "А почему не GPGPU?". И ответ тут не так уж чтобы и простой. Одна из итераций у меня была на Compute Shaders, результаты по производительности впечатляющие, пока не начинаешь передавать данные (сгенерированные меши) с GPU на CPU. А это необходимо хотя бы в рамках построения физических коллайдеров. Также, вычислительные шейдеры - это не про гибкость, хотя часть моментов, например граф генерации шума, можно решить через кодогенерацию. Но я же вроде бы игру делаю, а не инструмент под Unity? 👏

Другая часть технического стэка была выбрана по ходу исследований и множества итераций. Если Jobs + Burst я использую для генерации, то что для представления?
С самого начала я думала использовать подход ECS, уж очень он гибкий по сравнению с классическим ООП. Но какой фреймворк взять? Вначале я взяла Leo ECS Lite (не реклама), с которым я раннее работала и который мне очень понравился своей простотой. Но потом, когда я изучала BRG и интегрировала его к себе в проект, мне подсказали, что UECS из пакета DOTS, вполне себе уже используемый (все мы знаем про UECS, да? 🤪). И я, соблазнившись избавлением от GameObject, получением BRG из коробки для всего, что я захочу отрисовать, перешла на него. Хотя тот же BRG все равно использую в задачах, где даже entity можно не создавать.

Еще работая "на дядю" я мечтала, что не буду использовать uGUI (не буду рассказывать почему, подозреваю, что вы и так знаете), а возьму что-нибудь WPF-like. Поэтому в своей игре я сразу сделала ставку на NoesisGUI - WPF-like фреймворк с MVVM из коробки. Сейчас конечно уже появился UIToolkit, и даже с нормальными биндингами (те, которые runtime), но хотелось более мощное решение. Кстати, Baldur's Gate 3 тоже использует NoesisGUI ☺️.

Что касается сетевой части (да-да, она уже в каком-то виде даже есть, и изменение ландшафта синхронизируется между сервером и клиентами), выбора у меня было немного, раз я на UECS - Netcode for Entities. Авторитарный сервер (вместо p2p) конечно усложняет жизнь, но примеров достаточно, а также есть доброжелательное комьюнити. О том, как я решила задачу синхронизации ландшафта (как генерации так и изменения) я опишу чуть позже 🫥

Итого, мой основной технический стэк выглядит вот так:
- Unity
- DOTS (Jobs, Burst, UECS, BRG)
- Netcode for Entities
- NoesisGUI

Генерация. Шум

Продолжаю рассказывать про генерацию, и прежде чем перейти к генерации геометрии, наверное стоит рассказать про шум. Тем более тут есть что показать интересного)

Для воксельных миров подойдет любой непрерывный шум. Это может быть всеми известный шум Перлина, или какой-нибудь Simplex. Хотя подойдет даже просто обычная синусоида, главное выбрать несколько итераций с разной периодичностью и сложить вместе. Но, я человек-визуал, и мне сложно через числа что-то собрать адекватное 🤪, поэтому с самого начала я ориентировалась на визуальные инструменты и граф шума.

Под графом шума я подразумеваю именно набор нод и связей между собой. Чтобы упростить себе работу, я взяла уже готовое решение - FastNoise2. Это С++ библиотека, которая содержит множество API для генерации разнообразного шума, причем с поддержкой SIMD (хотя тут не все так просто). И самое главное - предоставляет граф из коробки!
Не все так просто с SIMD у меня по той причине, что я пишу на C# (привет P/Invoke) и использую Jobs + Burst. Также, я вычисляю шум для каждого вокселя отдельно, и не могу сократить кол-во вызовов P/Invoke, которые очень дорогие по сравнению с прямым вызовом метода. Ну и теряю векторизацию и все оптимизации Burst. Вот и получается, что SIMD вроде и есть, но очень условно.
Решение тут одно: переход на Burst математику и кодогенерацию по графу. Но это пока только в планах 🥹

Вокруг библиотеки FastNoise2 у меня написан обычный C# враппер и редактор для Unity, чтобы можно было визуально связывать ноды и сразу видеть результат. Editor часть (на скриншоте) реализована с помощью Unity.GraphView, который до сих пор в экспериментальном статусе, и фреймворка NodeGraphProcessor. Очень жду Graph Tools Foundation, который должен быть с Unity 6 (предположительно) и который должен быть намного быстрее, чем GraphView.

Сам граф в Runtime выглядит просто как поинтер (IntPtr) на C++ часть, и я хотя бы не пробегаюсь по графу в C# части. Использование unmanaged типов позволяет мне их упаковать в Unity.Collections и использовать в Jobs.

Кстати, может стоит сюда писать и о всяких мелочах?) Например, различных нюансах Unity, с которыми я сталкиваюсь в ходе работы над проектом.

Вот вчера и сегодня оптимизировала генерацию текстурных данных для чанков. Была проблема, что текстурные массивы (Texture2DArray), которые у меня генерируются в runtime на лету, создавались слишком долго. Причина оказалась в том, что даже в случае, если массив используется только на GPU стороне, на CPU также создается его копия, и (!) после создания копируется на GPU. Это приводило к огромным задержкам (до 1 секунды 🔥).
Я нашла "экспериментальное" API - флаги TextureCreationFlags, с помощью которых можно указать необходимое поведение. Но флаг TextureCreationFlags.DontInitializePixels не убирал синхронизацию с GPU, а вот флаги TextureCreationFlags.DontInitializePixels | TextureCreationFlags.DontUploadUponCreate уже привели к нужному поведению. Но правда на CPU все равно создается копия, она просто не используется и пока ее никак не убрать 😔

var textureArray = new Texture2DArray(width, height, 16,GraphicsFormat.RGBA_DXT1_SRGB, TextureCreationFlags.DontInitializePixels | TextureCreationFlags.DontUploadUponCreate | TextureCreationFlags.MipChain, mipCount)
{
      filterMode = FilterMode.Bilinear,
      wrapMode = TextureWrapMode.Repeat
};

Еще можно использовать RenderTexture с флагом TextureDimension.Tex2DArray, но RT не поддерживает сжатие, поэтому это для каких-то исключений.

На скриншоте голубое - то, что было, с синхронизацией с GPU, а оранжевое - без нее. Как видно, разница огромная!

Вот еще один нюанс работы с Unity. Что-то их сегодня прям много 🥔
В Assembly Definition можно указывать требуемые версии пакетов, и даже define для этого, что удобно. Но не верьте Unity, которая пишет x >= version! Потому что это совсем не так! Define определится только, если x > version.
Вроде бы мелочь, а я потратила достаточно времени, пытаясь понять, где же ошиблась ☺️

Кстати, если визуализировать воксели без всяких оптимизаций, то есть по 4913 вокселей (17х17х17) на чанк, то это будет выглядеть вот так)

Красиво, но сколько вычислять 😱

Генерация. Меши

После генерации вокселей настало время генерации мешей. Для этого можно взять алгоритм Marching Cubes, но он имеет несколько минусов, с которыми я не смогла согласиться:
- неоднозначность сетки в некоторых случаях (в том числе и "дырки" из-за этого)
- нельзя создать острые края
- есть проблемы в сшивании разных LOD

Поэтому я взяла алгоритм Dual Contouring, который основан на Marching Cubes, но решает все перечисленные выше проблемы. Но для этого алгоритма нужно генерировать больше информации: я уже писала в посте про воксели про градиент, вот он и нужен для Dual Contouring.

Вершины, в отличие от Marchig Cubes, размещаются не на гранях кубов, а внутри куба (чаще всего просто средняя позиция между угловыми вокселями в зависимости от их значения).

Дальше, эти вершины "адаптируется" по градиенту с помощью QEF (вот тут есть объяснение, там много математики, поэтому боюсь не объясню на пальцах). Остается только собрать получившиеся вершины в треугольники и получаем сетку.

Основные проблемы были тут распараллелить алгоритм для Jobs. Пока это выглядит довольно криво, но зато работает и достаточно шустро). Да и от дырок я полностью не избавилась пока что)

Скриншот только такой нашла с тех времен, но можно увидеть саму сетку 😶

А прямо сейчас работаю над детерминированным инстансингом объектов. Пока есть проблема с этой детерминированностью, но думаю, скоро покажу результаты)👏