Физическое затенение - окружающее / непрямое освещение

Я реализовал физически основанный трассировщик пути после изучения PBRT М. Фарром и Дж. Хамфрисом. Сейчас я пытаюсь применить физически основанный рендеринг к графике в реальном времени, используя OpenGL ES (в приложении для iPhone).

Я хочу начать использовать Oren-Nayar и Cook-Torrance в качестве рассеянного и зеркального BRDF, но у меня есть проблема: как мне моделировать непрямое освещение?

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

Как мне моделировать непрямое освещение в физическом рендере, написанном в OpenGL ES, используя компьютерную графику в реальном времени?

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

Окружающее освещение

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

Общие расширения основного освещения включают в себя:

• Сделайте так, чтобы окружающий цвет изменялся по направлению, например, используя сферические гармоники (SH) или маленькую кубическую карту , и ищите цвет в шейдере, основываясь на нормальном векторе каждой вершины или пикселя. Это позволяет визуально различать поверхности разной ориентации, даже если прямой свет не достигает их.
• Подать заявление методы ambient occlusion (AO) , включая предварительно вычисленные AO вершин, карты текстур AO, поля AO и AO на экранном пространстве (SSAO) . Все они работают, пытаясь обнаружить такие области, как дыры и щели, в которые непрямой свет попадает непрямой свет, и затемняя окружающий свет.
• Добавьте кубическую карту среды, чтобы обеспечить зеркальное отражение от окружающей среды. Кубическая карта с приличным разрешением (128 ² или 256 ² на лицо) может быть достаточно убедительной для зеркального отражения на изогнутых блестящих поверхностях.

Запеченное косвенное освещение

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

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

Результаты могут быть сохранены в текстурах ( световых картах ), примененных к статической геометрии на уровне, и / или они также могут быть преобразованы в SH и сохранены в объемных структурах данных, таких как объемы освещения (объемные текстуры, где каждый тексель хранит зонд SH) или четырехгранные сетки . Затем вы можете использовать шейдеры, чтобы искать и интерполировать цвета из этой структуры данных и применять их к вашей визуализированной геометрии. Объемный подход позволяет применять запеченное освещение к динамическим объектам, а также к статической геометрии.

Пространственное разрешение световых карт и т. Д. Будет ограничено памятью и другими практическими ограничениями, поэтому вы можете дополнить запеченное освещение некоторыми методами AO, чтобы добавить высокочастотные детали, которые не может обеспечить запеченное освещение, и реагировать на динамические объекты (например, затемнение непрямого света под движущимся персонажем или транспортным средством).

Существует также технология, называемая предсчитанной передачей излучения (PRT) , которая расширяет выпечку для обработки в более динамичных условиях освещения. В PRT вместо запекания самого непрямого освещения вы запекаете функцию передачи от некоторого источника света - обычно неба - к результирующему непрямому освещению в сцене. Передаточная функция представлена ​​в виде матрицы, которая преобразовывает коэффициенты SH от источника к месту назначения в каждой точке выборки. Это позволяет изменять среду освещения, и непрямое освещение в сцене будет правдоподобно реагировать. Far Cry 3 и 4 использовали эту технику, чтобы обеспечить непрерывный цикл день-ночь с непрямым освещением, меняющимся в зависимости от цвета неба в любое время суток.

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

Методы в реальном времени

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

