Что такое ssr в играх
SSLR: Screen Space Local Reflections в AAA-играх
Привет, друг! В этот раз я опять подниму вопрос о графике в ААА-играх. Я уже разобрал методику HDRR (не путать с HDRI) тут и чуть-чуть поговорил о коррекции цвета. Сегодня я расскажу, что такое SSLR (так же известная как SSPR, SSR): Screen Space Local Reflections. Кому интересно — под кат.
Введение в Deferred Rendering
Для начала введу такое понятие как Deferred Rendering (не путать с Deferred Shading, т.к. последнее относится к освещению). В чем суть Deferred Rendering? Дело в том, что все эффекты (такие как освещение, глобальное затенение, отражения, DOF) можно отделить от геометрии и реализовать эти эффекты как особый вид постпроцессинга. К примеру, что нужно, чтобы применить DOF (Depth Of Field, размытие на дальних расстояниях) к нашей сцене? Иметь саму сцену (Color Map) и иметь информацию о позиции текселя (другими словами на сколько пиксель далеко от камеры). Далее — все просто. Применяем Blur к Color Map, где радиус размытия будет зависеть от глубины пикселя (из Depth Map). И если взглянуть на результат — чем дальше объект, тем сильнее он будет размыт. Так что же делает методика Deferred Rendering? Она строит так называемый GBuffer, который, обычно, в себя включает три текстуры (RenderTarget):
В случае с Color map, Normal map вроде все понятно, это обычные Surface.Color текстуры: пожалуй, за исключением того, что вектор нормали может лежать в пределах [-1, 1] (используется простая упаковка вектора в формат [0, 1]).
А вот ситуация с Depth map становится непонятной. Как же Depth map хранит в себе информацию о позиции пикселя, да еще и одним числом? Если говорить сильно упрощенно, трансформация примитива:
Дает нам экранные координаты:
И некоторую информацию о том, насколько “далеко” от камеры пиксель:
Исходя из этого UV нам не нужен, т.к. при рисовании обычного квада на весь экран он и так известен. Поэтому стоит хранить в карте глубины не позицию пикселя, а только глубину.
В дальнейшем мы сможем реконструировать позицию пикселя очень простым способом:
Напомню, что для построения GBuffer необходима такая методика как MRT (Multiple Render Targets), которая рисует модель сразу в несколько Render Target (причем в каждом RT содержится разная информация). Одно из правил MRT — размерность всех Render Target должна быть одинаковой. В случае Color Map, Normal Map — Surface.Color: 32-ух битная RT, где на каждый канал ARGB приходится по 8 бит, т.е. 256 градаций от 0 до 1.
Благодаря такому подходу мы можем применять сложные эффекты к любой геометрии, например самый популярный Screen Space эффект: SSAO (Screen Space Ambient Occlusion). Этот алгоритм анализирует буферы глубины и нормали, считая уровень затенения. Весь алгоритм я описывать не буду, он уже описывался на хабре, скажу лишь то, что задача алгоритма сводится к трассировки карты глубины: у нас есть набор случайных векторов, направленных из считаемого “пикселя” и нам нужно найти кол-во пересечений с геометрией.
Пример эффекта (слева без SSAO, справа с SSAO):
Так же Deferred Shading является Screen Space эффектом. Т.е. для каждого источника света на экране (без всяких оптимизаций) мы рисуем квад в режиме Additive в так называемый RenderTarget: Light Map. И зная мировую позицию “пикселя”, его нормаль, позицию источника света — мы можем посчитать освещенность этого пикселя.
Пример Deferred Shading (освещение выполнено отложено, после отрисовки геометрии):
Достоинства и проблемы Screen Space эффектов
Самый главный плюс Screen Space эффектов — независимость сложности эффекта от геометрии.
Самый главный минус — локальность всех эффектов. Дело в том, что мы постоянно будем сталкиваться с Information Lost, во многих случаях это сильно зависит обзора, поскольку SSE зависит от смежных глубин текселей, которые могут быть сгенерированы любой геометрией.
Ну и стоит отменить, что Screen Space эффекты выполняются полностью на GPU и являются пост-процессингом.
Наконец SSLR
После всей теории мы подошли к такому эффекту, как Screen Space Local Reflections: локальные отражения в экранном пространстве.
Для начала разберемся с перспективной проекцией:
Горизонтальный и вертикальный угол зрения задается FOV (обычно 45 градусов, я предпочитаю 60 градусов), в виртуальной камере они разные т.к. учитывается еще и Aspect Ratio (соотношение сторон).
Окно проекции (там, где мы оперируем UV-space данными) — это, что мы видим, на то мы проецируем нашу сцену.
Передняя и задняя плоскости отсечения это соответственно Near Plane, Far Plane, задаются так же в проекцию как параметры. Делать в случае Deferred Rendering слишком большим значением Far Plane стоит, т.к. точность Depth Buffer сильно упадет: все зависит от сцены.
Теперь, зная матрицу проекции и позицию на окне проекции (а так же глубину) для каждого пикселя мы вычисляем его позицию следующим образом:
После нам нужно найти вектор взгляда на этот пиксель:
В качестве CameraPosition выступает позиция камеры.
И найти отражение этого вектора от нормали в текущем пикселе:
Далее задача сводится к трассировке карты глубины. Т.е. нам нужно найти пересечение отраженного вектора с какой-либо геометрией. Понятное дело, что любая трассировка производится через итерации. И мы в них сильно ограниченны. Т.к. каждая выборка из Depth Map стоит времени. В моем варианте мы берем некоторое начальное приближение L и динамически меняем его исходя из расстояния между нашим текселем и позицией, которую мы “восстановили”:
Вспомогательные функции, перевод мировой точки на экранное пространство:
После завершения итераций мы имеет позицию “пересечения с отраженной геометрией”. А наше значение nuv будет проекцией этого пересечения на экран, т.е. nuv.xy – это UV координаты в экранном нашем пространстве, а nuv.z это восстановленная глубина (т.е. abs(GetDepth(nuv.xy)-nuv.z) должен быть очень маленьким).
В конце итераций L будет показывать расстояние отраженного пикселя. Последний этап — собственно добавление отражения к Color Map:
Разбавим теорию иллюстрациями, исходное изображение (содержание Color Map из GBuffer):
После компиляции шейдера (отражения) мы получим следующую картину (Color Map из GBuffer + результат шейдера SSLR):
Не густо. И тут стоит еще раз напомнить, что Space-Screen эффекты это сплошной Information Lost (примеры выделены в красные рамки).
Дело в том, что если вектор отражения выходит за пределы Space-Screen – информация о Color-карте становится недоступной и мы видим Clamping нашего UV.
Чтобы частично исправить эту проблему, можно ввести дополнительный коэффициент, который будет отражать “дальность” отражения. И далее по этому коэффициенту мы будем затенять отражение, проблема частично решается:
Результат, отражение умноженное на error (попытка убрать артефакт SSLR — information lost):
Уже лучше, но мы замечаем еще одну проблему, что будет, если вектор отразится в направлении камеры? Clamping’а UV происходить не будет, однако, несмотря на актуальность UV (x > 0, y > 0, x
Отражение в играх. Как работают, различия и развитие технологий.
Предлагаю продолжить серию видео про настройки в играх. Напомню, что на сайте уже есть статьи про сглаживания, а также про синхронизацию кадров.
На этот раз предлагаю рассмотреть то, как делались отражения в играх. Как они делаются сейчас, и как происходила эволюция технологии, и почему существует так много кардинально различных подходов к реализации отражения.
Математика говорит, что ничего сложного в этом нет
Казалось бы — в чём может быть проблема? По сути — математика процесса отражения не такая уж и сложная.
Нужно всего то рассчитать положение камеры как бы за стеной в зеркальном месте от настоящей игровой камеры, а потом отрендерить всё с положения этой виртуальной камеры, а потом вставить полученную картинку в место где установлена зеркальная поверхность.
На деле, конечно, для такой топорной реализации нужна масса костылей. Допустим, если можно зайти за такую стену, то есть, условно есть отражающий столб, то виртуальное положение камеры будет загораживаться другими объектами, то есть нужно не переносить камеру, а пересчитывать видимую область для отражения, либо вкидывать вагон костылей, добавляя какие-то исключения видимости.
А теперь вспоминаем, что игровые движки для оптимизации отсекают невидимые объекты на этапе подготовки кадра, то есть учитывания зеркала должно быть до начала отрисовки кадра.
Естественно есть ряд прочих недостатков. Во первых — отражающих поверхностей может быть много. Допустим — каждое окно здания.
Очевидно, что если для каждого окна попытаться отрисовать свою область, то уже существенными будут затраты не только на отрисовку, но и на расчёт областей для которых потребуется отрисовка, то есть проблемы подъедут ещё раньше, чем на видеокарту рухнет основной объём работы. А если отражающая поверхность криволинейная, то разработчикам игры придётся попрощаться с евклидовой геометрией, так как работать с топорным методом отражений она перестанет.
Естественно даже один источник отражения может уменьшить FPS в два раза, так как сцен надо рендерить две. Опять же вспоминаем, что источников отражений может быть много.
На деле — задача сделать отражение совсем не так проста, как хотелось бы и как выглядит на первый взгляд.
Есть кардинально разные подходы
И методов построения отражений довольно много, я их разделяю на три группы. Одна группа методов — это построение дополнительных пространств для реализации отражений, вторая группа — преобразование имеющейся графики на экране для того чтобы использовать её в отражениях как один из фильтров постобработки. И третий метод — воспроизведение картинки такой, какой она была бы при использовании виртуальной камеры, в общем — то как я описывал в топорном методе. Но естественно есть свои ухищрения, так что в реальности эти методы были не столь прожорливы.
Перечислил я эти методы не в последовательности их появления, то есть на самом деле — изначально появились методы третьеей группы, так как это математически самые правильные методы, но применимы они могли быть только в не реалтайм графики, особенно если речь идёт про попытки сделать отражения от криволинейных поверхностей. Трассировка лучей, естественно, также относится к методам реального отображения объектов в игровой локации, но в играх этот метод появился совсем недавно.
Дополнительные камеры
А вот самый примитивный метод реальной картинки отражений — это дополнительные камеры, изображения которых вписанные в некоторые объекты.
И появились такие вещи в первую очередь в гоночных играх где необходим обзор сбоку и сзади от основного направления движения.
Тут, как вы понимаете, в экран встраивается изображение со второй камеры и естественно такой метод отбирает много производительности. Поэтому в гоночных играх может быть до половины настроек графики — это настройки качества зеркал. Просто потому что у обычного изображения и изображения для зеркал равные и одинаковые по сложности графические конвейеры, но отдельные опции отрисовки можно отключать, чтобы падение производительности было не таким сильным. Это самый топорный метод, но учитывая, что зеркало должно быть в кадре постоянно — разработчики игр приносят в жертву производительность. Правда есть игры, где игровая механика требовала применение подхода дополнительных камер и кроме гонок, например в игре Portal.
Где один портал показывает картинку с виртуальной камеры положения второго портала.
При этом в игре — за порталом не создавалось дополнительное пространство, то есть за порталом не строилась дополнительная локация, а в момент пересечения портала — игрок мордой просто упирался в интерактивную текстуру показывающую другую камеру, ракурс которой определялся относительно текущего положения игрока около портала и потом игрока телепортировало на другой портал в этой же локации.
Да в общем-то сурс генерировать уровни и не умел. Planar Reflections сейчас применяется довольно редко так как имеются другие более гибкие и менее затратные по производительности методы.
Как вы понимаете — в обычных играх сложно разобраться с производительностью, когда вы подходите к зеркалу, то есть можно оптимизировать игру под какое-то среднее железо и 90% времени всё будет нормально, но стоит только в кадре появиться зеркало, которое реализовано такой технологией, как сразу же возникнет сильная просадка по производительности.
Поэтому для игр в которых зеркало было не постоянным элементом картинки — честные методы пришли далеко не сразу.
Дополнительные пространства и виртуальные зазеркалья
И тут мы переходим к группе методов с отрисовкой дополнительных пространств.
Наиболее неожиданный метод — это дублирование локации в зазеркальном мире. То есть рядом с локацией строится её зеркальный клон, в которой перемещаются все персонажи из нормального мира.
Метод этот, понятное дело, очень костыльный и для больших открытых локаций не подходит, так как нужно было бы за каждым зеркальным объектом построить всё окружение. То есть если в городе 10 зеркал, то за ними должны скрываться видимые части 10 городов. Это накладывало бы чрезвычайно большие рамки на левелдизайн, так как отражения бы занимали слишком много места в локациях, я уже не говорю про то, что они увеличивали бы нагрузку на процессор и видеокарту.
В общем — метод этот крайне ограничен и в текущий момент в виде реальных локаций не применяется. Но теперь представьте, что у вас есть город с кучей окон, водной гладью, лужами и прочими подобными предметами.
В них должны отражаться одни и те же объекты. Ну то есть сам город. И игроделы вывернули идею дополнительной локации наизнанку. И решили, что для зазеркалья можно не делать отдельные локации внутри основной, а можно поместить основную локацию внутрь невидимой окружающей локации, созданной специально для отражений.
Что касается реализации, то по сути никакого пространства создавать и не надо, нужно текстурировать внешнее окружение, получив так называемый куб мепс, а затем накладывать эту текстуру на объекты вокруг которых этот кубмепс был получен.
Так как текстуры были получены от внешних объектов, а накладываются на внутренние — то зеркальный разворот отражений появляется естественным образом. Проблема только в том, что кубмепс для реальной игровой сцены проблематично получить в реальном времени. Для его получения нужно было бы получить отрисовку сцены с 6 сторон с прогрузкой кучи лишней геометрии, а затем её накладывать на зеркальный объект.
В общем — по мощностям это не вывозимый объём для того чтобы делать его для в играх. Поэтому кубмепсы делаются из максимально упрощённой локации, либо в принципе заранее заготавливаются для каждого зеркального объекта, то есть хранятся как обычная текстура, которая накладывается на предмет исходя из расположения игрока относительно зеркального объекта.
В целом — лично для меня накладывание этих вывернутых текстур напоминает почему-то популярную иллюзию (купить такую можно тут например) с дракон, который следит за наблюдателем.
Смотришь ты внутрь объекта, а накладывается текстуры от наружных.
Ну и естественно главный недостаток того, что это делается не с настоящим миром — это то, что в таких отражениях нельзя отразить игрока, нельзя отразить любые динамические объекты, проезжающие машины, разрушаемые объекты и т.д.. А порой игроделы вообще забивают на то, чтобы исправлять кубмапсы в процессе доработки игры и в отражении можно увидеть кубмапсы из недоделанной игры, то есть отражаются те вещи, которых в игре нет, или не отражаются даже статические объекты, которые в игре есть, но которых не было на момент разработки игры и создания кубмепса. Или пререндеренные кубмепсы смещены относительно тех мест, где они должны были быть созданы.
Комбинации методов
Ну и, конечно, тут начинаются первые комбинации методов. Зачастую отражений кубмепсами хватает для большинства задач, а не хватает их только в паре мест, в которых нужно отражение игрока. То есть в зеркалах для того чтобы в них смотреться.
Опять же для этого тоже применялись полноценные зеркальные комнаты, но дополняя кубмапс вируальным игроком — в целом можно уже получить и отражение игрока.
Естественно в таких случаях — это не отражение игрока, а отражение другого персонажа, который выглядит и дейсвует как персонаж. Отсюда берется и множество глюков зеркал в играх где применяются набор разных технологий, которые должны друг на друга накладываться.
Иногда возникают проблемы с отрисовкой игрового персонажа, иногда персонаж может подгружиться с запозданием, а иногда наоборот потусторонний игрок загружается, а окружение — нет.
Как правило игроделам приходится ещё и находить такой ракурс расположения зеркала, чтобы сделать сшивку технологий менее заметной. Ну то есть опять же есть ограничения в левел дизайне. Некоторые разработчики вообще создают отдельные локации только из-за того, что в них надо будет поместить зеркало.
Screen Space Reflections
Но есть и кардинально иной подход к созданию отражений. Дело в том, что зачастую отражается то, что уже есть в кадре.
То есть иногда надо применить немного геометрии и сделать реальное отражение в отражающих объектах взяв уже отрисованные куски кадра. Из плюсов — эта технология не требует дополнительных расчётов графики и является элементом постобработки. То есть накладываются дополнительные текстуры из уже отрисованного кадра. В чистом виде такой вид применяется редко по очень важной причине — его отражения геометрически неверны. Дело в том, что когда мы смотрим на отражения — мы видим объекты которые между нами и зеркалом с разных сторон. Естественно — Screen Space Reflections не может показать нам обратную сторону объекта.
Аналогично и с освещением. В зеркальных отражениях — тени объектов направлены под другими углами. Естественно Screen Space Reflections не может родить эти изменения в отображении. Ну и главный недостаток — как только какой-то объект скрылся из кадра или его закрыл другой объект, который ближе к камере — этот объект пропадает и на отражениях.
Что касается искажения геометрии — несмотря на то что оно сильное — его не очень видно, за исклюением случаев, когда мы играм от третьего лица и видим в отражении затылок персонажа.
Также — появление отражений трассировкой сильно расслбило разработчиков, которые делают игры уже исходя их того что они должны выглядеть нормально с DXR, а как они выглядят без него — уже никого не волнует. Например в Control выключив отражение трассировкой можно наловить очень много кринжатины.
Раньше разработчики подстраивали локации и отражающие поверхности в них под имеющиеся технологии так чтобы в уровнях было видно минимум технических дефектов. И эти ограничения очень значимые, по сути используя скрин спейс рефлекшен надо было следить за тем чтобы между отражающей поверхностью и камерой ничего не находилось, так как это корректно отразить было невозможно. И всё надо было размывать чтобы скрыть детали, иначе косяки были бы слишком заметны.
DXR off 
DXR on
Так как у технологии есть сильные недостатки — она может быть комбинирована с другими методами. Допустим на поддержку скрин спейс рефлекшен для мест, отражений, которые не подгружены могут подрисовываться куб мепсы. Проблема в том, что эти отражения отличаются по детализации, качеству и соответствию геометрии, так что нужно продумывать как будут выглядеть переходы и где они возможны. Гораздо проще состяковать скрин спейс рефлекшен с отражениями трассировкой.
В текущий момент, если в играх есть поддержка DXR отражений, то обычно отражения трассировкой работают для близких объектов, чтобы уменьшить радиус на котором работают лучи, а за дальние отражения отвечает спейс скрин рефлекшенс.
Таким образом можно избавиться от большей части проблемных мест скрин спейс рефлекшенс.
Трассировка лучей
Ну, и конечно, осталось кратко рассказать про отражения трассировкой. Я отношу этот метод к категории честных отражений, то есть в ту группу, где дополнительные камеры. Естественно общего в реализации этих технологий ничего нет. Но есть общие плюсы — отражается то что есть в игровом движке с сохранением всей геометрии и с правильной работой света и тени, в отличие от скрин спейс рефлекшенс. Имеется виду света и тени не трассировкой, а хотя бы — в рамках используемых технологий движка игры. Достоинства этого методы в том, что сохраняется одна камера, и всё изображение строится исходя из её положения. Отражения учитывают всю внешнюю геометрию. В этом кроются и недостатки — в окрестностях камеры — отключается оптимизация по отсечению объектов вне поля зрения, то есть увеличивается нагрузка на этап подготовки кадров, из-за этого для работы трассировки требуется не только мощная видеокарта, но и центральный процессор. Видео с тестами насколько игры становятся прожорливее на центральный процессор от включения трассировки на канале, кстати было уже года два назад.
Ну и, конечно, очень сильно возрастает нагрузка на видеокарту, что является главным и, по сути, единственным недостатком данной технологии. По показанным отрывкам вы можете ещё и увидеть, что видеокарты настолько недостаточно, что на построение картинки требуется копить лучи с нескольких кадров, из-за чего появляются шлейфы и размытия при резких движениях.
Но есть и огромные плюсы — нет ограничений на сложность отражений и на сложность геометрии отражающих объектов. Кроме того — рассеянные отражения, а также — увеличение размытости отражений при удалении от шершавых поверхностей выглядят как и в жизни и обеспечиваются естественным следствием применяемых алгоритмов.
Видно как при удалении от стола падает чёткость в отражении (это настоящее фото)
То есть для поверхности надо задать её шероховатость и все нужные эффекты появятся автоматически, так как они симулируются естественными алгоритмами, описывающими то как это происходит в реальности. Нет ограничений по сложности поверхностей. Подходят любые формы отражающих поверхностей, что не может работать с планар рефлекшнс.
В общем — у каждой из технологий есть ограничения и недостатки. Естественно меньше всего ограничений у самых новых технологий, но и по требуемым производительностям — они самые жрущие, так что пока им помогают менее совершенные варианты.