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

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

Для воксельных миров подойдет любой непрерывный шум. Это может быть всеми известный шум Перлина, или какой-нибудь 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. Пока это выглядит довольно криво, но зато работает и достаточно шустро). Да и от дырок я полностью не избавилась пока что)

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

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

Еще немножечко про архитектуру ☺️ Я уже в общих чертах описала модули генерации и шаблон генерации, которые используются уже в самом генераторе. А если быть конкретнее - в мире генерации, который объединяет множество аспектов генерации. Это и состояние чанков, и кэширование, и сама генерация и т.д.

Все эти аспекты связаны между собой, так что я не беспокоюсь о том, что для чанка у меня не будет кэша например. Если чанк раннее генерировался, то его кэш я получу и смогу решить, что делать дальше. Единственный аспект, который вынесен наружу - это аспект патчей.

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

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

Я старалась сделать понятное API для работы с патчами, потому что я сама забываю о том, как работать с тем, что написала 🫥
Создание патча выглядит просто:

public static unsafe WorldPatch Create(byte sourceId, NativeArray<Chunk> chunksToBuild, NativeArray<BorderMask> borderBitmasks, NativeArray<Chunk> chunksToRelease, Allocator allocator)
{
}

Также и применение:

public static PatchHandle ApplyPatch(this GenerationWorld world, ref WorldPatch patch, PatchOptions options = PatchOptions.Default)
{
}

Где на выход отдается PatchHandle, через который можно проверить, применился ли патч, сколько осталось чанков (полезно для экрана загрузки) и т.п.

Сегодня также закончила первую версию генератора деталей 💃 Под деталями имею в виду всякие мелкие объекты без коллайдеров: камушки, палочки, веточки и все такое)

Так как эти объекты зависят от поверхности ландшафта, то генерирую на основе данных о треугольниках. И тут важно перевести позиции вершин из world space в voxel space, тогда результаты всегда будут одинаковы для конкретного вокселя, даже если поверхность изменилась. Единственный момент был - нормали, но как я уже писала, нормали можно восстановить.

Рисуются детали с помощью BRG, который отлично подходит для данной задачи. BatchRendererGroup (BRG) - это API для ручного батчинга и создания команд отрисовки. Попробую кратенько рассказать.

Регистрируем меш и материал, создаем буфер, в котором будут храниться данные для шейдера (например матрицы трансформации) и получаем BatchID.

Дальше необходимо для каждого BatchID и соответствующего ему буфера данных провести culling - собрать индексы только тех инстансов, которые видны через камеру.

В конце, для каждого BatchID, если для него есть видимые инстансы, необходимо создать команды отрисовки и отправить их на выполнение.

В ходе исследований BRG у меня появился инструмент, который я использую в этом проекте. Он простенький и его нельзя назвать универсальным, но если кому-то будет интересно, то может стать неплохой стартовой точкой.

На одном скриншоте показан редактор деталей для каждого воксель материала, а на втором - Frame Debugger.

После деталей приступила к траве! Генерация травы очень похожа на генерацию деталей, но есть и отличия, так что придется хорошенько поработать 💃

Первая версия травы! 🙌 Выглядит кривовато, буду еще дорабатывать)

За счет уже готового процесса добавления новых модулей генерации, это заняло всего один день. Правда много т.н. бойлерплейта, хмм, есть о чем подумать 😶