• Динамическая среда кубической карты, в которой грани кубической карты повторно визуализируются в каждом кадре с использованием шести камер, сгруппированных вокруг выбранной точки, могут обеспечить прилично хорошее окружающее отражение для одного объекта. Например, это часто используется для автомобиля игрока в гоночных играх.
• Экран-пространство глобального освещения , расширение SSAO, которое собирает отраженное освещение от соседних пикселей на экране в процессе постобработки.
• Отражение с трассировкой лучей в пространстве экрана осуществляется путем прохождения луча через буфер глубины в последующем проходе. Он может обеспечить довольно высокое качество отражений, если отраженные объекты находятся на экране.
• Мгновенное излучение работает путем отслеживания лучей в сцене с использованием центрального процессора и размещения точечного источника света в каждой точке попадания луча, который приблизительно представляет исходящий отраженный свет во всех направлениях от этого луча. Эти многочисленные источники света, известные как виртуальные точечные источники света (VPL), затем обрабатываются графическим процессором обычным способом.
• Отражающие карты теней (RSM) аналогичны мгновенному излучению, но VPL генерируются путем рендеринга сцены с точки зрения источника света (например, карты теней) и размещения VPL в каждом пикселе этой карты.
• Объемы распространения света состоят из трехмерных сеток зондов SH, размещенных по всей сцене. RSM визуализируются и используются для «ввода» отраженного света в зонды SH, ближайшие к отражающим поверхностям. Затем процесс, подобный заливке, распространяет свет от каждого зонда SH на окружающие точки в сетке, и результат этого используется для применения освещения к сцене. Этот метод был распространен и на объемное рассеяние света .
• Трассировка воксельных конусов работает путем вокселизации геометрии сцены (вероятно, с использованием разных разрешений вокселей, более тонких вблизи камеры и более грубых вдали), а затем впрыскивая свет от RSM в сетку вокселей. При рендеринге основной сцены пиксельный шейдер выполняет «трассировку конуса» - марш лучей с постепенно увеличивающимся радиусом - через сетку вокселей, чтобы собирать входящий свет для рассеянного или зеркального затенения.

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

Как вы можете видеть, непрямое освещение в режиме реального времени - огромная тема, и даже этот (довольно длинный!) Ответ может дать только 10 000-футовый обзор и контекст для дальнейшего чтения. Какой подход лучше для вас, во многом будет зависеть от деталей вашего конкретного приложения, какие ограничения вы готовы принять и сколько времени вы должны вложить в него.

Это основная «трудная» проблема, остающаяся в компьютерной графике в реальном времени, и в настоящее время ведутся многочисленные исследования по ее решению.

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

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

Сферические гармоники часто используются в игровых движках для представления непрямого света. По сути, они представляют собой преобразование Фурье по всей поверхности сферы, отбрасывая высокочастотные компоненты, которые вы можете получить визуально приятным, в основном точным освещением окружающей среды, используя только 9 коэффициентов на цвет. Например, Unity использует SH для выпечки «световых зондов» в различных точках сцены, затем движущиеся объекты могут интерполироваться между соседними зондами, чтобы получить приближение непрямого света в их положении. Статья Робина Грина - это, по сути, библия об этой технике, но она довольно тяжелая.

Горячая техника на данный момент - это Voxel Cone Tracing, которая не включает в себя ни одного этапа перед выпечкой. Я сам не слишком знаком с этим, но, насколько я понимаю, это включает вокселизацию вашей сцены в мир в стиле Minecraft с низким разрешением, размещение вокселей в быстро перемещаемой пространственной структуре, такой как октри, с последующим приведением нескольких широких слоев. лучи (колбочки) из каждой точки и проверка, по каким вокселям они попадают, чтобы собрать отраженный свет. NVidia толкает это довольно трудно в данный момент, и есть документы на него здесь и здесь .

Надеюсь, это поможет :)

Трассировка пути является очень дорогим вычислительным алгоритмом и не подходит для работы в реальном времени. Архитектура PBRT также не подходит для работы в режиме реального времени. Главная цель PBRT - решить уравнение рендеринга, используя беспристрастную интеграцию Монте-Карло. См https://en.wikipedia.org/wiki/Unbiased_rendering для получения дополнительной информации.

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

В любом случае, трассировка пути может быть реализована в OpenGL, я бы посоветовал взглянуть на вычислительные шейдеры, которые очень мощные. OpenGL ES 3.1 поддерживает вычислительные шейдеры с некоторыми небольшими ограничениями, в отличие от Desktop GL.

Прочитайте эту страницу, чтобы получить больше информации: https://github.com/LWJGL/lwjgl3-wiki/wiki/2.6.1.-Ray-tracing-with-OpenGL-Compute-Shaders-(Part-I)

Удачи!