Практически в каждой игре необходимо наполнять игровые уровни объектами, которые создают визуальное богатство, красоту и вариативность виртуального мира. Возьмите любую игру с открытым миром. Там деревья, трава, земля и вода основные «заполнители» картинки. Сегодня GPGPU будет совсем немного, но я попробую рассказать, как нарисовать в кадре много деревьев и камней, когда нельзя, но очень хочется.

Сразу следует оговориться, что у нас маленькая инди девстудия, и ресурсов вырисовывать и вымоделивать каждую мелочь часто нету. Отсюда и требование к различным подсистемам, быть «надстройкой» над уже готовым функционалом движка. Так было и в первой статье цикла про анимации (там мы использовали и ускоряли уже готовую систему анимации Unity), так будет и тут. Это сильно упрощает внедрение нового функционала в игру (меньше учиться, меньше багов, etc).

Итак, задача: надо нарисовать много леса. Игра у нас стратегия реального времени (RTS) с большими уровнями (30х30 км), и это задает основные требования к системе отрисовки:

• С помощью миникарты мы можем мгновенно перенестись в любую точку уровня. И данные про объекты для новой позиции должны быть готовы. Мы не можем как в FPS или TPS играх полагаться на подгрузку ресурсов через какое-то время.
• Объектов на таких больших уровнях необходимо действительно большое количество. Сотни тысяч, если не миллионы.
• Опять же, большие уровни делают очень долгой и сложной процедуру расстановки «лесов» в ручном режиме. Необходима процедурная генерация леса, камней и кустов, но с возможностью ручной корректировки и расстановки в ключевых местах игрового уровня.

Как можно решить такую задачу? Такое количество обычных расставленных объектов юнити все равно не потянет. Умрем в куллинге и батчинге. Рендер возможен с помощью инстансинга. Надо писать систему управления. Деревья надо моделлить. Систему анимаций деревьев надо делать. Ох. Хочется красиво и сразу. Есть SpeedTree, но нет апи для анимаций, вид сверху на билборды ужасен, так как нет «horizontal billboard» и документация скудновата. Но когда нас такое останавливало? Будем оптимизировать SpeedTree рендер.

Рендеринг​

Посмотрим для начала, так ли все плохо с обычными speedtree объектами:

Вот около 2000 деревьев на сцене. С рендером все в порядке, там instancing объединил деревья в батчи, а вот с CPU все плохо. Половина времени рендера камеры — это куллинг. А нам надо сотни тысяч. Однозначно отказываемся от GameObject'ов, но теперь нам надо расковырять структуру модельки SpeedTree, механизм переключения LOD'ов и сделать все ручками.

Дерево SpeedTree состоит из нескольких LODов (обычно 4), последний из которых billboard, а все остальные — геометрия различной степени детализации. Каждый из них состоит из нескольких сабмешей, со своим материалом:

Это не специфика именно SpeedTree. Такую структуру может иметь любой объект. Переключение LODов реализовано двумя доступными режимами:

• Cross Fade:

• Speed Tree:

CrossFade (в терминах шейдеров Unity он определяется define'ом препроцессора LOD_FADE_CROSSFADE) — основной метод переключения LOD для любых объектов сцены с несколькими уровнями детализации. Он заключается в том, что когда происходит смена LOD, меш, который должен исчезнуть, не просто исчезает (так будет отчетливо виден скачок качества модели), а «растворяется» на экране с помощью dithering'a. Простой эффект, а позволяет избежать использования настоящей прозрачности (alpha blending). Модель, которая должна появиться, абсолютно таким же образом «проявляется» на экране.

SpeedTree (LOD_FADE_PERCENTAGE) же сделан специально для деревьев. В геометрию листьев, веток и ствола, помимо основных координат, записаны еще и дополнительные координаты позиции вершин младшего по отношению к текущему LOD уровня. Степень перехода из одного уровня в другой и есть значение веса для линейной интерполяции этих двух позиций. Переход в/из billboard происходит с помощью CrossFade метода.

В принципе, это все, что надо знать для реализации собственной системы переключения LOD'ов. Сам рендеринг прост. Проходимся в цикле по всем типам деревьев, по всем LOD'ам и по всем сабмешам каждого LOD'a. Устанавливаем соответствующий материал, и отрисовываем все экземпляры данного объекта одним махом с помощью инстансинга. Таким образом, количество DrawCall равно количеству уникальных объектов на сцене. Как мы знаем, что рисовать? В этом нам поможет

Генератор Леса​

Сама высадка проста и неприхотлива. Для каждого типа дерева разбиваем мир на квады так, чтобы в каждый помещалось одно дерево. Пробегаемся по всем квадам и проверяем маску вида:

в данной точке уровня, а можно ли садить тут дерево? Маску, c «лесистыми» местами, рисует level designer. Сначала все это дело было на CPU и C#. Генератор работал неспешно, а размеры уровней росли так, что ждать перегенерации по несколько десятков минут стало напряжно. Решено было перенести генератор на GPU и Compute шейдера. Тут тоже все просто. Нам нужна heightmap земли, маска посадки деревьев и AppendStructuredBuffer, куда мы добавляем сгенерированные деревья (позиция и ID, вот и все данные).

Расставленные руками деревья в ключевых точках специальный скрипт подтягивает в общие массивы и удаляет оригинальный объект со сцены.

Culling & LOD switсhing​

Знать позицию и тип дерева недостаточно, чтобы сделать эффективный рендеринг. Надо каждый кадр определять, какие объекты видны и какой LOD (учитывая логику переходов) отправлять на рендер.

Этим также будет заниматься специальный сompute shader. Для каждого объекта сначала выполняется Frustum Culling:

Если объект видим, то далее выполняется логика переключения LOD. По размеру на экране определяем нужный LOD level. Если для LOD группы задан режим CrossFade, то инкрементируем время перехода для dithering'a. Если SpeedTree Percentage, то считаем нормализированное значение перехода между LOD'ами.

В современных графических АПИ есть замечательные функции, позволяющие draw submission информацию передавать в вызов отрисовки в compute buffer (например ID3D11DeviceContext::DrawIndexedInstancedIndirect для D3D11). Это значит, что заполнять этот compute buffer можно и на GPU. Таким образом получается сделать полностью CPU независимую систему (ну только Graphics.DrawMeshInstancedIndirect вызвать). В нашем случае необходимо записать только количество инстансов каждого сабмеша. Остальная информация (количество индексов в меше и смещения) статична.

Compute buffer, с аргументами для draw call разбиваем на секции, каждая из которых отвечает за вызов отрисовки своего submesh. В сompute shader'e для меша, который должен быть отрисован в текущем кадре, инкрементируем соответствующее InstanceCount значение.

Вот как это выглядит в рендере:

GPU occlusion culling — очевидный следующий шаг, но для RTS с такой камерой, и не очень большой холмистостью выигрыши не так очевидны (а для заинтересованных вот и вот). Я пока не сделал.

Чтобы все корректно рисовалось, надо немного подправить SpeedTree'шные шейдера, чтобы брать позицию и значения для переходов между LOD из соответствующих compute буферов.

Теперь у нас рисуются красивые, но статичные деревья. А на SpeedTree деревья реалистично влияет ветер, анимируя их. Вся логика таких анимаций находится в файле SpeedTreeWind.cginc, но никакой документации, ни доступа к внутренним параметрам из Unity нет.

CBUFFER_START(SpeedTreeWind)
    float4 _ST_WindVector;
    float4 _ST_WindGlobal;
    float4 _ST_WindBranch;
    float4 _ST_WindBranchTwitch;
    float4 _ST_WindBranchWhip;
    float4 _ST_WindBranchAnchor;
    float4 _ST_WindBranchAdherences;
    float4 _ST_WindTurbulences;
    float4 _ST_WindLeaf1Ripple;
    float4 _ST_WindLeaf1Tumble;
    float4 _ST_WindLeaf1Twitch;
    float4 _ST_WindLeaf2Ripple;
    float4 _ST_WindLeaf2Tumble;
    float4 _ST_WindLeaf2Twitch;
    float4 _ST_WindFrondRipple;
    float4 _ST_WindAnimation;
CBUFFER_END

Как бы нам выковырять их? Для этого, для каждого типа дерева отрендерим оригинальный SpeedTree объект где-нибудь в невидном месте (вернее в видном для Unity, но не видном в камере, а то параметры не будут обновляться). Этого можно добиться сильно увеличив bounding box, и поместив объект за камеру). Каждый кадр снимаем нужный набор значений с помощью material.GetVector(...).

Так, деревья колыхаются на ветру, но вид сверху на билборды удручающий:

С шейдер вариантом BILLBOARD_FACE_CAMERA_POS еще хуже:

Нам нужны horizontal (top-down) billboards. Это стандартная фича SpeedTree со времен царя Гороха, но, судя по форумам, до сих пор не реализованная в Unity. Пост с официального форума SpeedTree: «The Unity integration never used the horizontal billboard». Будем прикручивать руками. Саму геометрию сделать несложно. Как узнать UV координаты спрайта в атласе для нее?

Достаем старенький SpeedTreeRT SDK, и находим в документации структурку:

struct SBillboard
{
    bool            m_bIsActive;
    const float*    m_pTexCoords;
    const float*    m_pCoords;
    float           m_fAlphaTestValue;
};

«m_pTexCoords points to a set of 4 (s,t) texture coordinates that define the images used on the billboard. m_pTexCoords contains 8 entries.», говорится в ней на иностранном языке. Что ж, будем в бинарном spm файле искать последовательность из 4-х floating point значений, каждое из которых лежит в диапазоне [0..1]. Методом научного тыка выясняем, что нужная последовательность находится перед блоком из 12 float cо знаками соответствующими паттерну:

float signs[] = { -1, 1, -1, 1, 1, -1, 1, 1, 1, -1, 1, 1 };

Пишем небольшую консольную утилиту на плюсах, которая перебирает все spm файлы, и в них ищет uv координаты для горизонтальных билбордов. На выходе получается такая себе CSV табличка:

Azalea_Desktop.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, 
Azalea_Desktop_Flowers_1.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, 
Azalea_Desktop_Flowers_2.spm: 0, 1, 0.333333, 1, 0.333333, 0.666667, 0, 0.666667, 
Leaf_Map_Maker_Desktop_1_Modeler_Use_Only.spm:  Pattern not found!
Leaf_Map_Maker_Desktop_2_Modeler_Use_Only.spm:  Pattern not found!
BarrelCactus_Cluster_Desktop_1.spm: 0, 0.592376, 0.407624, 0.592376, 0.407624, 0.184752, 0, 0.184752, 
BarrelCactus_Cluster_Desktop_2.spm: 0, 1, 0.499988, 1, 0.499988, 0.500012, 0, 0.500012, 
BarrelCactus_Desktop_1.spm: 0, 0.2208, 0.220748, 0.2208, 0.220748, 5.29885e-05, 0, 5.29885e-05, 
BarrelCactus_Desktop_2.spm: 0, 1, 0.301392, 1, 0.301392, 0.698608, 0, 0.698608,

Для назначения текстурных координат геометрии horizontal billboard'у, находим нужную запись и парсим ее.

Теперь стало вот так:

Все еще не очень. Будем фейдить с помощью alpha test threshold вертикальный билборд, в записимости от угла к камере:

Итоги​

Профайлер, показывающий динамическую (сколько всего чего рендерится) и статическую (сколько всего на сцене объектов и их параметры) статистику:

Ну и финальное красивое видео (во второй половине показаны переключения quality levels):

Что имеем в итоге:

• Система полностью CPU независима.
• Работает быстро.
• Использует готовые SpeedTree ассеты, коих можно купить в интернете.
• Конечно, я ее подружил с любыми LODGroup, а не только SpeedTree. Так что много камушков теперь тоже можно.

Из недостатков можно отметить отсутствие occlusion culling и таки не очень выразительные билборды.

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

Ууууу, опять анимации. Про это уже сто раз написано и описано. Что там сложного? Пакуем матрицы костей в буфера/текстурки, и используем для скиннига в вертекс шейдере. Это было описано еще в GPU Gems 3 (Chapter 2. Animated Crowd Rendering). И реализовано в недавней Unite Tech Presentation. А можно ли по-другому?

Технодемка от Unity​

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

В масштабной битве сражаются две армии, каждая состоящая… из одного типа юнита. Слева скелеты, справа рыцари. Разнообразие так себе. Каждый юнит состоит из 3-х LOD (~300, ~1000, ~4000 вершин на каждый), и на вертекс влияют всего 2 кости. Система анимаций состоит из всего 7 анимаций на каждый тип юнита (напомню, что их аж 2). Анимации не блендятся, а переключаются дискретно из простого кода, который исполняется в job'ax, на которые делается акцент в презентации. Никакой стейт машины нет. Когда у нас два типа меша, то и рисовать всю эту толпу можно за два instanced draw call. Скелетная анимация, как я уже писал, основана на технологии описанной в далеком 2009 году. Новаторски? Хм… Прорыв? Эм… Подходит для современных игр? Ну, разве что, соотношением фпс к количеству юнитов хвастаться.

Основные недостатки данного подхода (пребейк матриц в текстуры):

• Зависимость от фреймрейта. Захотели в два раза больше кадров анимации — пожалуйте в два раза больше памяти.
• Отсутствие блендинга анимаций. Их конечно можно сделать, но в шейдере скиннига будет образовываться сложная каша из логики блендинга.
• Отсутствие привязки к Unity Animator стейт машине. Удобный инструмент для настройки поведения персонажа, который можно подключить к любой системе скинннига, но в нашем случае, по причине пункта 2, все становится очень сложно (представьте как блендить вложенные BlendTree).

GPAS​

GPU Powered Animation System. Название только что придумал. К новой системе анимаций предъявлялось несколько требований:

• Быстро работать (ну понятно). Нужно анимировать десятки тысяч различных юнитов.
• Быть полным (или почти) аналогом системы анимцаии Unity. Если там анимация выглядит так, то и в новой системе должно выглядеть точно также. Возможность переключения между built-in CPU и GPU системами. Это необходимо часто для отладки. Когда анимации «глючат», то переключением в классический аниматор можно понять: это глюки новой системы, или стейтмашины/самой анимации.
• Все анимации настраиваются в Unity Animator. Удобный, проверенный, а главное готовый к использованию, инструмент. Мы будем строить велосипеды в другом месте.

Переосмыслим подготовку и запекание анимаций. Матрицы мы использовать не будем. Современные видеокарты хорошо работают с циклами, нативно поддерживают int помимо float, так что мы будем работать с кейфреймами как на CPU.

Рассмотрим пример анимации в юнити Animation Viewer:

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

Позиция — Vector3, кватернион — Vector4, масштаб — Vector3. Структура кейфрейма у нас будет одна общая (для упрощения), так что нам нужно 4 float, чтобы уместить любой из вышеперечисленных типов. Еще нам надо InTangent и OutTangent для правильной интерполяции между кейфреймами согласно кривизны. Ах да, и нормализированное время не забыть:

struct KeyFrame
{
    float4 v;
    float4 inTan, outTan;
    float time;
};

Для получения всех кейфреймов используем AnimationUtility.GetEditorCurve(). Также, мы должны запомнить имена костей, так как надо будет сделать ремап костей анимации в кости скелета (а они могут не совпадать) на этапе подготовки гпу данных.

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

Теперь интересное. Анимация скелета на GPU.

Подготавливаем большой («количество анимированных скелетов» Х «количество костей в склете» Х «эмпирический коэффициент максимального количества блендов анимаций») буффер. В нем будем хранить позицию, вращение и масштаб кости в данный момент анимации. И для всех запланированных анимированных костей в этом кадре запускаем compute shader. Каждый thread выполняет анимацию своей кости.

Каждый кейфрейм, вне зависимости к какой величине он пренадлежит (Translate, Rotation, Scale), интерполируется абсолютно одинаково (поиск линейным перебором, да простит меня Кнут):

void InterpolateKeyFrame(inout float4 rv, int startIdx, int endIdx, float t)
{
    for (int i = startIdx; i < endIdx; ++i)
    {
        KeyFrame k0 = keyFrames[i + 0];
        KeyFrame k1 = keyFrames[i + 1];

        float lerpFactor = (t - k0.time) / (k1.time - k0.time);
        if (lerpFactor < 0 || lerpFactor > 1)
            continue;

        rv = CurveInterpoate(k0, k1, lerpFactor);
        break;
    }
}

Кривая представляет собой cubic Bezier curve, так что функция интерполяции будет следующая:

float4 CurveInterpoate(KeyFrame v0, KeyFrame v1, float t)
{
    float dt = v1.time - v0.time;
    float4 m0 = v0.outTan * dt;
    float4 m1 = v1.inTan * dt;

    float t2 = t * t;
    float t3 = t2 * t;

    float a = 2 * t3 - 3 * t2 + 1;
    float b = t3 - 2 * t2 + t;
    float c = t3 - t2;
    float d = -2 * t3 + 3 * t2;

    float4 rv = a * v0.v + b * m0 + c * m1 + d * v1.v;
    return rv;
}

Посчитали локальную позу (TRS) кости. Далее, отдельным compute shader'ом, сблендим все нужные анимации для данной кости. Для этого у нас есть буффер с индексами анимаций и весами каждой анимации в финальном бленде. Эту информацию мы получаем из стейт машины. Ситуация BlendTree внутри BlendTree решается так. Например есть такое дерево:

BlendTree Walk будет иметь вес 0.35, Run — 0.65. Соответственно, финальная позиция костей должна определяться 4-мя анимациями: Walk1, Walk2, Run1 и Run2. Их веса будут иметь значения (0.35 * 0.92, 0.35 * 0.08, 0.65 * 0.92, 0.65 * 0.08) = (0.322, 0.028, 0.598, 0.052) соответственно. Следует отметить, что сумма весов всегда должна быть равна еденице, не то волшебные баги обеспечены.

«Сердце» функции блендинга:

float bw = animDef.blendWeight;
			
BoneXForm boneToBlend = animatedBones[srcBoneIndex];
float4 q = boneToBlend.quat;
float3 t = boneToBlend.translate;
float3 s = boneToBlend.scale;

if (dot(resultBone.quat, q) < 0)
    q = -q;

resultBone.translate += t * bw;
resultBone.quat += q * bw;
resultBone.scale += s * bw;

Теперь можно перевести в матрицу трансформации. Стоп. Про иерархию костей забыли совсем. По данным из скелета строим массив индексов, где ячейка с индексом кости содержит индекс своего parent'a. В root записываем -1.

Пример:

float4x4 animMat = IdentityMatrix();
float4x4 mat = initialPoses[boneId];

while (boneId >= 0)
{
    BoneXForm b = blendedBones[boneId];
    float4x4 xform = MakeTransformMatrix(b.translate, b.quat, b.scale);
    animMat = mul(animMat, xform);

    boneId = bonesHierarchyIndices[boneId];
}

mat = mul(mat, animMat);
resultSkeletons[id] = mat;

Вот, в принципе и все основные моменты просчета и блендинга анимаций.

GPSM​

GPU Powered State Machine (вы правильно угадали). Система анимаций, описанная выше, прекрасно работала бы с Unity Animation State Machine, но в таком случае все усилия станут бесполезны. При возможностях просчета десятков (если не сотен) тысяч анимаций в кадр, UnityAnimator не вытянет и тысячи одновременно работающих стейт машин. Хм… Что представляет собой стейт машина в Unity? Это замкнутая система состояний и переходов, которая управляется простыми численными свойствами. Каждая стейт машина работает независимо друг от друга, и по одному и тому же набору входных данных. Постойте-ка. Это же идеальная задача для GPU и compute shader'ов!

Baking phase​

Сначала нам надо собрать и разместить в GPU friendly структуры все данные стейт машины. А это: состояния (states), переходы (transitions) и параметры (parameters). Все эти данные размещаются в линейные буфера, и адресуются по индексам. Каждый compute thread считает свою стейт машину. AnimatorController предоставляет интерфейс ко всем нужным внутренним структурам стейт машины.

