Внезапно обнаружила, что в библиотеке FastNoise, о которой рассказывала раньше, фрактальный шум (Fbm, Ridged, Ping-Pong) не совсем фрактальный на самом деле! 😧

Автор библиотеки допустил ошибку, и весь фрактальный шум генерируется на основе линейных параметров, не учитывая предыдущие шаги. Это дает совсем неинтересные результаты: фактически значение в каждой точке просто уточняется N итераций (октав). А как мы знаем, фракталы - это немного другое.

Дописать и решить эту проблему не сложно, в общем случае все сводится к добавлению множителя на каждом шаге, который рассчитывается вот так:

pow(lacunarity, -index * spectralExponent);

На скриншоте слева - обычный Fractal Ridged из Fast Noise, справа - Multi Fractal Ridged моей версии. 🫥

#generation

Наконец-то пофиксила все баги, которые наделала 🫥, а также вернула почти весь функционал, чтобы можно было сравнить старую версию генератора с новой. 😧

Я не меняла алгоритмы генерации, только снизила нагрузку как общую, так и per frame.
Список изменений:
🔹 планирование генерации чанков стало Burst Compatible и полностью unmanaged;
🔹 планирование теперь предполагает подход Wave Front (волнами) по 32 чанка на волну;
🔹 были убраны отдельные Thread Worker для генерации, вместо них вся генерация была переписана на Job System, а также все максимально стало Burst Compatible;
🔹 расчет SDF для вокселей был полностью перенесен на GPGPU - это позволило считать SDF сразу для всех вокселей, что очень сильно упростило дальнейшие алгоритмы;
🔹 пост-процессинг сгенерированных данных был сильно упрощен, а также изменен в сторону like-ECS;
🔹 были переписаны структуры данных: где-то в угоду производительности (но больше использование памяти), где-то наоборот, но в целом они мало поменяли картину;
🔹 был упрощен подход с хранением типов вокселей: теперь есть общие наборы типов вокселей для всех биомов, биомы же только предоставляют веса для типов вокселей из сетов;
🔹 множество мелких исправлений и улучшений, что-то даже уже не помню 🤭

Что касается цифр, было:
❌ были большие пики, абсолютные цифры также удручающие - свыше 600 мс на кадр❗️
❌ генерация всего мира занимала примерно 1 секунду, но ценой времени кадра (свыше 100 мс).

Стало:
✅ пики ушли, на графике есть локальные пики, которые не относятся к генерации и никак не влияют на время кадра;
✅ за кадр медиана 0,03мс на генерацию в Main Thread и примерно ~10 мс суммарно по всем Job System Workers;
✅ генерация всего мира занимает примерно 1 секунду, но время кадра почти не меняется (полезно будет при реализации телепортов/быстрого перемещения).

#generation

ГД как часть разработки

Без грамотного описания игры разработка скорее всего не достигнет успеха. Потому что это будет не процесс разработки, а процесс нащупывания в темноте. ГД (геймдизайн) тут выступает в качестве факела, который освещает путь и разгоняет темноту ☺️

Я конечно же тоже работаю над ГДД (геймдизайн документом). Это большая и сложная задача, к которой приходится подходить постепенно, шаг за шагом. И также как и с кодом, итеративно.

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

Так что, не считая понедельника, всю неделю я не написала ни единой строчки кода 😔, зато написала сотни и даже тысячи строк текста 🤭

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

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

Это правда очень сильно облегчает жизнь: получается прямая ссылка, название которой еще можно менять в одно действие. В таблице, для каждого элемента можно также завести описание, чтобы при клике на ссылку мы еще видели и описание.

В Notion, который я использую, это делается максимально просто:
🔹создается таблица;
🔹таблица заполняется нужными элементами;
🔹сослаться на элемент из таблицы в любом блоке текста можно через @ и в выпадающем списке выбрать конкретный элемент.

#game_design

