Тіні в відкладеній візуалізації


12

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

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

Тож як відкладене відображення здійснює тіні, еквівалентні візуалізації вперед?

Відповіді:


14

Відкладене затінення не робить нічого особливого для тіней. Вам все одно потрібно візуалізувати карти тіней, а потім виводити кожне світло з відповідною тіньовою картою, пов'язаною як текстура.

Це все ж краще, ніж візуалізація вперед, тому що вам не потрібно перемальовувати сцену в головному огляді, щоб застосувати освітлення. Малювання тіньової карти часто набагато дешевше, ніж малювати більше проходів у головному огляді, тому що не потрібно робити затінення пікселів, а тіньові карти часто містять менше сцени (ви можете викреслити набагато більше матеріалів).

Люди іноді роблять «відкладені тіні» для одного світла, як правило, головного спрямованого світла. Основна причина цього - використання каскадних карт тіней або інший підхід, який використовує кілька тіньових карт для одного і того ж світла. Ви можете зарезервувати один канал у буфері G для тіньової маски (білий там, де горить, темно - там, де тінь) і застосувати всі каскадні тіньові карти до цього каналу G-буфера; то шейдер для світла просто зчитує маску тіні і примножує її на світлий колір. Це добре, оскільки він знімає тіні від затінення, але ви все одно малюєте все ті ж карти тіней.


1
Якщо ви надзвичайно розумні, ви можете спробувати використовувати шейдер для геометрії під час створення GBuffer, щоб "вбудувати" створення тіньової карти (як це робить зразок карти куба DX10). Я не впевнений , якщо це було зроблено, якщо це взагалі можливо , або , якщо це буде повільніше , врешті-решт - але це принесло б створення карт тіней ближче до відкладеного затінення, або в визначення в залежності від вашої релігії.
Джонатан Дікінсон

6

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

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

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

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

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

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

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

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

У будь-якому випадку ви маєте перегляд позицій у просторі камер. І, як було сказано вище, ми можемо застосувати матрицю, щоб перетворити їх з простору камери перегляду в тіньовий прожекторний простір текстури. Отже ... зроби це. Потім перейдіть до своєї тіньової карти.

Проблема вирішена.


Чи можна виключити геометрію на світло при відкладеному візуалізації (заради оптимізації)?
Самаурса

@Samaursa: "Виключити геометрію на світло" з чого? Від заходу в карту тіней? Від запалення?
Нікол Болас

Я бачу, ви відповіли на питання щодо цього, дякую. Для інших, якщо вони хочуть , щоб слідувати питання / відповідь: gamedev.stackexchange.com/q/178755/2287
Samaursa
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.