Основные структуры стейт машины:

struct State
{
    float speed;
    int firstTransition;
    int numTransitions;
    int animDefId;
};

struct Transition
{
    float exitTime;
    float duration;
    int sourceStateId;
    int targetStateId;
    int firstCondition;
    int endCondition;
    uint properties;
};

struct StateData
{
    int id;
    float timeInState;
    float animationLoop;
};

struct TransitionData
{
    int id;
    float timeInTransition;
};

struct CurrentState
{
    StateData srcState, dstState;
    TransitionData transition;
};

struct AnimationDef
{
    uint animId;
    int nextAnimInTree;
    int parameterIdx;
    float lengthInSec;
    uint numBones;
    uint loop;
};

struct ParameterDef
{
    float2 line0ab, line1ab;
    int runtimeParamId;
    int nextParameterId;
};

struct Condition
{
    int checkMode;
    int runtimeParamIndex;
    float referenceValue;
};

• State содержит скорость с которой проигрывается состояние, и индексы условий прехода в другие согласно стейт машине.
• Transition содержит индексы состояния «из» и «в». Время перехода, время выхода и ссылку на массив условий входа в это состояние.
• CurrentState — это runtime data block с данными о текущем состояние стейт машины.
• AnimationDef содержит описание анимации со ссылками на другие, связанные с ней, по BlendTree.
• ParameterDef — это описание параметра управляющего поведением стейт машины. Line0ab и Line1ab — это коэффициенты уравнения прямых, для определения веса анимации по значению параметра. Отсюда:

Runtime Phase​

Главный цикл каждой стейт машины можно отобразить с помощью следующего алгоритма:

В Unity animator 4 типа параметров: float, int, bool и trigger (которая bool). Всех их мы представим как float. При настройке условий есть возможность выбрать один из шести типов сравнения. If == Equals. IfNot == NotEqual. Так что мы будем использовать только 4. Индекс оператора передаем в поле checkMode структуры Condition.

for (int i = t.firstCondition; i < t.endCondition; ++i)
{
    Condition c = allConditions[i];
    float paramValue = runtimeParameters[c.runtimeParamIndex];
    switch (c.checkMode)
    {
    case 3:	if (paramValue < c.referenceValue) return false;
    case 4:	if (paramValue > c.referenceValue) return false;
    case 6:	if (abs(paramValue - c.referenceValue) > 0.001f) return false;
    case 7:	if (abs(paramValue - c.referenceValue) < 0.001f) return false;
    }
}
return true;

Чтобы начать переход, необходимо, чтобы все условия были true. Странные case labels — это просто (int)AnimatorConditionMode. Interruption logic это хитрая логика прерывания и откатывания перехода.

После того как мы обновили состояние стейт машины и прокрутили time stamp'ы на delta t кадра, пора подготовить данные про то, какие анимации следует считать в этом кадре, и соответствующие веса. Этот этап пропускается, если моделька юнита не в кадре (Frustum culled). Зачем нам считать анимации того, чего не видно? Пробегаемся по blend tree source state, по blend tree destination state, добавляем все анимации из них, а веса считаем по нормализированному времени перехода из source в destination (времени пребывания в transition). C подготовленными данными в дело вступает GPAS, и считает анимации для каждой анимированной сущности в игре.

Из логики управления юнитами поступают параметры управления стейт машиной. Например надо включить бег, устанавливаем параметр CharSpeed, а правильно настроенная стейт машина плавно сблендит анимации перехода из «ходьбы» в «бег».

Естественно, что полной аналогии c Unity Animator не получилось. Внутренние принципы работы, если они не описаны в документации, приходилось реверсить и делать аналог. Некоторый функционал еще не доделан (может быть и не будет). Например BlendType в BlendTree поддерживается только 1D. Сделать другие типы, в принципе, не сложно, просто это сейчас не нужно. Нет animation event'ов, так как надо делать readback c GPU, а «правильный» readback будет отставать на несколько кадров, что не всегда приемлемо. Но тоже можно.

Рендер​

Рендер юнитов осуществляется с помощью инстансинга. По SV_InstanceID, в вертексном шейдере, получаем матрицы всех костей которые влияют на вертекс, и трансформируем его. Абсолютно ничего необычного:

float4 ApplySkin(float3 v, uint vertexID, uint instanceID)
{
    BoneInfoPacked bip = boneInfos[vertexID];
    BoneInfo bi = UnpackBoneInfo(bip);

    SkeletonInstance skelInst = skeletonInstances[instanceID];
    int bonesOffset = skelInst.boneOffset;

    float4x4 animMat = 0;
    for (int i = 0; i < 4; ++i)
    {
        float bw = bi.boneWeights[i];
        if (bw > 0)
        {
            uint boneId = bi.boneIDs[i];
            float4x4 boneMat = boneMatrices[boneId + bonesOffset];
            animMat += boneMat * bw;
        }
    }
    float4 rv = float4(v, 1);
    rv = mul(rv, animMat);
    return rv;
}

Итоги​

Быстро ли все это хозяйство работает? Явно медленнее, чем семплинг текстурки с матрицами, но, все же, кое-какие цифры я могу показать (GTX 970).

Вот 50000 стейтмашин:

Вот 280000 анимированных костей:

Разработка и отладка всего этого настоящая боль. Куча буферов и смещений. Куча компонентов и их взаимодействия. Бывало руки опускались, когда бъешься несколько дней о проблему головой, а найти, в чем неполадка, не можешь. Особенно «приятно», когда на тестовых данных все работает как надо, а в реальной «боевой» ситуации нет, да проскочит какой-то глюк анимации. Несоответствия работы стейтмашин Unity и своей, тоже не сразу видны. В общем, если решите сделать у себя аналог, то я вам не завидую. Собственно, вся разработка под GPU она такая, чего жаловаться.

P.S. Хочется кинуть камень в огород разработчиков Unite TechDemo. У них на сцене большое количество одинаковых моделей руин и мостов, а они никак не оптимизировали их отрисовку. Вернее они попытались, поставив галочку «static». Только вот, в 16 битные индексы не запихнешь много геометрии (три раза хаха, 2017 год) и ничего не объеденилось, так как модели высокополигональные. Я проставил всем шейдерам «Enable Instancing», и снял галку «Static». Ощутимого буста не произошло, но, блин, вы же технодемку делаете, боретесь за каждый фпс. Нельзя так лажать.

*** Summary ***

Draw calls: 2553
Dispatch calls: 0
API calls: 8378
  Index/vertex bind calls: 2992
  Constant bind calls: 648
  Sampler bind calls: 395
  Resource bind calls: 805
  Shader set calls: 682
  Blend set calls: 230
  Depth/stencil set calls: 92
  Rasterization set calls: 238
  Resource update calls: 1017
  Output set calls: 74
API:Draw/Dispatch call ratio: 3.28163

298 Textures - 1041.01 MB (1039.95 MB over 32x32), 42 RTs - 306.94 MB.
Avg. tex dimension: 1811.77x1810.21 (2016.63x2038.98 over 32x32)
216 Buffers - 180.11 MB total 17.54 MB IBs 159.81 MB VBs.
1528.06 MB - Grand total GPU buffer + texture load.

*** Draw Statistics ***

Total calls: 2553, instanced: 2, indirect: 2

Instance counts:
  1:  
  2:  
  3:  
  4:  
  5:  
  6:  
  7:  
  8:  
  9:  
  10:  
  11:  
  12:  
  13:  
  14:  
>=15: ******************************************************************************************************************************** (2)

*** Summary ***

Draw calls: 1474
Dispatch calls: 0
API calls: 11106
  Index/vertex bind calls: 3647
  Constant bind calls: 1039
  Sampler bind calls: 348
  Resource bind calls: 718
  Shader set calls: 686
  Blend set calls: 230
  Depth/stencil set calls: 110
  Rasterization set calls: 258
  Resource update calls: 1904
  Output set calls: 74
API:Draw/Dispatch call ratio: 7.5346

298 Textures - 1041.01 MB (1039.95 MB over 32x32), 42 RTs - 306.94 MB.
Avg. tex dimension: 1811.77x1810.21 (2016.63x2038.98 over 32x32)
427 Buffers - 93.30 MB total 9.81 MB IBs 80.51 MB VBs.
1441.25 MB - Grand total GPU buffer + texture load.

*** Draw Statistics ***

Total calls: 1474, instanced: 391, indirect: 2

Instance counts:
  1:  
  2: ******************************************************************************************************************************** (104)
  3: ************************************************* (40)
  4: ********************** (18)
  5: ****************************** (25)
  6: ********************************************************************************************* (76)
  7: *********************************** (29)
  8: ************************************************** (41)
  9: ********* (8)
  10: ************** (12)
  11:  
  12: ****** (5)
  13: ******* (6)
  14: ** (2)
>=15: ****************************** (25)

P.P.S. Во все времена игры были, в основном, CPU bound, т.е. CPU не успевал за GPU. Слишком много логики и физики. Пренося часть игровой логики с CPU на GPU, мы разгружаем первый и нагружаем второй, т.е. делаем ситуацию GPU bound более вероятной. Отсюда и название статьи.

— cпросили меня. «Да не вопрос! Конечно, смогу», — ответил я, но голос предательски задрожал. «А, еще и на Unity?», — и мне стало понятно, что впереди очень много работы.

Итак, водичка. Unity до того момента я в глаза не видел, ровно как и C#, так что решил, что буду делать прототип на знакомых мне инструментах: С++ и DX9. Что я знал и умел на практике на тот момент так это скроллящиеся текстурки нормалей для формирования поверхности, и примитивный дисплейсмент маппинг на их основе. Тут же надо было менять абсолютно все. Реалистичная анимированная форма водной поверхности. Усложненый (сильно) шейдинг. Генерация пены. LOD система, привязанная к камере. Начал я выискивать информацию в интернете как же все это сделать то.

Первым пунктом, естественно, было вникание в «Simulating Ocean Water» Джерри Тессендорфа.

Академические пейперы с кучей заумных формул никогда мне особо не давались, так что после пары прочтений я мало что понял. Общие принципы были понятны: каждый кадр генерируется карта высот с помощью Fast Fourier Transform, которая, как функция от времени, плавно меняет свою форму формируя реалистичную водную поверхность. Но как и что считать я не знал. Я потихоньку вникал в премудрости просчета FFT на шейдерах в D3D9, и мне в этом очень помог исходник со статьей где-то в дебрях интернета, который я битый час пытался отыскать, но безуспешно (к сожалению). Первый результат был получен (страшный как ядерная война):

Стартовые успехи порадовали, и начался перенос воды на Unity с его доработкой.

К воде в игре про морские битвы выдвигались несколько требований:

Реалистичный внешний вид. Красивые как близкие так и дальние ракурсы, динамическая пена, скаттеринг и т. д. Поддержка различных погодных условий: штиль, шторм и промежуточные состояния. Смена времени суток. Физика плавучести кораблей по симулированной поверхности, плавучие объекты. Так как игра мультиплеерная, вода должна быть у всех участников боя одинаковая. Рисование по поверхности: нарисованные зоны полета ядер залпа, пена от попаданий ядер в воду.

Геометрия​

Решено было построить quadtree-like структуру, с центром вокруг камеры, которая дискретно перестраивается при движении наблюдателя. Почему дискретно? Если двигать меш плавно вместе с камерой или использовать screen space reprojection как в статье Real-time water rendering — introducing the projected grid concept, то на дальних планах из-за недостаточного разрешения геометрической сетки при выборке карты высот волны будут «скакать» полигоны вверх и вниз. Это очень сильно бросается в глаза. Картинка «рябит». Чтобы это побороть, надо либо сильно увеличивать разрешение полигональной сетки water mesh'a, либо «уплощать» геометрию на дальних дистанциях, либо так строить и двигать полигоны, чтобы эти сдвиги не было видно. Вода у нас прогрессивная (хехе) и выбрал я третий путь. Как и в любой подобной технике (особенно знакомой всем, кто создавал terrain в играх), необходимо избавиться от T-junctions на границах переходов уровней детализации. Для решения этой задачи на старте предрасчитывается 3 вида квадов с заданными параметрами тесселяции:

Первый тип для тех квадов, которые не являются переходными на более низкую детализацию. Ни одна из сторон не имеет уменьшенное в 2 раза количество вершин. Второй тип для граничных, но не угловых квадов. Третий тип — угловые граничные квады. Финальный меш для воды строится поворотом и масштабированием этих трех видов мешей.

Вот так выглядит рендер с подсветкой разным цветом LOD уровней воды:

На первых кадрах видно соединение двух различных уровней детализации.

Видео как кадр заполняется водяными квадами:

Напомню, это все было давно (и неправда). Сейчас более оптимально и гибко можно сделать сразу на GPU (GPU Pro 5. Quadtrees on the GPU). И рисовать будет в один draw call, и тесселяцией можно поднять детализацию.

Позднее проект переехал на D3D11, но до апгрейда этой части рендера океана руки так и не дошли.

Генерация формы волны​

Вот для этого нам понадобится Fast Fourier Transform. Для выбранного (нужного) разрешения текстуры волны (пока назовем ее так, далее я объясню, какие данные там хранятся) подготавливаем начальные данные, используя параметры, заданные художниками (сила, направление ветра, зависимость волны от направления ветра и другие). Все это необходимо скормить в формулы т.н. Phillips spectrum'а. Полученные начальные данные модифицируем каждый кадр с учетом времени и выполняем FFT над ними. На выходе получаем тайлящуюся по всем направлениям текстуру которая содержит смещение вершин плоского меша. Почему не просто heightmap? Если хранить только оффсет по высоте, то результатом будет нереалистичная «бурлящая» масса, лишь отдаленно напоминающая море:

Если считать смещения для всех трех координат, то будут генерироваться красивые «острые» реалистичные волны:

Одной анимированной текстурки мало. Виден тайлинг, недостаточно деталей на ближних планах. Берем описанный алгоритм и делаем не одну, а 3 fft-generated текстуры. Первая — крупные волны. Она задает основную форму волны и используется для физики. Вторая — средние волны. Ну и напоследок самые мелкие. 3 FFT генератора (4-й вариант это финальный микс):

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

«Одинаковость» воды у всех участников боя обеспечивается синхронизацией параметров океана на старте боя. Эту информацию передает сервер каждому клиенту.

Физическая модель плавучести​

Так как необходимо было сделать не только красивую картинку, но и реалистичное поведение кораблей. А также учитывая то, что в игре должно присутствовать штормовое море (крупные волны), то еще одной задачей, которую требовалось решить, являлось обеспечение плавучести объектов на поверхности сгенерированного моря. Сперва я попытался сделать GPU readback текстуры волны. Но, так как быстро выяснилось, что всю физику морского боя необходимо делать на сервере, то и море, а точнее первый его слой который задает форму волны, необходимо считать также и на сервере (а на нем, скорее всего, нет быстрого и/или совместимого GPU), то было принято решение написать полную функциональную копию GPU FFT генератора, на CPU в виде native C++ плагина к Unity. Сам FFT алгоритм я не реализовывал и использовал готовый в библиотеке Intel Performance Primitives (IPP). А вот всю обвязку и постпроцессинг результатов был выполнен мной, с последующей оптимизацией на SSE и распараллеливанием по потокам. Сюда входила и подготовка массива данных для FFT каждый кадр, и финальное преобразование посчитанных значений в wave offset map.

Была еще одна интересная особенность алгоритма, которая исходила из требований к физике воды. Нужна была функция быстрого получения высоты волны в данной точке мира. Логично, ведь это и есть основа построения плавучести любого объекта. Но, так как на выходе FFT процессора у нас получалается offsetmap, а не heightmap, то обычная выборка из текстуры не давала нам высоту волны там где было необходимо. Для простоты рассмотрим 2D вариант:

Для формирования волны, тексели (текстурные элементы, показанные вертикальными линиями) содержат вектор (стрелки) который задает смещение вертекса плоского меша (синие точки) в направлении его финальной позиции (острие стрелки). Предположим мы возьмем эти данные и попробуем извлечь из нее высоту воды в интересующей нас точке. Например, нам надо узнать высоту в точке hB. Если мы возьмем вектор в текселе tB, то мы получим смещение в точку около hC, что может сильно отличаться от того что нам нужно. Вариантов решения этой проблемы два: при каждом запросе высоты проверять множество соседних текселей, пока не найдем тот, который имеет смещение в интересующую нас позицию. В нашем примере мы найдем тексель tA как содержащий наиболее близкое смещение. Но такой подход не назовешь быстрым. Сканирование радиуса текселей непонятно какого размера (а от того, штормовое море или спокойное, смещения могут сильно варьироваться) может занять продолжительное время.

Второй вариант — после просчета offset map конвертировать ее в height map, используя scattering подход. Это означает, что для каждого offset vector'а мы запишем высоту волны, которую он задает, в ту точку, куда он смещается. Это будет отдельный массив данных, который и будет использоваться для получения высоты в интересующей точке. Используя нашу иллюстрацию, ячейка tB будет содержать высоту hB полученную из вектора tA→hB. Есть еще одна особенность. Ячейка tA не будет содержать валидного значения, так как нет вектора, смещающегося в него. Для заполнения таких «дырок» выполняется проход заполнения их соседними значениями.

Вот так это выглядит, если сделать визуализацию смещений с помощью векторов (красные — большое смещение, зеленый — малое):

Далее все просто. Для корабля задается плоскость условной ватерлинии. На ней определяется прямоугольная сетка точек-проб, которая задает места приложения выталкивающих из воды сил для корабля. Затем для каждой точки проверяем, под водой она или нет, используя water heightmap, описанную выше. Если точка под водой, то прикладываем вертикальную силу вверх к physics hull корпуса в этой точке, масштабированной расстоянием от точки до водной поверхности. Если над водой, то ничего не делаем, гравитация сделает все для нас. На самом деле там формулы немного сложнее (вся для тонкого тюнига поведения корабля), но основной принцип такой. На видео визуализации плавучести ниже, синие кубы — это места расположения проб, а линии от них вниз — это величина выталкивающей из воды силы.

В реализации сервера есть еще один интересный оптимизационный момент. Нет никакой надобности симулировать разную воду для разных боевых инстансов, если они проходят в одинаковых погодных условиях (одинаковые параметры FFT симулятора). Так что логичным решением было сделать пул симуляторов, к которым боевые инстансы выполняют запросы на получение симулированной воды с заданными параметрами. Если параметры одинаковые от нескольких инстансов, то им вернется одна и та же вода. Реализовано это с помощью Memorу Mapped File API. Когда FFT симулятор создается, он дает доступ к своим данным, экспортируя дескрипторы нужных блоков. Серверный инстанс вместо того, чтобы запускать реальный симулятор, запускает «пустышку» которая просто отдает данные, открытые по этим дескрипторам. Было несколько веселых багов, связанных с этим функционалом. Из-за ошибок подсчета ссылок симулятор уничтожался, но memory mapped file жив пока открыт хоть один дескриптор на него. Данные переставали обновляться (симулятора-то нет) и вода «останавливалась».

На клиентской стороне нам необходима информация о форме волны для просчета попаданий ядер в волну и проигрывания систем частиц и пены. Просчет повреждений происходит на сервере и там также необходимо корректно определять, попало ли ядро в воду (волна может закрывать корабль, особенно в штормах). Тут уже необходимо делать heightmap tracing по аналогии как это делается в parallax mapping либо SSAO эффектах.

Шейдинг​

В принципе как и везде. Отражения, преломления, subsurface scattering хитро замешиваем, учитывая глубину дна, учитываем fresnel effect, считаем спекуляр. Скаттеринг считаем для гребней в зависимости от позиции солнышка. Пена генерируется следующим образом: создаем «пятно пены» на гребнях волн (используем высоту как метрику), затем накладываем новосозданные пятна на пятна с предыдущих кадров одновременно уменьшая их интенсивность. Таким образом получаем размазывание пятен пены в виде хвоста от идущего гребня волны.

