Отражение в играх. Как работают, различия и развитие технологий.

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

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

Математика говорит, что ничего сложного в этом нет

Казалось бы — в чём может быть проблема? По сути — математика процесса отражения не такая уж и сложная.

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

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

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

Естественно есть ряд прочих недостатков. Во первых — отражающих поверхностей может быть много. Допустим — каждое окно здания.

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

Естественно даже один источник отражения может уменьшить FPS в два раза, так как сцен надо рендерить две. Опять же вспоминаем, что источников отражений может быть много.

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

Есть кардинально разные подходы

И методов построения отражений довольно много, я их разделяю на три группы. Одна группа методов — это построение дополнительных пространств для реализации отражений, вторая группа — преобразование имеющейся графики на экране для того чтобы использовать её в отражениях как один из фильтров постобработки. И третий метод — воспроизведение картинки такой, какой она была бы при использовании виртуальной камеры, в общем — то как я описывал в топорном методе. Но естественно есть свои ухищрения, так что в реальности эти методы были не столь прожорливы.

Перечислил я эти методы не в последовательности их появления, то есть на самом деле — изначально появились методы третьеей группы, так как это математически самые правильные методы, но применимы они могли быть только в не реалтайм графики, особенно если речь идёт про попытки сделать отражения от криволинейных поверхностей. Трассировка лучей, естественно, также относится к методам реального отображения объектов в игровой локации, но в играх этот метод появился совсем недавно.

Дополнительные камеры

А вот самый примитивный метод реальной картинки отражений — это дополнительные камеры, изображения которых вписанные в некоторые объекты. 

И появились такие вещи в первую очередь в гоночных играх где необходим обзор сбоку и сзади от основного направления движения.

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

Где один портал показывает картинку с виртуальной камеры положения второго портала.

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

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

Как вы понимаете — в обычных играх сложно разобраться с производительностью, когда вы подходите к зеркалу, то есть можно оптимизировать игру под какое-то среднее железо и 90% времени всё будет нормально, но стоит только в кадре появиться зеркало, которое реализовано такой технологией, как сразу же возникнет сильная просадка по производительности.

Поэтому для игр в которых зеркало было не постоянным элементом картинки — честные методы пришли далеко не сразу.

Дополнительные пространства и виртуальные зазеркалья

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

Наиболее неожиданный метод — это дублирование локации в зазеркальном мире. То есть рядом с локацией строится её зеркальный клон, в которой перемещаются все персонажи из нормального мира.

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

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

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

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

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

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

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

Смотришь ты внутрь объекта, а накладывается текстуры от наружных.

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

Комбинации методов

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

Опять же для этого тоже применялись полноценные зеркальные комнаты, но дополняя кубмапс вируальным игроком — в целом можно уже получить и отражение игрока.

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

Иногда возникают проблемы с отрисовкой игрового персонажа, иногда персонаж может подгружиться с запозданием, а иногда наоборот потусторонний игрок загружается, а окружение — нет.

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

Screen Space Reflections

Но есть и кардинально иной подход к созданию отражений. Дело в том, что зачастую отражается то, что уже есть в кадре.

То есть иногда надо применить немного геометрии и сделать реальное отражение в отражающих объектах взяв уже отрисованные куски кадра. Из плюсов — эта технология не требует дополнительных расчётов графики и является элементом постобработки. То есть накладываются дополнительные текстуры из уже отрисованного кадра. В чистом виде такой вид применяется редко по очень важной причине — его отражения геометрически неверны. Дело в том, что когда мы смотрим на отражения — мы видим объекты которые между нами и зеркалом с разных сторон. Естественно — Screen Space Reflections не может показать нам обратную сторону объекта.

Аналогично и с освещением. В зеркальных отражениях — тени объектов направлены под другими углами. Естественно Screen Space Reflections не может родить эти изменения в отображении. Ну и главный недостаток — как только какой-то объект скрылся из кадра или его закрыл другой объект, который ближе к камере — этот объект пропадает и на отражениях.

Что касается искажения геометрии — несмотря на то что оно сильное — его не очень видно, за исклюением случаев, когда мы играм от третьего лица и видим в отражении затылок персонажа.

Также — появление отражений трассировкой сильно расслбило разработчиков, которые делают игры уже исходя их того что они должны выглядеть нормально с DXR, а как они выглядят без него — уже никого не волнует. Например в Control выключив отражение трассировкой можно наловить очень много кринжатины.

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

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

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

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

Трассировка лучей

Ну, и конечно, осталось кратко рассказать про отражения трассировкой. Я отношу этот метод к категории честных отражений, то есть в ту группу, где дополнительные камеры. Естественно общего в реализации этих технологий ничего нет. Но есть общие плюсы — отражается то что есть в игровом движке с сохранением всей геометрии и с правильной работой света и тени, в отличие от скрин спейс рефлекшенс. Имеется виду света и тени не трассировкой, а хотя бы — в рамках используемых технологий движка игры. Достоинства этого методы в том, что сохраняется одна камера, и всё изображение строится исходя из её положения. Отражения учитывают всю внешнюю геометрию. В этом кроются и недостатки — в окрестностях камеры — отключается оптимизация по отсечению объектов вне поля зрения, то есть увеличивается нагрузка на этап подготовки кадров, из-за этого для работы трассировки требуется не только мощная видеокарта, но и центральный процессор. Видео с тестами насколько игры становятся прожорливее на центральный процессор от включения трассировки на канале, кстати было уже года два назад.

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

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

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

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