Знаю знаю, что ландшафт цвета детской неожиданности совсем не впечатляет 🤭 (обещаю, что скоро это изменится), но все равно поделюсь поделюсь видео с первыми результатами переноса поддержки множества биомов на GPU.

Когда я считала воксели на Job System, то у меня уже была успешно реализована функция смешивания разных биомов. Сейчас же, в рамках задачи возвращения оставшихся функций на новый пайплайн генерации, переношу смешивание на HLSL.

Это оказалось не так просто, так как столкнулась с очень долгой компиляцией вычислительных шейдеров 😔 Все потому, что весь код инлайнится, а алгоритмы шумов - большие и дорогие 😭 Но ничего, я уже успешно снизила время с 30 минут до 30 секунд, жить можно) А там еще что-нибудь придумаю 🥔

#generation

Графический дебаг иногда бывает красивым, а иногда даже жутковатым 🤭

Сломала шейдинг, приходится искать проблему самым простым способом: выводить вертекс каналы в качестве Albedo. Это например веса нескольких материалов, жаль, что неправильные, интересно почему? 🤔

#generation

Суббота прошла не зря (кря-кря): я вернула шейдинг, который ранее поломала, а также перенесла смешивание биомов на GPU сторону. 🥔

Интересный эффект "висюлек" получился на границе двух биомов + пещер. 😧

Теперь надо подумать, как генерировать карту биомов, чтобы переходы были плавными, а не такими резкими 🔍

#generation

Путешествие в гору

Долго же я возилась со смешиванием биомов 😔: попробовала множество вариантов, механик, функций. Четыре дня непрерывных поисков.

Пока пришла к весовым функциям для каждого биома + карта высоты, которая является входным параметром для весовых функций. В дальнейшем добавится карта температуры и влажности. Но сейчас всего лишь три тестовых биома, и усложнять не очень хочется.

Каждый биом сам является функцией, которая определяет как SDF, так и воксели. Но некоторым биомам, оказалось, нужна и та самая базовая высота, по которой считается вес, иначе выглядит фу 🫣

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

Note: текстуры сейчас используются максимально простые, чтобы видеть как смешивается, в дальнейшем их заменю на более подходящие.

#generation

StructLayout.Pack и Burst

Когда мы работаем со структурами, нам часто бывает важно как именно расположены члены этой структуры в памяти. Это может быть по причинам работы с P/Invoke, или может мы захотели оптимизировать использование памяти.

Для того, чтобы управлять тем, как члены структуры расположены в памяти, мы можем обратиться к атрибуту StructLayout, который имеет несколько параметров.

Note: атрибут StructLayout может применяться также и к классам!

1️⃣ Первый параметр - LayoutKind - тип макета, который бывает:
1. Sequential: все поля располагаются в памяти последовательно в порядке объявления.
2. Explicit: поля располагаются в памяти по заданным смещениям. Эти смещения указываются через атрибут FieldOffset.
3. Auto: автоматическое расположение полей в зависимости от компилятора. Совсем не обязательно, что поля будут располагаться в порядке объявления, так что с этим поосторожнее.

Note: по умолчанию всегда стоит Sequential, то есть получаем поведение из пункта 1.

2️⃣ Второй параметр, который тоже частенько используется - Size. Он отвечает за абсолютный размер структуры. Используется, когда мы хотим выделять конкретное количество байт на структуру. Причем, мы можем выделить больше, чем поля в сумме занимают на самом деле. Таким образом можно, например, выделить кусочек памяти на header структуры и там хранить какую-то информацию.

Note: размер структуры без каких-либо полей равен одному байту. Так что не обязательно указывать Size = 1 у "пустой" структуры.

3️⃣ Третий параметр - CharSet - задает кодировку для строк. Но в рамках Burst это мало интересует. Но может понадобиться, если работа ведется с неуправляемыми библиотеками.

4️⃣ И четвертый параметр - Pack - задает выравнивание полей. Тоже может использоваться частенько, но надо быть очень осторожным с ним. Полезен, если мы хотим, чтобы структура не занимала лишнее место в памяти, если используем поля с разным размером.