Используем полученную текстуру «пятен» как маску к которой примешиваем текстуры пузырьков, разводов и т. д. Получаем довольно реалистичный динамический рисунок пены на поверхности волн. Данная маска создается для каждого FFT слоя (напомню, у нас их 3), и в финальном миксе они все смешиваются.

На видео выше визуализация маски пены. Первый и второй слои. Я модифицирую параметры генератора и результат виден на текстуре.

И видео немножко коряво настроенного штормового моря. Тут хорошо видна форма волны, возможности генератора и пена:

Рисование по водной поверхности​

Картинка-пример использования:

Используется для:

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

Очевидный базовый вариант — проективное текстурирование. Оно и было реализовано. Но тут появились дополнительные требования. Ближние виды — мыло из-за недостаточного разрешения (можно увеличивать, но не бесконечно), и хочется чтобы далеко было видно эти проективные рисунки на воде. Где решается такая же задача? Правильно, в тенях (shadow map). Как она там решается? Правильно, Cascaded (Parallel Split) Shadow Maps. Возьмем и мы эту технологию на вооружение и применим к нашей задаче. Разбиваем фрустум камеры на N (3-4 обычно) сабфрустумов. Для каждого строим описывающий прямоугольник в горизонтальной плоскости. Для каждого такого прямоугольника строим orthographic projection матрицу и рисуем все интересующие объекты для каждой из N таких ortho камер. Каждая такая камера рисует в отдельную текстуру, а затем, в шейдере океана, мы их комбинируем в одну цельную проективную картинку.

Вот я положил на море большущую плоскость с текстурой флагов:

Вот то что содержится в сплитах:

Кроме обычных картинок надо абсолютно таким же образом нарисовать дополнительную маску пены (для следов кораблей и мест попаданий ядер), а также маску выдавливания воды под кораблями. Это много камер и много проходов. Поначалу оно так тормозно и работало, но затем, после перехода на D3D11, с помощью «размножения» геометрии в геометрическом шейдере и рисования каждой копии в отдельный render target через SV_RenderTergetArrayIndex, удалось сильно ускорить этот эффект.

Улучшения и модернизации​

D3D11 очень сильно развязывает руки во многих моментах. После перехода на него и Unity 5 я сделал FFT генератор на сompute шейдерах. Визуально ничего не поменялось, но стало чуточку быстрее. Перевод просчет текстуры отражений с отдельного полноценного рендера камеры на технологию Screen Space Planar Reflections дал неплохой буст производительности. Про оптимизацию water surface objects я писал выше, а до перевода mesh'а на GPU Quadtree руки так и не дошли.

Многое, возможно, можно было сделать оптимальнее и проще. Например, не городить огороды с CPU симулятором, а просто запустить GPU вариант на сервере с WARP (программным) d3d девайсом. Массивы данных там не очень большие.

Ну, в общем как-то так. В то время, как разработка начиналось, все это было современно и круто. Сейчас уже местами подустарело. Появилось больше доступных материалов, даже есть похожий аналог на github: Crest. В большинстве игр, где есть моря, используется похожий подход.

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

Рендер игры построен на базе технологии Direct3D 9. Это позволяет покрыть более широкую аппаратную базу видеокарт, а те расширенные возможности, которые предлагает D3D 10 и 11 зачастую либо вовсе не нужны, либо реализуемы теми или иными способами в девятой версии.

Тени​

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

Лайтмапа просчитывается заранее в пакете 3Д моделирования (3ds max, Maya), либо собственным рейтрейсером в редакторе уровней. Одна такая текстура используется для нескольких игровых объектов, либо их частей, если объект крупный (например, террейн).

Для динамических объектов (монстры, фигурки персонажа) используются динамические тени выполненные по технологии “shadow map” (stencil shadows в наше время уже практически не используется). Разработчики решили отступить от классических канонов в этой сфере, и не использовали hardware shadows (текстуры которые могут быть использованы как буфера глубины, и поддерживающие аппаратный Percentage Closer Filtering – PCF), которые предлагают все популярные производителями видеокарт. Вместо этого, была применена технология Variance Shadow Maps. Она позволяет получить мягкие края путем стандартного размытия текстуры тени (для классических карт теней этот метод неприменим, так как усреднение значений глубины пикселя не имеет смысла). Подробности VSM я расписывать не буду (см. полезные ссылки в конце статьи), скажу лишь только, что для ее реализации необходимо хранить 2 значения: глубину пикселя и глубину пикселя в квадрате. Именно второе значение диктует довольно жесткие условия к точности хранения этой информации, поэтому была выбрана текстура формата A32B32G32R32 float. Размер ее при максимальных настройках качества теней 2048х2048.

Процесс создания карты теней стандартный. Рисуем все объекты отбрасывающие тень (окклюдеры) в карту тени с позиции источника освещения. Размываем карту тени сначала по горизонтали, а затем по вертикали. При рендере объектов, которые должны получать тень (ресиверы), семплим шадоу мапу, определяем степень освещенности пикселя и соответственным образом затемняем финальный цвет. Семплинг карты теней должен происходить с билинейной фильтрацией. Аппаратная фильтрация формата A32B32G32R32F поддерживается далеко не всей линейкой shader model 3.0 capable видеокарт, поэтому она реализуется программно, в шейдере (хотя на моей видеокарте она поддерживается, но это не учли).

Рендеринг теней происходит с ортографической проекцией, если тень от направленного (directional) источника (солнце), либо с перспективной для конусовидных (omni). Техники перспективного искажения карты теней (например, Perspective Shadow Maps,Trapezoidal Shadow Maps и др.) для положения камеры используемой в игре (направление взгляда сверху вниз, под небольшим углом к направлению главного источнику освещения) не нужны и не используются. Каскадное разделение теней на сектора (Cascaded Shadow Maps, Parallel Split Shadow Maps) не реализованы по тем же причинам. Карта тени в разрешении 512х512 со сглаживанием и без:

Шейдер для патча террейна в варианте со сглаживанием состоит из 12 текстурных и 59 арифметических инструкций. Без сглаживания 10 и 29 соответственно. Разница в арифметических инструкциях есть реализация билинейной фильтрации и VSM.

Динамическое освещение​

Удивительно, но все динамическое освещение повертексное. Как в старые добрые времена. Никаких карт нормалей в игре нет. Смелое решение, но учитывая финальный результат, очевидно, что он себя оправдал на 100%. Недостатка в детализации геометрии совершенно не ощущается. В вертексном шейдере реализованы один точечный источник света с квадратичной аттенюацией (как в классических FFP формулах), один цилиндрический источник (он используется как подсветка персонажа, для освещения близкого окружения героя) и до 16 точечных источников с простейшей линейной аттенюацией по расстоянию.

В игре реализованы также объемные источники освещения. Сделаны они следующим образом. Рисуем сферу, или другую выпуклую фигуру, в месте источника освещения. В вершинном шейдере высчитываем альфу вертексов на основе нормали и вектора направления камеры. Чем больше угол между ними, тем большая прозрачность должна быть. Получаем полупрозрачную сферу с увеличением прозрачности от центра к краям. Так как эта сфера будет пересекать геометрию уровня, мы получим визуальный артефакт изображения в месте пересечения объектов уровня и самой сферы. Данный недостаток исправляется абсолютно таким же методом, как и делаются так называемые soft particles. Берется выборка из буфера глубины и сравнивается с глубиной отрисовывамого пикселя. Если значения близки, то модифицируя альфу (уменьшая ее до нуля), мы делаем место пересечения геометрий невидимым.

Специальные эффекты​

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

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

Для некоторых эффектов (пост-процесс, в частности) необходима информация о глубине сцены в данной точке. Стандартные средства Direct3D 9 не позволяют получить буфер глубины как текстуру для последующего чтения. Очевидным вариантом будет рендеринг всей сцены еще раз, с выводом глубины пикселей в текстуру формата R32F. Этот метод в большинстве случаев неприемлем, так как удвоение отрисовываемой геометрии сильно скажется на общей производительности игры. Производители графических адаптеров давно знают об этой проблеме, и предлагают специальные форматы текстур, которые могут использоваться и как текстура в шейдере, и как буфер глубины при рендеринге. Одним из таких форматов является так называемый INTZ формат. Он то и используется в Diablo III. Текстура такого типа используется при рендеринге сцены как depth buffer, а затем значения из нее можно получить в шейдерах, где необходима информация о глубине. Я не знаю, как выполняется рендеринг на аппаратуре, которая не поддерживает INTZ текстуры (не все shader model 3 видеокарты поддерживают данный «хак»), у меня нет видеокарты без такой поддержки. Возможно, выполняется дополнительный проход, либо эффекты, зависящие от глубины, реализуются по-другому, либо совсем выключаются.

Подсветка объектов под курсором реализуется путем рендеринга выделяемого объекта в отдельную текстуру. Шейдер при этом используется простейший – вывод единицы в альфа канал рендер таргета, и цвета выделения в rgb каналы. Затем полученная текстура размывается по горизонтали и вертикали. Для корректного наложения эффекта и получения финального изображения необходимо оставить только ореол объекта, но не его основной силуэт. Имея оригинальное (не размытое) изображение, финальный шейдер наложения проверяет значение альфа канала в этой текстуре. Если он равен 1 (объект в этом пикселе есть), то выводимый альфа канал устанавливается в ноль. Если значение 0 (объекта в этом пикселе нет), то используется альфа канал размытой текстуры.

Пост-процесс эффекты​

Количеством пост-процесс эффектов игра похвастаться не может. Среди всего арсенала были замечены bloom, full screen distortion и полноэкранное сглаживание, выполненное по технологии FXAA. Дисторшн реализуется по классической схеме. Отрисовываем партиклы, которые должны привносить искажения в финальную картинку (горячий воздух, например) в специальную текстуру. Записываемые данные являются u и v смещениями текстурных координат. В следующем полноэкранном проходе используем эту текстуру и смещаем текстурные координаты для семплинга основного изображения сцены.

Полноэкранное сглаживание выполнено также как пост-процесс эффект. Причин этому несколько. Использование INTZ буфера глубины становится невозможным (нельзя создать чистый multisampled INTZ depth buffer для последующего копирования его в non-multisampled INTZ текстуру), и shadow map будет занимать очень много памяти (напомню, что ее формат A32R32G32B32F, т.е. 16 байт на пиксель). Полноэкранное сглаживание в игре выполнено по технологии Fast Approximate Anti-Aliasing (FXAA).

Геометрия и материалы​

Все данные вершин игровых моделей упакованы в cache-friendly 32 байт формат. Исключение составляют анимированные модели, там 48. Дополнительные данные это веса костей их индексы. В игре используется скелетная анимация, которая выполняется в шейдере. По этой причине для анимированных моделей количество точечных источников ограничено семью, из-за нехватки константных регистров для хранения параметров источников освещения и матриц костей.

Общее количество draw call’s невелико. Значение колеблется в пределах 300-800 DIP, что является хорошим показателем.

Шейдера выполнены по технологии uber-shader, т.е. компиляция множества вариантов одного эффекта с помощью перебора набора дефайнов препроцессора. Например эффект может быть с туманом и без, с тенью и без, с лайтмапой и без. За туман, тень и лайтмапу отвечает определенный define вида: #define USE_FOG 1. В теле шейдера блок кода, отвечающий за наложение тумана выполнен внутри блока #if USE_FOG … #endif. Таким образом переключая значение USE_FOG 1/0, мы получаем шейдер с туманом и без. Схожим образом делаются и все эффекты. Система сборки всех вариантов шейдеров, автоматически перебирает весь набор значений дефайнов, и для каждого набора компилирует шейдер.

Пользовательский интерфейс​

Внутриигровой интерфейс отрисовывается на экран довольно стандартно. Особой группировки элементов с целью уменьшения вызовов на отрисовку (DIP calls) не наблюдается. Хочется отметить рендеринг текста. Подготовка символов для рендера очень похожа на метод используемый в Scaleform GFX. Все уникальные символы отрисовываются в отдельную текстуру, и уже эта текстура используется для рендеринга текста. Не смотря на схожесть текстового рендера, сам Scaleform не используется.

Послесловие​

Сам рендер оставляет приятные впечатления. Такой себе микс олдскула и некоторых современных веяний. Производительность на высоте при красивой картинке (как всегда у игр от Blizzard, собственно). Большую роль в этой всей красоте отыгрывает работа художников и дизайнеров. Diablo III еще раз доказывает, что очень красивую графику можно сделать и на не самом технологичном рендере.

Полезные ссылки​

• Variance Shadow Maps. www.punkuser.net/vsm
• FXAA. https://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf
• Список известных GPU «хаков». https://aras-p.info/texts/D3D9GPUHacks.html

Рендер роликов концептуально очень похож на рендер игры, но есть и отличия. Как и в игровом рендере, если есть глобальные источники освещения, то создается шадоумапа от них. Затем идет отрисовка всех объектов в 4 рендер таргета формата argb16f:

1. Основной буфер, куда ведется рендер цвета с освещением от глобальных источников. Альфа канал не используется.

2. Нормали в пространстве камеры. В альфа канале глубина сцены.

3. Диффузный цвет, который используется для некоторых пост процесс эффектов в дальнейшем. В альфа канал идет предрасчитанный статический (из текстур) АО фактор.

4. Спекуляр фактор в RGB, альфа канал не используется.

После того как заполнили буфера нужными данными идет рендер локальных источников освещения. Алгоритм абсолютно аналогичен описанному в первой части. Помечаем область влияния источника с помощью стенсил буфера и геометрического футпринта, а затем рендерится опять этот же футпринт с шейдером освещения. Deferred shading в чистом виде. Для источников, которые должны отбрасывать тень сначала рендерится шадоумапа с его позиции (для спот и направленных источников; omnidirectional shadowmaps замечены небыли) затем рендерится деферред источник с этой картой тени. Пару примерчиков шадоумап:

Для примера, в этой сцене что на всех скриншотах, 24 deferred источника освещения, которые не отбрасывают тень, и еще 7, которые отбрасывают. Вот как получилось после применения источников освещения:

После идут все полупрозрачные объекты. Для крупных объектов прямо на месте применяется пост процесс эффект для искажения изображения находящегося за полупрозрачным объектом. Для этого используется текстура с диффузным цветом в рендер таргете 3. В рендере старкрафта 2 присутствуют также волуметрик эффекты, как то volumetric light и volumetric fog. Реализуется данный эффект в 5 проходов:

1. Рендерим бэкфейсы объема очерчивающего границы влияния volumetric эффекта. Тест глубины включен. Записываем глубину в рендер таргет.

2. Включаем альфаблендинг в режим сложения цветов (Blend source: D3DBLEND_ONE, Blend destination: D3DBLEND_ONE, Blend operation: D3DBLENDOP_ADD) и рисуем фронтфейсы объема, выводя отрицательную глубину пикселя. При блендинге пикселей происходит операция: глубина дальней стенки – глубина ближней стенки, что есть толщина объема в пространстве камеры.

3. Толщину объема мы получили, и можем варьировать прозрачность в зависимости от этого числа, но нам надо еще учитывать объекты внутри объема. Для этого мы опять рендерим бекфейсы объема, но с инвертированным тестом глубины (D3DCMP_GREATER). Режим блендинга остался таким же как и в предыдущем шаге.

4. Так как на предыдущем шаге мы учитывали все объекты перед задней стенкой объема, даже те, что перед передней стенкой, мы должны исправить этот момент. Рисуем фронтфейсы с режимами как в шаге 3, только выводим минус глубину. Т.о. мы отнимаем глубину всех неверно учтенных пикселей, что находятся перед объемом volumetric эффекта.

5. Используя текстуру глубины полученную на шагах 1-4, рисуем объем еще раз, но уже в главный рендер таргет цвета изменяя прозрачность в зависимости от глубин пикселей. Скриншот только эффекта:

Результат с остальной картинкой:

Далее идет Depth-of-Field. Эффект реализован достаточно интересно и в точности повторяет описание в презентации от разработчиков которую я упомянул в первой части. Я не буду повторяться тут, скажу лишь, что основная борьба велась за корректность отображения эффекта (правильность блендинга объектов перед, в и позади фокуса). После DoF идет Bloom. И на этом рендеринг заканчивается.

Отдельно хочется отметить 2 момента: Очень качественный рендеринг кожи человека, даже без применения хитрых техник, таких как texture space diffusion и subsurface scattering. Качественная настройка материалов и используемых текстур опять зарулило.

Отсутствие SSAO. Да-да. То о чем писали разработчики в своем докладе, почему-то не используется. Хотя шейдеры присутствуют. Я перепроверил настройки рендера когда обнаружил, что АО канал заполняется во время основного прохода рендера в 4 РТ. Видимо предрасчитанное АО устроило арт отдел. Вот красивая текстура лица Джима Рейнора с АО:

Вот собственно и все. Пишите комментарии, задавайте вопросы.

Технологии шагнули далеко вперед. Уже можно играть в игры с поддержкой DX11. Есть игры которые изначально разрабатывались на DX10 и не поддерживают DX9 железо. Но, игры компании Близзард всегда славилась поддержкой широкого спектра аппаратуры (взять тот же ВоВ, который и на ФФП нормально бегает). Не исключением стала и SC2. Рендер стратегии разработан с использованием D3D версии 9 (для windows). DX10 не поддерживается. Я думаю после нескольких лет разработки было накладно переводить рендер на новый АПИ, поэтому имеем только DX9 (и Open GL для Mac).

Первое с чем я столкнулся после того как я сел за дело были проблемы с тулзами. СК2 использует хитрую систему запуска, через всякие лоадеры, так что под PerfHUD’ом запустить не удалось. Можно было бы поковыряться в исходниках лоадера (который форсит PerfHUD девайс), чтобы скипал несколько процессов, но из-за того, что стар молча выходил, при попытках тестовых запусков, я отложил вариант с PerfHUD’ом. Плюс некоторый функционал этого профайлера перестал работать на новой Win7 OS (не показывает перфоманс графики). Новый профайлер Nvidia Parallel Insight показал себя с лучшей стороны. Он быстрый, удобный и практически не глючный. Один недостаток – DX9 не поддерживается. Так что у меня оставался всего один вариант – MS PIX for Windows. За два года данную тулзу немного улучшили (особенно в плане производительности), так что пользовался я исключительно ей.

Вторая неприятность возникла, когда я взглянул на шейдеры. Обычно, когда шейдер собирается из эффект (*.fx) файла, то в бинарном байткоде остается немного дебаговой информации. Это информация включает комментарии в начале шейдера с блоком прешейдера (если используется) и, что самое главное, названия переменных и их соответствия константным регистрам.

Вот как выглядит шейдер который я ожидал: http://www.everfall.com/paste/id.php?fgnlr6ffcx0y Вот так выглядят шейдера от Близзард: http://www.everfall.com/paste/id.php?njt5do17c4bi Что в первом, что во втором случае разобрать по асму что там происходит сложно, но в первом примере есть имена переменных, по которым можно сориентироваться. В общем, я понял, что так я далеко не уеду, и полез ковырять данные игры. Распаковал пару MPQшек, и нашел исходники шейдеров. Зачастую мне было сходу понятно, что делается в данном draw call. Но иногда я заходил в тупик. Помогало медитирование над входными текстурами, вертекс форматом и константами объявленными в шейдере. Если вижу, например, операцию вычитания двух регистров, один из которых константный со значением 1.5, я ищу по всем hlsl шейдерам текст -1.5 (или просто 1.5) и часто с первого раза попадаю в нужный. Если шейдер небольшой, то разбирал прямо по ассемблеру.

По рендеру СК2 есть замечательная дока: http://developer.amd.com/documentation/presentations/legacy/Chapter05-Filion-StarCraftII.pdf В ней описаны многие аспекты рендера, и я ей активно пользовался. Рекомендую к ознакомлению.

