shadow map 4096 что это
DirectX 11 шаг за шагом:Shadow Mapping
Содержание
Введение [ ]
Почитать теорию можно здесь (на русском) и здесь (английский). Последнюю статью рекомендую хотя бы посмотреть, так как кроме теории там представлен список разных реализаций (техник) теневых карт, что пригодится в будущем.
Реализация теневых карт [ ]
Для реализации данной техники мы должны выполнить следующие шаги:
Рендер сцены из позиции источника света в специальную текстуру глубины (в которой сохраняем расстояние от источника света, до поверхности объекта ). Данная текстура выглядит вот так:
Рендерим сцену во вторую текстуру, но уже из позиции камеры( наблюдателя ), сравнивая глубину пикселя( расстояние до источника ) со значением, записанным в текстуре глубин ( полученной в предыдущем этапе ). Если глубина пикселя больше, то пиксель затенен.
Прорисовываем финальную сцену, накладывая карту теней на объекты.
Light.h [ ]
Light.cpp [ ]
Ну а здесь у нас сцена будет рендерить в текстуру 1024 на 1024 и если их поделить, то как раз и будет 1.0.
RenderTarget.h [ ]
Данный класс будет управлять рендером в текстуру.
RenderTarget.cpp [ ]
SHADOWMAP_WIDTH и SHADOWMAP_HEIGHT указывают размер карты теней. Позже можете поэксперементировать с размером. Чем он меньше, тем меньше нагрузки, но при этом ухудшается качество. Например у меня, если выставить размер как 256х256, то будет 1500 FPS, но тень при этом будет «пикселявой». А при размере 1024х1024 у меня всего 300 FPS, но тень уже получше:).
DepthShader.h [ ]
У нас будет два класса для работы с шейдерами. Данный используется при рендере глубины в текстуру.
DepthShader.cpp [ ]
ShadowShader.h [ ]
ShadowShader.cpp [ ]
MyInput.h [ ]
В данном примере мы будем управлять камерой, поэтому нам нужен класс для управления вводом.
MyInput.cpp [ ]
main.cpp [ ]
MyRender.h [ ]
MyRender.cpp [ ]
Создаем геометри, грузим шейдеры и т.д.
Вначале мы обновляем кадр (позицию света и камеры). Затем мы производим рендер в текстуру. В итоге мы получим текстуру глубины (текстуру в которой записан не цвет, а значение глубины). После чего выводим все уже на экран.
Выводим всю геометрию в текстуру. При этом используем класс m_DepthShader для того чтобы использовать шейдеры depth.vs и depth.ps.
Снова выводим всю геометрию, но теперь на экран и используем класс m_ShadowShader (шейдеры shadow.vs и shadow.ps).
Шейдеры [ ]
depth.vs [ ]
depth.ps [ ]
Напомню, данный шейдер нужен для рендера значения глубины в текстуру, поэтому здесь нет цвета.
Learn OpenGL. Урок 5.3 — Карты теней
Тень — это отсутствие света. Если лучи от источника света не попадают на объект, так как поглощаются другим объектом, то первый объект находится в тени. Тени добавляют реализма к изображению и дают увидеть взаимное расположение объектов. Благодаря ним сцена приобретает «глубину». Сравните следующие изображения сцены с тенями и без:
Как можно заметить, тени делают намного более очевидным то, как объекты расположены друг относительно друга. Благодаря теням видно, что один из кубов висит в воздухе.
Тени сложновато реализовать, особенно потому что реалтайм алгоритм для идеальных теней ещё не придуман. Существуют несколько хороших способов для приблизительного рассчёта теней, но они все имеют свои особенности, которые надо принимать во внимание.
Один из методов — карты теней (shadow maps) — относительно простой в реализации, используется в большинстве видеоигр и даёт достойные результаты. Карты теней не так уж и трудно понять, они довольно дёшевы с точки зрения производительности и их легко улучшить до более продвинутых алгоритмов (типа теней от точечного источника света или каскадных карт теней)
Часть 2. Базовое освещение
Часть 3. Загрузка 3D-моделей
Часть 4. Продвинутые возможности OpenGL
Часть 5. Продвинутое освещение
(Примечение переводчика — в дальнейшем некоторые русские версии терминов будут дублироваться устоявшимся английским вариантом. Если вы их знаете — не будет заблуждений, не знаете — запоминайте вместе с оригинальным термином, в интернете куча хороших статей на английском и довольно мало на русском)
Карты теней
Идея, лежащая в основе карт теней, достаточно проста: мы рисуем сцену с точки зрения источника света. Всё, что мы видим, освещено, остальное — в тени. Представьте кусочек пола с большим кубом между ней и источником света. Так как источник света «видит» куб, а не кусочек пола, эта часть пола будет затенена.
На картинке выше синими линиями нарисованы поверхности, которые источник света может увидеть. Закрытые поверхности нарисованы чёрным — они будут нарисованы затенёнными. Если нарисовать линию (луч) от источника света вершине самого правого куба, то она сначала пересечёт висящий в воздухе кубик. Из-за этого левая поверхность висящего кубика освещена, в отличие от куба справа.
Мы хотим найти точку самого первого пересечения луча с поверхностью и сравнить её с остальными пересечениями. Если точка пересечения луча с поверхностью не совпадает с ближайшим пересечением, то она в тени. Повторение такой операции для тысяч различных лучей от источника будет крайне неэффективным и не подойдёт для рисования в каждом кадре игры.
Возможно Вы уже читали про тест глубины: перевод на хабре, оригинал. Значение в буфере глубины- это глубина фрагмента из точки зрения камеры, ограниченная значениями от 0 до 1. Что если мы отрендерим сцену с точки зрения источника света и сохраним значения глубины в текстуру? Таким образом мы получим наименьшие значения глубины, которые видно с точки зрения источника света. Кроме того, значения глубины показывают поверхности, ближайщие для источника света. Такую текстуру называют картой глубины (depth map) или картой теней (shadow map).
На левой картинке показан направленый источник света (все лучи параллельны), отбрасывающий тень на поверхность ниже куба. С помощью значений глубины, сохранённых в текстуру, мы находим ближайшую к источнику поверхность и с её помощью определяем, что находится в тени. Мы создаём карту глубины с помощью рендеринга сцены, в качестве матриц вида и проекции используя матрицы, соответствующие нашему источнику света.
Направленный свет с параллельными лучами не имеет позиции и находится как бы «бесконечно далеко». Тем не менее, ради создания карты теней нам придётся рисовать сцену из позиции на линии направления света.
Рисование теней состоит из двух проходов: сначала рисуем карту глубины, во втором проходе рисуем мир как обычно, с помощью карты глубины определяя, какие фрагменты поверхности находятся в тени. Это может показаться сложным, но когда мы пройдём всё шаг за шагом, всё станет понятным.
Карта глубины
В первом проходе мы сгенерируем карту глубины. Карта глубины — это текстура со значениями глубины, отрендеренная с точки зрения источника света. Мы потом будем использовать её для вычисления теней. Чтобы сохранить отрендеренный результат в текстуру, нам понадобится кадровый буфер (framebuffer): перевод на хабре, оригинал.
Сначала создадим кадровый буфер для рисования карты глубины:
После создадим 2д текстуру, чтобы использовать её качестве буфера глубины для кадрового буфера.
Теперь присоединим текстуру глубины к кадровому буферу в качестве буфера глубины
Теперь у нас есть правильно настроенный кадровый буфер, которые записывает значения глубины в текстуру, и мы можем рендерить карту глубины. Полная реализация для обоих проходов рендеринга выглядит примерно так:
Этот код не содержит некоторых подробностей, но он даёт общую идею карт теней. Обратитке внимание на вызовы glViewport : обычно размер карты глубины отличается от размера экрана (или текстуры, в которую рендерится итоговое изображение). Если вы забудете его поменять, то текстуре глубины будет обновлён только квадратный кусочек с размером экрана или (если текстура меньше) часть информации на ней не будет отображена (останется за краями).
Пространство источника света
Мы моделируем направленный источник света, поэтому все лучи света параллельны. По этой причине мы будет использовать ортографическую матрицу проекции для источника света (в ней нет переспектиных искажений).
Это пример матрицы ортографической проекции, используемый в демо к этой статье. Так как матрица проекции определяет расстояние, на котором вы будете видеть объекты (т.е., их не будет отсекать видеокарта как слишком близкие или далёкие), стоит убедиться, что размер области отсечения содержит все объекты, которые Вы хотите отобразить в карте глубины.
(Прим. пер. — первый вектор — расположение камеры, второй — куда она смотрит, третий — направление взгляда вверх)
Комбинация этих двух матриц даёт нам матрицу преобразования из координат мира в координаты, в которых источник света «видит» мир. Это именно то, что нужно нам для рендеринга карты глубины.
Рендеринг в карту глубины
Когда мы рендерим сцену для источника света, нам нужны только координаты вершин и ничего больше. Для такого простого шейдера (назовём его simpleDepthShader ) напишем вершинный шейдер:
Пустой фрагментный шейдер ничего не даелает, и в конце работы шейдера мы получим обновлённый буфер глубины. Мы можем раскомментировать эту линию кода, реально глубина будет вычислена в любом случае.
Рисование в буфер глубины превращается в следующий код:
Функция RenderScene принимает шейдер, вызывает необходимые для рисования функции и утснавливает матрицы модели при необходимости.
В результате у нас заполненный буфер глубины, для каждого пикселя содержащий глубину ближайщего фрагмента с точки зрения света. Можно спроецировать эту текстуру на прямоугольник размером с экран и показать её. (схоже с тем, что было в постобработке в примере c кадровым буфером. перевод на хабре, оригинал.)
Для рисования карты глубины на прямоугольнике используется такой шейдер:
Если при рендеринге тени матрица проекции будет перспективной, а не ортогональной, то глубина будет изменяться нелинейно. В конце статьи мы обсудим это отличие.
Исходный код рендеринга сцены в карту глубины можно увидеть здесь.
Рисование теней
С помощью правильно сделанной карты глубины мы сможем рисовать тени. Мы проверяем, находится ли фрагмент в тени с фрагментном шейдере, но преобразование в пространство источника света делаем в вершинном шейдере.
Это по большей части копия шейдера, который мы использовали в примере с освещением: перевод на хабре, advanced lighting.
Получаем позицию фрагмента в пространстве источника света.
При использовании ортографической проекции координата w=1.0 не изменяется и деление на w становится не нужным. Но деление необходимо при использовании перспективной проекции, и наш код будет корректно работать для обоих случаев.
(Прим. пер. — деление на w необходимо делать именно в фрагментном шейдере. Вот в этой статье на первой картинке показана разница между линейной и перспективной интерполяцией для текстурных координат.)
Текстурные координаты лежат в интервале [0,1], а координаты видимых фрагментов при рендеринге принимают значения в [-1,1]. Приведём их к интервалу [0,1]:
По этим координатам мы можем посмотреть значение глубины в текстуре — это будет глубина ближайщего к источнику света объекта.
Чтобы получить глубину текущего фрагмента, мы просто берём его координату z в пространстве источника света.
После этого простым сравнением currentDepth и closestDepth можно определить, является ли наш фрагмент ближайщим или лежит в тени.
Весь код функции ShadowCalculation получается таким:
Использование этого шейдера вместе с текстурами и обычными матрицами вида и проекции для второго прохода рендера даст результат примерно как на картинке:
Если Вы сделали всё правильно, вы увидите тени на полу и кубиках (впрочем, с некоторыми артефактами). Исходный код демо.
Улучшаем карты теней
Мы смогли добиться работы для карт теней, но Вы можете видеть некоторые артефакты на изображении. Дальнейший текст посвящён их исправлению.
Муаровый узор
Очевидно, в изображении ниже что-то неправильно. Увеличенная картинка напоминает муаровый узор.
Весь пол покрыт явно заметными чередующимися чёрными полосками. Этот эффект может быть объяснён с помощью одной каринки:
(Прим. пер. — для описания эффекта автор использует термин «shadow acne«. Я не нашёл устоявшегося перевода. Я мог бы перевести это как «теневые точки», но в русскоязычном интернете по этому термину всё равно ничего не найти)
Так как у карты теней ограниченное разрешение (в примере выше мы использовали текстуру 1024*1024 ), несколько пикслей на итоговом изоражении могут получить одно и то же значение из карты глубины. На картинке выше показан пол, на котором каждый наклонный кусочек (снизу слева вверх на право) представляет собой один тексель из карты глубины. (тексель — текстурный пиксель)
В общем-то это нормально, но может стать проблемой, если свет падает под углом к поверхности, как на примере выше. Некоторые фрагменты, получающие глубину из текстуры, получают значение больше или меньше, что не соответствуюет реальной глубине пола для этого фрагмента. Из-за этого часть фрагментов считаются затенёнными — и мы видим полосочки.
Мы можем решить это проблему с помощью маленького хака — сдвиг значений глубины на маленькую величину (shadow bias), чтобы все фрагменты были над поверхностью.
(Прим. пер. — у меня сильное чувство, что картинки нарисованы некорректно. Чтобы фрагмент не был затенён, зигзагообразные линии, описывающие значения из карты глубины, должны быть ниже поверхности)
Сдвиг на 0.005 для нашей сцены в целом решает проблему, но некоторые поверхности, на которые свет падает под очень маленьким углом, всё ещё будут иметь полосочки тени. Более серьёзным подходом будет изменение сдвига в зависимости от угла, под которым свет падает на поверхность. Воспользуемся скалярным произведением.
Таким образом, поверхности типа пола, которые почти перпендикулярны лучам света, будут иметь очень маленький сдвиг. Чем больше угол между нормалью и направлением света, тем больше будет сдвиг. На следующей картинке показана та же сцена, но уже с использованием сдвига: она выглядит явно лучше.
Выбор корректных значений для сдвига требует их подбора, так как они могут отличаться для каждой сцены, но обычно это делается простым увеличение сдвига до тех пор, пока не пропадут артефакты.
Эффект Питера Пэна
Недостаток использования сдвига для глубины в том, что мы применяем его к реальной глубине объекта. В результате этот сдвиг может стать достаточно большим, чтобы появилось заметное расстояние между объектом и тенью, которую он отбрасывает, как на картинке ниже (с преувеличенно большим смещением):
Это называется эффектом Питера Пэна, так как тень немного убегает от своего объекта. Мы можем использовать маленькую уловку для решения большей части проблем: использовать отсечение фронтально ориентированных полигонов при рисовании карты глубины. Прочитать про отсчение граней на хабре, оригинал.
По-умолчанию openGL отсекает обратно ориентированные полигоны. Мы можем переключить openGL, чтобы сделать наоборот.
В первом проходе рендеринга нам нужны только значения глубины, и нам не важно, какую глубину взять — от фронтальной поверхности или от обратной. Мы не заметим неправильных результатов, так как нам не важно, есть ли тени внутри объекта — их всё равно не видно.
Это решает проблему с эффектом Питера Пена, но только для объектов, которые имеют поверхность со всех сторон. В нашем примере это превосходно работает для кубиков, но не будет работать для пола, так как отсечение фронтальных полигонов полностью уберёт пол. Если вы собираетесь использовать этот способ, используйте отсечение фронмально ориентированных полигонов только там, где это имеет смысл.
(Прим. пер.- конкретно в этом примере нет ничего страшного в том, что отсечение полностью уберёт пол, так как ниже него нет объектов, и не важно, есть под ним тень или нет.)
Если объекты расположены слишком близко к затеняемой поверхности, то результат может выглядеть неправильным. Используйте отсечение фронтальных граней только для объектов, для которых это имеет смысл. Впрочем, с помощью хорошо выбранных значений для сдвига можно полностью избежать эффекта Питера Пена.
Ещё один видимый недостаток, который вам может нравиться или нет — некоторые поверхности за пределами области видимости источника света могут рисоваться затенёнными, даже если на них теоретически должен падать свет. Это происходит из-за того, что для удалённой точки в системе отсчёта источника света координаты будут больше, чем 1.0, а текстурные координаты меняются только от 0.0 до 1.0. Если поверхность находится слишком в стороне от источника света, то в карте глубины нет значения для неё.
Хотелось бы для таких фрагментов возвращать глубину 1.0 — это значит, что они никогда не будут в тени (так как у видимого объекта глубина не может быть больше единицы). Для этого мы установим цвет края для текстуры и остановим опцию «GL_CLAMP_TO_BORDER»
Теперь, если мы читаем значение из карты глубины по координатам вне интервала [0,1], мы будем получать в ответ глубину 1.0, из за чего значение shadow в шейдере будет 0.0. Теперь сцена выглядит лучше:
Похоже, часть картинки всё ещё находится в тёмной области. Это поверхность, которая находится дальше дальней области отсечения для источника света. Вы можете видеть, что эта тёмная область всегда возникает далеко от источника освещения.
Для таких областей координата z в пространстве источника света оказывается больше, чем 1.0, в этом случае опция GL_CLAMP_TO_BORDER нам не помогает. Мы сравниваем реальную глубину (которая больше 1.0) со значением из карты глубин (в текстуре глубины хранятся значения не больше 1.0) — поэтому далёкие участки будут в тени.
Исправление этого эффекта относительно простое — мы будем считать незатенёнными все объекты, для которых z координата больше единицы.
Проверка для дальней плоскости отсечения в сочетании с возвращеним глубины 1.0 для значений за границами текстуры дают нам желаемый результат.
В результате всё это значит, что мы рисуем тени только там, где координаты в пространстве источника света помещаются в пределах текстуры глубины, в остальных местах теней не будет. Обычно в играх такое случается только вдали от камеры, и этот эффект выглядит намного лучше, чем тёмные области.
Percentage-closer filtering
Прямо сейчас тени выглядят хорошим дополнением к сцене, но это всё ещё не то, чего мы хотим. Если увеличить кусочек изображения с тенью, становится очевидной зависимость теней от размера текстуры глубины.
Текстура глубины имеет фиксированный размер, и довольно часто несколько пикселей на итоговой картинке используют значение глубины из одного и того же текселя текстуры. В итоге получаются зазубренные края тени.
Вы можете уменьшить размер этих квадратиков, если увеличите размер текстуры с тенями и подберёте положение источника света.
Ещё одно (частичное) решение проблемы с зазубренными краями теней — PCF (Percentage-closer filtering), содержащий различные функции фильтрации, которые дают нам мягкие тени. Идея состоит в том, чтобы выбирать несколько значений из карты глубины — каждое с немного отличающимися координатами. Для каждого значения мы проверяем, находимся в тени или нет. Потом усредняем все результаты и получаем красивые мягие тени.
Простая реализация PCF — просто выбрать соседние тексели в карте глубины и усреднить результат:
Издалека тени выглядят намного лучше. У них нет резких краёв, но если приблизиться, то всё ещё видно артефакты (впрочем, 9 оттенков тени разнообразнее одного). В целом, PCF даёт хороший результат в большинстве случаев.
На самом деле, существует намного больше способов реализовать PCF, и некоторые методы могут значительно улучшить мягкие тени. Но эта статья и так уже большая, так что обсудим это позже.
Перспективная проекция vs ортографическая
Есть различия в рендеринге карты глубины с помощью матриц ортографической или перспективной проекции. Ортографическая проекция не вносит перспективных искажений в сцену, все лучики света двигаются параллельно, что хорошо для направленного освещения. У перспективной проекции всё иначе. На картинках ниже показаны затенённые области с помощью этих двух способов.
Для перспективной проекции позиция источника света реально важна (в отличие от источника направленного освещения). Перспективную проекцию чаще всего используют для точечных источников света, а ортографическую — для направленного света.
Ещё одно небольшое отличие перспективной проекции — визуализация буфера глубины часто будет давать полностью белый результат. Это происходит потому, что перспективная проеция преобразует глубину нелинейно, и большая часть значений оказываются около ближней плоскости отсечения. Чтобы можно было хорошо видеть значения глубины, как для ортографической проекции, можно преобразовать нелинейные значения глубины обратно в линейные. Это обсуждалось в статье про буфер глубины: хабр, оригинал.
Этот код показывает значения глубины, схожие с тем, что мы видели при ортографической проекции. Обратите внимание, что это нужно только для отладки. Нелинейное преобразование монотонно и сравнение двух значений глубины будет давать одинаковые результаты независимо от того, являются они линейными или нелинейными.
Обман игроков, или как устроены отражения в играх.
ПРЕДИСЛОВИЕ
Довольно часто разработчики игр пытаются сделать отражения в своих играх как можно более правдоподобными, но знаете ли вы, что с отражениями в реальной жизни они не имеют ничего общего. Практически всегда это обман. Создать эффект отблеска зеркал, переотражения на воде, преломление света от осколков стекла помогают многочисленные ухищрения и упрощения создателей игр. Сегодня нескольких таких методах мы и поговорим.
МЕТОДЫ
1. Рендер сцены с нескольких ракурсов. (planar reflections)
Это пожалуй самый распространённый метод создания зеркальных поверхностей в играх. Сцена (видимая игроком часть локации) рендерится (рендер — отрисовка кадра, либо сцены) с нескольких точек, далее уже накладывается на слой, которому нужно создать эффект отражения. Этот процесс добавляет много «гемороя», так как рендер сцены «съедает» очень много ресурсов компьютера, соответственно разработчикам игр требуется дополнительное время на оптимизацию. Довольно часто о таком методе вспоминают только под конец создания проекта, поскольку приоритет стоит у более важных аспектах игры (Например проработка персонажей, создание ландшафта и проработка мира). Пример на скриншотах внизу.
2.Полностью созданная зеркальная комната.
Это был очень популярный способ до начала 2000-х годов. Использовался метод в 99% случаев только для создания зеркал. Он ещё более ресурсозатратен, чем первый способ, зато очень простой в создании. Для начала создаются две абсолютно одинаковых комнаты, выставляется всё те же объекты, те же источники света, вообщем обе комнаты просто дублируются. Самое главное то, что вместо зеркала было просто отверстие в другую комнату, а другая комната просто отражалась по горизонтали. Естественно и сам персонаж в комнате-зеркале spawnился(создавался) и отрисовывался заново. По причинам всё большего нарастания количества объектов в локациях данный метод на сегодняшний день мало кем используется. Пример на скриншотах внизу.
3. Screen-space reflections (упрощённая трассировка лучей).
SSR (Screen-space reflections) появилась задолго технологии RTX от Nvidia, но в целом использует похожий принцип. Однако, в отличие от технологии Nvidia, такой метод задействует трассировку только для тех объектов, которые находятся в поле зрения игрока, остальные же объекты не просчитиваются для экономии ресурсов ПК. Это логично, так как технология впервые появилась в 2011 году, и представила её компания Crytek в своей Crysis 2, а после и в Crysis 3, в то время мощность видеокарты просто не позволяла разработчикам рендерить лишнее. Сейчас же такая технология присутствует во всех современных «движках» («движок» — ПО для создания игры) таких как Unreal Engine 4, Unity, CryEngine и других. Пример на скриншотах внизу.
4. Qube maps (кубическая карта).
Способ очень популярный, хотя не без своих изъянов, таких например как отсутствие игрока в отражении, поскольку кубическая карта «prerender» объект («prerender» объект — объект, отрисованый до присутствия персонажа в локации) а также большая степень размытия, из за чего qube maps нельзя использовать для зеркал. Кубическая карта состоит из шести граней куба, у которого на каждую грань «накладывается» своя текстура. Каждую текстуру можно увидеть только по отдельности, смотря в одно из шести направлений. Определяется такая текстура в зависимости от того, куда смотрит центральная точка на экране игрока. Метод используется как в настоящее время, так и в недалёком прошлом, так как не требует большого количества ресурсов ПК. Саму технологию представила Nvidia в 1999 году вместе со своей видеокартой GeForce 256. Примеры на скриншотах.
5. RTX (Ray Tracing). Трассировка лучей от Nvidia.
Многие считают, что RTX просчитывает тени, источники света и отражения также, как и в реальной жизни, но это не так. Ray Tracing это тоже лишь имитация, но основанная на природных и физических явлениях. Вообще в целом RTX — это целый набор различных технологий, таких например как: создание динамических теней; реалистичных отражений; реалистичных источников света, а также степень их преломления от объектов (перечислена лишь малая часть, на деле их гораздо больше). Благодаря тому, что в видеокартах серии RTX имеются RT ядра и достигается высокая производительность и приемлемый FPS, так как нагрузка на просчёт отражений ложится на них, а не на видеоядро. На самом деле, такой метод может работать и на видеокартах линейки GTX (пример: GTX 1080, 1070), но производительность будет очень низкой. Немного о том, как работает сама технология: это метод комбинированной отрисовки кадра, где отлеживается траектория лучей света во всех точках пространства. Он даёт возможность определить степень освещённости, степень отражения и преломления объектов. Даже сейчас, в 2020 году использовать «на полную» RTX не получается, так как мощности нынешних видеокарт всё ещё не хватает, но будем надеяться на лучшее. Примеры RTX на скриншотах внизу.
6. iRAY. Трассировка лучей на GTX видеокартах.
iRAY на самом деле редко используется непосредственно в играх, зато очень часто использовалась (пока на замену не пришёл RTX) в создании 3D моделей для этих самых игр. О том как работает «Nvidia iRAY» достаточно мало информации, но принцип схож с трассировкой лучей на видеокартах 2000 серии, хотя и с большим количеством упрощений и послаблений (так как до недавнего времени работала только на GTX видеокартах, поддержку RTX добавили в прошлом году). Примеры на скриншотах ниже (с помощью него созданы источники света, отражения на полу на первом скриншоте и в окнах на втором скриншоте).
7.Global illumination и shadow map (глобальное освещение и карты теней).
8. Дополнительная камера.
Этот способ довольно редко используется в играх, так как требует очень много ресурсов и в целом он очень похож на способ #1, однако он очень прост в реализации, поэтому его используют в основном неопытные разработчики. Суть в том, что помимо камеры игрока (через неё вы видите всё, что происходит на экране) создаётся ещё одна с таким ракурсом, чтобы кадр для последующего отражения получился естественным. Далее на полученный кадр накладываются эффекты (самый частый из них это размытие) и для экономии ресурсов понижается разрешение (но даже с пониженным разрешением ресурсов требуется слишком много). Кроме высокого потребления ресурсов ПК, ещё одним недостатком является статичность кадра, то есть где бы ваш персонаж не встал, отражение не перестроится (хотя через «множество костылей» это можно реализовать, но это очень глупо, поскольку есть способы лучше, тот же SSR). Примеры на скриншотах внизу.
КОНЦОВКА
Сегодня вы узнали для себя чуть больше об отражениях в играх, надеюсь вы не жалеете о потраченном времени на прочтение, я же в свою очередь за уделённое мне время вас благодарю. (Можете также посмотреть новый блог о самых популярных игровых условностях у меня в профиле, мне будет приятно если именно вы его прочитаете)
ССЫЛКИ НА ВСЕ ИСТОЧНИКИ