Трава кстати уже шевелится 💃 Я взяла ассеты из сэмплов HDRP, чтобы сейчас немного укориться ☺️

В комментариях я обещала рассказать про основные структуры данных, о которых я уже упоминала 💃

Воксель - просто информация о пространстве: density и gradient + информация по визуализации (индексы материалов).

public readonly struct Voxel : IEquatable<Voxel>
{
    public readonly float3 Gradient;
    public readonly half Density;
    ...

    public readonly FixedVoxelType4 VoxelTypes;
    ...
}

Позицию в вокселе я не храню, так как доступ к ним и так через позицию, и хранятся они в отношении позиция вокселя -> воксель. Но это не HashMap! А обычный массив с вычислением индекса из позиции: math.dot(coordinate, new int3(1, dimension.x, dimension.x * dimension.y)); (когда математику вдруг можно применить и в таких случаях).

Чанк - тут еще меньше информации: позиция и lod!

public readonly struct Chunk : IEquatable<Chunk>
{
    public readonly int3 Position;
    public readonly ChunkLod Lod;
}

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

Octree - фактически, дерево у меня представлено в виде HashMap, где ключ - просто число без знака, а значение - нода с какой-либо информацией.

public readonly struct LocationCode : IEquatable<LocationCode>
{
    public readonly uint Value;
}

Ключ - просто набор бит (причем используются первые 30 бит). Зная, что каждая нода разбивается на 8 нод, на каждый уровень можно выделить по 3 бита (2^3 = 8). Максимальная глубина соответственно равна 10, чего мне хватает с запасом. Чтобы получить значение ребенка: (source.Value << 3) | childIndex, где childIndex - значение от 0 до 7. Чтобы получить значение родителя: code >> 3.

Немного побитовых операций, а уже не надо в ноде хранить ссылки на другие ноды ☺️ Я после этого начала использовать побитовые операции везде где надо и не надо 🤭

Генерация и ECS

Наверное многие задумывались: "она говорит про ECS, DOTS, но показывает ООП код, что-то тут не так"? 👍 И ведь правда, причем тут ECS?

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

Все, что генерируется и видимо игроком, должно каким-либо образом рисоваться. Для этого я разбила представление окружающих объектов на две части:
- окружающие объекты без физики;
- окружающие объекты с физикой.

Почему именно такое распределение? Потому что объекты без физики я могу рисовать самостоятельно без создания самих объектов (GameObject или Entity). Мне нужно знать только что рисовать и где рисовать.

А вот объекты с физикой (или любые другие объекты, с которыми игрок может взаимодействовать) необходимо уже собирать из кусочков. Тут и компоненты отображения, и компоненты физики, и компоненты взаимодействия вместе с состоянием. А еще они должны быть представлены и на сервере!

По этой причине, на этапе процессинга сгенерированных данных я подготавливаю их в требуемом виде (например, меши ландшафта уже представлены в виде UnityEngine.Mesh) и отправляю в соответствующие ECS-системы. Не могу сказать, что именно такая связь правильная, возможно было бы лучше, если бы ECS-системы сами собирали информацию. 🤷

ECS-системы, в свою очередь, создают из этих данных сущности с компонентами. Например, есть система, которая создает сущности чанков. Другая система - создает уже отображение этих чанков. Третья - коллайдеры, с ними кстати все не так просто оказалось в UECS, надеюсь когда-нибудь расскажу. И вот на выходе у меня уже не просто меши, а самые настоящие ентити с набором компонентов.

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

Добавляю поддержку лодов в BRG, алгоритм уже работает (но еще не протестировала до конца), начала интегрировать в проект, скоро будет видео)

Редактор конечно кривоватый, но и так сойдет пока что 🫥

Обещанное видео) Конечно тут кубики, с разными цветами, обозначающие уровень детализации 🤷