Данный разбор касается только игровой части рендера. Рендер роликов будет отдельным постингом.

Хочется остановиться на системе материалов используемой в СК2. Применяется техника убершейдера, с плотной интеграцией в С++ код. Вот пример главной функции пиксельного шейдера и вычисления цвета материала: http://www.everfall.com/paste/id.php?bjpc19uks7he. Как видно, в исходном коде имеются множественные проверки булевых констант, которые определяют разветвления комбинаций опций шейдинга. Система пиксельной обработки построена на т.н. слоях (layers) каждый из которых состоит из одной текстуры (вернее самплера) и параметров-свойств этого слоя. Вот как оно реализовано: http://www.everfall.com/paste/id.php?5ekjmezzcllx. В шейдере, перед телом, идет декларация нескольких слоев:

DECLARE_LAYER(Diffuse);
DECLARE_LAYER(Decal);
DECLARE_LAYER(Specular);
DECLARE_LAYER(Emissive);
DECLARE_LAYER(Emissive2);
DECLARE_LAYER(Envio);
DECLARE_LAYER(EnvioMask);
DECLARE_LAYER(AlphaMask);
DECLARE_LAYER(AlphaMask2);
DECLARE_LAYER(Normal);
DECLARE_LAYER(Heightmap);
DECLARE_LAYER(Lightmap);
DECLARE_LAYER(AmbientOcclusion);

Настройка слоя происходит внутри тела шейдера с помощью макроса SETUP_LAYER (пример можно посмотреть в предыдущей ссылке с кодом главной функции пиксельного шейдера). DX Effect System не используется. В доке указанной выше, сказано, что система материалов разрабатывалась для максимального удобства программистов. Плюсовая часть ее мне не видна, к сожалению, но шейдерная сделана довольно интересно.

Рендер сцены начинается с рендера карты тени (shadowmap) размером 2048х2048 пикселов. Трик с нулевым рендер таргетом не используется. Соответствующий буфер цвета используется для рендера полупрозрачных объектов с позиции источника света для создания цветных теней. Также для полупрозрачный объектов используется отдельная карта теней с тем же размером. Искажающие перспективу и каскадные техники не используются по понятным причинам. Камера никогда не смотрит вдаль, и в нормальном игровом процессе расположена под углом 60-70 градусов к поверхности земли. В данной ситуации ни каскадные тени ни перспективное искажение возле положения камеры не дадут сколь видимого эффекта.

Пример шадоумапы:

Пример буфера цвета для цветных теней:

Далее если в игре присутствует зерг, то создается текстура крипа (такая коричневая субстанция, которая покрывает землю вокруг базы зерга). Если вы играли в СК2, то возможно заметили, что на крипе присутствует эффект движения. Делается он просто. Из чёрно-белой текстуры шума с помощью нескольких коэффициентов выделяются несколько пятен. Затем полученная карта высот трансформируется в карту нормалей. Затем данная карта нормалей используется в дальнейшем для рендеринга самого крипа на земле.

Оригинальная текстура шума:

Полученная карта высот:

Карта нормалей полученная из карты высот:

Заметьте, что оригинальная карта высот сделана тайлящейся по всем направлениям. Т.о. мы имеем тайлящуюся карту нормалей.

Дальше начинается основной рендеринг. Устанавливается 3 рендертаргета формата ARGB16F в первые 3 MRT слота. Первый RT содержит освещенную глобальными источниками света картинку. Второй нормали в пространстве камеры. Третий только диффузный цвет.

Система освещения в СК2 комбинированная. Глобальные источники, как то солнце и те что занимают много места на экране, применяются сразу в первом проходе (т.е. forward shading). Множество мелких источников применяются после, с помощью аддитивного блендинга (т.е. deferred shading). Deferred источники используют стенсил для минимизации обрабатываемых пикселей. Стенсил буфер очищается, и перед отрисовкой deferred источника, рендерится его футпринт (т.е. шар для точечных, конус для спот источников). Сначала помечаем всю поверхность источника света, а затем исключаем из стенсил маски те участки, где прошел тест глубины для бэк-фейс полигонов. Т.о. получается маска пикселов которые буду затронуты данным источником освещения. Forward источников может быть не много, упираемся в шейдерные константы:

#define MAX_DIRECTIONAL_LIGHTS 3
#define MAX_POINT_LIGHTS 5
#define MAX_SPOTLIGHTS 5

Deferred источников может быть бесконечное множество.

Перед рендером геометрии с шейдингом идет depth prepass, в котором заполняется буфер глубины патчами земли. Почему только земля? Потому что, неровности земли часто скрывают элементы ландшафта, а остальные объекты небольшие. Таким образом, экономим еще немного производительности на пиксельной обработке.

Шейдеры главного прохода очень большие. Наложение теней, полупрозрачных теней, параллакс маппинга (в коде шейдера реализованы методы relief mapping и parallax occlusion mapping. Хорошо видно после взрыва протосовского здания – котлован взрыва), тумана войны, наложение крипа, того же направленного освещения. Блендинг кучи текстур. Сплаттинг для террейна часто не помещается по инструкциям в один большой шейдер. Слоя земли смешиваются в отдельном RT, а затем этот RT используется как диффузная текстура в рендере патча земли. Все движения выполняются посредством применения скелетной анимации.

Обычные тени размываются посредством percentage closer filtering’а. Для рандомизации семплов используется текстура с 2D rotation векторами: L канал:

А канал:

Туман войны считается на CPU и хрантися в небольшой текстурке:

Эта текстура используется для всех эффектов в игре.

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

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

После рендера всей геометрии идет проход deferred источников света, о которых я писал выше.

Далее идет отрисовка рамок UI, маркеров юнитов и портрета текущего выбранного юнита. К портрету юнита применятся depth of field.

Затем идет брайтпасс, и блур. Получаем блум эффект. После этого комбинируем все с тонемаппингом. Далее отрисовка миникарты со всем маркерами юнитов (одним вызовом), туманом войны и крипом.

Поэлементно дорисовывается весь интерфейс. Текст рендерится пачками – применяется рендер скейлформа, который пакует все нужные буквы в кадре в текстуру. Получается эффективно.

Результат:

Формат вершин моделей сделан хорошо, зачастую 32 байта. Данные упакованы хорошо. Количество DIPов тоже неплохое. В средней сцене – 800-1200. Лимит зерглингов на экране с основной базой показал 1800-1900 DIPов. Все карты нормалей хранятся в DXT5 формате со сжатием и распределением по каналам для большего качества. Реверс инжиниринг проходил на компьютере Core 2 Duo, GF460GTX, все настройки ультра. Качество текстур – высокое (при попытка захвата кадра пиксом, на настройках текстур ультра, старкрафт падал с out of memory).

Да, это реверс рендера Кризиса. С самого начала хочу сделать 2 ремарки:

1. Существует документация по технологиям Кризиса, где в сжатом виде рассказаны те или иные подходы к реализации. Мне известно 3 документа. Первый это доклад Мартина Миттринга (Martin Mittring) на Siggraph 2007 (p97-mittring.pdf). Второй - доклад Карстена Вензеля (Carsten Wenzel) на GDC 2007 (D3DTutorial_Crytek.pdf) И последний - статья Тиаго Сусы (Tiago Sousa) в GPU Gems 3. Все эти источники информации мне сильно помогли, так что советую их просмотреть. Я не буду акцентировать большое внимание на момментах, которые неплохо описаны в этих документах.
2. Я очень уважаю команду разработчиков. Это команда экстра класса. Естественно, что вряд ли я один смогу вот так, наскоком, постичь все премудрости движка. Поэтому вполне вероятно, что в процессе анализа я что-то упустил (возможно даже существенное), либо не так понял.

Итак, Crysis, Windows Vista, DX10. Компьютер Core2 Duo E6550, 3GB RAM, GF 8600GTS. Все настройки Ultra High. Наверное, у всех на слуху знаменитый Screen Space Ambient Occlusion (SSAO). С него и начну. Основной ингредиент для приготовления данного эффекта является camera space normalized scene depth, или текстура с глубиной сцены в пространстве камеры, если по-русски. Рисуется этот эффект в отдельный буфер, и результат выглядит вот так:

Это полностью реалтаймовый эффект, который считается на видеокарте. Как он реализован? Для каждого пикселя изображения берутся 8 векторов, которые можно представить внутри кубика. Эти вектора идут от центра кубика до его углов. Как и в классическом алгоритме просчета AO, это и есть лучи с помощью которых мы проверяем заслонённость данной точки каким-то объектом (правда тут проверка производится не по полусфере, а по полной сфере, так как нормаль в точке недоступна). Затем, чтобы избавиться от регулярности, нужно как-то сэмулировать произвольное распределение лучей. Это сделано с помощью операции вычисления отраженного вектора из данного (полный аналог интринсика reflect в DX HLSL). Нормаль, относительно которой выполняется отражение берется из вот такой текстурки (увеличено в 50 раз):

Это текстура размером 4х4 текселя, она проецируется так, каждый тексель этой текстурки соответсвует каждому пикселю выходного изображения. Достигается это тайлингом (текстурным повторением) размер_экрана/4 раз. Т.о., для каждого пикселя экрана мы получили псевдопроизвольную нормаль. Повернув все 8 исходных векторов относительно полученной псевдопроизвольной нормали, мы получим 8 псевдопроизвольных лучей для тестов. Лучи у нас единичной длины, так что их длина скейлится в зависимости от отдаленности обрабатываемой точки от near plane (ближние пиксели получают меньшую длину лучей, дальние большую). Затем полученные текстурные координаты и Z смещаются по каждому лучу и производится проверка на Z на конце вектора-луча. Если луч приникнет в какую-либо геометрию, то Z в буфере глубины камеры будет меньше Z на конце луча. Данная ситуация означает, что процент загороженных лучей будет увеличен, что в конце повлияет на общую освещенность точки. К сожалению, малое количество лучей-тестов и недостаточная произвольность выборок приводит к ярко выраженной, зернистой, структуре изображения:

Для нивелирования этого побочного эффекта, применятся проход полноэкранного сглаживания c color leak correction и используется scene camera z. В результате чего, получается картинка, которая приведена в начале. Кому интересно посмотреть этот эффект вживую, вот вам ссылочка на RenderMonkey проект, сделанный мной. В нём содержится практически полная реплика эффекта из Кризиса. Crysis.zip на upload.com.ua

Далее эфффект, который, на сколько мне помнится, не описан нигде. Dynamic Terrain AO, или динамический амбиент окклюжен для террейна (земли). Рендеринг производится в G канал текстуры с SSAO (в то время как сам SSAO хранится в R). Данный эффект предназначен для аттенюации освещения объектов под влиянием террейна:

Создается он хитро. Террейн разбит на прямоугольные патчи различного размера. Для каждого такого патча имеется прямоугольный параллелепипед выровненный по самой нижней точке (т.е. самая нижня точка патча земли совпадает с нижней плоскостью параллелепипеда). По сути это ААBB, только вытянутый немного по вертикали. Данный бокс, рендерится 2 раза используя предрассчитанный ранее depth buffer. z-test on, z-write off и color write off. Первый раз с front face culling, второй с back face culling. Эти 2 прохода являют собой stencil fill pass. В обоих случаях StencilFunc = Always, ZFail = Replace, остальные операции Keep. Отличия между этими двумя проходами в StencilRefl. Первым идет front face culling, и тут StencilRef = 6 (не знаю чего именно 6. Cчитайте что просто больше нуля). После отрисовки бокса, стенсил как бы "подсвечивает" не нулями то место в кадре, которое соответствует данному патчу земли. Но эта информация для шейдинга пока неверна, так как все объекты в кадре, которые ближе к камере, чем задняя стенка бокса, оказываются помеченными. Для исправления ситуации используется второй рендер бокса, но с back face cull, и StencilRef = 0. Данным проходом мы снимаем пометку с пикселей, которые не попадают в пространство внутри куба. Т.е. если игрок, например, вне этого патча земли, то оружие, которое он держит в руках, будет исключено из сгенерированной маски. Чтобы проще было понять вот картиночка с кубиком. Фиолетовый цвет это Terrain AO в G канале текстуры. Вернее это уменьшение яркости канала, так как Terrain AO расчитвает только затенение.

После этого, в пространстве экрана рендерится прямоугольник, который описан над ААBB упомянутым ранее. В параметрах рендеринга устанавливается SetncilFunc = Equal, StencilRef = 6. Таким образом, обработке подвергнутся только пиксели объектов, которые лежат внутри баундинг бокса патча террейна. Для картинки приведенной выше он выглядит так:

Дальше - интереснее. Рисуем то мы всё в пространстве экрана. Как вообще можно что-то сделать полезное? Оказывается можно. Для каждого патча террейна, есть пара текстурок, которые используются при его рендеринге. Часть информации из них нужна при генерации Terrain AO. Вот они:

В терминах Crytek, они называются незамысловато: TerrainInfo0, TerrainInfo1. :) Из нулевой текстуры нам нужна предрасчитанная грубая степень освещенности террейна от солнца (я так понимаю это что-то сродни статическому амбиент окклюжену). Она в R канале:

В текстуре с индексом 1, нам потребуется хейтмапа и карта высоты растительности на данном клочке земли (А и G каналы соответсвенно).

Как же использовать эти текстуры? Естественно необходимо посчитать текстурные координаты для проецирования этих текстур на поверхность земли. Сделано просто шикарно. Первым шагом вычисляется мировые координаты обрабатываемого пикселя. У нас есть уже буфер глубины сцены. Формула проста: мировая позиция камеры + вектор направления взгляда на пиксель * Z. 1 mad инструкция! Как узнать вектор направления взгляда, спросите вы? Очень просто. Можно посчитать его для каждого вертекса в вершинном шейдере для уголов Screen Aligned Quad. Интерполированные значения будут соответствовать искомым. Но команда Crytek пошла ещё дальше по пути оптимизации. Соответствующий вектор передаётся как per-vertex info отдельным стримом. Вот что значит оптимизация! :) Вторым шагом нам нужно перевести world space координаты в локальные координаты патча земли. Это делается простым вычитанием координат ближайшего к мировому 0 угла ААBB патча из мировых координат пикселя. Перевод в стандартный [0..1] uv тривиален. Полученные локальные, относительно патча, координаты делим на его ширину и длину. Текстурные координаты для проективного текстурирования получены. Далее чистый арт. Зная высоту обрабатываемого пикселя, высоту террейна под этой точкой, высоту растительности и предрасчитанный статический АО, всё это смешивается в хитрых формулах, с кучей коэффициентов. В результате получается амбиент тень от деревьев снизу, затенения в арках и гротах и т.д. Fade out эффекта также реализован по расстоянию. Результат на изображении в начале описания эффекта.

Каустика от воды. Красивый эффект. Делается достаточно просто. На основе вектора направления солнечного света строим проективную матрицу. Эта матрица используется для вычисления текстурных координат для карты нормалей. Правдами и неправдами, мешая высокочастотные семплы и низкочастотные, добиваемся отсутствия регулярной структуры нормалей. Нормаль после всех пертрубаций преломляем с помощью refrаct относительно направления света от солнца. При этом немножко меняем угол преломления для каждого компонента цвета (R, G и B). Это даст в результате сдвиг спектра в результирующем изображении. Затем с помощью полученных нормалей семплим текстуру вида:

Реузльтат сеплирования возносится в степень, чтобы увеличить четкость изображения каустики. Степень видимости каустики определяется скалярным произведением направления света солнца и пертрубированной нормали. Есть также операции по предотвращению появления каустики на поверхностях под углом > 90 градусов к солнышку.

Облака. Бывают разные. Например, самые верхние состоят из 1 полигона параллельного земле. Шейдинг их состоит на определении влияния солнца и неба на цвет. Для расчета плотности применяется texture space tracing. Вектор взгляда на солнышко переводится в текстурное пространство облака и делается 8 семплов и текстуры плотности. Шаг семплирования фиксирован. Низкие же облака щейдятся с учетом atmospheric light scattering. Рендеринг большого облака, состоящего из множества маленьких, выполняется в отдельную тестуру. Затем полученное изображение уже переносится на основную картинку. Пример:

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

Океан. Поверхность океана представляется высокотесселированным параллелепипедом нижняя плоскость которого лежит на уровне поверхности воды, а верхняя на уровне камеры (глаз) игрока. Всё как писал Мартин Миттринг.

Я не совсем понимаю как они манипулируют координатами вертексов так, чтобы при растеризации экранная Z координата совпадала с water plane. Несколько часов ломания головы и пересмотра шейдеров мне не помогло. :) Ну да ладно. При помощи vertex texture fetch генерируются волны. В пиксельном шейдере всё как обычно: reflection, refraction, отражение солнышка. Также для рефракшена реализована хроматическая аберация (подробно тут), т.е. различные углы преломления световых волн разной длины. Это достигается путем небольшого смещения текстурных координат для каждого из цветовых каналов. Прямо как при генерации каустики.

Теперь рассмотрим рендер типичного кадра по порядку. Отражения для воды. Упрощенные шейдеры. Далее подготавливаются shadow maps для теней от нужных источников. Я не буду останавливаться на тенях подробно, так как они описаны в первом документе, который я упомянул первым в начале. Скажу лишь, что всё что там написано - правда. :) Для directional light sources - cascaded shadow maps. Для точечных кубемапа в обычной 2d текстуре (хотя по шейдерам похоже, что нативные кубемапы тоже поддерживаются). Для террейна variance shadow maps. Для большего заблуривания применяется не summed area tables, a простой проход блура VSM карты. Вы уже, наверное, заметили что мало какой эффект обходится без camera space depth buffer. Он используется практически повсеместно. На этом шаге подготавливаем его. Запись ведется в текстуру формата R32F, параллельно с заполнением depth buffer, чтобы далее снизить depth complexity до 0. Следующим эффектом идет SSAO + Terrain AO описанные выше. После подготовки этой текстуры она блурится. Теперь настал черёд создания shadow mask для т.н. deffered shadowing. Тени мы рисуем в отдельный буфер, чтобы сэкономить инструкции в шедерах в основном проходе. Основной проход выполняется в текстуру формата RGBA16F, так как HDR - наше всё. Буфер глубины настроен только на тест, так что перетирания пикселей нет. Это очень важно с учётом применения огромных шейдеров. Дополнительным бонусом является отсутствие необходимости сортировки объектов по дальности. В основном проходе также применены интересные решения. Например для металлов применяются модели освещения Schlick и Сook-Torrance (для люознательных: демка RenderMonkey и небольшая доканебольшая дока. Подробное описание можно найти в книге Kelly Dempski, Emmanuel Viale. 2004. "Advanced Lighting andMaterials with Shaders". Wordware Publishing, Inc.). Для облегчения вычислительной нагрузки, части функций предрассчитаны и вынесены в текстуры. Все системы частиц, и облака, используют depth buffer для удаления артефактов пересечения геометрии. Отличный батчинг растительности. Ближние деревья и кусты рисуются маленькими батчами и детализированно, дальние же вырождены в screen aligned quads и выводятся большущими батчами:

Рендерингу растительности посвящена статья в GPU Gems 3. Советую обратить на неё внимание. Если вкратце, то анимация реализуется на вертексном шейдере с применением различных карт жесткости. Освещение листвы двусторонне, с применением subsurface scattering. Небо с абсолютно честным atmospheric light scattering. Есть вот такая симпатичная текстурка луны:

Террейн и некоторые элементы сцены рисуются в 2 прохода. Первым проходом идет базовый цвет, вторым же накладываются детальный рельеф, каустика, etc. В конце volumetric fog, опять же с использованием scene camera z текстурки. Получилось так:

После основного прохода из текстуры со сценой мы выделяем яркие фрагметны, которые мы блурим, для получения блум текстуры. Считаем среднюю яркость сцены для перевода HDR в LDR в 1x1 текстурку. Теперь пора применить всякие пост-процесс эффекты. Motion blur: Блурим картинку по направлению движения камеры с учетом дальности пикселя (опять используем scene z) Ближние будут блурится сильнее. Применяется коррекция ликов цвета с оружия.

