Затінення на фізичній основі - зовнішнє / непряме освітлення


15

Я реалізував фізично обгрунтований трекер шляху після вивчення ПБРТ М. Фарра та Г. Хамфріса. Зараз я намагаюся застосувати фізичну основу візуалізації до графіки в режимі реального часу за допомогою OpenGL ES (в додатку для iPhone).

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

У інструменті відстеження шляху (як у тому, що міститься в pbrt), непряме / навколишнє світло дається "автоматично" з алгоритму відстеження шляху, оскільки він слідує по шляху світлових променів з урахуванням прямого та непрямого освітлення.

Як я моделюю непряме освітлення у фізично заснованому візуалізації, написаному на OpenGL ES, з використанням комп'ютерної графіки в реальному часі?

Відповіді:


39

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

Навколишнє освітлення

У самому простому кінці діапазону можна використовувати освітлення навколишнього середовища : глобальне, всенаправлене джерело світла, яке застосовується до кожного об'єкта в сцені, без огляду на фактичні джерела світла чи локальну видимість. Це зовсім не точно, але надзвичайно дешево, легко налаштувати художника, і може виглядати нормально залежно від сцени та бажаного візуального стилю.

Загальні розширення до базового освітлення включають:

  • Зробіть, щоб колір навколишнього середовища змінювався напрямком, наприклад, використовуючи сферичні гармоніки (SH) або невелику кубічну карту та шукаючи колір у шейдері на основі нормального вектора кожної вершини чи пікселя. Це дозволяє певну візуальну диференціацію між поверхнями різної спрямованості, навіть там, де пряме світло не досягає їх.
  • Застосовуйте методи зовнішньої оклюзії (AO) , включаючи попередньо обчислені вершини AO, карти текстури AO, поля AO та AO простору екрану (SSAO) . Всі вони працюють, намагаючись виявити такі ділянки, як отвори і щілини, де непряме світло менше шансів відскочити і затемнити навколишнє світло там.
  • Додайте екологічну кубічну карту, щоб забезпечити навколишнє дзеркальне відображення. Кубемапа з гідною роздільною здатністю (128 ² або 256 ² на обличчя) може бути досить переконливою для окулярів на вигнутих, блискучих поверхнях.

Запечене непряме освітлення

Наступний "рівень", так би мовити, прийомів передбачає випікання (попереднє обчислення в режимі офлайн) деякого зображення непрямого освітлення на сцені. Перевага випічки полягає в тому, що ви можете отримати досить якісні результати за невеликі обчислювальні витрати в режимі реального часу, оскільки всі важкі частини виконуються при випічці. Компроміс полягає в тому, що час, необхідний для процесу випічки, шкодить рівню ітерації дизайнерів; потрібно більше пам’яті та дискового простору для зберігання попередньо обчислених даних; можливість зміни освітлення в режимі реального часу дуже обмежена; і процес запікання може використовувати інформацію лише з статичної геометрії рівня, тому непрямі освітлювальні ефекти від динамічних об'єктів, таких як символи, будуть пропущені. І все-таки печене освітлення дуже широко використовується в іграх AAA сьогодні.

Крок запікання може використовувати будь-який потрібний алгоритм візуалізації, включаючи відстеження траєкторій, радіовипромінювання або використання самого ігрового двигуна для виведення кубічних карт (або півмісяців ).

Результати можуть бути збережені у текстурах ( світлових картах ), застосованих до статичної геометрії на рівні, та / або вони також можуть бути перетворені в SH та збережені в об'ємних структурах даних, таких як обсяги опромінення (текстури обсягу, де кожен тексель зберігає зонд SH) або чотиригранні сітки . Потім можна використовувати шейдери для пошуку та інтерполяції кольорів із цієї структури даних та застосувати їх до відображеної геометрії. Об'ємний підхід дозволяє застосовувати пече освітлення як динамічним об'єктам, так і статичній геометрії.

