[Предыдущие части анализа: первая и вторая, третья и четвёртая.]
В предыдущем посте я рассказывал, как в «Ведьмаке 3» реализованы падающие звёзды. Этого эффекта нет в «Крови и вине». В посте я опишу эффект, который есть только в этом DLC: Млечный путь.
Вот видео, в котором показан Млечный путь.
И несколько скриншотов: (1) до вызова отрисовки купола неба, (2) только с цветом Млечного пути, (3) после вызова:
Готовый кадр только с одним Млечным путём (без цвета неба и звёзд) выглядит так:
Эффект Млечного пути, ставший одним из самых сильных отличий от версии игры 2015 года, вкратце упомянут в разделе «Глупые трюки с небом». Давайте разберёмся, как он реализован!
План изложения будет привычным: сначала мы вкратце объясним всё, относящееся к геометрии, а затем расскажем про пиксельный шейдер.
Давайте начнём с используемого меша купола неба. Есть два серьёзных отличия между куполом 2015 года (основная игра + DLC «Каменные сердца», я обычно называю их обе «игрой 2015 года») и куполом в DLC «Кровь и вино» (2016 год):
а) В «Крови и вине» меш намного более плотный,
б) В меше купола неба «КиВ» используются векторы нормалей.
Вот меш купола неба 2015 года — DrawIndexed(720)
Меш купола неба в «Ведьмаке 3» 2015 года — 720 индексов
А вот меш из «КиВ» — DrawIndexed(2640):
Меш купола неба DLC «Ведьмак 3: Кровь и вино» — 2640 индексов
Вот ещё раз меш из «КиВ»: я нарисовал, как распределены нормали — они направлены в «центр» меша.
Меш купола неба DLC «Кровь и вино» с нормалями
Вершинный шейдер купола неба довольно прост. Вот соответствующий ассемблерный код. Ради простоты я пропустил вычисление SV_Position:
Входными данными из буфера вершин являются:
1) Позиция в локальном пространстве [0-1] — v0.xyz,
2) Texcoords — v1.xy,
3) Вектор нормали [0-1] — v2.xyz
Входящие данные из cbuffer:
1) Матрица мира (0-3) — классический подход: однородное масштабирование и преобразование по позиции камеры,
2) Масштаб и смещение для вершины (4-5) — трюк, используемый в течении игры для преобразования из локального пространства [0-1] в пространство [-1;1], и для потенциального «сплющивания» мешей.
А вот краткое описание того, что происходит в шейдере:
Шейдер начинается с простой передачи texcoords (строка 0). К позиции вершины в мире применяется масштаб и смещение (строка 1), а результат умножается на матрицу мира (строки 3-4, 12). Вектор нормали должен быть перенесён из интервала [0-1] в [-1;1] (строка 5), а затем он умножается на матрицу мира (строки 6-8) и в конце нормализуется (строки 9-11).
Готовые выходные данные имеют следующую схему:
Вычисления Млечного пути — это просто одна часть шейдера неба. В «КиВ» он гораздо длиннее, чем в версии 2015 года. Он состоит из 385 строк на ассемблере, а вариант 2015 года — из 267 строк.
Давайте рассмотрим фрагмент ассемблерного кода, отвечающий за Млечный путь:
Довольно пугающе, не так ли? Когда я увидел его впервые (это было до того, как я увидел шейдер падающих звёзд), то подумал: «Что это за ад? Этот код невозможно реверсировать!»
Но есть один аспект — если вы читали пост про падающие звёзды, то можете легко узнать этот паттерн. Код работает очень похоже на отрисовку метеоритов! Скоро мы поговорим и о кривой.
Фрагмент начинается с сэмплирования кубической карты звёзд (строка 175), где направление сэмплирования хранится в r2.xyz. Как видите, в строке line 177 есть инструкция сэмплировпния ещё одной кубической карты. В отличие от шейдера 2015 года, в шейдере «КиВ» есть ещё одна текстура «кубическая карта шума», грани которой выглядят примерно так:
Прежде чем мы доберёмся до кривой, давайте найдём входящие данные для неё. Сначала вычисляется скалярное произведение (строка 184) между нормализованным вектором нормали купола неба (строки 178-180) и вектором света Луны (строки 181-183) — по сути, это N*L.
Вот визуализация скалярного произведения (в линейном пространстве):
Значение, используемое в качестве входящих данных для функции «кривой Млечного пути», получается в строке 185:
x = saturate( noise * 0.2 + Ndot );
А вот визуализация такого искажённого N*L, тоже в линейном пространстве:
Теперь давайте перейдём к функции Млечного пути! Она чуть сложнее, чем функция падающих звёзд. Как я говорил в предыдущем посте, мы начинаем со списка контрольных точек по оси x. Взглянув на ассемблерный код, мы сразу их увидим:
Откуда мы знаем, что первые контрольные точки равны нулю? Это довольно просто: в строке 189 нет инструкции «add».
Согласно посту о падающих звёздах, контрольные точки определяют количество сегментов, а далее нам нужно найти для них веса.
Для первого сегмента это довольно просто. Вес равен 0.949254:
Давайте попробуем найти их для второго и третьего сегментов:
Именно на этом моменте я прекратил писать статью, потому что здесь что-то было не так (один из моментов, когда ты думаешь «хмм»). Посмотрите, всё не так легко, как простое умножение на один вес. Кроме того, откуда взялись значения наподобие -0.113726 и 0.015873?
Потом я понял, что эти значения просто являются разностями между максимальными возможными значениями в каждом сегменте ( 0.835528 — 0.949254 = -0.113726 и 0.851401 — 0.835528 = 0.015873)! Довольно очевидно (один из моментов, когда ты думаешь «эврика!»). Как оказалось, эти значения являются не весами, а просто координатами y точек, образующих кривую!
Это многое меняет и упрощает. Во-первых, мы можем избавиться от веса в функции, которую использовали в предыдущем посте
И можем записать функцию Млечного пути следующим образом:
Это обобщённое решение для любого количества точек, образующих плавную кривую. Кроме того, оно объясняет происхождение «странных» значений контрольных точек — вероятно, разработчики для задания точек использовали какой-то визуальный редактор.
Разумеется, тот же принцип применим к коду падающих звёзд.
Вот график функции:
График функции Млечного пути.
Красное — значение функции,
Зелёное — координаты по x
Синее — координаты по y
Жёлтые точки — контрольные
Хорошо, но что дальше? В строке 263 мы умножаем значение из функции на синеватый цвет:
Но это ещё не конец! Нам просто нужно выполнить гамма-коррекцию:
Теперь интересная штука: я назначил разные цвета контрольным точкам по оси x:
И вот что у меня получилось:
И на этом практически всё для Млечного пути сделано.
В строке 264 есть r4.xyz и…
Я знаю, что эта часть статьи называется «Млечный путь», но не смог удержаться от того, чтобы не рассказать вкратце, как создаются звёзды Туссента. Они гораздо ярче, чем в Новиграде, на Скеллиге или в Велене.
В одном из предыдущих постов я рассказывал о звёздах 2015 года; настало время поговорить о звёздах 2016 года!
На самом деле, основная часть ассемблерного кода выглядит так:
На HLSL это можно записать так:
То есть сами звёзды просто умножаются на 3 (строка 264), а затем вместе с влиянием Млечного пути на 2 (строка 304) — олдскульный способ, но работает отлично!
Разумеется, позже происходит и кое-что ещё (например, мерцание звёзд при помощи целочисленного шума, и т.д.), но это уже не относится к теме статьи.
В этой части я разобрался, как в «Ведьмаке 3: Кровь и вино» реализованы Млечный путь и звёзды.
Давайте заменим исходный шейдер кодом, который только написали. Готовый кадр выглядит вот так:
а с исходным шейдером кадр выглядит вот так:
Неплохо.
Один из эффектов постобработки, который можно встретить в «Ведьмаке 3» почти везде — это цветокоррекция. Её принцип заключается в использовании текстуры таблицы поиска (LUT) для преобразования одного множества цветов в другое.
Обычно процесс выглядит так: есть нейтральная (выходной цвет = входящему цвету) таблица поиска, которая редактируется в инструментах наподобие Adobe Photoshop — усиливается её контрастность/яркость/насыщенность/оттенок и т.д., то есть все модификации и изменения, которые достаточно затратны при вычислении в реальном времени. Благодаря LUT-ам эти операции можно заменить менее затратным поиском в текстуре.
Существует как минимум три известных мне цветовых таблиц LUT: трёхмерные, «длинные» двухмерные и «квадратные» двухмерные.
Нейтральная «длинная» двухмерная LUT
Нейтральная «квадратная» двухмерная LUT
Прежде чем мы перейдём к реализации цветокоррекции в «Ведьмаке 3», вот несколько полезных ссылок по этой технике:
Хорошая реализация на OpenGL с онлайн-демо
Цветокоррекция
Исследование графики Metal Gear Solid V (хорошая статья в целом, есть раздел о цветокоррекции) [перевод на Хабре]
Цветокоррекция при помощи текстур поиска (LUT)
Тема с форума gamedev.net
Статья из книги «GPU Gems 2» — цветокоррекция при помощи трёхмерных текстур
Документация UE4 о создании и использовании цветовых LUT
Давайте взглянем на пример LUT, использованной примерно в начале игры White Orchard — бОльшая часть зелёных цветов заменена на жёлтые:
В «Ведьмаке 3» используются двухмерные текстуры размером 512x512.
В общем случае ожидается, что цветокоррекция будет выполняться в пространстве LDR. Поэтому получается 2563 возможных входящих значений — больше 16 миллионов комбинаций, преобразуемых всего в 5122=262 144 значения. Чтобы покрыть весь интервал входящих значений, используется билинейное сэмплирование.
А вот скриншоты для сравнения: до и после прохода цветокоррекции.
Как видите, разница невелика, но заметна — небо имеет более оранжевый оттенок.
Что касается реализации в «Ведьмаке 3», и входящий, и выходной render targets являются полноэкранными текстурами с плавающей запятой (R11G11B10). Любопытно, что конкретно в этой сцене каналы самых ярких пикселей (рядом с Солнцем) имеют значения, превышающие 1.0f — даже почти до 2.0f!
Вот ассемблерный код пиксельного шейдера:
В целом, разработчики «Ведьмака 3» не стали изобретать велосипед и использую много «надёжного» кода. Это логично, ведь это один из эффектов, в котором нужно быть чрезвычайно аккуратным с координатами текстур.
Тем не менее, требуется два запроса к LUT, это следствие использования 2D-текстуры — необходимо симулировать билинейное сэмплирование канала синего. В представленной по ссылке выше реализации на OpenGL слияние этих двух запросов зависит от дробной части канала синего.
Что мне показалось интересным, так это отсутствие в ассемблерном коде инструкций ceil (round_pi) и frac (frc). Однако в нём довольно много инструкций floor (round_ni).
Шейдер начинается с получения входящей текстуры цвета и извлечения из неё цвета в гамма-пространстве:
Допустимые координаты сэмплирования min и max берутся из cbuffer:
Этот конкретный кадр был захвачен в разрешении 1920x1080 — значения max равны: (1919/1920, 1079/1080)
Довольно легко заметить, что ассемблерный код шейдера содержит два довольно похожих блока, за которыми следует получение данных из LUT. Поэтому я создал вспомогательную функцию, которая вычисляет uv для LUT. Давайте сначала взглянем на соответствующий ассемблерный код:
Здесь r2.xyz — это входящий цвет.
Первое, что происходит — проверка того, находятся ли входящие данные в интервале [0-1]. (строка 7). Это, например, используется для пикселей с компонентами > 1.0, как у вышеупомянутых пикселей Солнца.
Далее канал синего умножается на 0.99999 (строка 8), чтобы floor(color.b) возвращала значение в интервале [0-7].
Для вычисления координат LUT шейдер первым делом преобразует каналы красного и зелёного, чтобы «втиснуть» из в верхний левый сегмент. Канал синего [0-1] разрезается на 64 фрагмента, которые соответствуют всем 64 сегментам в текстуре поиска. На основании текущего значения канала синего выбирается соответствующий сегмент и вычисляется смещение для него.
Пример
Давайте, например, выберем (0.75, 0.5, 1.0). Каналы красного и зелёного преобразуются в верхний левый сегмент, что даёт нам:
float2 rgOffset = (0.75, 0.5) / 8 = (0.09375, 0.0625)
Далее мы проверяем, в каком из 64 сегментов расположено значение синего (1.0). Разумеется, в нашем случае это последний сегмент — 64.
Смещение выражается в сегментах (rowOffset, columnOffset):
float blue_rowOffset = 7.0;
float blue_columnOffset = 7.0;
float2 blueOffset =float2(blue_rowOffset, blue_columnOffset) / 8.0 = (0.875, 0.875)
В конце мы просто суммируем смещения:
float2 finalUV = rgOffset + blueOffset;
finalUV = (0.09375, 0.0625) + (0.875, 0.875) = (0.96875, 0.9375)
Это был просто короткий пример. Теперь давайте изучим подробности реализации.
Для каналов красного и зелёного (r2.xy) в строке 9 прибавляется смещение в полпикселя (0.5 / 64). Затем мы умножаем их на 0.996094 (строка 10) и ограничиваем их (clamp) особым интервалом (строки 11-12).
Необходимость смещения в полпикселя довольно очевидна — мы хотим выполнять сэмплирование из центра пикселя. Гораздо более загадочным аспектом является коэффициент масштабирования из строки 10 — он равен 63,75/64.0. Скоро мы расскажем о нём подробнее.
В конце координаты ограничиваются интервалом [1/64 — 63/64].
Зачем нам это нужно? Я не знаю точно, но похоже, это сделано для того, чтобы билинейное сэмплирование никогда не брало сэмплы за пределами сегмента.
Вот изображение с примером в виде сегмента 6x6, демонстрирующее, как работает эта операция ограничения (clamp):
Вот сцена без применения clamp — заметьте довольно серьёзное обесцвечивание вокруг Солнца:
Для простоты сравнения покажу ещё раз результат из игры:
Вот фрагмент кода для этой части:
Теперь пора найти смещение для канала синего.
Чтобы найти смещение строк канал синего делится на 8 частей, каждая из которых покрывает ровно одну строку в текстуре поиска.
Чтобы найти смещение столбца, полученное значение нужно ещё раз разделить на 8 меньших частей, что соответствует всем 8 сегментам строки. Уравнение из шейдера довольно запутанное:
На этом этапе стоит заметить, что:
frac(x) = x — floor(x)
Поэтому уравнение можно переписать так:
А вот фрагмент кода для этого:
Таким образом мы получили функцию, возвращающую координаты текстуры для сэмплирования текстуры LUT. Давайте назовём эту функцию «getUV».
Теперь вернёмся к основной функции шейдера. Как говорилось выше, из-за использования двухмерной LUT для симуляции билинейного сэмплирования канала синего нужны два запроса к LUT (из двух соседних друг с другом сегментов).
Рассмотрим следующий фрагмент на HLSL:
Принцип заключается в том, чтобы получать цвета из двух расположенных по соседству сегментов, а затем выполнять интерполяцию между ними — величина интерполяции зависит от дробной части входящего синего цвета.
Part 1 получает цвет из «дальнего» сегмента из-за явно заданного смещения синего ( + 1.0 / 64 );
Результат интерполяции хранится в переменной «finalLUT». Заметьте, что после этого результат снова возвращается в линейное пространство и умножается на lutCorrectedMult. В этом конкретном кадре его значение равно 1.00916. Это позволяет изменять яркость цвета LUT.
Очевидно, самой интригующей частью является «63.75» и «63.75 / 64». Я не совсем понимаю, откуда они берутся. Единственное объяснение, которое я нашёл: 63.75 / 64.0 = 510.0 / 512.0. Как говорилось выше существует ограничение (clamp) для каналов .rg, то есть при прибавлении смещения синего это по сути означает, что самые внешние строки и столбцы LUT не будут использоваться напрямую. Думаю, что цвета явным образом «втиснуты» в центр области текстуры поиска размером 510x510.
Давайте допустим, что inputColorGamma.b = 0.75 / 64.0.
Вот как это работает:
Здесь у нас есть первые четыре сегмента (1-4), которые покрывают канал синего с [0 — 4/64].
Судя по расположению пикселя, похоже, что каналы красного и зелёного примерно равны 0.75 и 0.5.
Мы дважды выполняем запрос к LUT — «Part 1» указывает на сегмент 2, а «Part 2» указывает на первый сегмент.
А интерполяция основана на дробной части цвета, которая равна 0.75.
То есть окончательный результат имеет 75% цвета из первого сегмента и 25% цвета из второго.
Мы почти закончили. Последним нужно сделать следующее:
Ха! В этом случае окончательный цвет состоит из 80% входящего цвета и 20% цвета LUT!
Давайте снова проведём краткое сравнение изображений: входящий цвет (то есть, по сути, с 0% цветокоррекции), окончательный кадр (20%) и полностью обработанное изображение (100% влияния цветокоррекции):
0% цветокоррекции
20% цветокоррекции (истинный шейдер)
100% цветокоррекции
В некоторых случаях «Ведьмак 3» использует несколько LUT.
Вот сцена, в которой используются два LUT:
До прохода цветокоррекции
После прохода цветокоррекции
Используемые LUT:
LUT 1 (texture1)
LUT 2 (texture2)
Давайте изучим ассемблерный фрагмент из этой версии шейдера:
К счастью, тут всё довольно просто. В соответствии с ассемблерным кодом мы получаем:
После получения двух цветов из LUT между ними выполняется интерполяция в lut_Interp. Всё остальное практически такое же, как в версии с одной LUT.
В этом случае единственной дополнительной переменной является lut_interp, сообщающая, как смешиваются две LUT.
Её значение в этом конкретном кадре примерно равно 0.96, то есть finalLUT содержит 96% цвета из LUT2 и 4% цвета из LUT1.
Однако это ещё не конец! Сцена, которую я изучал в части «Туман» использует три LUT!
Давайте взглянем!
До прохода цветокоррекции
После прохода цветокоррекции
LUT1 (texture1)
LUT2 (texture2)
LUT3 (texture3)
И снова ассемблерный фрагмент:
К сожалению, эта версия шейдера гораздо более запутанная, чем предыдущие две. Например, UV под названием «uv1» раньше встречались в ассемблерном коде перед «uv2» (сравните ассемблерный код шейдера всего с одной LUT). Но здесь всё не так — UV для «Part 1» вычисляются в строке 34, UV для «Part 2» — в строке 23.
Потратив гораздо больше ожидаемого времени на изучение того, что здесь происходит и недоумевая, почему Part2, похоже, поменялась местами с Part1, я написал фрагмент кода на HLSL для трёх LUT:
После завершения всех запросов текстур сначала интерполируются результаты LUT1 и LUT2, затем они умножаются на коэффициент масштабирования, а далее комбинируются с линейным цветом основной сцены. Давайте назовём результат lut12_finalLUT.
Затем примерно то же самое происходит для LUT3 — умножаем на ещё один коэффициент масштабирования и комбинируем с цветом основной сцены, что даёт нам lut3_finalLUT.
В конце оба промежуточных результата снова интерполируются.
Вот значения из cbuffer:
Если вы достаточно долго играли в «Ведьмака 3», то знаете, что Геральт — не большой любитель порталов. Давайте разберёмся, действительно ли они так страшны.
В игре есть два типа порталов:
Синий портал
Огненный портал
Я объясню, как создаётся огненный. В основном потому, что его код проще, чем у синего :)
Вот как огненный портал выглядит в игре:
Самая важная часть — это, разумеется, огонь, вращающийся по направлению к центру, но сам эффект состоит не только из видимой части. Подробнее об этом позже.
План этой части довольно стандартен: сначала геометрия, потом вершинные и пиксельные шейдеры. Будет довольно много скриншотов и видео.
С точки зрения рендеринга порталы отрисовываются в прямом проходе со включенным смешиванием — довольно распространённый в игре приём; подробнее см. в части о падающих звёздах.
Ну что, приступим.
Вот как выглядит меш портала:
Локальное пространство — вид спереди
Локальное пространство — вид сбоку
Меш напоминает рог Гавриила. Вершинный шейдер сжимает его по одной оси, вот тот же меш после сжатия в виде сбоку (в мировом пространстве):
Меш портала после вершинного шейдера (вид сбоку)
Кроме позиции у каждой вершины есть дополнительные данные: важны для нас следующие (на этом этапе я буду демонстрировать визуализации из RenderDoc, а позже расскажу о них подробнее):
Texcoords (float2):
Tangent (float3):
Color (float3):
Все эти данные будут использованы позднее, но на этом этапе у нас уже слишком много данных для файла .obj, поэтому экспорт этого меша может вызвать проблемы. Я экспортировал каждый канал как отдельный файл .csv, а затем загрузил все файлы .csv в моё приложение на C++ и сборка меша на основании этих собранных данных выполняется во время выполнения.
Вершинный шейдер не особо интересен, но давайте всё равно взглянем на соответствующий фрагмент:
Вершинный шейдер очень похож на прочие шейдеры, которые мы встречали ранее.
После краткого анализа и сравнения схемы входных данных я выяснил, что выходную struct можно записать так:
Я хотел продемонстрировать один аспект — как шейдер получает глубину в пространстве обзора (o0.z): это просто компонент .w переменной SV_Position.
На gamedev.net есть тема, в которой это объясняется чуть подробнее.
Вот сцена примера непосредственно перед отрисовкой портала:
… и после отрисовки:
кроме того, в утилите просмотра текстур RenderDoc есть полезная опция оверлея «Clear Before Draw», при помощи которой мы со всей точностью можем увидеть отрисованный портал:
Первый интересный аспект заключается в том, что сам слой пламени отрисовывается только в центральной области меша.
Пиксельный шейдер состоит из 186 строк, для удобства я выложил его сюда. Как обычно, во время объяснения я буду приводить соответствующие фрагменты на ассемблере.
Также стоит заметить, что 100 из 186 строк относятся к вычислению тумана.
В начале на вход подаются 4 текстуры: огонь (t0), шум/дым (t1), цвет сцены (t6) и глубина сцены (t15):
Текстура огня
Текстура шума/дыма
Цвет сцены
Глубина сцены
Также есть отдельный буфер констант с 14 параметрами, которые управляют эффектом:
Входящие данные: позиция, tangent и texcoords — довольно понятные концепции, но давайте внимательнее приглядимся к каналу «Color». После нескольких экспериментов мне кажется, что это не цвет сам по себе, а три различные маски, которые шейдер использует, чтобы различать отдельные слои и понимать, где применять различные эффекты:
Color.r — маска теплового марева. Как понятно из названия, она используется для эффекта теплового искажения воздуха (подробнее о нём позже):
Color.g — внутренняя маска. В основном используется для эффекта огня.
Color.b — задняя маска. Используется для определения того, где находится «задняя» часть портала.
Я считаю, что в случае подобных эффектов лучше описать отдельные слои, а не анализировать ассемблерный код от начала до конца, как я делал раньше.
Итак, поехали:
Для начала давайте исследуем самую важную часть: слой огня. Вот видео с ним:
Основной принцип реализации такого эффекта заключается в использовании статичных texcoords из данных для каждой вершины и анимировании их при помощи переменной истекшего времени из буфера констант. Благодаря таким анимированным texcoords мы сэмплируем текстуру (в нашем случае огня) при помощи сэмплера искажения/повтора.
Интересно, что в этом конкретном эффекте сэмплируется только канал .r текстуры огня. Чтобы эффект был более правдоподобным, описанным выше способом получаются два слоя огня, которые затем комбинируются друг с другом.
Ну, давайте наконец посмотрим на код!
Начинаем мы с того, что делаем texcoords более динамичными, когда они достигают центра меша:
А вот то же самое, но на ассемблере:
Затем шейдер получает texcoords для первого слоя огня и сэмплирует текстуру огня:
Вот соответствующий фрагмент на ассемблере:
Вот как выглядит первый слой при elapsedTimeSeconds = 50.0:
Чтобы показать, что же делает y_cutoff, продемонстрируем ту же сцену, но с y_cutoff = 0.5:
Таким образом мы получили первый слой. Далее шейдер получает второй:
А вот соответствующий ассемблерный фрагмент:
То есть, как вы видите, единственное отличие заключается в UV: теперь X тоже анимируется.
Второй слой выглядит так:
Получив два слоя внутреннего огня, мы можем их скомбинировать. Однако этот процесс чуть сложнее, чем обычное умножение, поскольку в нём участвует внутренняя маска:
Вот соответствующий ассемблерный код:
Получив inner_influence, которая является ни чем иным, как маской для внутреннего огня, мы можем просто умножить маску на цвет внутреннего огня:
Ассемблерный код:
Вот видео, в котором демонстрируются отдельные слои внутреннего огня. Порядок: первый слой, второй слой, внутреннее влияния и окончательный внутренний цвет:
Создав внутренний огонь, переходим ко второму слою: свечению. Вот видео, демонстрирующее сначала только внутренний огонь, потом только свечение, а затем их сумму — готовый эффект огня:
Вот как шейдер вычисляет свечение. Аналогично созданию внутреннего огня, сначала генерируется маска, которая затем умножается на цвет свечения из буфера констант.
Вот как выглядит outer_mask:
(1.0 — backMask) * innerMask
Свечение не имеет постоянного цвета. Чтобы оно выглядело интереснее, используется анимированный первый слой огня (в квадрате), поэтому заметны идущие к центру колебания:
Вот ассемблерный код, отвечающий за свечение:
Когда я начал анализировать реализацию шейдера портала, мне было непонятно, почему в качестве одной из входящих текстур используется цвет сцены без портала. Я рассуждал так — «здесь мы используем смешение, поэтому достаточно возвращать пиксель с нулевым значением альфы, чтобы сохранить цвет фона».
Шейдер имеет небольшой, но красивый эффект марева (теплового искажения воздуха) — от портала исходят тепло и энергия, поэтому фон искажён.
Принцип заключается в смещении texcoords пикселя и сэмплировании текстуры цвета фона с новыми координатами — такую операцию невозможно выполнить простым смешением.
Вот видео с демонстрацией того, как это работает. Порядок: сначала полный эффект, потом марево из шейдера, а в конце я умножаю смещение на 10, чтобы усилить эффект.
Давайте посмотрим, как вычисляется смещение.
Соответствующий ассемблер разбросан по коду:
Мы вычислили смещение, так давайте его используем!
Итак, в конечном итоге мы получили sceneColor.
Под цветом «цели» я подразумеваю центральную часть портала:
К сожалению, он весь чёрный. И причиной этого является туман.
Я уже рассказывал о том, как реализован туман в этой статье. В шейдере портала вычисления тумана находятся в строках [35-135] исходного ассемблерного кода.
HLSL:
И таким образом мы получаем готовую сцену:
Дело в том, что камера в кадре находится так близко к порталу, что вычисляемый destination_color равен нулю, то есть чёрный центр портала на самом деле является туманом (или, строго говоря, его отсутствием).
Так как при помощи RenderDoc мы можем инъектировать в игру шейдеры, давайте попробуем сместить камеру вручную:
И вот результат:
Ха!
Итак, хотя в этом конкретном случае очень мало смысла использовать вычисления тумана, теоретически ничто не мешает нам использовать в качестве destination_color . например, ландшафт из другого мира (возможно, потребуется дополнительная пара texcoords, но, тем не менее, это вполне реализуемо).
Использование тумана может быть полезным в случае огромного портала, который игрок может увидеть с большого расстояния.
Я раздумывал, куда поместить этот раздел — в «Цвет „цели“» или «Собираем всё вместе», но решил создать новый подраздел.
Итак, на этом этапе у нас есть описанный в 3.3 sceneColor, уже содержащий эффект марева (теплового искажения), а также есть destination_color из раздела 3.4.
Они интерполируются при помощи:
Что за значение, которое их интерполирует (r0.w)?
Здесь применяется текстура шума/дыма.
Она используется для создания того, что я называю «маской цели портала».
Вот видео (сначала полный эффект, затем маска цели, затем интерполированные подвергнутый мареву цвет сцены и цвет цели):
Взгляните на этот фрагмент на HLSL:
Маска цели портала в целом получается так же, как огонь — при помощи анимированных координат текстуры. Для настройки местоположения эффекта используется переменная "region_mask".
Для получения region_mask используется ещё одна переменная под названием vsDepth1. Чуть подробнее я опишу её в следующем разделе. Впрочем, она имеет незначительное влияние на маску цели.
Ассемблерный код маски цели выглядит так:
Фух, почти закончили.
Давайте сначала получим цвет портала:
Единственный аспект, который я хочу здесь обсудить — это vsDepth1.
Вот как выглядит эта маска:
В предыдущем подразделе я показал, как она получается; по сути, это «линейный буфер глубин», используемый для уменьшения цвета портала так, чтобы не было резкой границы из-за теста глубин.
Рассмотрим ещё раз готовую сцену, с умножением и без умножения на vsDepth1.
После создания portal_final получить готовый цвет просто:
Вот и всё. Есть ещё одна переменная finalPortalAmount, определяющая, сколько пламени видит игрок. Я не стал тестировать её подробно, но предполагаю, что она используется, когда портал появляется и исчезает — на короткий промежуток времени игрок не видит огня, зато видит всё остальное — свечение, цвет цели и т.п.
Готовый шейдер на HLSL выложен здесь. Мне пришлось поменять местами несколько строк, чтобы получить тот же ассемблерный код, что и у оригинала, но это не мешает общему потоку выполнения. Шейдер готов к использованию с RenderDoc, все cbuffers присутствуют и т.д, поэтому вы можете его инъектировать и поэкспериментировать самостоятельно.
Надеюсь, вам понравилось, спасибо за прочтение!
Часть 1: Млечный путь
В предыдущем посте я рассказывал, как в «Ведьмаке 3» реализованы падающие звёзды. Этого эффекта нет в «Крови и вине». В посте я опишу эффект, который есть только в этом DLC: Млечный путь.
Вот видео, в котором показан Млечный путь.
И несколько скриншотов: (1) до вызова отрисовки купола неба, (2) только с цветом Млечного пути, (3) после вызова:
Скриншоты
Готовый кадр только с одним Млечным путём (без цвета неба и звёзд) выглядит так:
Эффект Млечного пути, ставший одним из самых сильных отличий от версии игры 2015 года, вкратце упомянут в разделе «Глупые трюки с небом». Давайте разберёмся, как он реализован!
План изложения будет привычным: сначала мы вкратце объясним всё, относящееся к геометрии, а затем расскажем про пиксельный шейдер.
1. Геометрия
Давайте начнём с используемого меша купола неба. Есть два серьёзных отличия между куполом 2015 года (основная игра + DLC «Каменные сердца», я обычно называю их обе «игрой 2015 года») и куполом в DLC «Кровь и вино» (2016 год):
а) В «Крови и вине» меш намного более плотный,
б) В меше купола неба «КиВ» используются векторы нормалей.
Вот меш купола неба 2015 года — DrawIndexed(720)
Меш купола неба в «Ведьмаке 3» 2015 года — 720 индексов
А вот меш из «КиВ» — DrawIndexed(2640):
Меш купола неба DLC «Ведьмак 3: Кровь и вино» — 2640 индексов
Вот ещё раз меш из «КиВ»: я нарисовал, как распределены нормали — они направлены в «центр» меша.
Меш купола неба DLC «Кровь и вино» с нормалями
2. Вершинный шейдер
Вершинный шейдер купола неба довольно прост. Вот соответствующий ассемблерный код. Ради простоты я пропустил вычисление SV_Position:
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb1[4], immediateIndexed
dcl_constantbuffer cb2[6], immediateIndexed
dcl_input v0.xyz
dcl_input v1.xy
dcl_input v2.xyz
dcl_output o0.xyzw
dcl_output o1.xyzw
dcl_output_siv o2.xyzw, position
dcl_temps 3
0: mov o0.xy, v1.xyxx
1: mad r0.xyz, v0.xyzx, cb2[4].xyzx, cb2[5].xyzx
2: mov r0.w, l(1.000000)
3: dp4 o0.z, r0.xyzw, cb2[0].xyzw
4: dp4 o0.w, r0.xyzw, cb2[1].xyzw
5: mad r1.xyz, v2.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), l(-1.000000, -1.000000, -1.000000, 0.000000)
6: dp3 r2.x, r1.xyzx, cb2[0].xyzx
7: dp3 r2.y, r1.xyzx, cb2[1].xyzx
8: dp3 r2.z, r1.xyzx, cb2[2].xyzx
9: dp3 r1.x, r2.xyzx, r2.xyzx
10: rsq r1.x, r1.x
11: mul o1.xyz, r1.xxxx, r2.xyzx
12: dp4 o1.w, r0.xyzw, cb2[2].xyzw Входными данными из буфера вершин являются:
1) Позиция в локальном пространстве [0-1] — v0.xyz,
2) Texcoords — v1.xy,
3) Вектор нормали [0-1] — v2.xyz
Входящие данные из cbuffer:
1) Матрица мира (0-3) — классический подход: однородное масштабирование и преобразование по позиции камеры,
2) Масштаб и смещение для вершины (4-5) — трюк, используемый в течении игры для преобразования из локального пространства [0-1] в пространство [-1;1], и для потенциального «сплющивания» мешей.
А вот краткое описание того, что происходит в шейдере:
Шейдер начинается с простой передачи texcoords (строка 0). К позиции вершины в мире применяется масштаб и смещение (строка 1), а результат умножается на матрицу мира (строки 3-4, 12). Вектор нормали должен быть перенесён из интервала [0-1] в [-1;1] (строка 5), а затем он умножается на матрицу мира (строки 6-8) и в конце нормализуется (строки 9-11).
Готовые выходные данные имеют следующую схему:
3. Пиксельный шейдер
Вычисления Млечного пути — это просто одна часть шейдера неба. В «КиВ» он гораздо длиннее, чем в версии 2015 года. Он состоит из 385 строк на ассемблере, а вариант 2015 года — из 267 строк.
Давайте рассмотрим фрагмент ассемблерного кода, отвечающий за Млечный путь:
175: sample_indexable(texturecube)(float,float,float,float) r4.xyz, r2.xyzx, t0.xyzw, s0
176: mul r4.xyz, r4.xyzx, r4.xyzx
177: sample_indexable(texturecube)(float,float,float,float) r0.w, r2.xyzx, t1.yzwx, s0
178: dp3 r1.w, v1.xyzx, v1.xyzx
179: rsq r1.w, r1.w
180: mul r2.xyz, r1.wwww, v1.xyzx
181: dp3 r1.w, cb12[204].yzwy, cb12[204].yzwy
182: rsq r1.w, r1.w
183: mul r5.xyz, r1.wwww, cb12[204].yzwy
184: dp3 r1.w, r2.xyzx, r5.xyzx
185: mad_sat r0.w, r0.w, l(0.200000), r1.w
186: ge r1.w, l(0.497925), r0.w
187: if_nz r1.w
188: ge r1.w, l(0.184939), r0.w
189: mul r2.y, r0.w, l(5.407188)
190: min r2.z, r2.y, l(1.000000)
191: mad r2.w, r2.z, l(-2.000000), l(3.000000)
192: mul r2.z, r2.z, r2.z
193: mul r2.z, r2.z, r2.w
194: mul r5.xyz, r2.zzzz, l(0.949254, 0.949254, 0.949254, 0.000000)
195: mov r2.x, l(0.949254)
196: movc r2.xw, r1.wwww, r2.xxxy, l(0.000000, 0.000000, 0.000000, 0.500000)
197: not r4.w, r1.w
198: if_z r1.w
199: ge r1.w, l(0.239752), r0.w
200: add r5.w, r0.w, l(-0.184939)
201: mul r6.y, r5.w, l(18.243849)
202: mov_sat r5.w, r6.y
203: mad r6.z, r5.w, l(-2.000000), l(3.000000)
204: mul r5.w, r5.w, r5.w
205: mul r5.w, r5.w, r6.z
206: mad r5.w, r5.w, l(-0.113726), l(0.949254)
207: movc r5.xyz, r1.wwww, r5.wwww, r5.zzzz
208: and r7.xyz, r1.wwww, l(0.949254, 0.949254, 0.949254, 0.000000)
209: mov r6.x, l(0.835528)
210: movc r2.xw, r1.wwww, r6.xxxy, r2.xxxw
211: mov r2.xyzw, r2.xxxw
212: else
213: mov r7.xyz, l(0, 0, 0, 0)
214: mov r2.xyzw, r2.xxxw
215: mov r1.w, l(-1)
216: endif
217: not r5.w, r1.w
218: and r4.w, r4.w, r5.w
219: if_nz r4.w
220: ge r5.w, r0.w, l(0.239752)
221: ge r6.x, l(0.294564), r0.w
222: and r1.w, r5.w, r6.x
223: add r5.w, r0.w, l(-0.239752)
224: mul r6.w, r5.w, l(18.244175)
225: mov_sat r5.w, r6.w
226: mad r7.w, r5.w, l(-2.000000), l(3.000000)
227: mul r5.w, r5.w, r5.w
228: mul r5.w, r5.w, r7.w
229: mad r5.w, r5.w, l(0.015873), l(0.835528)
230: movc r5.xyz, r1.wwww, r5.wwww, r5.xyzx
231: movc r7.xyz, r1.wwww, l(0.835528, 0.835528, 0.835528, 0.000000), r7.xyzx
232: mov r6.xyz, l(0.851401, 0.851401, 0.851401, 0.000000)
233: movc r2.xyzw, r1.wwww, r6.xyzw, r2.xyzw
234: endif
235: not r5.w, r1.w
236: and r4.w, r4.w, r5.w
237: if_nz r4.w
238: ge r1.w, r0.w, l(0.294564)
239: add r0.w, r0.w, l(-0.294564)
240: mul r6.w, r0.w, l(4.917364)
241: mov_sat r0.w, r6.w
242: mad r4.w, r0.w, l(-2.000000), l(3.000000)
243: mul r0.w, r0.w, r0.w
244: mul r0.w, r0.w, r4.w
245: mad r0.w, r0.w, l(-0.851401), l(0.851401)
246: movc r5.xyz, r1.wwww, r0.wwww, r5.xyzx
247: movc r7.xyz, r1.wwww, l(0.851401, 0.851401, 0.851401, 0.000000), r7.xyzx
248: mov r6.xyz, l(0, 0, 0, 0)
249: movc r2.xyzw, r1.wwww, r6.xyzw, r2.xyzw
250: endif
251: else
252: mov r7.xyz, l(0, 0, 0, 0)
253: mov r2.xyzw, l(0.000000, 0.000000, 0.000000, 0.500000)
254: mov r1.w, l(0)
255: endif
256: mov_sat r2.w, r2.w
257: mad r0.w, r2.w, l(-2.000000), l(3.000000)
258: mul r2.w, r2.w, r2.w
259: mul r0.w, r0.w, r2.w
260: add r2.xyz, -r7.xyzx, r2.xyzx
261: mad r2.xyz, r0.wwww, r2.xyzx, r7.xyzx
262: movc r2.xyz, r1.wwww, r5.xyzx, r2.xyzx
263: mul r2.xyz, r2.xyzx, l(0.150000, 0.200000, 0.250000, 0.000000)Довольно пугающе, не так ли? Когда я увидел его впервые (это было до того, как я увидел шейдер падающих звёзд), то подумал: «Что это за ад? Этот код невозможно реверсировать!»
Но есть один аспект — если вы читали пост про падающие звёзды, то можете легко узнать этот паттерн. Код работает очень похоже на отрисовку метеоритов! Скоро мы поговорим и о кривой.
Фрагмент начинается с сэмплирования кубической карты звёзд (строка 175), где направление сэмплирования хранится в r2.xyz. Как видите, в строке line 177 есть инструкция сэмплировпния ещё одной кубической карты. В отличие от шейдера 2015 года, в шейдере «КиВ» есть ещё одна текстура «кубическая карта шума», грани которой выглядят примерно так:
Прежде чем мы доберёмся до кривой, давайте найдём входящие данные для неё. Сначала вычисляется скалярное произведение (строка 184) между нормализованным вектором нормали купола неба (строки 178-180) и вектором света Луны (строки 181-183) — по сути, это N*L.
Вот визуализация скалярного произведения (в линейном пространстве):
Значение, используемое в качестве входящих данных для функции «кривой Млечного пути», получается в строке 185:
x = saturate( noise * 0.2 + Ndot );
А вот визуализация такого искажённого N*L, тоже в линейном пространстве:
Теперь давайте перейдём к функции Млечного пути! Она чуть сложнее, чем функция падающих звёзд. Как я говорил в предыдущем посте, мы начинаем со списка контрольных точек по оси x. Взглянув на ассемблерный код, мы сразу их увидим:
// Control points (x-axis)
float controlPoint0 = 0.0;
float controlPoint1 = 0.184939;
float controlPoint2 = 0.239752;
float controlPoint3 = 0.294564;
float controlPoint4 = 0.497925; Откуда мы знаем, что первые контрольные точки равны нулю? Это довольно просто: в строке 189 нет инструкции «add».
Согласно посту о падающих звёздах, контрольные точки определяют количество сегментов, а далее нам нужно найти для них веса.
Для первого сегмента это довольно просто. Вес равен 0.949254:
194: mul r5.xyz, r2.zzzz, l(0.949254, 0.949254, 0.949254, 0.000000)
195: mov r2.x, l(0.949254) Давайте попробуем найти их для второго и третьего сегментов:
206: mad r5.w, r5.w, l(-0.113726), l(0.949254)
207: movc r5.xyz, r1.wwww, r5.wwww, r5.zzzz
208: and r7.xyz, r1.wwww, l(0.949254, 0.949254, 0.949254, 0.000000)
209: mov r6.x, l(0.835528)
...
229: mad r5.w, r5.w, l(0.015873), l(0.835528)
230: movc r5.xyz, r1.wwww, r5.wwww, r5.xyzx
231: movc r7.xyz, r1.wwww, l(0.835528, 0.835528, 0.835528, 0.000000), r7.xyzx
232: mov r6.xyz, l(0.851401, 0.851401, 0.851401, 0.000000) Именно на этом моменте я прекратил писать статью, потому что здесь что-то было не так (один из моментов, когда ты думаешь «хмм»). Посмотрите, всё не так легко, как простое умножение на один вес. Кроме того, откуда взялись значения наподобие -0.113726 и 0.015873?
Потом я понял, что эти значения просто являются разностями между максимальными возможными значениями в каждом сегменте ( 0.835528 — 0.949254 = -0.113726 и 0.851401 — 0.835528 = 0.015873)! Довольно очевидно (один из моментов, когда ты думаешь «эврика!»). Как оказалось, эти значения являются не весами, а просто координатами y точек, образующих кривую!
Это многое меняет и упрощает. Во-первых, мы можем избавиться от веса в функции, которую использовали в предыдущем посте
float getSmoothTransition(float cpLeft, float cpRight, float x)
{
return smoothstep( 0, 1, linstep(cpLeft, cpRight, x) );
} И можем записать функцию Млечного пути следующим образом:
float milkyway_curve( float x )
{
// Define a set of 2D points which form the curve
// Of course, you can use a Point2D-like struct here
// Control points (x-axis)
float controlPoint0 = 0.0;
float controlPoint1 = 0.184939;
float controlPoint2 = 0.239752;
float controlPoint3 = 0.294564;
float controlPoint4 = 0.497925;
// Values at points (y-axis)
float value0 = 0.0;
float value1 = 0.949254;
float value2 = 0.835528;
float value3 = 0.851401;
float value4 = 0.0;
float function_value = 0.0;
[branch] if (x <= controlPoint4)
{
[branch] if (x <= controlPoint1)
{
float t = getSmoothTransition(controlPoint0, controlPoint1, x);
function_value = lerp(value0, value1, t);
}
[branch] if (x >= controlPoint1 && x <= controlPoint2)
{
float t = getSmoothTransition(controlPoint1, controlPoint2, x);
function_value = lerp(value1, value2, t);
}
[branch] if (x >= controlPoint2 && x <= controlPoint3)
{
float t = getSmoothTransition(controlPoint2, controlPoint3, x);
function_value = lerp(value2, value3, t);
}
[branch] if (x >= controlPoint3)
{
float t = getSmoothTransition(controlPoint3, controlPoint4, x);
function_value = lerp(value3, value4, t);
}
}
return function_value;
} Это обобщённое решение для любого количества точек, образующих плавную кривую. Кроме того, оно объясняет происхождение «странных» значений контрольных точек — вероятно, разработчики для задания точек использовали какой-то визуальный редактор.
Разумеется, тот же принцип применим к коду падающих звёзд.
Вот график функции:
График функции Млечного пути.
Красное — значение функции,
Зелёное — координаты по x
Синее — координаты по y
Жёлтые точки — контрольные
Хорошо, но что дальше? В строке 263 мы умножаем значение из функции на синеватый цвет:
263: mul r2.xyz, r2.xyzx, l(0.150000, 0.200000, 0.250000, 0.000000) Но это ещё не конец! Нам просто нужно выполнить гамма-коррекцию:
263: mul r2.xyz, r2.xyzx, l(0.150000, 0.200000, 0.250000, 0.000000)
264: mad r2.xyz, r4.xyzx, l(3.000000, 3.000000, 3.000000, 0.000000), r2.xyzx
...
269: log r2.xyz, r2.xyzx
270: mul r2.xyz, r2.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
271: exp r2.xyz, r2.xyzx Теперь интересная штука: я назначил разные цвета контрольным точкам по оси x:
float3 gradient0 = float3(1, 0, 0);
float3 gradient1 = float3(0, 1, 0);
float3 gradient2 = float3(0, 0, 1);
float3 gradient3 = float3(1, 1, 0);
float3 gradient4 = float3(0, 1, 1); И вот что у меня получилось:
И на этом практически всё для Млечного пути сделано.
В строке 264 есть r4.xyz и…
4. Звёзды Туссента (бонус)
Я знаю, что эта часть статьи называется «Млечный путь», но не смог удержаться от того, чтобы не рассказать вкратце, как создаются звёзды Туссента. Они гораздо ярче, чем в Новиграде, на Скеллиге или в Велене.
В одном из предыдущих постов я рассказывал о звёздах 2015 года; настало время поговорить о звёздах 2016 года!
На самом деле, основная часть ассемблерного кода выглядит так:
175: sample_indexable(texturecube)(float,float,float,float) r4.xyz, r2.xyzx, t0.xyzw, s0
176: mul r4.xyz, r4.xyzx, r4.xyzx
...
264: mad r2.xyz, r4.xyzx, l(3.000000, 3.000000, 3.000000, 0.000000), r2.xyzx
...
269: log r2.xyz, r2.xyzx
270: mul r2.xyz, r2.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
271: exp r2.xyz, r2.xyzx
...
302: add r0.z, -cb0[9].w, l(1.000000)
303: mul r2.xyz, r0.zzzz, r2.xyzx
304: add r2.xyz, r2.xyzx, r2.xyzxНа HLSL это можно записать так:
float3 stars = texStars.Sample(sampler, starsDir).rgb;
stars *= stars;
float3 milkyway = milkyway_func(noisePerturbed) * float3(0.15, 0.20, 0.25);
float3 skyContribution = milkyway + 3.0 * stars;
// gamma correction
skyContribution = pow(skyContribution, 2.2);
// starsOpacity - 0.0 during the day (so stars and the Milky Way are not visible then), 1.0 during the night
float starsOpacity = 1.0 - cb0_v9.w;
skyContribution *= starsOpacity;
skyContribution *= 2;То есть сами звёзды просто умножаются на 3 (строка 264), а затем вместе с влиянием Млечного пути на 2 (строка 304) — олдскульный способ, но работает отлично!
Разумеется, позже происходит и кое-что ещё (например, мерцание звёзд при помощи целочисленного шума, и т.д.), но это уже не относится к теме статьи.
Заключение
В этой части я разобрался, как в «Ведьмаке 3: Кровь и вино» реализованы Млечный путь и звёзды.
Давайте заменим исходный шейдер кодом, который только написали. Готовый кадр выглядит вот так:
а с исходным шейдером кадр выглядит вот так:
Неплохо.
Часть 2: цветокоррекция
Один из эффектов постобработки, который можно встретить в «Ведьмаке 3» почти везде — это цветокоррекция. Её принцип заключается в использовании текстуры таблицы поиска (LUT) для преобразования одного множества цветов в другое.
Обычно процесс выглядит так: есть нейтральная (выходной цвет = входящему цвету) таблица поиска, которая редактируется в инструментах наподобие Adobe Photoshop — усиливается её контрастность/яркость/насыщенность/оттенок и т.д., то есть все модификации и изменения, которые достаточно затратны при вычислении в реальном времени. Благодаря LUT-ам эти операции можно заменить менее затратным поиском в текстуре.
Существует как минимум три известных мне цветовых таблиц LUT: трёхмерные, «длинные» двухмерные и «квадратные» двухмерные.
Нейтральная «длинная» двухмерная LUT
Нейтральная «квадратная» двухмерная LUT
Прежде чем мы перейдём к реализации цветокоррекции в «Ведьмаке 3», вот несколько полезных ссылок по этой технике:
Хорошая реализация на OpenGL с онлайн-демо
Цветокоррекция
Исследование графики Metal Gear Solid V (хорошая статья в целом, есть раздел о цветокоррекции) [перевод на Хабре]
Цветокоррекция при помощи текстур поиска (LUT)
Тема с форума gamedev.net
Статья из книги «GPU Gems 2» — цветокоррекция при помощи трёхмерных текстур
Документация UE4 о создании и использовании цветовых LUT
Давайте взглянем на пример LUT, использованной примерно в начале игры White Orchard — бОльшая часть зелёных цветов заменена на жёлтые:
В «Ведьмаке 3» используются двухмерные текстуры размером 512x512.
В общем случае ожидается, что цветокоррекция будет выполняться в пространстве LDR. Поэтому получается 2563 возможных входящих значений — больше 16 миллионов комбинаций, преобразуемых всего в 5122=262 144 значения. Чтобы покрыть весь интервал входящих значений, используется билинейное сэмплирование.
А вот скриншоты для сравнения: до и после прохода цветокоррекции.
Как видите, разница невелика, но заметна — небо имеет более оранжевый оттенок.
Что касается реализации в «Ведьмаке 3», и входящий, и выходной render targets являются полноэкранными текстурами с плавающей запятой (R11G11B10). Любопытно, что конкретно в этой сцене каналы самых ярких пикселей (рядом с Солнцем) имеют значения, превышающие 1.0f — даже почти до 2.0f!
Вот ассемблерный код пиксельного шейдера:
ps_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb3[2], immediateIndexed
dcl_sampler s0, mode_default
dcl_sampler s1, mode_default
dcl_resource_texture2d (float,float,float,float) t0
dcl_resource_texture2d (float,float,float,float) t1
dcl_input_ps linear v1.xy
dcl_output o0.xyzw
dcl_temps 5
0: max r0.xy, v1.xyxx, cb3[0].xyxx
1: min r0.xy, r0.xyxx, cb3[0].zwzz
2: sample_indexable(texture2d)(float,float,float,float) r0.xyzw, r0.xyxx, t0.xyzw, s0
3: log r1.xyz, abs(r0.xyzx)
4: mul r1.xyz, r1.xyzx, l(0.454545, 0.454545, 0.454545, 0.000000)
5: exp r1.xyz, r1.xyzx
6: mad r2.xyz, r1.xyzx, l(1.000000, 1.000000, 0.996094, 0.000000), l(0.000000, 0.000000, 0.015625, 0.000000)
7: min r2.xyz, r2.xyzx, l(1.000000, 1.000000, 1.000000, 0.000000)
8: min r2.z, r2.z, l(0.999990)
9: add r2.xy, r2.xyxx, l(0.007813, 0.007813, 0.000000, 0.000000)
10: mul r2.xyzw, r2.xyzz, l(0.996094, 0.996094, 64.000000, 8.000000)
11: max r2.xy, r2.xyxx, l(0.015625, 0.015625, 0.000000, 0.000000)
12: min r2.xy, r2.xyxx, l(0.984375, 0.984375, 0.000000, 0.000000)
13: round_ni r3.xz, r2.wwww
14: mad r2.z, -r3.x, l(8.000000), r2.z
15: round_ni r3.y, r2.z
16: mul r2.zw, r3.yyyz, l(0.000000, 0.000000, 0.125000, 0.125000)
17: mad r2.xy, r2.xyxx, l(0.125000, 0.125000, 0.000000, 0.000000), r2.zwzz
18: sample_l(texture2d)(float,float,float,float) r2.xyz, r2.xyxx, t1.xyzw, s1, l(0)
19: mul r2.w, r1.z, l(63.750000)
20: round_ni r2.w, r2.w
21: mul r1.w, r2.w, l(0.015625)
22: mad r1.z, r1.z, l(63.750000), -r2.w
23: min r1.xyw, r1.xyxw, l(1.000000, 1.000000, 0.000000, 1.000000)
24: min r1.w, r1.w, l(0.999990)
25: add r1.xy, r1.xyxx, l(0.007813, 0.007813, 0.000000, 0.000000)
26: mul r1.xy, r1.xyxx, l(0.996094, 0.996094, 0.000000, 0.000000)
27: max r1.xy, r1.xyxx, l(0.015625, 0.015625, 0.000000, 0.000000)
28: min r1.xy, r1.xyxx, l(0.984375, 0.984375, 0.000000, 0.000000)
29: mul r3.xy, r1.wwww, l(64.000000, 8.000000, 0.000000, 0.000000)
30: round_ni r4.xz, r3.yyyy
31: mad r1.w, -r4.x, l(8.000000), r3.x
32: round_ni r4.y, r1.w
33: mul r3.xy, r4.yzyy, l(0.125000, 0.125000, 0.000000, 0.000000)
34: mad r1.xy, r1.xyxx, l(0.125000, 0.125000, 0.000000, 0.000000), r3.xyxx
35: sample_l(texture2d)(float,float,float,float) r1.xyw, r1.xyxx, t1.xywz, s1, l(0)
36: add r2.xyz, -r1.xywx, r2.xyzx
37: mad r1.xyz, r1.zzzz, r2.xyzx, r1.xywx
38: log r1.xyz, abs(r1.xyzx)
39: mul r1.xyz, r1.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
40: exp r1.xyz, r1.xyzx
41: mad r1.xyz, cb3[1].zzzz, r1.xyzx, -r0.xyzx
42: mad o0.xyz, cb3[1].yyyy, r1.xyzx, r0.xyzx
43: mov o0.w, r0.w
44: ret В целом, разработчики «Ведьмака 3» не стали изобретать велосипед и использую много «надёжного» кода. Это логично, ведь это один из эффектов, в котором нужно быть чрезвычайно аккуратным с координатами текстур.
Тем не менее, требуется два запроса к LUT, это следствие использования 2D-текстуры — необходимо симулировать билинейное сэмплирование канала синего. В представленной по ссылке выше реализации на OpenGL слияние этих двух запросов зависит от дробной части канала синего.
Что мне показалось интересным, так это отсутствие в ассемблерном коде инструкций ceil (round_pi) и frac (frc). Однако в нём довольно много инструкций floor (round_ni).
Шейдер начинается с получения входящей текстуры цвета и извлечения из неё цвета в гамма-пространстве:
float3 LinearToGamma(float3 c) { return pow(c, 1.0/2.2); }
float3 GammaToLinear(float3 c) { return pow(c, 2.2); }
...
// Set range of allowed texcoords
float2 minAllowedUV = cb3_v0.xy;
float2 maxAllowedUV = cb3_v0.zw;
float2 samplingUV = clamp( Input.Texcoords, minAllowedUV, maxAllowedUV );
// Get color in *linear* space
float4 inputColorLinear = texture0.Sample( samplerPointClamp, samplingUV );
// Calculate color in *gamma* space for RGB
float3 inputColorGamma = LinearToGamma( inputColorLinear.rgb ); Допустимые координаты сэмплирования min и max берутся из cbuffer:
Этот конкретный кадр был захвачен в разрешении 1920x1080 — значения max равны: (1919/1920, 1079/1080)
Довольно легко заметить, что ассемблерный код шейдера содержит два довольно похожих блока, за которыми следует получение данных из LUT. Поэтому я создал вспомогательную функцию, которая вычисляет uv для LUT. Давайте сначала взглянем на соответствующий ассемблерный код:
7: min r2.xyz, r2.xyzx, l(1.000000, 1.000000, 1.000000, 0.000000)
8: min r2.z, r2.z, l(0.999990)
9: add r2.xy, r2.xyxx, l(0.007813, 0.007813, 0.000000, 0.000000)
10: mul r2.xyzw, r2.xyzz, l(0.996094, 0.996094, 64.000000, 8.000000)
11: max r2.xy, r2.xyxx, l(0.015625, 0.015625, 0.000000, 0.000000)
12: min r2.xy, r2.xyxx, l(0.984375, 0.984375, 0.000000, 0.000000)
13: round_ni r3.xz, r2.wwww
14: mad r2.z, -r3.x, l(8.000000), r2.z
15: round_ni r3.y, r2.z
16: mul r2.zw, r3.yyyz, l(0.000000, 0.000000, 0.125000, 0.125000)
17: mad r2.xy, r2.xyxx, l(0.125000, 0.125000, 0.000000, 0.000000), r2.zwzz
18: sample_l(texture2d)(float,float,float,float) r2.xyz, r2.xyxx, t1.xyzw, s1, l(0) Здесь r2.xyz — это входящий цвет.
Первое, что происходит — проверка того, находятся ли входящие данные в интервале [0-1]. (строка 7). Это, например, используется для пикселей с компонентами > 1.0, как у вышеупомянутых пикселей Солнца.
Далее канал синего умножается на 0.99999 (строка 8), чтобы floor(color.b) возвращала значение в интервале [0-7].
Для вычисления координат LUT шейдер первым делом преобразует каналы красного и зелёного, чтобы «втиснуть» из в верхний левый сегмент. Канал синего [0-1] разрезается на 64 фрагмента, которые соответствуют всем 64 сегментам в текстуре поиска. На основании текущего значения канала синего выбирается соответствующий сегмент и вычисляется смещение для него.
Пример
Давайте, например, выберем (0.75, 0.5, 1.0). Каналы красного и зелёного преобразуются в верхний левый сегмент, что даёт нам:
float2 rgOffset = (0.75, 0.5) / 8 = (0.09375, 0.0625)
Далее мы проверяем, в каком из 64 сегментов расположено значение синего (1.0). Разумеется, в нашем случае это последний сегмент — 64.
Смещение выражается в сегментах (rowOffset, columnOffset):
float blue_rowOffset = 7.0;
float blue_columnOffset = 7.0;
float2 blueOffset =float2(blue_rowOffset, blue_columnOffset) / 8.0 = (0.875, 0.875)
В конце мы просто суммируем смещения:
float2 finalUV = rgOffset + blueOffset;
finalUV = (0.09375, 0.0625) + (0.875, 0.875) = (0.96875, 0.9375)
Это был просто короткий пример. Теперь давайте изучим подробности реализации.
Для каналов красного и зелёного (r2.xy) в строке 9 прибавляется смещение в полпикселя (0.5 / 64). Затем мы умножаем их на 0.996094 (строка 10) и ограничиваем их (clamp) особым интервалом (строки 11-12).
Необходимость смещения в полпикселя довольно очевидна — мы хотим выполнять сэмплирование из центра пикселя. Гораздо более загадочным аспектом является коэффициент масштабирования из строки 10 — он равен 63,75/64.0. Скоро мы расскажем о нём подробнее.
В конце координаты ограничиваются интервалом [1/64 — 63/64].
Зачем нам это нужно? Я не знаю точно, но похоже, это сделано для того, чтобы билинейное сэмплирование никогда не брало сэмплы за пределами сегмента.
Вот изображение с примером в виде сегмента 6x6, демонстрирующее, как работает эта операция ограничения (clamp):
Вот сцена без применения clamp — заметьте довольно серьёзное обесцвечивание вокруг Солнца:
Для простоты сравнения покажу ещё раз результат из игры:
Вот фрагмент кода для этой части:
// * Calculate red/green offset
// half-pixel offset to always sample within centre of a pixel
const float halfOffset = 0.5 / 64.0;
const float scale = 63.75/64.0;
float2 rgOffset;
rgOffset = halfOffset + color.rg;
rgOffset *= scale;
rgOffset.xy = clamp(rgOffset.xy, float2(1.0/64.0, 1.0/64.0), float2(63.0/64.0, 63.0/64.0) );
// place within the top left slice
rgOffset.xy /= 8.0; Теперь пора найти смещение для канала синего.
Чтобы найти смещение строк канал синего делится на 8 частей, каждая из которых покрывает ровно одну строку в текстуре поиска.
// rows
bOffset.y = floor(color.b * 8); Чтобы найти смещение столбца, полученное значение нужно ещё раз разделить на 8 меньших частей, что соответствует всем 8 сегментам строки. Уравнение из шейдера довольно запутанное:
// columns
bOffset.x = floor(color.b * 64 - 8*bOffset.y ); На этом этапе стоит заметить, что:
frac(x) = x — floor(x)
Поэтому уравнение можно переписать так:
bOffset.x = floor(8 * frac(color.b * 8) ); А вот фрагмент кода для этого:
// * Calculate blue offset
float2 bOffset;
// rows
bOffset.y = floor(color.b * 8);
// columns
bOffset.x = floor(color.b * 64 - 8*bOffset.y );
// or:
// bOffset.x = floor(8 * frac(color.b * 8) );
// at this moment bOffset stores values in [0-7] range, we have to divide it by 8.0.
bOffset /= 8.0;
float2 lutPos = rgOffset + bOffset;
return lutPos; Таким образом мы получили функцию, возвращающую координаты текстуры для сэмплирования текстуры LUT. Давайте назовём эту функцию «getUV».
float2 getUV(in float3 color)
{
...
} Теперь вернёмся к основной функции шейдера. Как говорилось выше, из-за использования двухмерной LUT для симуляции билинейного сэмплирования канала синего нужны два запроса к LUT (из двух соседних друг с другом сегментов).
Рассмотрим следующий фрагмент на HLSL:
// Part 1
float scale_1 = 63.75/64.0;
float offset_1 = 1.0/64.0; // 0.015625
float3 inputColor1 = inputColorGamma;
inputColor1.b = inputColor1.b * scale_1 + offset_1;
float2 uv1 = getUV(inputColor1);
float3 color1 = texLUT.SampleLevel( sampler1, uv1, 0 ).rgb;
// Part 2
float3 inputColor2 = inputColorGamma;
inputColor2.b = floor(inputColorGamma.b * 63.75) / 64;
float2 uv2 = getUV(inputColor2);
float3 color2 = texLUT.SampleLevel( sampler1, uv2, 0 ).rgb;
// frac(x) = x - floor(x);
//float blueInterp = inputColorGamma.b*63.75 - floor(inputColorGamma.b * 63.75);
float blueInterp = frac(inputColorGamma.b * 63.75);
// Final LUT-corrected color
const float lutCorrectedMult = cb3_v1.z;
float3 finalLUT = lerp(color2, color1, blueInterp);
finalLUT = lutCorrectedMult * GammaToLinear(finalLUT);Принцип заключается в том, чтобы получать цвета из двух расположенных по соседству сегментов, а затем выполнять интерполяцию между ними — величина интерполяции зависит от дробной части входящего синего цвета.
Part 1 получает цвет из «дальнего» сегмента из-за явно заданного смещения синего ( + 1.0 / 64 );
Результат интерполяции хранится в переменной «finalLUT». Заметьте, что после этого результат снова возвращается в линейное пространство и умножается на lutCorrectedMult. В этом конкретном кадре его значение равно 1.00916. Это позволяет изменять яркость цвета LUT.
Очевидно, самой интригующей частью является «63.75» и «63.75 / 64». Я не совсем понимаю, откуда они берутся. Единственное объяснение, которое я нашёл: 63.75 / 64.0 = 510.0 / 512.0. Как говорилось выше существует ограничение (clamp) для каналов .rg, то есть при прибавлении смещения синего это по сути означает, что самые внешние строки и столбцы LUT не будут использоваться напрямую. Думаю, что цвета явным образом «втиснуты» в центр области текстуры поиска размером 510x510.
Давайте допустим, что inputColorGamma.b = 0.75 / 64.0.
Вот как это работает:
Здесь у нас есть первые четыре сегмента (1-4), которые покрывают канал синего с [0 — 4/64].
Судя по расположению пикселя, похоже, что каналы красного и зелёного примерно равны 0.75 и 0.5.
Мы дважды выполняем запрос к LUT — «Part 1» указывает на сегмент 2, а «Part 2» указывает на первый сегмент.
А интерполяция основана на дробной части цвета, которая равна 0.75.
То есть окончательный результат имеет 75% цвета из первого сегмента и 25% цвета из второго.
Мы почти закончили. Последним нужно сделать следующее:
// Calculate the final color
const float lutCorrectedInfluence = cb3_v1.y; // 0.20 in this frame
float3 finalColor = lerp(inputColorLinear.rgb, finalLUT, lutCorrectedInfluence);
return float4( finalColor, inputColorLinear.a ); Ха! В этом случае окончательный цвет состоит из 80% входящего цвета и 20% цвета LUT!
Давайте снова проведём краткое сравнение изображений: входящий цвет (то есть, по сути, с 0% цветокоррекции), окончательный кадр (20%) и полностью обработанное изображение (100% влияния цветокоррекции):
0% цветокоррекции
20% цветокоррекции (истинный шейдер)
100% цветокоррекции
Несколько LUT
В некоторых случаях «Ведьмак 3» использует несколько LUT.
Вот сцена, в которой используются два LUT:
До прохода цветокоррекции
После прохода цветокоррекции
Используемые LUT:
LUT 1 (texture1)
LUT 2 (texture2)
Давайте изучим ассемблерный фрагмент из этой версии шейдера:
18: sample_l(texture2d)(float,float,float,float) r3.xyz, r2.xyxx, t2.xyzw, s2, l(0)
19: sample_l(texture2d)(float,float,float,float) r2.xyz, r2.xyxx, t1.xyzw, s1, l(0)
...
36: sample_l(texture2d)(float,float,float,float) r4.xyz, r1.xyxx, t2.xyzw, s2, l(0)
37: sample_l(texture2d)(float,float,float,float) r1.xyw, r1.xyxx, t1.xywz, s1, l(0)
38: add r3.xyz, r3.xyzx, -r4.xyzx
39: mad r3.xyz, r1.zzzz, r3.xyzx, r4.xyzx
40: log r3.xyz, abs(r3.xyzx)
41: mul r3.xyz, r3.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
42: exp r3.xyz, r3.xyzx
43: add r2.xyz, -r1.xywx, r2.xyzx
44: mad r1.xyz, r1.zzzz, r2.xyzx, r1.xywx
45: log r1.xyz, abs(r1.xyzx)
46: mul r1.xyz, r1.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
47: exp r1.xyz, r1.xyzx
48: add r2.xyz, -r1.xyzx, r3.xyzx
49: mad r1.xyz, cb3[1].xxxx, r2.xyzx, r1.xyzx
50: mad r1.xyz, cb3[1].zzzz, r1.xyzx, -r0.xyzx
51: mad o0.xyz, cb3[1].yyyy, r1.xyzx, r0.xyzx
52: mov o0.w, r0.w
53: ret К счастью, тут всё довольно просто. В соответствии с ассемблерным кодом мы получаем:
// Part 1
// ...
float2 uv1 = getUV(inputColor1);
float3 lut2_color1 = texture2.SampleLevel( sampler2, uv1, 0 ).rgb;
float3 lut1_color1 = texture1.SampleLevel( sampler1, uv1, 0 ).rgb;
// Part 2
// ...
float2 uv2 = getUV(inputColor2);
float3 lut2_color2 = texture2.SampleLevel( sampler2, uv2, 0 ).rgb;
float3 lut1_color2 = texture1.SampleLevel( sampler1, uv2, 0 ).rgb;
float blueInterp = frac(inputColorGamma.b * 63.75);
float3 lut2_finalLUT = lerp(lut2_color2, lut2_color1, blueInterp);
lut2_finalLUT = GammaToLinear(lut2_finalLUT);
float3 lut1_finalLUT = lerp(lut1_color2, lut1_color1, blueInterp);
lut1_finalLUT = GammaToLinear(lut1_finalLUT);
const float lut_Interp = cb3_v1.x;
float3 finalLUT = lerp(lut1_finalLUT, lut2_finalLUT, lut_Interp);
const float lutCorrectedMult = cb3_v1.z;
finalLUT *= lutCorrectedMult;
// Calculate the final color
const float lutCorrectedInfluence = cb3_v1.y;
float3 finalColor = lerp(inputColorLinear.rgb, finalLUT, lutCorrectedInfluence);
return float4( finalColor, inputColorLinear.a );
} После получения двух цветов из LUT между ними выполняется интерполяция в lut_Interp. Всё остальное практически такое же, как в версии с одной LUT.
В этом случае единственной дополнительной переменной является lut_interp, сообщающая, как смешиваются две LUT.
Её значение в этом конкретном кадре примерно равно 0.96, то есть finalLUT содержит 96% цвета из LUT2 и 4% цвета из LUT1.
Однако это ещё не конец! Сцена, которую я изучал в части «Туман» использует три LUT!
Давайте взглянем!
До прохода цветокоррекции
После прохода цветокоррекции
LUT1 (texture1)
LUT2 (texture2)
LUT3 (texture3)
И снова ассемблерный фрагмент:
23: mad r2.yz, r2.yyzy, l(0.000000, 0.125000, 0.125000, 0.000000), r3.xxyx
24: sample_l(texture2d)(float,float,float,float) r3.xyz, r2.yzyy, t2.xyzw, s2, l(0)
...
34: mad r1.xy, r1.xyxx, l(0.125000, 0.125000, 0.000000, 0.000000), r1.zwzz
35: sample_l(texture2d)(float,float,float,float) r4.xyz, r1.xyxx, t2.xyzw, s2, l(0)
36: add r4.xyz, -r3.xyzx, r4.xyzx
37: mad r3.xyz, r2.xxxx, r4.xyzx, r3.xyzx
38: log r3.xyz, abs(r3.xyzx)
39: mul r3.xyz, r3.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
40: exp r3.xyz, r3.xyzx
41: sample_l(texture2d)(float,float,float,float) r4.xyz, r1.xyxx, t1.xyzw, s1, l(0)
42: sample_l(texture2d)(float,float,float,float) r1.xyz, r1.xyxx, t3.xyzw, s3, l(0)
43: sample_l(texture2d)(float,float,float,float) r5.xyz, r2.yzyy, t1.xyzw, s1, l(0)
44: sample_l(texture2d)(float,float,float,float) r2.yzw, r2.yzyy, t3.wxyz, s3, l(0)
45: add r4.xyz, r4.xyzx, -r5.xyzx
46: mad r4.xyz, r2.xxxx, r4.xyzx, r5.xyzx
47: log r4.xyz, abs(r4.xyzx)
48: mul r4.xyz, r4.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
49: exp r4.xyz, r4.xyzx
50: add r3.xyz, r3.xyzx, -r4.xyzx
51: mad r3.xyz, cb3[1].xxxx, r3.xyzx, r4.xyzx
52: mad r3.xyz, cb3[1].zzzz, r3.xyzx, -r0.xyzx
53: mad r3.xyz, cb3[1].yyyy, r3.xyzx, r0.xyzx
54: add r1.xyz, r1.xyzx, -r2.yzwy
55: mad r1.xyz, r2.xxxx, r1.xyzx, r2.yzwy
56: log r1.xyz, abs(r1.xyzx)
57: mul r1.xyz, r1.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
58: exp r1.xyz, r1.xyzx
59: mad r1.xyz, cb3[2].zzzz, r1.xyzx, -r0.xyzx
60: mad r0.xyz, cb3[2].yyyy, r1.xyzx, r0.xyzx
61: mov o0.w, r0.w
62: add r0.xyz, -r3.xyzx, r0.xyzx
63: mad o0.xyz, cb3[2].wwww, r0.xyzx, r3.xyzx
64: ret К сожалению, эта версия шейдера гораздо более запутанная, чем предыдущие две. Например, UV под названием «uv1» раньше встречались в ассемблерном коде перед «uv2» (сравните ассемблерный код шейдера всего с одной LUT). Но здесь всё не так — UV для «Part 1» вычисляются в строке 34, UV для «Part 2» — в строке 23.
Потратив гораздо больше ожидаемого времени на изучение того, что здесь происходит и недоумевая, почему Part2, похоже, поменялась местами с Part1, я написал фрагмент кода на HLSL для трёх LUT:
// Part 1
// ...
float2 uv1 = getUV(inputColor1);
float3 lut3_color1 = texture3.SampleLevel( sampler3, uv1, 0 ).rgb;
float3 lut2_color1 = texture2.SampleLevel( sampler2, uv1, 0 ).rgb;
float3 lut1_color1 = texture1.SampleLevel( sampler1, uv1, 0 ).rgb;
// Part 2
// ...
float2 uv2 = getUV(inputColor2);
float3 lut3_color2 = texture3.SampleLevel( sampler3, uv2, 0 ).rgb;
float3 lut2_color2 = texture2.SampleLevel( sampler2, uv2, 0 ).rgb;
float3 lut1_color2 = texture1.SampleLevel( sampler1, uv2, 0 ).rgb;
float blueInterp = frac(inputColorGamma.b * 63.75);
// At first compute linear color for LUT 2 [assembly lines 36-40]
float3 lut2_finalLUT = lerp(lut2_color2, lut2_color1, blueInterp);
lut2_finalLUT = GammaToLinear(lut2_finalLUT);
// Compute linear color for LUT 1 [assembly: 45-49]
float3 lut1_finalLUT = lerp(lut1_color2, lut1_color1, blueInterp);
lut1_finalLUT = GammaToLinear(lut1_finalLUT);
// Interpolate between LUT 1 and LUT 2 [assembly: 50-51]
const float lut12_Interp = cb3_v1.x;
float3 lut12_finalLUT = lerp(lut1_finalLUT, lut2_finalLUT, lut12_Interp);
// Multiply the LUT1-2 intermediate result with scale factor [assembly: 52]
const float lutCorrectedMult_LUT1_2 = cb3_v1.z;
lut12_finalLUT *= lutCorrectedMult;
// Mix LUT1-2 intermediate result with the scene color [assembly: 52-53]
const float lutCorrectedInfluence_12 = cb3_v1.y;
lut12_finalLUT = lerp(inputColorLinear.rgb, lut12_finalLUT, lutCorrectedInfluence_12);
// Compute linear color for LUT3 [assembly: 54-58]
float3 lut3_finalLUT = lerp(lut3_color2, lut3_color1, blueInterp);
lut3_finalLUT = GammaToLinear(lut3_finalLUT);
// Multiply the LUT3 intermediate result with the scale factor [assembly: 59]
const float lutCorrectedMult_LUT3 = cb3_v2.z;
lut3_finalLUT *= lutCorrectedMult_LUT3;
// Mix LUT3 intermediate result with the scene color [assembly: 59-60]
const float lutCorrectedInfluence3 = cb3_v2.y;
lut3_finalLUT = lerp(inputColorLinear.rgb, lut3_finalLUT, lutCorrectedInfluence3);
// The final mix between LUT1+2 and LUT3 influence [assembly: 62-63]
const float finalInfluence = cb3_v2.w;
float3 finalColor = lerp(lut12_finalLUT, lut3_finalLUT, finalInfluence);
return float4( finalColor, inputColorLinear.a );
} После завершения всех запросов текстур сначала интерполируются результаты LUT1 и LUT2, затем они умножаются на коэффициент масштабирования, а далее комбинируются с линейным цветом основной сцены. Давайте назовём результат lut12_finalLUT.
Затем примерно то же самое происходит для LUT3 — умножаем на ещё один коэффициент масштабирования и комбинируем с цветом основной сцены, что даёт нам lut3_finalLUT.
В конце оба промежуточных результата снова интерполируются.
Вот значения из cbuffer:
Часть 3: порталы
Если вы достаточно долго играли в «Ведьмака 3», то знаете, что Геральт — не большой любитель порталов. Давайте разберёмся, действительно ли они так страшны.
В игре есть два типа порталов:
Синий портал
Огненный портал
Я объясню, как создаётся огненный. В основном потому, что его код проще, чем у синего :)
Вот как огненный портал выглядит в игре:
Самая важная часть — это, разумеется, огонь, вращающийся по направлению к центру, но сам эффект состоит не только из видимой части. Подробнее об этом позже.
План этой части довольно стандартен: сначала геометрия, потом вершинные и пиксельные шейдеры. Будет довольно много скриншотов и видео.
С точки зрения рендеринга порталы отрисовываются в прямом проходе со включенным смешиванием — довольно распространённый в игре приём; подробнее см. в части о падающих звёздах.
Ну что, приступим.
1. Геометрия
Вот как выглядит меш портала:
Локальное пространство — вид спереди
Локальное пространство — вид сбоку
Меш напоминает рог Гавриила. Вершинный шейдер сжимает его по одной оси, вот тот же меш после сжатия в виде сбоку (в мировом пространстве):
Меш портала после вершинного шейдера (вид сбоку)
Кроме позиции у каждой вершины есть дополнительные данные: важны для нас следующие (на этом этапе я буду демонстрировать визуализации из RenderDoc, а позже расскажу о них подробнее):
Texcoords (float2):
Tangent (float3):
Color (float3):
Все эти данные будут использованы позднее, но на этом этапе у нас уже слишком много данных для файла .obj, поэтому экспорт этого меша может вызвать проблемы. Я экспортировал каждый канал как отдельный файл .csv, а затем загрузил все файлы .csv в моё приложение на C++ и сборка меша на основании этих собранных данных выполняется во время выполнения.
2. Вершинный шейдер
Вершинный шейдер не особо интересен, но давайте всё равно взглянем на соответствующий фрагмент:
vs_5_0
dcl_globalFlags refactoringAllowed
dcl_constantbuffer cb1[7], immediateIndexed
dcl_constantbuffer cb2[6], immediateIndexed
dcl_input v0.xyz
dcl_input v1.xy
dcl_input v3.xyz
dcl_input v4.xyzw
dcl_input v6.xyzw
dcl_input v7.xyzw
dcl_input v8.xyzw
dcl_output o0.xyz
dcl_output o1.xyzw
dcl_output o2.xyz
dcl_output o3.xyz
dcl_output_siv o4.xyzw, position
dcl_temps 3
0: mov o0.xy, v1.xyxx
1: mul r0.xyzw, v7.xyzw, cb1[6].yyyy
2: mad r0.xyzw, v6.xyzw, cb1[6].xxxx, r0.xyzw
3: mad r0.xyzw, v8.xyzw, cb1[6].zzzz, r0.xyzw
4: mad r0.xyzw, cb1[6].wwww, l(0.000000, 0.000000, 0.000000, 1.000000), r0.xyzw
5: mad r1.xyz, v0.xyzx, cb2[4].xyzx, cb2[5].xyzx
6: mov r1.w, l(1.000000)
7: dp4 o0.z, r1.xyzw, r0.xyzw
8: mov o1.xyzw, v4.xyzw
9: dp4 o2.x, r1.xyzw, v6.xyzw
10: dp4 o2.y, r1.xyzw, v7.xyzw
11: dp4 o2.z, r1.xyzw, v8.xyzw
12: mad r0.xyz, v3.xyzx, l(2.000000, 2.000000, 2.000000, 0.000000), l(-1.000000, -1.000000, -1.000000, 0.000000)
13: dp3 r2.x, r0.xyzx, v6.xyzx
14: dp3 r2.y, r0.xyzx, v7.xyzx
15: dp3 r2.z, r0.xyzx, v8.xyzx
16: dp3 r0.x, r2.xyzx, r2.xyzx
17: rsq r0.x, r0.x
18: mul o3.xyz, r0.xxxx, r2.xyzx Вершинный шейдер очень похож на прочие шейдеры, которые мы встречали ранее.
После краткого анализа и сравнения схемы входных данных я выяснил, что выходную struct можно записать так:
struct VS_OUTPUT
{
float3 TexcoordAndViewSpaceDepth : TEXCOORD0;
float3 Color : TEXCOORD1;
float3 WorldSpacePosition : TEXCOORD2;
float3 Tangent : TEXCOORD3;
float4 PositionH : SV_Position;
}; Я хотел продемонстрировать один аспект — как шейдер получает глубину в пространстве обзора (o0.z): это просто компонент .w переменной SV_Position.
На gamedev.net есть тема, в которой это объясняется чуть подробнее.
3. Пиксельный шейдер
Вот сцена примера непосредственно перед отрисовкой портала:
… и после отрисовки:
кроме того, в утилите просмотра текстур RenderDoc есть полезная опция оверлея «Clear Before Draw», при помощи которой мы со всей точностью можем увидеть отрисованный портал:
Первый интересный аспект заключается в том, что сам слой пламени отрисовывается только в центральной области меша.
Пиксельный шейдер состоит из 186 строк, для удобства я выложил его сюда. Как обычно, во время объяснения я буду приводить соответствующие фрагменты на ассемблере.
Также стоит заметить, что 100 из 186 строк относятся к вычислению тумана.
В начале на вход подаются 4 текстуры: огонь (t0), шум/дым (t1), цвет сцены (t6) и глубина сцены (t15):
Текстура огня
Текстура шума/дыма
Цвет сцены
Глубина сцены
Также есть отдельный буфер констант с 14 параметрами, которые управляют эффектом:
Входящие данные: позиция, tangent и texcoords — довольно понятные концепции, но давайте внимательнее приглядимся к каналу «Color». После нескольких экспериментов мне кажется, что это не цвет сам по себе, а три различные маски, которые шейдер использует, чтобы различать отдельные слои и понимать, где применять различные эффекты:
Color.r — маска теплового марева. Как понятно из названия, она используется для эффекта теплового искажения воздуха (подробнее о нём позже):
Color.g — внутренняя маска. В основном используется для эффекта огня.
Color.b — задняя маска. Используется для определения того, где находится «задняя» часть портала.
Я считаю, что в случае подобных эффектов лучше описать отдельные слои, а не анализировать ассемблерный код от начала до конца, как я делал раньше.
Итак, поехали:
3.1. Слой огня
Для начала давайте исследуем самую важную часть: слой огня. Вот видео с ним:
Основной принцип реализации такого эффекта заключается в использовании статичных texcoords из данных для каждой вершины и анимировании их при помощи переменной истекшего времени из буфера констант. Благодаря таким анимированным texcoords мы сэмплируем текстуру (в нашем случае огня) при помощи сэмплера искажения/повтора.
Интересно, что в этом конкретном эффекте сэмплируется только канал .r текстуры огня. Чтобы эффект был более правдоподобным, описанным выше способом получаются два слоя огня, которые затем комбинируются друг с другом.
Ну, давайте наконец посмотрим на код!
Начинаем мы с того, что делаем texcoords более динамичными, когда они достигают центра меша:
const float2 texcoords = Input.TextureUV;
const float uvSquash = cb4_v4.x; // 2.50
...
const float y_cutoff = 0.2;
const float y_offset = pow(texcoords.y - y_cutoff, uvSquash); А вот то же самое, но на ассемблере:
21: add r1.z, v0.y, l(-0.200000)
22: log r1.z, r1.z
23: mul r1.z, r1.z, cb4[4].x
24: exp r1.z, r1.z Затем шейдер получает texcoords для первого слоя огня и сэмплирует текстуру огня:
const float elapsedTimeSeconds = cb0_v0.x;
const float uvScaleGlobal1 = cb4_v2.x; // 1.00
const float uvScale1 = cb4_v3.x; // 0.15
...
// Sample fire1 - the first fire layer
float fire1; // r1.w
{
float2 fire1Uv;
fire1Uv.x = texcoords.x;
fire1Uv.y = uvScale1 * elapsedTimeSeconds + y_offset;
const float scaleGlobal = floor(uvScaleGlobal1); // 1.0
fire1Uv *= scaleGlobal;
fire1 = texFire.Sample(samplerLinearWrap, fire1Uv).x;
} Вот соответствующий фрагмент на ассемблере:
25: round_ni r1.w, cb4[2].x
26: mad r2.y, cb4[3].x, cb0[0].x, r1.z
27: mov r2.x, v0.x
28: mul r2.xy, r1.wwww, r2.xyxx
29: sample_indexable(texture2d)(float,float,float,float) r1.w, r2.xyxx, t0.yzwx, s0 Вот как выглядит первый слой при elapsedTimeSeconds = 50.0:
Чтобы показать, что же делает y_cutoff, продемонстрируем ту же сцену, но с y_cutoff = 0.5:
Таким образом мы получили первый слой. Далее шейдер получает второй:
const float uvScale2 = cb4_v6.x; // 0.06
const float uvScaleGlobal2 = cb4_v7.x; // 1.00
...
// Sample fire2 - the second fire layer
float fire2; // r1.z
{
float2 fire2Uv;
fire2Uv.x = texcoords.x - uvScale2 * elapsedTimeSeconds;
fire2Uv.y = uvScale2 * elapsedTimeSeconds + y_offset;
const float fire2_scale = floor(uvScaleGlobal2);
fire2Uv *= fire2_scale;
fire2 = texFire.Sample(samplerLinearWrap, fire2Uv).x;
} А вот соответствующий ассемблерный фрагмент:
144: mad r2.x, -cb0[0].x, cb4[6].x, v0.x
145: mad r2.y, cb0[0].x, cb4[6].x, r1.z
146: round_ni r1.z, cb4[7].x
147: mul r2.xy, r1.zzzz, r2.xyxx
148: sample_indexable(texture2d)(float,float,float,float) r1.z, r2.xyxx, t0.yzxw, s0 То есть, как вы видите, единственное отличие заключается в UV: теперь X тоже анимируется.
Второй слой выглядит так:
Получив два слоя внутреннего огня, мы можем их скомбинировать. Однако этот процесс чуть сложнее, чем обычное умножение, поскольку в нём участвует внутренняя маска:
const float innerMask = Input.Color.y;
const float portalInnerColorSqueeze = cb4_v8.x; // 3.00
const float portalInnerColorBoost = cb4_v9.x; // 188.00
...
// Calculate inner fire influence
float inner_influence; // r1.z
{
// innerMask and "-1.0" are used here to control where the inner part of a portal is.
inner_influence = fire1 * fire2 + innerMask;
inner_influence = saturate(inner_influence - 1.0);
// Exponentation to hide less luminous elements of inner portal
inner_influence = pow(inner_influence, portalInnerColorSqueeze);
// Boost the intensity
inner_influence *= portalInnerColorBoost;
} Вот соответствующий ассемблерный код:
149: mad r1.z, r1.w, r1.z, v1.y
150: add_sat r1.z, r1.z, l(-1.000000)
151: log r1.z, r1.z
152: mul r1.z, r1.z, cb4[8].x
153: exp r1.z, r1.z
154: mul r1.z, r1.z, cb4[9].x Получив inner_influence, которая является ни чем иным, как маской для внутреннего огня, мы можем просто умножить маску на цвет внутреннего огня:
// Calculate portal color
const float3 colorPortalInner = cb4_v5.rgb; // (1.00, 0.60, 0.21961)
...
const float3 portal_inner_final = pow(colorPortalInner, 2.2) * inner_influence; Ассемблерный код:
155: log r2.xyz, cb4[5].xyzx
156: mul r2.xyz, r2.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
157: exp r2.xyz, r2.xyzx
...
170: mad r2.xyz, r2.xyzx, r1.zzzz, r3.xyzx Вот видео, в котором демонстрируются отдельные слои внутреннего огня. Порядок: первый слой, второй слой, внутреннее влияния и окончательный внутренний цвет:
3.2. Свечение
Создав внутренний огонь, переходим ко второму слою: свечению. Вот видео, демонстрирующее сначала только внутренний огонь, потом только свечение, а затем их сумму — готовый эффект огня:
Вот как шейдер вычисляет свечение. Аналогично созданию внутреннего огня, сначала генерируется маска, которая затем умножается на цвет свечения из буфера констант.
const float portalOuterGlowAttenuation = cb4_v10.x; // 0.30
const float portalOuterColorBoost = cb4_v11.x; // 1.50
const float3 colorPortalOuterGlow = cb4_v12.rgb; // (1.00, 0.61961, 0.30196)
...
// Calculate outer portal glow
float outer_glow_influence;
{
float outer_mask = (1.0 - backMask) * innerMask;
const float perturbParam = fire1*fire1;
float outer_mask_perturb = lerp( 1.0 - portalOuterGlowAttenuation, 1.0, perturbParam );
outer_mask *= outer_mask_perturb;
outer_glow_influence = outer_mask * portalOuterColorBoost;
}
// the final glow color
const float3 portal_outer_final = pow(colorPortalOuterGlow, 2.2) * outer_glow_influence;
// and the portal color, the sum of fire and glow
float3 portal_final = portal_inner_final + portal_outer_final;Вот как выглядит outer_mask:
(1.0 — backMask) * innerMask
Свечение не имеет постоянного цвета. Чтобы оно выглядело интереснее, используется анимированный первый слой огня (в квадрате), поэтому заметны идущие к центру колебания:
Вот ассемблерный код, отвечающий за свечение:
158: add r2.w, -v1.z, l(1.000000)
159: mul r2.w, r2.w, v1.y
160: mul r1.w, r1.w, r1.w
161: add r3.x, l(1.000000), -cb4[10].x
162: add r3.y, -r3.x, l(1.000000)
163: mad r1.w, r1.w, r3.y, r3.x
164: mul r1.w, r1.w, r2.w
165: mul r1.w, r1.w, cb4[11].x
166: log r3.xyz, cb4[12].xyzx
167: mul r3.xyz, r3.xyzx, l(2.200000, 2.200000, 2.200000, 0.000000)
168: exp r3.xyz, r3.xyzx
169: mul r3.xyz, r1.wwww, r3.xyzx
170: mad r2.xyz, r2.xyzx, r1.zzzz, r3.xyzx 3.3. Марево
Когда я начал анализировать реализацию шейдера портала, мне было непонятно, почему в качестве одной из входящих текстур используется цвет сцены без портала. Я рассуждал так — «здесь мы используем смешение, поэтому достаточно возвращать пиксель с нулевым значением альфы, чтобы сохранить цвет фона».
Шейдер имеет небольшой, но красивый эффект марева (теплового искажения воздуха) — от портала исходят тепло и энергия, поэтому фон искажён.
Принцип заключается в смещении texcoords пикселя и сэмплировании текстуры цвета фона с новыми координатами — такую операцию невозможно выполнить простым смешением.
Вот видео с демонстрацией того, как это работает. Порядок: сначала полный эффект, потом марево из шейдера, а в конце я умножаю смещение на 10, чтобы усилить эффект.
Давайте посмотрим, как вычисляется смещение.
const float ViewSpaceDepth = Input.ViewSpaceDepth;
const float3 Tangent = Input.Tangent;
const float backgroundDistortionStrength = cb4_v1.x; // 0.40
// Fades smoothly from the outer edges to the back of a portal
const float heatHazeMask = Input.Color.x;
...
// The heat haze effect is view dependent thanks to tangent vectors in view space.
float2 heatHazeOffset = mul( normalize(Tangent), (float3x4)g_mtxView);
heatHazeOffset *= float2(-1, 1);
// Fade the effect as camera is further from a portal
const float heatHazeDistanceFade = backgroundDistortionStrength / ViewSpaceDepth;
heatHazeOffset *= heatHazeDistanceFade;
heatHazeOffset *= heatHazeMask;
// this is what animates the heat haze effect
heatHazeOffset *= pow(fire1, 0.2);
// Actually I don't know what's this :)
// It was 1.0 usually so I won't bother discussing this.
heatHazeOffset *= vsDepth2; Соответствующий ассемблер разбросан по коду:
11: dp3 r1.x, v3.xyzx, v3.xyzx
12: rsq r1.x, r1.x
13: mul r1.xyz, r1.xxxx, v3.xyzx
14: mul r1.yw, r1.yyyy, cb12[2].xxxy
15: mad r1.xy, cb12[1].xyxx, r1.xxxx, r1.ywyy
16: mad r1.xy, cb12[3].xyxx, r1.zzzz, r1.xyxx
17: mul r1.xy, r1.xyxx, l(-1.000000, 1.000000, 0.000000, 0.000000)
18: div r1.z, cb4[1].x, v0.z
19: mul r1.xy, r1.zzzz, r1.xyxx
20: mul r1.xy, r1.xyxx, v1.xxxx
...
33: mul r1.xy, r1.xyxx, r2.xxxx
34: mul r1.xy, r0.zzzz, r1.xyxxМы вычислили смещение, так давайте его используем!
const float2 backgroundSceneMaxUv = cb0_v2.zw; // (1.0, 1.0)
const float2 invViewportSize = cb0_v1.zw; // (1.0 / 1920.0, 1.0 / 1080.0 )
// Obtain background scene color - we need to obtain it from texture
// for distortion effect
float3 sceneColor;
{
const float2 sceneUv_0 = pixelUv + backgroundSceneMaxUv*heatHazeOffset;
const float2 sceneUv_1 = backgroundSceneMaxUv - 0.5*invViewportSize;
const float2 sceneUv = min(sceneUv_0, sceneUv_1);
sceneColor = texScene.SampleLevel(sampler6, sceneUv, 0).rgb;
} 175: mad r0.xy, cb0[2].zwzz, r1.xyxx, r0.xyxx
176: mad r1.xy, -cb0[1].zwzz, l(0.500000, 0.500000, 0.000000, 0.000000), cb0[2].zwzz
177: min r0.xy, r0.xyxx, r1.xyxx
178: sample_l(texture2d)(float,float,float,float) r1.xyz, r0.xyxx, t6.xyzw, s6, l(0) Итак, в конечном итоге мы получили sceneColor.
3.4. Цвет «цели» портала
Под цветом «цели» я подразумеваю центральную часть портала:
К сожалению, он весь чёрный. И причиной этого является туман.
Я уже рассказывал о том, как реализован туман в этой статье. В шейдере портала вычисления тумана находятся в строках [35-135] исходного ассемблерного кода.
HLSL:
struct FogResult
{
float4 paramsFog;
float4 paramsAerial;
};
...
FogResult fog;
{
const float3 CameraPosition = cb12_v0.xyz;
const float fogStart = cb12_v22.z; // near plane
fog = CalculateFog( WSPosition, CameraPosition, fogStart, false );
}
...
const float3 destination_color = fog.paramsFog.a * fog.paramsFog.rgb; И таким образом мы получаем готовую сцену:
Дело в том, что камера в кадре находится так близко к порталу, что вычисляемый destination_color равен нулю, то есть чёрный центр портала на самом деле является туманом (или, строго говоря, его отсутствием).
Так как при помощи RenderDoc мы можем инъектировать в игру шейдеры, давайте попробуем сместить камеру вручную:
const float3 CameraPosition = cb12_v0.xyz + float3(100, 100, 0); И вот результат:
Ха!
Итак, хотя в этом конкретном случае очень мало смысла использовать вычисления тумана, теоретически ничто не мешает нам использовать в качестве destination_color . например, ландшафт из другого мира (возможно, потребуется дополнительная пара texcoords, но, тем не менее, это вполне реализуемо).
Использование тумана может быть полезным в случае огромного портала, который игрок может увидеть с большого расстояния.
3.5. Смешение цвета сцены (с наложенным маревом) с «целью»
Я раздумывал, куда поместить этот раздел — в «Цвет „цели“» или «Собираем всё вместе», но решил создать новый подраздел.
Итак, на этом этапе у нас есть описанный в 3.3 sceneColor, уже содержащий эффект марева (теплового искажения), а также есть destination_color из раздела 3.4.
Они интерполируются при помощи:
178: sample_l(texture2d)(float,float,float,float) r1.xyz, r0.xyxx, t6.xyzw, s6, l(0)
179: mad r3.xyz, r4.wwww, r4.xyzx, -r1.xyzx
180: mad r0.xyw, r0.wwww, r3.xyxz, r1.xyxz Что за значение, которое их интерполирует (r0.w)?
Здесь применяется текстура шума/дыма.
Она используется для создания того, что я называю «маской цели портала».
Вот видео (сначала полный эффект, затем маска цели, затем интерполированные подвергнутый мареву цвет сцены и цвет цели):
Взгляните на этот фрагмент на HLSL:
// Determines the back part of a portal
const float backMask = Input.Color.z;
const float ViewSpaceDepth = Input.TexcoordAndViewSpaceDepth.z;
const float viewSpaceDepthScale = cb4_v0.x; // 0.50
...
// Load depth from texture
float hardwareDepth = texDepth.SampleLevel(sampler15, pixelUv, 0).x;
float linearDepth = getDepth(hardwareDepth);
// cb4_v0.x = 0.5
float vsDepthScale = saturate( (linearDepth - ViewSpaceDepth) * viewSpaceDepthScale );
float vsDepth1 = 2*vsDepthScale;
....
// Calculate 'portal destination' mask - maybe we would like see a glimpse of where a portal leads
// like landscape from another planet - the shader allows for it.
float portal_destination_mask;
{
const float region_mask = dot(backMask.xx, vsDepth1.xx);
const float2 _UVScale = float2(4.0, 1.0);
const float2 _TimeScale = float2(0.0, 0.2);
const float2 _UV = texcoords * _UVScale + elapsedTime * _TimeScale;
portal_destination_mask = texNoise.Sample(sampler0, _UV).x;
portal_destination_mask = saturate(portal_destination_mask + region_mask - 1.0);
portal_destination_mask *= portal_destination_mask; // line 143, r0.w
} Маска цели портала в целом получается так же, как огонь — при помощи анимированных координат текстуры. Для настройки местоположения эффекта используется переменная "region_mask".
Для получения region_mask используется ещё одна переменная под названием vsDepth1. Чуть подробнее я опишу её в следующем разделе. Впрочем, она имеет незначительное влияние на маску цели.
Ассемблерный код маски цели выглядит так:
137: dp2 r0.w, v1.zzzz, r0.zzzz
138: mul r2.xy, cb0[0].xxxx, l(0.000000, 0.200000, 0.000000, 0.000000)
139: mad r2.xy, v0.xyxx, l(4.000000, 1.000000, 0.000000, 0.000000), r2.xyxx
140: sample_indexable(texture2d)(float,float,float,float) r2.x, r2.xyxx, t1.xyzw, s0
141: add r0.w, r0.w, r2.x
142: add_sat r0.w, r0.w, l(-1.000000)
143: mul r0.w, r0.w, r0.w 3.6. Соединяем всё вместе
Фух, почти закончили.
Давайте сначала получим цвет портала:
// Calculate portal color
float3 portal_final;
{
const float3 portal_inner_color = pow(colorPortalInner, 2.2) * inner_influence;
const float3 portal_outer_color = pow(colorPortalOuterGlow, 2.2) * outer_glow_influence;
portal_final = portal_inner_color + portal_outer_color;
portal_final *= vsDepth1; // fade the effect to avoid harsh artifacts due to depth test
portal_final *= portalFinalColorFilter; // this was (1,1,1) - so not relevant
} Единственный аспект, который я хочу здесь обсудить — это vsDepth1.
Вот как выглядит эта маска:
В предыдущем подразделе я показал, как она получается; по сути, это «линейный буфер глубин», используемый для уменьшения цвета портала так, чтобы не было резкой границы из-за теста глубин.
Рассмотрим ещё раз готовую сцену, с умножением и без умножения на vsDepth1.
После создания portal_final получить готовый цвет просто:
const float finalPortalAmount = cb2_v0.x; // 0.99443
const float3 finalColorFilter = cb2_v2.rgb; // (1.0, 1.0, 1.0)
const float finalOpacityFilter = cb2_v2.a; // 1.0
...
// Alpha component for blending
float opacity = saturate( lerp(cb2_v0.x, 1, cb4_v13.x) );
// Calculate the final color
float3 finalColor;
{
// Mix the scene color (with heat haze effect) with the 'destination color'.
// In this particular example fog is used as destination (which is black where camera is nearby)
// but in theory there is nothing which stops us from putting here a landscape from another world.
const float3 destination_color = fog.paramsFog.a * fog.paramsFog.rgb;
finalColor = lerp( sceneColor, destination_color, portal_destination_mask );
// Add the portal color
finalColor += portal_final * finalPortalAmount;
// Final filter
finalColor *= finalColorFilter;
}
opacity *= finalOpacityFilter;
return float4(finalColor * opacity, opacity); Вот и всё. Есть ещё одна переменная finalPortalAmount, определяющая, сколько пламени видит игрок. Я не стал тестировать её подробно, но предполагаю, что она используется, когда портал появляется и исчезает — на короткий промежуток времени игрок не видит огня, зато видит всё остальное — свечение, цвет цели и т.п.
4. Подведём итог
Готовый шейдер на HLSL выложен здесь. Мне пришлось поменять местами несколько строк, чтобы получить тот же ассемблерный код, что и у оригинала, но это не мешает общему потоку выполнения. Шейдер готов к использованию с RenderDoc, все cbuffers присутствуют и т.д, поэтому вы можете его инъектировать и поэкспериментировать самостоятельно.
Надеюсь, вам понравилось, спасибо за прочтение!