Depth of field: Даунсемпл и блур изображения сцены. Затем простое смешивание с учётом глубины. И ещё всяких много: chroma shift, и radial blur когда колбасят; эффект мокрого экрана, когда из воды вылазишь, и т.д. Далее идёт tonemap resolve, т.е. перевод из HDR в LDR.

Но это ещё не всё! :) Есть ещё 1 красивый эффект - геренация light shafts. Метод похож на описанный в статье "Volumetric Light Scattering as a Post-Process" в GPU Gems 3. В текстурном пространстве пускаем луч в направлении солнышка. Двигаясь по лучу проверяем загораживет ли слонце какоё-то предмет, сравнивая Z с 1 (0 - near plane, 1 - far). Количество загороженых семплов и есть степень загороженности солнца предметами. Аттенюация по дальности также пристутсвует.

После 3-х таких проходов с различным шагом (чтобы убрать артефакты дискретного семплинга), получаем таку. картиночку:

Финальная композиция выполняется с применением т.н. Soft Light Blend Mode, аналогичного фотошоповскому. Данный метод позволяет осветлить одни участки изображения и затемнить другие. Почитать про различные режимы блендинга и их формулы можно тут: http://www.pegtop.net/delphi/articles/blendmodes/softlight.htm Финальное изображение:

Гуи. По элементику, по буковке ~100 draw calls. Рендер завершен.

А, там же ещё снег есть. :) Сильно его не ковырял. Он адванснутый. Основная идея: отталкиваемся от отношения вертикальной оси и нормали к поверхности для создания слоя. Остальное это создание нерегулярной его структуры и вида.

В кадре 2М триугольников, размер вертексов выравнивать не сильно старались. Draw calls доходит до 2000. Почти все текстуры в DXT сжатии. Нормали в BC5 (ATI2N). Собственно всё. Что хочется отметить, так это повсеместное использование camera z буфера. Почти во всех эффектах.

Хочется поблагадорить команду Кризиса за замечательный экспириенс, и Серегу kss за апдейт мегатулзы, без которой данное увлекательное приключение не состоялось бы. :)

Конфигурация компьютера: A64 X2 4200+, GeForce 8800 GTX, 2GB Ram. Все настройки игры на максимум.

После запуска, невооруженным глазом сразу видно, что игра сильно нагружена спецеффектами, поэтому, как я и ожидал, первым проходом идёт заполнение scene depth буфера. Это не чисто only-z проход. На нем в R32F рендер таргет выводится camera space z. Полученная текстура далее используется во множестве случаев. Все последующие проходы геометрии используют полученный z-буфер устанавливая DepthWrite в false.

Движок игры многопроходный. Для каждого источника света существует отдельный проход рендера геометрии. Если источник должен отбрасывать тень, то первым идет рендер в R32F текстуру тени (omni shadows замечены небыли). Затем отрисовывается вся геометрия, на которую влияет данный источник. Во время рендера используются: Диффузная текстура (сделайте монитор поярче, картиночки темноваты):

Нормал мапа:

Примняется DXT5 сжатие. X и Y компоненты вектора лежат в G и A каналах. Данный способ сжатия нормал мап широко известен. Z вычисляется как sqrt(1 – x^2 – y^2), так как нормали у нас единичной длины и мы знаем, что Z координата в tangent space normal maps всегда положительное число. Более подробно про сжатие карт номалей можно почитать тут и тут Так как R компонента пустует, то её можно использовать для хранения чего-то полезного (но не критичного к качеству). В Jericho данный канал текстуры хранит низкочастотное значение высоты, или, если говорить иностранным языком - low frequency height map. Используется данный канал для самого простого параллакс маппинга. Ни Parallax Occlusion Mapping (URL), ни Relief Mapping не реализованы. Канал B текстуры не используется. Height map:

Также присутствует specular map:

Кубемапа с бликами приассоциированная к объекту (для оружия например):

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

Сцена с одним источником:

с двумя:

с тремя:

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

Далее идут частицы, которые забатчены довольно большими группами. К слову много частиц рисуется с аддитивным блендингом, создавая таким образом эффект volumetric light and fog. До партиклов:

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

Depth of Field. Для достижения данного эффекта сцена даунсемплится в РТ размером ¼ от оригинального, а затем 2 раза размывается. Полученная текстура комбинируется с исходным изображением, используя метод описанный ребятами из АТИ в ShaderX3. Ближняя плоскость, дальняя плоскость, фокусное расстояние, leak reduction используя scene depth texture – всё присутствует. Хочу отметить, что фокусное расстояние определяется динамически, в зависимости от объекта на который мы сейчас смотрим (простое пересечения луча с ближайшим объектом). Этим достигается плавное изменение степени заблуривания объектов. Как я и предполагал, качество видео в Youtube не позволит проиллюстрировать DoF с переменным фокусным расстоянием, поэтому будет 2 картиночки (обратите внимание на дальнюю освещенную колонну):

После DoF идут т.н. “image distortion” пост-процесс эффекты. Подход достаточно оригинален и необычен. В отдельную ARGB8 текстуру рисуются все смещения текстурных координат (используются нормал мапы), которые должны искажать картинку. Это и эффект мокрого экрана (капли на стекле), и heat-haze от огня и эффект телекинеза. Затем используя полученную динамическую карту смещений и изображение сцены полученной на предыдущих шагах делаем distortion эффекты. Динамическая карта смещений:

Полученная картинка:

Следующим идёт генерация velocity буфера для motion blur эффекта. Подход такой же как и во многих других играх. В шейдер передаются предыдущая и текущая матрицы трансформации. После их применения вычисляется вектор смещения в XY плоскости, который записывается в ARGB8 текстуру. Дабы увеличить точность значений и зря не расходовать память а R канале содержится +Х, в G –X. В каналах B и A содержится +Y и –Y соответственно. Визуализация velocity буфера в момент включения зума на снайперке у Black (она один из 3-х играбельных персонажей в демке).

На следующем этапе используя полученный буфер размываем изображение:

и видео:

На следующем шаге идет очередной пост-процесс эффект. Сцена даунсемплится и размывается в несколько шагов до 1х1 изображения в котором хранится средняя яркость. Используя эту мини-текстуру выполняется bright pass, или говоря нашим, родным языком, выделяются яркие области. Текстура с яркими областями подвергается «диагональному» размыванию в виде буквы Х. Вверх-вправо, вверх-влево, вниз-вправо, вниз-влево. Полученные лучи крестообразных бликов собираются в одно изображение и блендится с оригинальной картинкой.

Обратите внимание на glow в районе руки:

Последни пунктом идет UI, которого совсем немного.

С 5-ю активными источниками получается где-то 1800 dip’ов и до 400К полигонов в кадре. Средние значения: 1200 draw calls и 200K полигонов. Вся геометрия в невыровненных вертекс-форматах, хотя данные немного сжаты: позиция во float3 и нормали в short4n. В движке хорошая сортировка как по шейдерам, так и по текстурам. ЦПУ в драйвере не сидит, что тоже хорошо. Смущает только объем загруженных в видеопамять текстур. Аж 550 мегабайт. Вот вам и хай-энд :)

В послесловии я хочу подлиться своими соображениями по поводу многопроходности. Раньше я думал, что с длинными шейдерами данный подход себя изжил. Но данный реверс отчетливо показал, что мои выводы были преждевременными. Главное это бороться за минимизацию pixel-processing overhead и количество батчей. Рендер Clive Barker’s Jericho демонстрирует отличные показатели по обоим пунктам.

Для смягчения тени, мы не можем блурить shadow map (в привычном понимании этого слова), потому что в ней содержится глубина пикселя с позиции источника света. Операция разблуривания (усреднения соседних значений) глубины не имеет смысла. PCF алгоритм заключается в том, чтобы вместо того, чтобы проверить 1 пиксель на затенённость, проверяется несколько пикселей по заранее заданному filter kernel. Затем полученные значения (1 - в тени, 0 - не в тени) усредняются. Т.о. если в тени оказались всего 3 пикселя из 4-х, то степень затенённости можно установить в 0.75 (либо 75%), что создаёт полутень (переход от затенённой области в светлую). Данный алгоритм, в варианте квадратной области размером 2х2, реализован аппаратно в NVidia hardware, как составная часть т.н. NV hardware shadowmap hack, начиная с GeForce 3. Можно отметить, что для 2х2 алгоритма мы сможем иметь на выходе, только 5 градаций интенсивности затенения (0, 0.25, 0.5, 0.75 и 1), что приведет к довольно заметной "блочной" структуре полутени.

Тень без PCF

Тень с 2x2 PCF без линейной интерполяции

Для этого на NV железе выполняется ещё и линейная интерполяция полученных значений по точному положению экранного пикселя, в пространстве карты тени. Алгоритм достаточно прост. Post-perspective XY координаты текущего пикселя в пространстве SM имеют координаты [0..1]. Домножая их на размер карты тени, в целой части результата мы получим координаты текселя карты тени соответсвующего данному экранному пикселю. В дробной же части у нас будет субтексельное положение пикселя внутри текселя sm.

Пояснительная картиночка:

На ней изображён маппинг одного shadow texel в 3 screen pixels. Этот случай является как раз тем пресловутым perspective aliasing'ом с которым более-менее успешно борются все перспективные техники (PSM, TSM, LisPSM и др). Но речь сейчас не об этом. В нашем примере, координаты каждого из 3-х пикселей, будут иметь одно и то же целочисленное значение в пространстве карты теней. Но дробная часть координаты будет отличаться. Она то и является той субпискельной точностью, которая поможет нам ещё более сгладить края затенённых областей. Для первого сверху экранного пикселя она будет примерно 0.8, для среднего 0.5, а для нижнего 0.2.

Теперь рассмотрим вид с позиции карты тени (увеличенная 2х2 область):

Синим кружочком показано субтексельное положений экранного пикселя на карте тени. Цифрами - результат теста глубины из sm, c глубиной тестируемого экранного пикселя (1 - в тени, 0 - нет). Возьмём верхних 2 текселя shadow map'ы. При подходе влоб (без учёта субтексельного положения), степень затенённости в результате будет 0.5 ((1 + 0) / 2). Но мы знаем, что субтексельная позиция пикселя по оси u в нашем случае равна 0.2 (примерно). Следовательно, вместо простого усреднения соседних значений, мы можем сделать их линейную интерполяцию по субтексельному положению. Т.о. степень затенённости в нашем случае будет x + s(y - x) = 1 + 0.2(0 - 1) = 0.8, двигаясь дальше, вдоль оси u мы будем получать всё меньшее значение затенённости пикселя, т.о получая плавный градиент затенения. Тоже самое проделывается и по оси v.

Именно таким образом инженеры NV реализовали этот алгоритм в железе. Результат налицо:

Фрагмент кода шейдера для эмуляции поведения NV видеокарт на ATI:

// Perform Percentage Closer Filtering
// First determine lerp amounts
float4 la;
float2 texLA = frac(fragPos.xy * shadowMapSize.xy);
// Gather samples
// Fetch 4 neighbour points
depth.x = tex2D(shadow_s, fragPos).r;
depth.y = tex2D(shadow_s, fragPos + float4(shadowMapSize.z, 0.0, 0.0, 0.0)).r;
depth.z = tex2D(shadow_s, fragPos + float4(0.0, shadowMapSize.w, 0.0, 0.0)).r;
depth.w = tex2D(shadow_s, fragPos + float4(shadowMapSize.z, shadowMapSize.w, 0.0, 0.0)).r;
// Check visibility for all points
depth = depth < fragPos.zzzz ? 0.0 : 1.0;
// Final shadow factor
return lerp
(
    lerp(depth.x, depth.y, texLA.x),
    lerp(depth.z, depth.w, texLA.x),
    texLA.y
);

Вопросы?

Привет, друзья. Материалы по Dirt'у у меня были уже в основном готовы с середины июня, но множество всяких обстоятельств (хороших в основном :)) заставили отложить финальное оформление готового репорта до осени. И вот, набравшись сил, я решил завершить начатое.

Стандартная ремарка: компьютер A64 X2 4200+, GF8800GTX, WinXP SP2, 2GB RAM. Игра реверсилась в максимальных настройках в разрешении 1024х768.

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

Первым этапом рисуется динамическая миникарта. Это фрагмент карты плюс индикаторы машинок соперников и индикатор нашего транспортного средства. Рисуется квадратами по 2 треугольника на каждый draw call.

Следующим идет генерация динамической кубемапы для отражений. Фотографируем сцену с позиции камеры. Автомобили, кусты, людей и всякую мелочевку не рисуем.

Далее велосити буфер + scene depth. Используется текстура формата A16R16G16B16F. В rg каналах 2D вектор смещения точки с предыдущего кадра. Всё так же как и в моем предыдущем обзоре Lost Planet. В b глубина сцены во view space (т.е. не нормализированная). Этот RT используется в практически всех остальных этапах отрисовки.

Dynamic ambient occlusion pass. Нет, это не тот AO, который описан в GPU Gems 2. :) Это такая терминология разработчиков. В этом проходе создается RGBA8 текстура размеров в 8 раз меньше размеров вьюпорта (т.е. 128х96 в нашем случае).Используется только R канал, в который отрисовываются автомобили в определенном (небольшом) радиусе от камеры. Далее эта текстура размывается по горизонтали и вертикали, и используется как мягкая тень от машинок при рендеринге земли и объектов на ней.

Следующий пункт – тени. Использются 3 R32F 2Kx2K текстуры. Все они центрированы по камере и покрывают разные площади.

Затем, используя scene depth текстуру и все 3 шадовмапы разработчки создают т.н. маску тени.

Это достигается путем исполнения огромного шейдера в 250 инструкций. Зная scene depth и позицию пикселя в пространстве экрана можно вычислить его позицию в пространстве камеры. Затем стандартный SM. Из-за того, что приходится блендить 3 карты и тут же применять PCF и получаем столь длинный код. На маске с тенями всё ещё достаточно хорошо видны артефакты теней и PCF алгоритма, поэтому полученная текстура ещё разок легко размывается, благо это уже обычное изображение, а не глубина сцены. Можно отметить, что при таком подходе размытые участки с тенью могут вылезти за пределы мешей на которых они лежат, образуя артефакты. Именно поэтому, используется лёгкое размытие. На финальной картинке артефактов невидно.

Когда все подготовительные работы закончены, начинается основной проход. Front to back всё как надо. Сначала машинки. Шейдеры тут используются достаточно тяжёлые с точки зрения текстурной нагрузки. Для рендеринга авто используются диффузная текстура, карта нормалей, маска грязи, амбиент кубемапа, кубемапа с реалтайм отражениями, текстура с посчитанными тенями, текстура с повреждениями и спекулярная текстура с повреждениями. Все текстуры большие (1Kx1K)

Dirt map:

Карта грязи имеет формат DXT5, и в своих каналах содержит: Маску для грязи одного цвета (red):

Маску для грязи второго цвета (blue):

Коэффициент затемнения грязевого слоя. Он являет собой результат формулы вертикального вектора (перпендикулярного земли) и нормали модели авто в этой точке. Используется вариация формулы wrap-around освещения (или напрямую, не суть важно)

сolour * clamp(N.L+factor)/(1+factor)

Это сделано для того, чтобы угол в 90 градусов и больше не превращал всё в черноту.

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

Вот картиночки чистых и грязных машинок:

Освещаются машинки (как и всё остальное в игре) одним солнышком. Авто, при максимальное детализации помещается в 100 DIPов. По мере отдалённости мелкие детали в авто не рисуются. LOD'а шейдеров нет. Водители и зрители скинятся софтварно. Для отрисовки земли/дорог используются несколько фотографий местности c воздуха (размером 512x512) и несколько текстур деталей. Для бленда слоев предназначена следующая текстура (оригинальный размер 1024^2, слои отдельно рядом):

Для всех диффузных текстур есть сопутствующая нормалмапа. Всё освещается попиксельно, от солнца.

Деревья SpeedTree’шные. В конце полусфера неба, на текстуре которого нарисованы самый дальний слой леса. Все модели хранятся в своих VB/IB. Выравнивания по cache-friendly sizes отсутвует. Используемые вертексформаты декларируют вертексы с размерами 28, 36, 40, 48 и 60 байт (некоторые меши освещаются повертексно). Частицы мягкие. Для сглаживания пересечений геометрии используется текстура со scene depth информацией подготовленная ранее. Получилась вот такая картинка:

Затем в 5 этапов даунсемплим картинку до 1х1 с посчитанной scene luminance. Используя velocity буфер и яркость сцены блурим и модифицируем освещение финальной картинки соответсвенно. К слову motion blur используется даже в главном меню игры.

Затем блурим ещё 2 раза для создания glow областей. Финальное изображение:

UI поэлементно, можно было батчить лучше. Буквы – модельки. Текст батчится побуквенно, т.е. все одинаковые буквы, если встречается несколько раз, отрисовываются за 1 draw call.

Вот и всё, собственно. Хотелось бы отметить, что для для этого исследования не потребовался PIXWin вообще. 4-м перфхудом экспортил текстуры и рендертаргеты. 5-м же модифицировал шейдеры, чтобы понять как работают неочевидные вещи.

Итак, сегодня мы будем оперировать продукт японско-консольного мира, который намеревается вот-вот появиться на РС. Это игра Lost Planet: Extreme Condition. Полной версии игры у меня, естественно, нет, но есть публично доступная демка. Саму игру я впервые увидел на Xbox360, и она меня технологически впечатлила. Когда я решил побороть свою лень, и пореверсить что-нибудь, демо-версия была уже довольно долгое время доступна, и я выбрал её.

Конфигурация моей машины со времени последних обзоров не изменилась: A64 X2 4200+, GF8800GTX, 2GB RAM. Все настройки на максимум.

Сразу оговорюсь, что ревресилась DX9 версия. О DX10 я напишу ниже.

Общие впечатления по движку очень хорошие. Куча cutting-edge технологий, плюс виден очень грамотный подход к реализации. Весь SM3.0 only. На двух уровнях ~500DIPs на пустой сцене (персонаж + террейн), и до 1500 в бою с несколькими противниками. Вся геометрия, кроме совсем уж отдельных случаев, таких как интерфейс, имеет один и тот же вертекс формат:

0 SHORT4N POSITION 0
8 UBYTE4 BLENDINDICES 0
12 UBYTE4N BLENDWEIGHT 0
16 UBYTE4N NORMAL 0
20 UBYTE4N TANGENT 0
24 FLOAT16_2 TEXCOORD 0
28 FLOAT16_2 TEXCOORD 1

Итого 32 байта. Что бросается в глаза:

1. Очень vertex cache friendly.
2. Много входных данных, которые хорошо соптимизированны. • Позиция вместо 12 байт (float3) – 8 байт. • Веса костей вместо 16 байт (float4) – 4 байта. • Нормаль и тангент вместо 12 байт каждый (float3) - по 4 байта. • Текстурные координаты вместо 8 байт каждый (float2) – по 2 байта. В этом нет ничего экстраординарного, я для сравнения привёл то, как делают обычно. Просто видна аккуратность подхода. Все данные должны быть аккуратно созданы, чтобы не вылезти за допустимые границы.

Благодаря красивому вертексу, а ещё и высокому быстродействию vertex processor’a современных видечипов, практически вся игровая геометрия (кроме террейна) рисуется шейдером со скиннингом. У статичных моделек значащая матрица всего одна – она является world матрицей объекта.

Множество мешей содержатся в одном VB и IB, которые рисуются с помощью оффсетов.