Просторове дозвіл світлових карт тощо буде обмежено пам’яттю та іншими практичними обмеженнями, тому ви можете доповнити запечене освітлення деякими AO-методами, щоб додати деталі високої частоти, які не може забезпечити засвічене освітлення, та відповісти на динамічні об’єкти (наприклад, затемнення непрямого світла під рухомим символом чи транспортним засобом).

Існує також техніка під назвою попередньо обчислена радіаційна передача (PRT) , яка розширює випічку для більш динамічних умов освітлення. У PRT, замість того, щоб випекти саме непряме освітлення, ви випікаєте функцію передачі від якогось джерела світла - зазвичай неба - до непрямого непрямого освітлення в сцені. Функція передачі представлена ​​у вигляді матриці, яка перетворює від вихідного до кінцевого коефіцієнти SH в кожній точці вибірки. Це дозволяє змінювати освітлене середовище, а непряме освітлення на сцені реагуватиме правдоподібно. Far Cry 3 і 4 використовували цю методику, щоб дозволити безперервний цикл день-ніч, непряме освітлення змінюється залежно від кольорів неба в кожен час доби.

Ще один момент щодо випічки: може бути корисним мати окремі запечені дані для дифузного та дзеркального непрямого освітлення. Cubemap працює набагато краще, ніж SH для окулярів (оскільки кубічні карти можуть мати набагато більше кутових деталей), але вони також займають набагато більше пам’яті, тому ви не можете дозволити собі розміщувати їх так щільно, як зразки SH. Корекція паралакса може бути використана, щоб дещо компенсувати це, евристично перекочуючи кубічну карту, щоб її відображення відчували себе більш обґрунтованими до геометрії навколо неї.

Повністю методи реального часу

Нарешті, можна обчислити повністю динамічне непряме освітлення на GPU. Він може реагувати в режимі реального часу на довільні зміни освітлення або геометрії. Однак знову є компроміс між виконанням часу виконання, вірністю освітлення та розміром сцени. Деяким із цих методів потрібен взаємний GPU, щоб взагалі працювати, і можливо, це можливо лише для обмежених розмірів сцени. Вони, як правило, підтримують лише один відбій непрямого світла.

  • Динамічна кубічна карта середовища, де грані кубічної карти відтворюються кожен кадр за допомогою шести камер, згрупованих навколо обраної точки, може забезпечити пристойно хороші відбиття навколишнього середовища для одного об’єкта. Наприклад, це часто використовується для автомобілів гравців у гоночних іграх.
  • Глобальне освітлення екранного простору , розширення SSAO, яке збирає освітлення від відточених пікселів на екрані в проході після обробки.
  • Рефлекторне відбиття екранного простору працює шляхом проміння променів через буфер глибини в пост-проході. Він може забезпечити досить якісні відображення до тих пір, поки відображені предмети на екрані.
  • Система миттєвого випромінювання працює за допомогою відстеження променів у сцені за допомогою процесора та розміщення точкового світла у кожній точці удару променя, що приблизно представляє відходить світло у всіх напрямках від цього променя. Ці багато вогнів, відомих як віртуальні точкові світильники (VPL), потім передаються GPU звичайним способом.
  • Світловідбиваючі тіньові карти (RSM) схожі на миттєву радіовипромінювання, але VPL генеруються за допомогою відображення сцени з точки зору світла (як тіньова карта) та розміщення VPL на кожному пікселі цієї карти.
  • Обсяги поширення світла складаються з 3D-сіток зондів SH, розміщених по всій сцені. РСМ надаються та використовуються для "впорскування" світла відбиття в зонди SH, що знаходяться поблизу відбиваючих поверхонь. Потім процес, що заповнює заливку, поширює світло від кожного зонда SH до навколишніх точок сітки, і результат цього використовується для нанесення освітлення на сцену. Ця методика поширилася і на об'ємне розсіювання світла .
  • Відстеження конусу Вокселя працює за допомогою вокселізації геометрії сцени (можливо, із застосуванням різної роздільної здатності вокселів, точніше біля камери та більш грубої відстані), а потім введення світла від RSM в мережу вокселів. Під час візуалізації основної сцени піксельний шейдер виконує «конусовий слід» - промінь проміння з поступово збільшуючим радіусом - через воксельну сітку для збору вхідного світла для дифузного або дзеркального затінення.

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