С LOD оказалось все чуть сложнее, чем я думала. Но все же победа вот-вот будет за мной! Осталось откинуть те кубики, которые слишком далеко от камеры👏

А вот теперь есть и поддержка "пустых" лодов, которые не рендерят ничего 💃

Стоит заметить, что LOD выбирается не просто по дистанции до камеры, а по эвристике, определяющей, сколько объект занимает в процентном соотношении места на экране! Это позволяет более точно выбирать LOD и рисовать только то, что реально видно и имеет шанс быть замеченным (поэтому маленькие объекты даже в близи могут быть еще скрыты, тогда как большие - уже рисоваться).

Следующий шаг - добавление cross fade, чтобы лоды плавно смешивались.

Хочу немного рассказать, как я выбираю LOD. Это не очень сложно на самом деле, как бы не звучало в моем предыдущем посте 🤭

Самый простой способ выбирать LOD - зная позицию камеры и для каждого инстанса матрицу трансформации, можно взять дистанцию между ними. Потом сравнить дистанцию с теми значениями диапазонов, которые мы указали в редакторе. Получается линейная выборка, которая никак не учитывает размер объекта.

А размер объекта на самом деле очень важен. Цель LOD - уменьшить не только кол-во треугольников, но и кол-во инстансов. Маленькие объекты вдалеке человеку чаще не заметны, тогда зачем их рисовать?

Диапазоны расстояний в итоге заменяются на процентное соотношение относительно экрана. То есть при настройке LOD мы указываем уже не дистанцию, а процентное соотношение. Например, 100% - виден когда занимает весь экран, 60% - виден, когда занимает примерно 60% площади экрана, 15% - когда объект занимает совсем небольшую площадь экрана, то есть он или маленький или находится далеко от нас.

В BRG у нас на руках есть матрица трансформации (с поворотом и скейлом в том числе) для каждого инстанса, а также размер меша per LOD в world space. То есть вычислить фактический размер в world space - уже не проблема, для удобства берем самое большее значение по одной из осей.

Зная размер меша и зная процентное соотношение, можно вычислить для него диапазон уже дистанций: worldSpaceSize / screenRelativeTransitionHeight[i]. С этими дистанциями уже можно сравнивать дистанцию от объекта до камеры.

Но дистанция от объекта до камеры тоже не просто math.distance, так как для перспективной камеры у нас есть искажение, а для ортогональной его нет. Также необходимо еще учитывать LOD Global Bias из QualitySettings,

https://telegra.ph/Level-of-Detail-v-Unity-BRG-04-10

Написала статью про LOD в BRG 🚪 Весь код можно найти в моем репозитории по BRG (MIT-лицензия) 😶 Документацию там тоже скоро обновлю.

Видео с камушками! 🤩 (и с LOD вместе с CrossFade). 🙌

Как по мне, выглядит неплохо, очень нравится, что камушки плавненько появляются и исчезают, ради этого я и добавила поддержку LOD (а не ради оптимизации, как вы могли подумать ☺️)

Чтобы не делать много постов, скриншот из Frame Debugger приложу в комментариях 🚪

Протестировала на траве! 🥔

К сожалению не нашла в HDRP ассетах от Unity лоды для травы, они ее просто скрывают плавно по дистанции (ага, и десятки и сотни млн треугольников в итоге в кадре, хоть и не видно их). Пришлось также взять просто Lit шейдер, чтобы не писать сейчас поддержку для Cross Fade для их шейдера. В итоге трава не шевелится :(

Но ничего, то, что мы не видим, то не рисуется, а это главное! 🙌 Хотя при этом трава сгенерирована и находится в памяти.

P.S.: Я думала, думала, и решила немного уточнить момент с графикой. Это не стиль будущей игры, и она не будет в реализме, поэтому я не работаю сейчас над визуальной составляющей (некоторые подвижки в эту сторону скоро начнутся). Это пока что просто технические решения и некоторые стресс тесты для них (и для меня 😄).

https://telegra.ph/Shading-landshafta-04-13

Решила сегодня попробовать формат не просто поста, а поста-статьи, так как в телеграмме не получится написать такой длинный пост 😢 Но это не статья как в прошлый раз! Просто чуть длинненький пост)