Давайте придумаем пример:

[StructLayout(LayoutKind.Sequential, Pack = 1)]
struct ExampleStruct
{
    public byte ByteValue;
    public int IntValue;
    public short ShortValue;
}

Какой размер у такой структуры? Ответ - 7 байт. Почему? Потому что мы указали выравнивание 1 байт, тогда: поле ByteValue занимает 1 байт, поле IntValue занимает 4 байта и поле ShortValue - 2 байта. Если указать Pack = 4, то размер структуры будет уже 12 байт, по 4 байта на каждое поле.

Вроде бы все логично, но не для Burst: до версии 1.8.16 включительно было замечено такое поведение, что Burst пытается вставить свое выравнивание. Возможно это связано с векторизацией 🤷, но это приводит к тому, что в коде без Burst, структура занимает N памяти, например, те же 7 байт, а в коде с Burst, это структура будет занимать уже 16 байт.

К чему приводит такое поведение? А то, что если выделить память по размеру структуры без Burst, а потом попытаться читать/писать под Burst, то приходим к крашу, так как получаем сдвиг элементов и выходим за границы выделенной памяти.

Как с этим справляться? Я пока не придумала лучше того, чтобы совсем не использовать Pack. Но иногда так хочется, хочется сэкономить пару байт (да-да, я часто использую поля с размером 1 байт). А потом вспоминаю, как я искала неделю причину краша. 🤦

Когда-то Burst поддерживал только частично параметр Pack, сейчас в документации написано, что полностью поддерживает. Но все равно будьте осторожны!

P.S.: возможно кто-то сталкивался с подобным, поделитесь в комментариях!

#programming

Редакторы тоже важны

Возвращала инстансинг объектов, и столкнулась с тем, что совсем не помню, что и как указывать в LOD. Я просто не могла настроить свои же лоды! 😔

Причина в том, что там надо указывать процентное отношение объекта к размеру камеры, а не какие-то понятные единицы. Это отношение еще надо посчитать, ох, лучше я редактор напишу ☺️

Взяла за основу редактор от UnityEngine.LODGroup - он понятен и привычен. Переписала его под свои нужды: в моей реализации LOD многое упрощено, да и работаю я напрямую с Mesh и Material, так как моя реализация под BRG.

Что ж, часа 4, и вот, PropertyDrawer, который почти повторяет функционал LODGroup. Рисуется в MonoBehaviour, ScriptableObject, везде, где указано сериализованное поле моего типа. Удобненько. 🥔

#programming

Когда ты инди-разработчица, то приходится делать абсолютно все: продумывать геймдизайн, разрабатывать геймплейные фичи, инструменты, оптимизировать свой же код и графику, рисовать текстуры и моделировать объекты. Направлений просто куча! 😧

Каждое из этих направлений интересно по своему: где-то можно прокачаться в сохранении байтиков и получении более маленьких циферок в Profiler, а где-то можно почувствовать себя художником (может даже не от слова "худо" 🤭) и воплотить свои идеи в реальность в виде различных красивостей.

Последнюю неделю я изучала Adobe Substance 3D Designer: очень мощный инструмент для создания разнообразных текстур. Правда оказался достаточно сложным для меня: после тысячи часов за кодом снова вернуться к арту - задачка та еще)

Зато этот инструмент довольно близок ко мне по духу: шум, много шума, очень много шума и различные операции над ним. Тяп-ляп, и текстура готова 😄 Процесс почти такой же, что и у меня в генераторе мира)

#texturing

Нас уже 300 человек! Удивительно ✨ Спасибо вам всем за поддержку! ❤️

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

Написала статью по новому этапу разработки 👏 Будет серия постов и статей.

К сожалению, telegraph больше не поддерживается telegram, поэтому пришлось переехать на teletype 🧂 Надеюсь вам будет удобно читать! 🥰

Русская версия: вот тут.
English: here.

#game_design #demo_scene