Як бачимо, непряме освітлення в режимі реального часу - це величезна тема, і навіть ця (досить довга!) Відповідь може лише забезпечити огляд у 10000 футів та контекст для подальшого читання. Який підхід для вас найкраще залежатиме від деталей вашої конкретної заявки, які обмеження ви готові прийняти та скільки часу вам потрібно вкласти.


Привіт @Nathan, дякую за детальну відповідь. Я знаю, що це величезна тема (і великий предмет вивчення). Найбільша проблема полягає в тому, що документація в Інтернеті фрагментарна, і важко знайти хороший підхід. Мій проект - це goo.gl/Fgo21x : переглядач BRDF (натхненний переглядачем WDAS), щоб показати найпоширеніші емпіричні та фізично засновані моделі BRDF, що підтримує обчислення кольорів за допомогою спектральних даних - тристимульні значення. Це навчальний проект для вивчення OpenGL.
Фабріціо Дуроні

Я думаю, що хорошим першим підходом може бути використання загального згаданого вами розширення: SH або маленька кубічна карта + карта куби навколишнього середовища (для відображення та заломлення). Що ви думаєте про це? (Я розробляю цей додаток після роботи під час безсонніх ночей :)). Дякую ще раз за збірку джерел, які ви зв'язали вище (у мене зараз багато матеріалу для вивчення).
Фабріціо Дуроні

@FabrizioDuroni Так! Для глядача BRDF простий навколишній середовище плюс екологічна кубічна карта повинен бути чудовим.
Натан Рід

Можливо, це відноситься до однієї з ваших категорій, але хіба не старомодна технічна візуалізація - це повністю техніка в реальному часі? Крім того, чи не можливо збільшити основну обстановку за допомогою кубічної карти середовища для розсіяних відображень?

@racarate Вибачте, мені потрібно було відповісти деякий час, але так, ви маєте рацію! Думаю, я мав на увазі це згадати, але забув. :) У всякому разі, я його додав. (Я вже згадував використання кубічної карти для розповсюдження в першій точці кулі.)
Натан Рід,

5

Це основна "важка" проблема, що залишається в СГ в режимі реального часу, і для її вирішення триває багато досліджень.

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

Дешевим методом виконання є використання запечених світлих карт, де ви запускаєте щось повільне, але дивовижне, як радіочутливість або відстеження шляху в автономному режимі, а потім зберігаєте інформацію про освітлення разом зі звичайними даними вершин. Це чудово підходить для статичної геометрії, але стає проблематичним, як тільки ви додаєте об’єкти, що рухаються. Міхал Іваніцький зробив хорошу презентацію про те, як вони вирішили це для "Останніх з нас".

Сферичні гармоніки багато використовуються в ігрових двигунах для подання непрямого світла. Вони в основному є перетворенням Фур'є по всій поверхні сфери, відкинувши високочастотні компоненти, ви зможете отримати візуально приємне, переважно точне освітлення навколишнього середовища лише у 9 коефіцієнтів на колір. Наприклад, Єдність використовує SH для випікання «світлових зондів» у різних точках сцени, а об'єкти, що рухаються, можуть потім інтерполювати між сусідніми зондами, щоб отримати наближення непрямого світла до їх положення. Папір Робіна Гріна - це в основному біблія про цю техніку, але це досить важко.

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

Сподіваюся, що це допомагає :)


0

Трасування шляхів - це дуже дорогий обчислювальний алгоритм, який не підходить в режимі реального часу. Архітектура 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)

Удачі!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.