В игре используются динамически генерируемые кубемапы. Схема работы алгоритма хитрая. Изображение шотится в cubemap в позиции главного персонажа, раз в несколько кадров (возможно генерация фейсов размазана по кадрам, я, к сожалению, этот момент не поймал). Вместе с текущим отражением хранится ещё и предыдущее в отдельной текстуре. В начале каждого кадра в третью кубемапу блендятся предыдущее и текущее изображение, с учётом весов. Таким образом, производится плавный переход одной environment map’ы к другой. Чтобы лучше проиллюстрировать процесс, приведу несколько картинок:

Фейс кубемапы с текущим отражением:

Фейс кубемапы с предыдущим отражением:

Скомбинированное отражение (обратите внимание на видимый ghost-image здания):

Кубемапы размером 128х128 A8R8G8B8. Бледнятся все мип-уровни. Визуально полезность данного технического решения определить я не смог, так как на уровнях, где можно побегать, хороших отражающих объектов я не заметил. На воде (о ней ниже), где сгенерированная envmap’a тоже используется, ничего толком не видно.

Далее генерируются шадовмапы. Используется технология т.н. Cascaded Shadow Maps, когда пространство, покрываемое view frustum-ом, разбивается на несколько регионов, по мере удалённости от позиции камеры, и каждой области назначается своя shadow-текстура. В LT:EC используются 3 текстуры формата R32F размером 2Кх2К. Соответственно hardware shadow map хаки от NV и ATI не используются. Кажется, даже применяются перспективные искажения кусков (визуально понять сложно). В текстуру идет z/w, ничего необычного.

Следующим пунктом идёт сохранение post-perspective z, в текстуру. Формат A8R8G8B8, размер экрана. Floating point упаковывается по в 3 канала по формуле.

R = frc(z * 65535)
G = frc(z * 255)
A = z – R – G

Всё хорошо, только непонятно зачем было геморроится с упаковкой (9 инструкций на упаковку, 2 на распаковку), если можно было воспользоваться R32F.

Симпатичная картиночка с упакованными данными:

Далее идёт рендер основного изображения. Всё в нём рисуется в RT формата A16R16G16F.

Первый проход для моделек сцены. Огромные и ужасные шейдеры. vs - 60 инструкций, ps 260 инструкций. Все в принципе одинаковые, с небольшими вариациями. Про тотальный хардварный скиннинг (4 кости) я уже говорил. Используется исключительно попиксельное освещение. 8 динамических точечных источников (другие, возможно, поддерживаются, но в коде я их не увидел). 4 важных, 4 не очень. Первая четвёрка отличается от второй исключительно наличием спекуляра. Источники включаются/выключаются посредством булевых регистров. Расчет стандартный (как в FFP), за исключением формулы аттенюации. Как по мне, в FFP она слишком хитромудрая. Здесь проще (нечто подобное я сам использовал):

lightIntensity = 1 - saturate((distance - startFadeDist)/fadeDist)

Пояснительная картиночка:

Если освещаемая точка будет внутри внутреннего круга, то интенсивность источника будет максимальная. В кольце от внутреннего круга до внешнего интенсивность падает линейно от 1 до 0. Ближние объекты освещаются с использованием текстур нормалей, для дальних берутся нормали из вертексов. Нормал-мапы в DXT5, в котором используются только green и alpha каналы для xy компонент вектора соответсвенно. Z = 1 – x^2 – y^2. Особенности запаковки карт нормалей в сжатые форматы можно почитать тут: http://developer.nvidia.com/object/bump_map_compression.html Статические источники запакованы в 7 коэффициентов, которые используются в Spherical Harmonics Lighting (подробности про этот метод освещения в предыдущем реверсе). Учитывается также туманчик.

Есть интересный момент в учёте ambient lighting. Он не константный для всей сцены, а запакован в текстурку. Таким образом нужные части моделек подсвечиваются ярче, чем другие.

Все шейдеры имеют несколько вариаций. Например, крупные объекты используют ambient occlusion map, мелкие нет. Совсем статические объекты (terrain, здания) используют лайтмапы вместо SH (правильно, 1 текстурная выборка быстрее десятка арифметических инструкций). Также применяется динамически сгенерированная environment cube map, о которой я писал в самом начале.

Диффузная текстурка персонажа

Амбиент текстура

Ambient occlusion для террейна (оригинал был 2Kx2K)

Лайтмапа для террейна (оригинал был 2Kx2K). Она такая цветастая, т.к. каналы используются отдельно

Альфа-канал лайтмапы (оригинал был 2Kx2K)

Второй проход для моделек сцены, в котором рисуются тени. Используются 3 R32F текстуры, о которых было выше. PCF в шейдере.

Скрин до расчёта теней:

Скрин после наложения теней:

В игре есть технология визуализации меха. Как оказалось она очень простая. Рисуем несколько раз меш, на котором должен быть мех, увеличивая его каждый раз в размерах. С помощью альфа-канала на текстуре модели получается, что во все стороны торчат как бы ворсинки и волокна. Если сильно присмотреться, то артефакты видны, и то, в близи. А так в глаза не бросается и выглядит симпатично.

На первом уровне есть вода. Она простая. 1 скроллящаяся в разные стороны нормал-мапа. По нормали выбираем тексели из динамической envmap’ы. Может быть полупрозрачная. Далее soft партиклы. Они не освещаются, а для фейда по альфе на границах с геометрией, используется текстурка с post-prerspective z, подготовленная ранее.

После того как основной рендеринг сцены закончен, начинается перевод HDR image в LDR. Технология стандартная:

1. Пинг-понгом посчитали усредненную scene luminance.
2. Bright-pass – выделили яркие области.
3. Поблурили картинку после bright-pass’a несколько раз.
4. Скомбинировали все ингредиенты с применением tone-mapping’а.

HDR image (на ней нет очень ярких частей, к сожалению)

LDR image

Следующий эффект – depth of field. Да, на статике его практически не видно, но он есть. :) Возможно в движении эффект более заметен (без него игру не запускал, если его вообще можно отключить). Реализован просто: берем downsampled (даже не заблуренную) картинку, оригинал и текстуру с z. Используя фокусное расстояние, рассчитываем степень заблуривания пикселя по формулам из статьи «Improved Depth of Field Rendering» из ShaderX3. По этому коэффициенту берем либо оригинал, либо уменьшенную картинку. Учитывается также дальность удаления пикселя от камеры.

Получается вот так:

Предпоследним идет motion-blur. Алгоритм эффекта таков: Сначала копируется текущее изображения сцены, в дополнительный RT, в альфа-канал которого записывается дальность удаления пикселя от камеры.

Далее берется A8R8G8B8 текстурка, и рисуются все анимированные объекты (персонажи, крутящееся оружие на земле, и т.д.) со специальным шейдером. В него передаются предыдущие и текущие матрицы костей для скелетной анимации, предыдущая и текущая матрица view и projection. Вычисляются 2 позиции объекта (предыдущая и текущая), координаты переводятся в screen-space, а затем вычитаются (естественно с учетом множества коэффициентов и т.п.). Т.о. мы получили двумерный вектор смещения текущего пикселя со времени предыдущего кадра. В RT рисуются объекты в текущей и предыдущей позиции, чтобы захватить все пространство занимаемое моделью за эти 2 кадра.

Вот такая картиночка:

Для статики всё проще. Т.к. её позиция определяется исключительно view-projection матрицей, и у нас есть координаты каждого пикселя (z - в текстуре, а xy – текстурные координаты), то можно получить позицию пикселя в предыдущем кадре. Для этого достаточно умножить текущее post-perspective положение на инверсную матрицу проекции, затем перевести координаты в пространство предыдущего кадра, используя cохранённые view и projection матрицы. Так получается вектор смещения для статики. Для того чтобы не перетирались данные рассчитанные для динамических объектов, используется stencil буфер.

Render Target с векторами смещения

Финальная композиция использует полученные выше данные, чтобы заблурить пиксели учитывая вектор смещения пикселя.

Получили (эффект хорошо наблюдать, если взять картинку после depth of field и эту, и быстро переключать их в просмотрщике):

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

И, напоследок, делается что-то типа гамма- коррекции с каким-то хитрым color remap’ом, чтобы «подсинить» картинку.

Финальное изображение:

Ну и UI (блоками, не поэлементно).

Что можно сказать напоследок? Присутствует хорошая сортировка по материалам/текстурам/вертекс буферам. А вообще очень наворочено и технологично. Естественно всё это хозяйство жрёт немеряно памяти и вычислительных ресурсов. Вот такой он, консольный пришелец. :) З.Ы. Обещанные 2 слова о DX10 версии. Я было хотел реверсить её, но по каким-то причинам под PixWin на Висте игра ужаснейшим образом тормозит. Кадр в секунд 30 где-то. Причём, даже в заставочном видео (тут соврал, в видео 1 кадр - секунды 3). Я кое-как добрался до загрузки уровня, терпеливо прождал около часа, вырубил игру нафиг, и пошёл реверсить DX9 версию. :)

Из первой части мы хорошо помним, что в DoW всё сделано на FFP. Видно было, что СоН выглядит технологичнее, но вероятность того, что движки схожи, существовала очень и очень большая.

Вторая страшная тайна Relic заключается в том, что в CoH используется совершенно отличный от DoW рендер. Представьте себе автомобиль 1990 и 2006 годов выпуска, какой-нибудь известной марки (нет, ВАЗ не надо, они не развивались :)). Ауди, или БМВ подойдет. Старые машины тоже были качественно сделаны, и сейчас многие неплохо ездят, но то количество нововведений, технологий и опций, которые доступны сейчас, просто умопомрачительно. Так вот, качественный прыжок в движках от Relic примерно такой же.

Реверсил я на машине A64 X2 4200+, 2 гига памяти, GF 8800GTX. Все настройки в игре на максимуме.

FFP нету совсем. В основном используется shader model 3.0. Сразу хочется отметить очень навороченную систему освещения. Сделано очень грамотно и красиво. Но обо всем по порядку.

С самого начала создается, так называемая Point Light Map (в терминах самого Relic). Это обычная, изначально темная, текстура, в которую рисуются все яркие места на карте. На ночных уровнях это фонари прожекторов, например. Процесс простой: если смотреть на карту сверху, то в местах, где ярко, рисуем квадратики с текстурой блика. В результате получаем картинку, которая отдалённо напоминает спутниковую фотографию ночного города. Пример:

Затем идет 2 прохода в 2 различные карты теней. Первый для близких от камеры объектов (больше деталей), вторая для более дальних. Все видимые модели не захватываются. Если присмотреться, то видно как появляется тени на удалённой геометрии. Никаких хитромудрых техник (PSM, TSM) не реализовано. Естественно, используется NV shadow map hack. На ATI, думаю, будет использоваться ихние depth textures. Шейдеры простые, но есть один нюанс: всегда используется texkill для эмуляции альфатеста. Почему не использовали обычный альфатест?. Оказалось всё просто: в буфер цвета выводится глубина пикселя. По-видимому, программисты решили сэкономить на вариациях, чтобы сделать единственный шейдер для обычной R32F, а также NV и ATI depth textures. Это решение мне кажется спорным, так как, сделав ещё одно разбиение (без texkill’a и alphatest’a), получаем double speed z-only проход. Обе текстуры 2Кх2К.

Water reflection pass (если в кадре есть вода, естественно). Туда попадают все объекты, рисуемые шейдерами, которые используются в основном проходе (о нём далее). Единственная оптимизация, которая применяется, это куллинг дальних объектов. Если двигаться вдоль водной поверхности, то видно как появляются объекты в отражении.

Небо. Простая полусфера, рисуемая несложными шейдерами. Интересный момент №1: в игре используется Atmospheric Light Scattering. Я в этой сфере не силён, но после небольшого изучения появились подозрения, что используется упрощенная модель, которая была описана Naty Hoffman’ом и Arcot J Preetham’ом, на GDC 2002 (дополнительное описание есть в ATI SDK). А упрощенная потому, что в игре нет динамической смены дня и ночи, поэтому большинство коэффициентов можно предрасcчитать на CPU.

Пример текстуры неба:

Объекты на карте. Дома, юниты: всё тут. Шейдеры сложные. Вертексный шейдер для статичных моделек – 126 инструкций. Если скиненая – 150 (используется аппаратный скиннинг). Пиксельный общий - 65 инструкций. Что же такого там делается?

1. Интересный момент №2: в игре используется Spherical Harmonics Lighting. Подход очень сильно напоминает метод, который описал Tom Forsyth в заметках к своей презентации на GDC 2003 (http://home.comcast.net/~tom_forsyth/papers/SH_GDCE_TomF.zip. Блог тут: http://home.comcast.net/~tom_forsyth/blog.wiki.html. Смотреть пост за 17 января). В двух словах суть метода такова: 3-4 самых ярких источника мы обсчитываем как обычно (бамп, спекуляр, и т.д.). Все остальные переводим на CPU в SH коэффициенты и считаем освещение в вертексном шейдере. Грубо говоря, освещение с помощью SH можно считать диффузным освещением с использованием кубемапы. Только в реальном времени считать кубемапу не в пример накладнее 7 коэффициентов (именно столько используется в CoH). Использование всего семи первых членов полинома, вносит достаточно большую ошибку (обычно берут 9), но, по-видимому, разработчики были удовлетворены результатами экспериментов.

2. Используется описанный выше Atmospheric Light Scattering. Визуально это выглядит как туманчик, которым покрываются дальние объекты.

3. Используются 2 карты теней. Искусственно мягкие не делали, ограничились бесплатным 2x2 PCF на NV железе. Как там дело на ATI, не знаю. Реализовать не сложно, но уже и так довольно тяжело тянуть эту шейдерную нагрузку.

4. Источники «средней важности» считаются в VS. Самые важные в PS c нормал-маппингом.

5. В пиксельном шейдере использутся:

   Specular map

   

   Gloss map

   

   Ambient occlusion map

   

AO Detail map (в терминах Relic: Dirt map) Local ambient occlusion map. LAO Совершенно чудесная текстура. :) Мои долгие медитации над кодом шейдера не дали сколь-либо чётких результатов. Видно, что в разных каналах содержится разная информации о освещенности уровня с видом сверху. Происходит какая-то аттенюация базового цвета, с использованием этой текстуры. Каналы отдельно:

R:

G:

B:

Туман войны (считается на CPU):

Для разрушаемых объектов есть ещё и damage map. Накладывается по маске.

Вот так всё непросто. :)

Водичка. В принципе незамысловатая. Только отражения. Есть текстура с маской прибрежных зон, для имитации пены на волнах. Тот же light scattering. Направление ветра регулируется из приложения.

Земля. Уже 10 текстур занято, места для тайлов и маски совсем не остается. Выход простой – отмоделить и оттекстурить землю, как обычные объекты. Шейдеры используются абсолютно такие же, как для объектов, только вдобавок применяется еще и Point Light Map описанная в самом начале.

Партиклы. Сложный вертексный шейдер хитро считает освещение, зависящее от кучи входных параметров. Также он считает текстурные координаты, так как в Relic использовали хитрую систему запаковки текстур в атласы. Когда одной большой (2Кх2К) стало мало, а рисовать всё скопом очень хотелось, программисты вспомнили про кубемапы. Вот так на свет появилась огромная кубемапа (6х2Кх2К), в которой содержатся все изображения, необходимые для рендеринга эффектов. Вот примеры 2-х сторон:

На самом деле, очень необычное решение. Я такого ещё нигде не видел. В пиксельном шейдере вездесущий light scattering + странное смешивание семплов из кубемапы с nearest и point фильтрациями (2 семплера). Для чего они это делают? Я не разобрался. :)

В конце идут границы игровых зон и выделения юнитов. Тут тоже таится необычность. Это высокотесселированые модельки, которые считаются на CPU. Тяжело описать, лучше 1 раз увидеть:

Блум. Даунсемпл + color remap + фильтр Гаусса по горизонтали и вертикали.

UI. Вообще неплохой, но после всего остального сильно проигрывает в эффектности. Батчить можно было лучше. Текст по словам, а вот иконки на миникарте по одной.

Общие впечатления от рендера очень положительные. Технологично и чётко. При стандартном наклоне камеры (если Backspace нажать), на максимальной высоте 600-800 DIP’ов. Из них 100 DIP’ов UI. Если смотреть горизонтально, то 2000, но это не критично, так как так никто не играет. Как и в DoW, применена scissor rectangle оптимизация: область, закрываемая UI, отсекается. Это было не столь важно в DoW, но в CoH, с его супер шейдерами, важно. Естественно, всё это безобразие не без офигенного арта.

Мини выводы:

1. В этот раз решил хороший баланс арта и технологии. :)
2. Небольшие замечания по движку всё равно есть. Например, вместо Atmospheric Light Scattering’а, влияние которого видно только при горизонтальном положении камеры, можно было сделать обычный туман. Картинка пострадала бы не сильно, но мы бы получили прирост в скорости, за счет более лёгких шейдеров. Хотя в игре много cut-scenes… В общем это так, ни на что не претендующие мысли вслух. Отмечу также отсутствие double speed z, и UI.
3. Движки DoW и СoH совсем непохожи друг на друга. Я не буду утверждать, что они были сделаны разными командами, но подозрение есть. Ещё одно доказательство «разности»: в CoH остались специальные маркеры, которые видны в PixWin. Это мне немного облегчило «разделку». А вообще, по таким деталям отмечаешь высокую культуру программирования.

Готовы узнать страшную тайну? :) В игре полностью FFP’шный рендер! Fixed Function Pipeline, то есть совсем без шейдеров! Честно признаться, это было для меня полной неожиданностью.

Исследование, как обычно, проходило на максимальных настройках графики.

Движок отличается хорошей сортировкой объектов по рендерстейтам и текстурам. DIP’ов не много.

Отрисовка сцены начинается с земли. Простые квадратные патчи. На экран помещается 5-6, при стандартном положении камеры. Используются 2 текстурки:

Первая делает имитацию бликов на земле. Блендятся они линейной интерполяцией, используя альфа канал диффузной текстуры, который выглядит вот так:

Результат после первого прохода:

Далее второй проход для земли. Накладываются детали на землю, используя стандартный альфаблендинг. Примеры текстурок с деталями (зелено-красные клетки показывают альфу):

Затем поверх рисуются тени от зданий и юнитов, рытвины от взрывов, и т.д. Используются примерно такие текстуры:

После всего этого следует ещё 1 проход, в котором накладывается лайтмапа, туман войны и вот такая странная 2-х тексельная текстурка (я её увеличил и добавил рамочку, так как белое на белом смотрится не очень:) ):

Это альфаканал. Сама она белая. Текстурными координатами для неё является позиция вертекса в пространстве камеры (D3DTSS_TCI_CAMERASPACEPOSITION), умноженная на матрицу странного вида. После долгих (и тщетных) попыток понять всю эту хитрую математику логически, я запустил игру и стал приглядываться, пытаясь обнаружить что-то визуально. Единственное, что я заметил, так это темная полоса посреди экрана. Уверен, что это и есть эффект, который даёт эта текстура, хотя для чего это было сделано остается загадкой. Кто знает, может, без этой хитрости, картинка резко отличается в худшую сторону? :)

Лайтмапа земли:

Туман войны в формате LUMINANСE8. Считается на CPU:

Результат таков:

Далее следует небо. На меш в форме купола накладывается текстура вот такого вида:

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

Когда отрисовка неба закончена, начинается рендеринг объектов. Формула простая: диффузная текстура + туман войны + та самая, хитрая 2-х тексельная текстурка . Постоянно включено солнышко – первый directional источник. Пример текстуры объектов:

Юниты отображаются абсолютно аналогично. Скининг на CPU. Диффузная текстура:

Системы частиц. Тут всё стандартно. Далее идут маркеры под юнитами, рамка под выделенным зданием (рисуется каждая сторона прямоугольника отдельно, что очень странно), и т.д.

Последним идет UI. DPUP’ов нет (слава богу), но всё поэлементно. Текстуры для UI не в атласах (что тоже странно). Каждая кнопочка – отдельная картинка. Текст блоками.

