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

Демо-сцена. Форма ландшафта.

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

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

Приятного чтения! 🥰

#generation #demo_scene

Custom properties в DOTS Instancing

Как и в GPU Instancing, в DOTS Instancing есть определенные правила работы с полями, которые должны быть per instance. 🧐

Если рассматривать как в DOTS Instancing устроено хранение данных для каждого инстанса, то стоит обратиться к Batch Renderer Group. А там, фактически, один буфер, где под каждое поле (будь то матрица или просто цвет) выделяется определенный кусок памяти. Дальше, с помощью оффсетов, которые можно вычислить, зная размер данных поля и количество интансов, можно получить доступ к конкретному значению конкретного поля для конкретного инстанса.

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

Определение поля:

#ifdef UNITY_DOTS_INSTANCING_ENABLED
UNITY_DOTS_INSTANCING_START(MaterialPropertyMetadata)
    UNITY_DOTS_INSTANCED_PROP(float4, _ChunkDebugColor)
UNITY_DOTS_INSTANCING_END(MaterialPropertyMetadata)
#else
int _ChunkDebugColor;
#endif

И получение значения:

float4 debug_color = (float4)0;
#ifdef UNITY_DOTS_INSTANCING_ENABLED
debug_color = UNITY_ACCESS_DOTS_INSTANCED_PROP(float4, _ChunkDebugColor);
#else
debug_color = _ChunkDebugColor;
#endif

Но как же указать значение для инстансов? 🤔
Когда мы работаем с GPU Instancing, то необходимо передать буфер per property, который мы можем как-то заполнить на стороне CPU. В случае же с DOTS Instancing, мы должны работать с буфером BRG и заполнять его. Это немного сложновато, но у меня есть небольшая реализация, которая упрощает этот процесс.

Но также есть и другой способ, если используется пакет Entities. Там мы можем указывать значения через компоненты! ✨
Для этого необходимо создать небольшой компонент и повесить его на сущность, все остальное за нас сделает Unity:

[Serializable]
[MaterialProperty("_ChunkDebugColor")]
public struct DebugChunkColorProperty : IComponentData
{
    public float4 Value;

    public static implicit operator DebugChunkColorProperty(float4 value)
    {
        return new DebugChunkColorProperty
        {
            Value = value
        };
    }
}

#dots

Что такое Biome?

Биом - это правила генерации ландшафта, правила выбора вокселей, правила генерации окружения и многое другое.

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

Фактически, это просто математическое уравнение. Довольно большое и сложное, но все же уравнение: на входе позиция в world space и зерно (seed) мира, а на выходе - дистанция для Signed Distance Field и вектор типов вокселей, которые могут быть в указанной точке пространства. Вот и все 👏

#generation

Демо-сцена. Базовые цвета ландшафта. Часть 1.

На этот раз затрагиваю тему материалов вокселей и базовых цветов ландшафта для демо сцены.

Это первая часть статьи, так как для продолжения необходимо вначале настроить освещение 👏

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

Приятного чтения! 🥰

#generation #demo_scene

Вынужденный 🤭 отпуск закончился и я возвращаюсь потихоньку за работу! 🥔

Начала работать над блокингом сцены: расставляю вначале крупные детали, потом перейду к средним, и в конце уже к мелким. 👏

Заодно дописываю генерацию, так как появляются разные небольшие моменты, о которых раньше и не предполагала) Например, для будущих камушков и скал на склонах надо учитывать нормаль, а не просто рандомно поворачивать 🤔

#generation #demo_scene