Зато там получилось выложить побольше информации и побольше скриншотов 🙌

Всем спасибо за голосование! 🥰

10% проголосовало за маленькие частые посты, 10% за большие, но редкие, и 80% за смешанный тип. Тогда буду стараться поразнообразней публиковать посты)

Burst и делегаты

Иногда в задачах никак не обойтись без делегатов, но что делать, если код на Jobs + Burst? Delegate - это managed тип, под Burst не вызовешь, а от преимуществ отказываться не хочется.

В C# есть unmanaged делегаты, которые также поддерживаются и Burst если правильно приготовить 🧂

Все, что нужно сделать, так это:
Шаг 1. Определить самый обыкновенный delegate и пометить его как CallingConvention.Cdecl если собираем IL2CPP:

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
public delegate void OperationPerformDelegate(ref OperationExecutor.Parameters parameters);

Шаг 2. Определить метод/методы, которые хотим вызывать с помощью делегата и пометить атрибутом с ним [MonoPInvokeCallback(typeof(OperationPerformDelegate))]:

[BurstCompile]
[MonoPInvokeCallback(typeof(OperationPerformDelegate))]
private static void InvokeExecute(ref OperationExecutor.Parameters parameters)
{
   OperationExecutor.Execute<CapsuleOperation, CapsuleOperation>(ref parameters);
}

Шаг 3. Пометить вызываемые методы из п.2 и типы, которые их содержат атрибутом [BurstCompile].

Шаг 4. Скомпилить каждый делегат через BurstCompiler.CompileFunctionPointer:

private static readonly FunctionPointer<OperationPerformDelegate> m_InvokeExecuteFunctionPointer =
BurstCompiler.CompileFunctionPointer<OperationPerformDelegate>(InvokeExecute);

FunctionPointer можно передать любым удобным образом в Job и вызывать или с помощью обычного Invoke:

m_ExecutePtr.Invoke.Invoke(ref parameters);

Или по старинке вот так:

((delegate * unmanaged[Cdecl] <ref OperationExecutor.Parameters, void>)m_ExecutePtr.Value)(ref parameters);

А что по производительности? FunctionPointer существенно медленнее, чем прямой вызов, поэтому использовать лучше в тех моментах, где совсем не обойтись. Вот тут можно посмотреть сравнение.

Например, у меня так реализованы операции над ландшафтом.🚪 Я использую указатели на функции, чтобы все типы операций (копание/возведение, по сфере, по кубу и т.п.) можно было описать абстрактной структурой NativeOperation, которая содержит только упакованные данные операции + указатель на метод, который по этим данным может произвести вычисления.

public struct NativeOperation : IDisposable
{
   private readonly FunctionPointer<OperationPerformDelegate> m_ExecutePtr;

   [NativeDisableUnsafePtrRestriction]
   internal unsafe void* m_Data;

   public readonly int3 Min;
   public readonly int3 Max;
}

Все эти операции складываются в массив, по которому пробегаюсь при вычислении SDF вокселя. 🥔

Добавляю генерацию объектов, с которыми игрок может взаимодействовать тем или иным образом (например, физика). Это все большие камни, деревья, постройки и т.п.

Также учитываю и тот момент, что ландшафт может меняться☺️ Пока что реализовала самый простой вариант, когда при изменении ландшафта мы просто опускаем объект вниз (понадобится для кустов и подобных небольших объектов). Но в планах конечно в такие моменты включать физику, и пусть булыжник упадет кому-нибудь на голову 😕🤭

Так как это объекты с коллайдером, то они симулируются и на серверной стороне, а не только на клиентской 😶