Вот и всё. W40K: DoW – это ярчайший пример заруливания арта и дизайнерской работы. Сказать больше нечего. После таких вот откровений, мне стало очень интересно, а как дело обстоит в Company of Heroes? Помня о том, что там я видел шадоумапы (да, их можно сделать на FFP, но только на NVidia аппаратуре), я понимал, что вряд-ли встречу чистый FFP во второй раз. Единственное, что могу сказать сейчас, так это то, что CoH таит в себе не меньшее количество сюрпризов. :) Часть 2 не за горами. Stay tuned!

Недавно, я себе открыл простой и быстрый способ определения качества рендера. Надо всего-лишь запустить игру с дебаговым директом, а потом смотреть где и как падает. :) Готика падает очень быстро. Первый кадр рендера ГУИ. Как контр-пример: вархамерровский движок Relic'а (Warhammer 40K: Down of War, W40K: Winter Assault, W40K: Dark Crusade, Company of Heroes). Прошёл в Dark Crusade пару миссий, и только потом заметил, что сижу на дебаговом директе. Хороший рендер. :) Извините, отвлёкся.

Машина на которой тестировалась игра: A64X2 4200+, 2GB RAM, GF7800GT. Настройки игры - high.

Фпс 15-20. Чему удивляешься сразу, так это маленькому количеству DIP calls. 400-700. Всегда. Без динамических тенюшек так вообще 300. Все здорово до того момента, когда мы достаём факел. DIPы подскакивают до 1200. Вы тоже подумали сразу про omnidirectional shadow maps? Правильно, они там есть. :) Кстати, фпс падает всего на 2-3.

Что, как и в каком порядке рисуется в готике:

1. Shadow map от солнышка (directional light). Тут все просто. Берём квадрат вокруг персонажа со стороной 20 метров, и все объекты что туда попали рисуем. PSM, TSM, LiSPSM и т.д. не используется. Используем NV depth texture hack.

2. Если включен факел, то рисуем R32F cubemap.

3. Z-only pass. Рисуется не все, а только крупные объекты. Очень правильно.

4. Баундинг боксы для использования HW Occlusion Query. Опять же, объекты не все.

5. Если включен Depth of Field эффект, используем MRT. 2 рендер таргета: цвет (R8G8B8A8), и глубина (тоже R8G8B8A8). Глубина записывается как есть, никакой запаковки флоата в восьмибитные каналы не происходит.

6. Рисуем персонажей. Скиннинг на GPU, нормал мапы, попиксельные точечные (я видел 2) и направленные источники. 2 шадовмапы (от точечного источника и солнышка). Предрасчитанная текстура с тенями от террейна. Используются даже Spherical Harmonics (не спрашивайте меня, что это. Я сам с трудом представляю:) ). Шейдеры показывать не буду, так как они длинные и страшные.

7. Ближняя земелька рисуется очень похоже. Нет скининга, есть несколько слоёв смешанных по маске. Я бы текстурки показал, но по причинам описанным выше (pix не работает), я их не добыл. Сорри.

8. Ближние объекты (деревья, камни, травка).

9. Всякие дальние объекты. Огромные куски земли. Спидтришные деревья, крупные объекты. Шейдеры тут простые. Зачастую туманчик + 1 текстура. Получается примерно следующие картиночки:

10. Простое Небо.

Далее идет пост-процесс.

1. Даунсемплим картинку. Используем color remap, чтобы выделить яркие области.
2. Блурим её разочек.
3. Собираем финальное изображение. Блум текстура + сцена + глубина сцены. Пуассоновским фильтром блурим основную картинку, радиус распределения получая из текстуры с глубиной. Не Depth of Field, конечно, но нечто похожее.

Про воду забыл. Я по игре много не бегал, но морская вода совсем не такая, которая была описана Куртом Пельзером (Kurt Pelser) в ShaderX2 - Tips and Tricks. Простая какая-то. Я думал уже накручивать сложность эффектов так накручивать. Хотя ещё проходы они бы, наверное, уже не потянули. :)

ГУИ - хороший. Не по буковке. :) Отвлекусь ещё раз. Вот в Supreme Commander Multiplayer Beta ГУИ! ГУИще самый настоящий. :) Кто не знает - это стратегия такая. Так вот, там весь ингейм ГУИ рисуется за 1 (один) draw call! :) Сильно.

Короткие выводы. Что понравилось: Впечатлён технологичностью рендера. Отличная draw call reduction оптимизация, что позволило сделать даже такую экзотическую вещь, как omni shadows.

Что не понравилось: Чувствуется халатный подход (дебаговый D3D. VB, IB постоянно создаются в рантайме).

Мне рендер скорее понравился, чем нет. Это даже не смотря на тяжёлые шейдеры, и как следствие низкий фпс.

Update Нашёл параллакс. Есть на каменной площади в стартовом городишке. По просьбам больше картинок, которые прояснят ситуацию с батчингом геометрии. Ближняя травка: Ближняя земелька: Дальние деревья: Камешки: Дальняя земля: В городах все стандартно. Домики по кускам. Отдельные объекты (лавочки, столбики, заборчик).

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

Итак NFS Carbon. Супер бренд, ведущий издатель. У вас высокие ожидание к этому продукту? У меня тоже. Были. Если, вы читали мои предыдущие постинги, то знаете, что я увлекаюсь реверс ижинерингом рендеров популярных игр. Обычно я брал хорошую игру, и смотрел почему же так все хорошо. Когда я запустил демку нового NFS, меня стали сильно одолевать вопросы "почему все так плохо?" и "откуда такие тормоза?".

Итак, "чудо" програмистского исскуства NFS Carbon. Ингейм рендер (первая гонка в демке): в кадре от 1000 до 3000 (!) DIPов. Это ужас. Среднее значение 2200-2300. Рисуется все мелкими объектами. Окна на домах отдельно каждое, и т.д. Огромные шейдеры. Огромноая универсальность. В шейдерах для машинок учитывается всё: какие-то туманы, microflakes для металлических поверхностей (я понимаю использовать их в "гараже", там машинку рассматриваешь. Зачем они в гонке, объясните?). Слава богу для машинок есть LOD шейдеров. Для статики нету. Всего переключений шейдеров на кадр 100-200, а вот текстур 1500-2000, а рендер стейтов (о ужас) 15000 и больше!

Ужасно рисуется небо. Каким-то ужасно сложным шейдером (инструкций в 70, кажется) смешивается 2 текстурки первыми DIP вызовами. Естественно занимает это все дело половину экрана. А потом, с чистой совестью, затёрли процентов 80 неба домиками. Какие молодцы. У вас крутая видяха, у которой пиксельные конвеера исчисляются десятками? Я вас поздравляю. Теперь есть чем её занять. :)

На нашем болиде realtime environment mapping, создание которого размазано по 6 кадрам (т.е. в 1 кадр игры рисуется 1 сторона кубемапы). Flatout 2 ясно показал, что честного и не надо вовсе. Я долго ездил в NFS'е на Gallardo туда сюда, пытаясь более точно определить схему обновления кубемапы. Вычислял эти честные отражения. Так и не вычислил. Единственное, где их более менее видно,то в кинематографических пролётах камеры на старте гонки. Хотя, так как машинки не отражаются (они в кубическую текстуру не рисуются), то и понту не много. А машинки не отражаются потому, что так как текстура всего одна (только для нашей машинки), то было бы заметно, что отражения в машинах компьютерных гонщиков (для них используется та же текстура) стало неправильное. В общем, моё мнение по этому вопросу - выкинуть реалтайм нафиг, и практически без потери качества поднять ФПС. Плюс ко всему, есть A16R16G16B16F текстура, в красный канал которой, на каждом кадре, записывается нормализированная глубина всей сцены. Используется она только время генераци кубической текстуры (как я так и не понял). Я было подумал про soft particles. Ан нет, фигушки. ABG каналы не используются. У вас на борту видеокарты много памяти? Так вот знайте, что играя в NFS Carbon почти 5 мегабайт (это в разрешении 1024х768) заняты пустотой.

GUI. Попробуете отгадать? Да, да, DrawPrimitiveUP. Весь GUI рисутеся DPUP'ами! Поэлементно. По буковке. 200-300 вызывов. У вас быстрый процессор? (даже с двумя ядрами?) Вот знайте, что играя в NFS Carbon он занимается простаиванием и пустой пересылкой вертексов в видеокарту. Очень полезная работа.

Motion blur. На самом деле это просто весовой Radial Blur. В основном проходе рендера пишем в альфа канал степень разблуривания конкретного пикселя. Ближние сильнее дальние слабее. На первый взгляд все просто. Смущает всего две вещи:

1. Почему шейдер блура такой огромный (100 инструкций)?
2. Почему в картинке, которая блурится нет машинок? Хотя может потому, что машинки обычно двигаются с сопоставимыми скоростями. Не предусмотрено одно: траффик часто двигается навстречу. Чёткий автомобиль, что едет по соседней полосе, на фоне размытой дороги смотрится аляповато.

Гараж и главное меню. Всегда очень "уважал" игры, которые начинают тормозить прямо с меню. Я "уважаю" NFS Carbon :). Она начинает тормозить с экрана, где пишут "Loading..." Но это не удивительно, ведь вы не знали, что на этом экранчике 1000 DPUP'ов :) В общем гараж это обычный уровень, на котором рисуется даже небо (кто его там увидит, тому пирожок). Все те же, никому не нужные, сложные шейдеры. Отдельный перл гаража - отражения на полу. Не видно? Присмотритесь внимательнее. Так вот, в это "очень заметное отражение" рисуется абсолютно вся геометрия гаража. С теми же ужасными огромными шейдерами. Все супер мелкие детальки автомобиля. Все полочки, детальки и рюшечки гаража. Я не знаю чем думают разработчики, когда тратят столько ресурсов на фишку, которой практически не видно (я нашел отражения, только после того как увидел, что туда что-то рисуется).

Краткий вывод почему все так плохо:

• Огромное количество вызовов рендера (драйвер тайм половина времени кадра)
• Использвангие DPUP.
• Сомнительные графические решения.
• Большущие убер-шейдеры (я в них не разбирался, но у меня стойкое чувство, что можно проще).

З.Ы. Тестировалась демо версия. Сильно сомневаюсь, что в релизе будет лучше. З.З.Ы. Предыдущие версии NFS'а не исследовал. Я не знаю как там, но, по крайней мере, не тормозят.

Итак, реверсил я на максимальных настройках графики ("insane" в параметрах конфиграции) , на видеокарте GF6600.

Рендер игрового кадра состоит из следующих этапов:

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

• Тени для монстров. Для каждого используется RTT (render target texture) A8R8G8B8 128х128.

• Блурим эти текстуры каждую по 2 раза простым 4 tap фильтром, используя смещения координат. Получаем

• Монстрики. Используется хардварный скининг. Точно количество костей не знаю, но учитывая что vs.1.1, смею предположить что около 20. Модель содержит, естественно, больше, поэтому она разбивается на несколько сабмешей, по костям. Количество влияний на вершину – 4. Скиненные персонажи рисуются в 1 проход, поэтому освещаются сразу. Поддерживаются, похоже, только directional источники, коих может быть до 5 штук. Пиксельного шейдера нет. Освещение посчитанное в vs, умножается на диффузную текстуру (которая, кстати, очень качественная). Текстура монстрика (оригинальный размер 1024x1024):

vs_1_1
dcl_position v0
dcl_normal v1
dcl_texcoord v2
dcl_blendweight v3
dcl_blendindices v4
dp4 oT0.x, v2, c24
dp4 oT0.y, v2, c25
dp4 oT1.x, v2, c24
dp4 oT1.y, v2, c25
dp3 r0.w, v3, c8.z
add r0.w, c8.z, -r0.w
mad r1, v4.zyxw, c8.y, c8.x
mov a0.x, r1.x
m3x3 r5.xyz, v1, c0[a0.x] // Скининг позиции по первой кости
m4x3 r6.xyz, v0, c0[a0.x] // Скининг нормали
mul r3, r5.xyzz, v3.x // Блендим по весу кости
mul r4, r6.xyzz, v3.x
mov a0.x, r1.y
m3x3 r5.xyz, v1, c0[a0.x] // тут и дальше аналогично по 2-4 костям.
m4x3 r6.xyz, v0, c0[a0.x]
mad r3, r5.xyzz, v3.y, r3
mad r4, r6.xyzz, v3.y, r4
mov a0.x, r1.z
m3x3 r5.xyz, v1, c0[a0.x]
m4x3 r6.xyz, v0, c0[a0.x]
mad r3, r5.xyzz, v3.z, r3
mad r4, r6.xyzz, v3.z, r4
mov r4.w, c8.z
m4x4 r0, r4, c0
mov oPos, r0
mad oFog, r0.z, c9.y, c9.x
mov r4, c11.xyzz
mov r0.w, c10.w
dp3 r0.x, r3, c13 // n dot l
dp3 r0.y, r3, c14 // n dot h
lit r1, r0 // посчитали освещение от directional источника. Тут всего 1 источник, но может быть больше. Считается аналогично.
mad oD0, r1.y, c12, r4
mul r5, r1.z, c12
mul oD1, r5, c10
---
ps – ffp

• Первый проход на объекты. FFP + простые шейдеры (1.1). При отрисовке земли используется 2 диффузные текстуры с рисунком камешков и травички, которые блендятся по заданной маске. Также используется лайтмапа.

vs_1_1
dcl_position v0
dcl_texcoord v1
dcl_texcoord1 v2
m4x4 r0, v0, c0
mov oPos, r0
mad oFog, r0.w, c9.y, c9.x
dp4 oT0.x, v1, c24
dp4 oT0.y, v1, c25
dp4 oT1.x, v1, c27
dp4 oT1.y, v1, c28
mov oT2.xy, v2.xyyy
mov oT3.xy, v2.xyyy

// approximately 12 instruction slots used

ps_1_1
tex t0 // ground texture 1
tex t1 // ground texture 2
tex t2 // blend map
tex t3 // light map
mul r0.xyz, t0, 1-t2 // Темные регионы на маске блендинга соответсвуют t0
+ mul r0.w, t0.w, 1-t2.w // Зачем тут параллелить альфа и вектор пайпы? Не пойму.
mad r0.xyz, t1, t2, r0 // Светлые регионы - t1. Результат сложили
+ mad r0.w, t1.w, t2.w, r0.w // Опять…
mul_x2 r0.xyz, r0, t3 // * на лайтмапу и * 2
+ mul r0.w, r0.w, t3.w // альфу на 2 не умножаем.

// approximately 7 instruction slots used (4 texture, 3 arithmetic)

Пример маски блендинга для земли:

Пример лайтмапы для земли:

При отрисовке всех остальных объектов используется лайтмапа и 1 диффузная текстура. Для ближней геометрии используется также текстура с деталями.

vs_1_1
dcl_position v0
dcl_texcoord v1
dcl_texcoord1 v2
m4x4 r0, v0, c0
mov oPos, r0
mad oFog, r0.z, c9.y, c9.x // считаем туманчик
dp4 oT0.x, v1, c24 // тут какой-то рескейлинг. Присутствует во всех шейдерах. Глубоко не вникал.
dp4 oT0.y, v1, c25
dp4 oT1.x, v1, c27
dp4 oT1.y, v1, c28
mov oT2, v2

// approximately 11 instruction slots used
На момент теста в константах было вот что.
// c24 – 20, 0, 0, 0
// c25 – 0, 20, 0, 0
// c27 – 20, 0, 0, 0
// c28 – 0, 20, 0, 0

ps – FFP
t0 – base
t1 – detail – для ближних объектов этого нет.
t2 – lightmap

формула блендинга текстур: (base + detail – 0.5) * lightmap * 2

Лайтмапа для объектов (оригинальный размер 1024x1024):

• Вода. Первый проход. Сложные шейдеры, до конца не осилил :) Приводить их не буду. Большое количество входных параметров. Vs – 56 инструкций, ps – 31 инструкция. В этом проходе накладываем reflections, анимируя её используя 2 dudv карты. Волнение геометрии создаем анимацией вершин в vs. Я вообще обнаружил повертексную анимацию, только после того, как шейдер проанализировал, и увидел, что там меняется позиция вершины. Так думал, что вода плоская.

• Второй проход для воды. Освещаем её 4-мя направленными (directional) источниками повертексно.

vs_1_1
dcl_position v0
dcl_normal v1
dcl_texcoord v2
m4x4 r0, v0, c0
mov oPos, r0
mad oFog, r0.z, c9.y, c9.x
dp4 oT0.x, v2, c24
dp4 oT0.y, v2, c25
dp4 oT1.x, v2, c27
dp4 oT1.y, v2, c28
mov r4, c11.xyzz // r4.xyzw = 0.125
mov r0.w, c10.w
m3x3 r3.xyz, v1, c4 // во view space
dp3 r0.x, r3, c13 // n dot l
dp3 r0.y, r3, c14 // n dot h
lit r1, r0 // осветили. После операции r1.y = diffuse, r1.z = specular
mad r4, r1.y, c12, r4 // в c12 хранится цвет источника света
mul r5, r1.z, c12 // для спекуляра тоже самое.
dp3 r0.x, r3, c16 // дальше аналогично накапливаем diffuse и specular contribution для еще 3-х источников.
dp3 r0.y, r3, c17
lit r1, r0
mad r4, r1.y, c15, r4
mad r5, r1.z, c15, r5
dp3 r0.x, r3, c19
dp3 r0.y, r3, c20
lit r1, r0
mad r4, r1.y, c18, r4
mad r5, r1.z, c18, r5
dp3 r0.x, r3, c22
dp3 r0.y, r3, c23
lit r1, r0
mad oD0, r1.y, c21, r4
mad r5, r1.z, c21, r5
mul oD1, r5, c10

// approximately 36 instruction slots used

ps – ffp

В арсенале PainKiller’а есть еще один тип воды. Без честных отражений, с использованием лайтмап. Такой тип используется на уровнях, где воды много. Например в локации C5L1_City_On_Water. Первый же тип используется на первом уровне аддона Battle Out Of Hell: C6L1_Orphanage. Думаю, что мощный редактор позволяет по-разному варьировать параметры воды, чтобы получить нужный визуальный стиль.

• Небо. До 4-х слоев. Компоненты трехслойного неба: полусфера, внутри чашечка в зените, потом опять полусфера. Эти слои блендятся стандартным альфаблендом (srcalpha, invsrcalpha), и используют шейдеры точно такие же как при рендеринге земли. Неиспользованные слои (вспомним, что при рендеринге земли используется 2 текстуры для комбинирования) заменяются dummy текстурой.

Пример текстур неба: Оригинальный размер 2048х512

Оригинальный размер 1024x1024

Оригинальный размер 1024x1024

• Второй проход на сцену – освещение. Тут все что земля, что остальные статические объекты рисуются одинаково. Освещение осуществляется от одного точечного источника, попиксельно. Весь процесс достаточно хитрый. Для учета расстояния используется текстура аттенюации такого содержания:

В вертексном шейдере мы вычисляем расстояние от источника света до вершины. Поделив полученное расстояние на дистанцию влияния источника, мы пакуем вектор так, что все расстояния на которые влияет источник попадают в диапазон [-1,1]. Скейлим дальше в [0,1]. Получили текстурные координаты для лукапа в текстуру аттенюации (так как address mode установлен в clamp, то все лукапы за пределами текстуры будут происходить по ее границе). В нашем примере используется простой кружочек, что означает простое постепенное ослабление освещения с расстоянием. Но задав, например тот же кружочек, но инвертировав его цвет, мы получим освещёнными дальние объекты, но неосвещённые ближние. В общем вариантов масса. Шейдеры для освещения статики:

vs_1_1
dcl_position v0
dcl_texcoord v1
dcl_normal v3
m4x4 r0, v0, c0
mov oPos, r0
mad oFog, r0.w, c9.y, c9.x
add r0, v0, -c13 // world pos – light pos
mul r1, r0, c12.w // В с12.w коэффициент дальности освещения источником. После умножения все расстояния на которые влияет источник, попадут в диапазон [-1, 1]
mad r1, r1, c8.w, c8.w // Пакуем вектор [-1, 1]->[0, 1]
mov oT0.xy, r1.xyyy // xy записали в tc0
mov oT1.x, r1.z // z – в tc1
mov oT1.y, c8.w // c8.w = 0.5, получаем эмуляцию 1D лукапа по горизонтальной линии в центре текстуры.
mov oT2, -r0 // записали vertex to light vector
dp4 oT3.x, v1, c33 // учитывая, что c33 1000, а с34 0100, эти 2 строки очень хитрый метод записать mov oT3.xy, v1. Возможно тут сделано с прицелом на анимацию текстурных координат.
dp4 oT3.y, v1, c34
mov oD0, c12
mad oD1, v3, c8.w, c8.w // запаковали нормаль в цвет

// approximately 17 instruction slots used

ps_1_1
tex t0 // Кружочек, снаружи непрозрачный, внутри прозрачный. А так белый.
tex t1 // Тот же кружочек
tex t2 // normalized vertex to light vector from normalization cubemap
tex t3 // diffuse texture
mul r0.xyz, t3.w, v0 // diffuse color * base texture alpha
dp3_sat r1, v1_bx2, t2_bx2 // n dot l
mul r0.xyz, r0, r1
+ add r0.w, 1-t0.w, -t1.w // Тут получаем аттенюацию по расстоянию, используя наш кружочек. t0.w – аттенюация по xy координатам, t1.w по z.
mul r0.xyz, r0, r0.w // Применили вычисленную аттенюацию к цвету.
+ mul r0.w, r1.w, r0.w
mul_x2 r0.xyz, r0, t3 // добавили diffuse texture

// approximately 9 instruction slots used (4 texture, 5 arithmetic)

Основные стетйты тендера установлены в: Depth write = false Srcblend = one Dstblend = one

Т.е. получаем блендинг pixel color + incoming color

• Третий проход на статику (только если включены тени). Рисуем геометрию, проективно накладывая текстуры с тенюшками от монстриков. Ничего особо интересного, разве что, тени еще больше разблуриваются (2 лукапа на текстуру).

• Партиклы. Используются динамические VB/IB. FFP.

• Оружие. Sm30. Normal mapping от нескольких (я видел 2) directional источников освещения. Тут все стандартно, за исключением того, что normal map’ы у них не в tangent, a в model space. Просто источники они тоже поворачивают в model space. Анимации оружия скинтся хардварно (на вертекс влияет 2 кости) Normal map оружия (оригинальный размер 1024х1024):

Specular mask хранится в альфа канале normal map’ы (оригинальный размер 1024х1024):

Диффузная карта (оригинальный размер 1024х1024):

// Registers:
//
// Name Reg Size
// ------------ ----- ----
// GClipMat c0 4
// GFogParams c9 1
// GLightDir0 c13 1
// GHalfDir0 c14 1
// GLightDir1 c16 1
// GHalfDir1 c17 1
// GSkinBones c27 69

vs_3_0
def c4, 765.005859, 1, 0, 0
dcl_position v0
dcl_texcoord v1
dcl_blendweight v2
dcl_blendindices v3
dcl_position o0
dcl_fog o1.x
dcl_texcoord o2.xy
dcl_texcoord1 o3.xy
dcl_texcoord2 o4.xyz
dcl_texcoord3 o5.xyz
dcl_texcoord4 o6.xyz
dcl_texcoord5 o7.xyz
mul r0.xy, c4.x, v3.zyzw
mova a0.xy, r0
dp4 r1.x, v0, c27[a0.x] // Скининг
dp4 r1.y, v0, c28[a0.x]
dp4 r1.z, v0, c29[a0.x]
dp4 r2.x, v0, c27[a0.y]
dp4 r2.y, v0, c28[a0.y]
dp4 r2.z, v0, c29[a0.y]
lrp r0.xyz, v2.x, r1, r2 // 2 кости, блендим по весам.
mov r0.w, c4.y
dp4 o0.x, r0, c0 // x * wvp
dp4 o0.y, r0, c1 // y * wvp
mov r4.xyz, c28[a0.x] // Тут немножко хитро. Так как используется не tangent space normal map, а model space, то параметры источников света (dir, half) перед установкой в константы переводится в это пространство. Затем поворачиваем вектора в соответствии с матрицами костей.
mul r3.xyz, r4, c13.y // y в animated model space
mul r1.xyz, r4, c14.y
mov r2.xyz, c27[a0.x]
mad r5.xyz, r2, c13.x, r3 // x
mad r3.xyz, r2, c14.x, r1
mov r1.xyz, c29[a0.x]
mad o4.xyz, r1, c13.z, r5 // o4 - light vector 0 в animated model space
mad o5.xyz, r1, c14.z, r3 // o5 – half vector 0 в animated model space
mul r3.xyz, r4, c16.y
mul r4.xyz, r4, c17.y
mad r3.xyz, r2, c16.x, r3
mad r2.xyz, r2, c17.x, r4
mad o6.xyz, r1, c16.z, r3 // o6 – light vector 1 в animated model space
mad o7.xyz, r1, c17.z, r2 // o7 – half vector 1 в animated model space
dp4 r1.z, r0, c2 // z * wvp
dp4 r1.w, r0, c3 // w * wvp
mad o1.x, r1.z, c9.y, c9.x // fog
mov o0.zw, r1
mov o2.xy, v1 // tc0 pass through
mov o3.xy, v1

// approximately 33 instruction slots used


// Name Reg Size
// ------------- ----- ----
// GLightEnable0 b0 1
// GLightEnable1 b1 1
// GAmbientColor c0 1
// GLightColor0 c1 1
// GLightColor1 c2 1
// ColorSampler s0 1
// NormalSampler s1 1

ps_3_0
def c3, 2, -1, 10, 0
dcl_texcoord v2.xy
dcl_texcoord1 v3.xy
dcl_texcoord2 v4.xyz
dcl_texcoord3 v5.xyz
dcl_texcoord4 v6.xyz
dcl_texcoord5 v7.xyz
dcl_2d s0
dcl_2d s1
texld_pp r0, v2, s0
texld r1, v3, s1
if b0
mad_pp r3.xyz, c3.x, r1, c3.y // распаковали нормаль из NM
nrm_pp r2.xyz, v4 // нормализировали light vector 0
nrm_pp r1.xyz, v5 // нормализировали half vector 0
dp3_sat_pp r2.w, r3, r2 // n dot l
dp3_sat_pp r2.z, r3, r1 // n dot h
pow_pp r1.z, r2.z, c3.z // посчитали спекуляр
mul_pp r2.xyz, r2.w, c1 // учли цвет источника
mul_pp r1.xyz, r1.z, r2 // учли спекуляр
if b1 // для второго тоже самое
nrm_pp r4.xyz, v7
nrm_pp r2.xyz, v6
dp3_sat_pp r4.w, r3, r4
dp3_sat_pp r2.z, r3, r2
pow_pp r3.w, r4.w, c3.z
mul_pp r2.xyz, r2.z, c2
mad_pp r1.xyz, r3.w, r2, r1
mad_pp r2.xyz, r2.w, c1, r2
endif
add r2.xyz, r2, c0 // добавили амбиент
mul r0.xyz, r0, r2 // добавили диффузную текстуру
mad_pp oC0.xyz, r1.w, r1, r0 // в альфа канале normal map’ы- specular mask
mov_pp oC0.w, r0.w
else
mul_pp oC0.xyz, r0, c0
mov_pp oC0.w, r0.w
endif

// approximately 45 instruction slots used (2 texture, 43 arithmetic)

• Downsample картики, с небольшим color remap’ом, для выделения ярких областей.

• Separable Gaussian blur. Горизонтальный, вертикальный, 13х13. Получили bloom текстуру.

vs_1_1
dcl_position v0
dcl_texcoord v1
add oT1.xy, v1, c20 // Посмещали в стороны текстурные координаты
add oT2.xy, v1, c21
add oT3.xy, v1, c22
add oT4.xy, v1, -c20
add oT5.xy, v1, -c21
add oT6.xy, v1, -c22
mov oPos, v0
mov oT0.xy, v1

ps_2_0
dcl t0.xy
dcl t1.xy
dcl t2.xy
dcl t3.xy
dcl t4.xy
dcl t5.xy
dcl t6.xy
dcl_2d s0
texld_pp r6, t1, s0 // 7 семплов используя TC посчитанные в VS
texld_pp r5, t0, s0
texld_pp r4, t2, s0
texld_pp r3, t3, s0
texld_pp r2, t4, s0
texld_pp r1, t5, s0
texld_pp r0, t6, s0
mul r6, r6, c1
mad_pp r5, r5, c0, r6 // Аккумулируем с учетом весов.
mad_pp r4, r4, c2, r5
mad_pp r3, r3, c3, r4
mad_pp r2, r2, c1, r3
mad_pp r1, r1, c2, r2
mad_pp r6, r0, c3, r1
add r5.xy, t0, c7 // Посчитали координаты еще 6 семплов.
add r4.xy, t0, c8 // Можно было заюзать все 4 компонента у oTx регистров в VS.
add r3.xy, t0, c9
add r2.xy, t0, -c7
add r1.xy, t0, -c8
add r0.xy, t0, -c9
texld_pp r5, r5, s0
texld_pp r4, r4, s0
texld_pp r3, r3, s0
texld_pp r2, r2, s0
texld_pp r1, r1, s0
texld_pp r0, r0, s0
mad_pp r5, r5, c4, r6
mad_pp r4, r4, c5, r5
mad_pp r3, r3, c6, r4
mad_pp r2, r2, c4, r3
mad_pp r1, r1, c5, r2
mad_pp r0, r0, c6, r1
mov_pp oC0, r0

// approximately 33 instruction slots used (13 texture, 20 arithmetic)

Блум текстура:

• Блендинг с блум тектурой. FFP. Блендим по формуле: blurred текстура + текстура сцены. Полученный результат отлично выглядит на динамическом небе.

• UI. Ингейм интерфейса в painkiller почти нет. Думаю именно по этому он сделан так ужасно J Рисуется поэлементно, группировок никаких нет. Зато в startup menu разработчики постарались. Особенно убило окно конфигурации кнопок. Несколько скринов из под NVPerfHUD’а:

3 раза перетиреть почти весь экран, причем такими маленькими квадратиками, это надо уметь :) 2000 дипов.

• Demon mode. Кто не играл, это такой режим, когда собираешь 66 душ, и превращаешься в бессмертного психа-убийцу. :) Процесс рендеринга таков: Рисуем сцену нормально в RTT. Затем из нее делаем ч.б. картинку (способ стандартный: dp3 pixel, float3(0.3, 0.59, 0.11). Потом рисуем монстров специальным шейдером, который используя нормали и градиентную текстуру выделяет границу объекта красным цветом. И, напоследок, используя dudv bump map, вносим в картинку искажения. Для получения motion blur эффекта блендим предыдущий и текущий кадр используя весовые коэффициенты.

ps_1_1
tex t0 // Семпл из оригинальной текстуры
texbem t1, t0 // Эффект мембраны, который возникает когда стреляешь в demon mode, реализуется твиками bumpenvmat текстурного стейджа.
tex t2 // Используем текстуру с предыдущего кадра, чтобы получить плавающий эффект.
mul r0, t1, c0
mad r0, t2, c1, r0 // Блендим текущий и предыдущий кадр по весам. Получаем motion blur like эффект.

Градиентная текстура:

Получаем вот такую картинку:

Вот собственно и всё.

Теперь общие сведения по рендеру.

1. Дипов мало. В аутдорах до 1000 (редко больше, но бывает). В индорах обычно меньше. Иногда сильно. При таком количестве проходов, это очень хороший показатель.
2. Сортировка по материалам и текстурам хорошая. D3DXEffect не используется.
3. Арт просто супер. Эффекты там где надо. Все хорошо настроены и сбалансированы. Дизайн уровней великолепен. Текстуры сделаны очень качественно. Полетайте в редакторе по C6L2_LoonyPark, например. Просто загляденье.
4. Загрузка видеопамяти 100 – 120 MB (у видеокарты на борту 128). AGP – 6 MB. Чувствуется умелая рука настройщика.
5. LOD’ов геометрии нет. Есть удаление glow партиклов по расстоянию.

Мои мини выводы (большинство перекликается с выводами по FlatOut2):

1. Первое, что надо продумать в рендере, это минимизация DP calls. PainKiller наглядно показал, что с малым количеством DP больше простора для применения интересных и разнообразных алгоритмов (которые могут потребовать несколько проходов рендера). Если для одного прохода требуется больше 1000 DP, то многопроходным алгоритмам, скорее всего, дорога закрыта. . Не надо брезговать предрасчетом освещения. Не подходят лайтмапы? Рассмотрите использование ambient occlusion. Никакие реалтайм алгоритмы не дадут вам того-же качества при таком малом потреблении ресурсов.
2. Арт и хорошая дизайнерская работа решает с огромной силой. Эти компоненты не просто делают игру красивее, но и позволяют применить более простые алгоритмы визуализации без ущерба для картинки, что разгружает рендер. Получается, что хороший арт ускоряет игру! Во как! J
3. Чтобы был хороший дизайн, надо давать хорошие рычаги управления этим дизайном (это не из исследования рендера, это после ознакомления с редактором и структурирования своих мыслей, после этого исследования). Методы управления по типу: «сказать программисту, чтобы исправил параметры материала там и там», не работают. Знаю по собственному опыту. Признаю, важность этого момента я недооценивал.

Сначала общие сведения. В кадре 70 - 120 тыс. полигонов. Все рисуется исключительно шейдерами 1.1 (что, в общем то, и не удивительно, учитывая то, что игра, также, вышла и на XBox). Дипов от 700 до 1100, что на удивление много.

Теперь процесс рендера поэтапно.

1. Тени для машин. Каждый автомобильчик имеет свою текстуру с тенью (256х256, R5G6B5). Туда рисуются только кузов и колеса. Очень похоже, что это самый малоденальный LOD. Шейдер элементарный. Получается такая картинка:

2. Небо. Сделано просто и оригинально: само небо - полукуб. Легко представить себе, как кубик разрезанный горизонтально пополам. Затем на уровне горизонта кольцо, с панорамной текстурой гор, домов, леса и т.д. Удобненько, потому что, тип неба (вечернее, дневное) можно менять отдельно. Хотя, можно было все тоже сделать одним кубиком и одной кубемапой. Вышло бы меньше draw calls.

3. Земля. Вот тут просто супер. Для каждой трассы есть одна (2048х2048) текстура земли, в которой рисунок уровня с видом сверху. Все статические тени от холмов, мостов, и других объектов уже на ней. При рендеринге используется эта текстура, и различные текстуры деталей (листики там, камешки). При их сложении получается очень симпатично. Модель освещения тоже очень простая и очень эффективная. Для всех статических объектов (не только земли) освещение предрасчитано, и хранится как диффузный цвет в вертексах меша. В реалтайме ничего не считается. В результате получаем очень короткие шейдеры, которые очень быстро исполняются. На этом этапе есть хорошая сортировка как по материалам, так и по текстурам.

Пример текстуры всей локации:

Пример текстуры деталей:

4. Кактусы, деревья. Есть статик батчингом. Я так и не понял, почему он то используется, то нет. Есть подозрение, что нефизические объекты за пределами трека рисуются кучами, а все остальные нет. На счет сортировки по материалам, то тоже не понятно. Хоть все рисуется одними и теми же шейдерами, но все равно каждые несколько draw calls обрамлены ID3DXEffect::Begin, BeginPass, EndPass, End. Освещение предрасчитано и тут. Шейдер такой же как и для земли. ps: 1+1 инструкций, vs: 6.

5. Машинки, часть 1. Без колес и стекол. Используются самые сложные шейдеры в игре. Есть диффузное освещение с использованием кубемапы (A8, вверху светло, книзу темнеет), спекуляр от солнца. В ps, также, передаётся степень повреждения рисуемой детали, на основе которой выбирается текстура новой, либо повреждённой машины. В алфа канале текстуры авто содержится отражающая степень поверхности. Для отражений используют левую кубемапу. Она одинаковая для всех трасс. На ней деревца и горы. Никакой динамики.

Новая машинка:

Поврежденная машинка:

before_p6. Физические объекты. Используют диффузную кубемапу. Опять странная сортировка по материалам. Частичная какая-то. 7. Машинки, часть 2. Элементы двигателя, интеръер, колесные диски. Шейдер как для части 1. 8. Водитель. Хардварный скининг. 9. Тени под машинами. Строится меш, который стелится по земле. Сначала рисуется простое тёмное пятно. Затем используется динамическая текстура тени сделанная в п.1. Интересно то как они заблуривают тень. Шейдеры с комментариями:

vs_1_1
dcl_position v0
dcl_color v2
dcl_texcoord v3
m4x4 oPos, v0, c0
add oT0.xy, v3, c32 // c32 0.000 -0.004 0.000 0.000
add oT1.xy, v3, c33 // c33 -0.004 0.000 0.000 0.000
add oT2.xy, v3, c34 // c34 0.004 0.000 0.000 0.000
add oT3.xy, v3, c35 // c35 0.000 0.004 0.000 0.000

ps_1_1
tex t0
tex t1
tex t2
tex t3
mul r0, c7, t0 // В c7, как можно догадаться, 1/4. В каждом текстурном стейдже одна
mad r0, c7, t1, r0 // и та же текстура с тенью от машины
mad r0, c7, t2, r0
mad_sat r0, c7, t3, r0

Т.е. блурят семпля 4 раза одну и ту же текстуру, немного смещая её в стороны. Учитывая их малый размер (256), и то что используется хардварная фильтрация текстур, и , результат выходит просто отличный.

10. Дальние + ближние кустики. То большие батчи (100-200 штук за раз), то по-одному. Простой шейдер.
11. Машинки, часть 3. Шины, стекла, фары. Для последних двух, простые отражения, используя ту же кубемапу, что и для кузова автомобиля.
12. Системы частиц. Дым, пыль, искры. Простейшие шейдеры.

Теперь всё нарисовано. Получилось вот так:

Далее пост-процесс.

13. Считаем яркость картинки. Проще говоря, из цветной делаем черно-белую.
14. Используя яркость пикселя (из ч.б. изображения) и специальной градиентной 1D текстуры делается color remap. Яркие пиксели получают один оттенок, темные другой. Вечером, например, освещённые участки немного красноватые. После ремапа, полученная картинка комбинируется с цветной, и получается вот такое:

15. Дайнсемплим изображение из п.14 в 256x256. Затем выделяем яркие места простым шейдером.
16. Блурим пинг-понгом 4 раза, методом, аналогичным с методом блура тенюшек от машин. 4 tap, используются смещения в текстурных координатах. Получаем вот такую картинку:

17. Объеденяем заблюреную текстуру, с основной картинкой. Получили glow еффект:

18. Делаем 2 radial blur тем-же методом, только теперь текстурные координаты не спещаются, а с каждым разом увеличиваются. Получили изображение, которое используется при нитро-ускорении:

19. UI. Тут все стандартно. Рисуем поэлементно. Сортировок никаких нет.

Это всё. Выводы, которые я сделал из этого маленького исследования:

• Арт решает (я это и раньше знал, но убеждаюсь все больше). Во Flatout2 нет ни одной cutting-edge графической технологии. Новомодных технологий можно наклепать три корзины. Но если у вас нет хорошего арта, и грамотной (!) настройки этих всех эффектов - у вас все будет тормозить и при этом выглядеть отстойно.
• Еще раз отметил для себя хороший принцип, который должен знать каждый разработчик игр: не надо считать каждый раз то, что можно посчитать один раз.
• Сортировки по материалам и текстурам в движке скорее нет, чем есть.
• Был немножко удивлен простоте, но не в ущерб качеству (хотя dip'ов можно было сделать и поменьше). Рендер прост и быстр.