Wojciech Toman

Dotychczasowe podejście do oświetlenia Idea deferred shadingu Typowe problemy wraz z propozycjami rozwiązania Optymalizacja wydajności Integracja z modułem renderującym Podsumowanie

Dotychczasowe podejście

Renderowanie świateł z użyciem wielu przebiegów renderingu: Duża złożoność czasowa: O(liczba_świateł * liczba_obiektów) Brak możliwości uzyskania dobrego batchingu (sortowanie po światłach lub geometrii) – częste przełączanie shaderów i stanów urządzenia Wniosek: na geometrię wpływa tylko część świateł

Uniwersalne shadery: 1 przebieg renderingu Inne zachowanie shaderów dla 1, 2, …, n świateł i wszystkich przewidzianych kombinacji modeli oświetlenia Długi, nieczytelny kod shadera Konieczność stosowania branchingu bądź makr Nieelastyczność – ciężko dodać nowe światło Przyzwoity batching przy sortowaniu po materiałach

Idea deferred shadingu

Rozbicie renderingu na dwie fazy: Geometrii Oświetlenia

Właściwości geometryczne sceny 3D są renderowane do kilku render targetów Render-targety te noszą nazwę G-Bufora (ang. G- Buffer), bufora geometrii Użycie mechanizmu MRT (ang. Multiple Render Target) Zwykle duża głębia dla zachowania precyzji przechowywanych danych

Renderowane dane Kolor rozpraszania Wektory normalne Informacje o położeniu pikseli Specular Glow Ambient-term Itd.

Wiele właściwości materiału jest stałych w ramach powierzchni Zastosowanie bufora materiałów Tekstura zawierająca potrzebne dane, w której każdy wiersz odpowiada innemu materiałowi Tablica stałych shadera Wniosek: jednym z atrybutów zapisywanych w G- Buforze jest indeks materiału

Kolor rozpraszania Przykład zawartości G-Bufora

Wektory normalne w przestrzeni widoku Przykład zawartości G-Bufora

Odwrotność głębokości pikseli w przestrzeni widoku Przykład zawartości G-Bufora

Dekodowanie danych zawartych w G-Buforze Obliczenia zgodnie z przyjętym modelem oświetlenia Dowolny, zależy tylko od użytego shadera Rendering prostokąta z włączonym blendingiem addytywnym dla każdego światła Wniosek: liczba źródeł światła teoretycznie jest nieograniczona

światło

Kilka kolorowych świateł punktowych wykorzystujących specular Przykład oświetlonej sceny

Kilka kolorowych świateł punktowych wykorzystujących specular oraz atmospheric scaterring Przykład oświetlonej sceny

Problemy

MRT nie wspiera sprzętowego anti-aliasingu Wszystkie obliczenia wykonywane są w przestrzeni ekranu – brak informacji o krawędziach Rozwiązania Akceptacja problemu – kompromis pomiędzy jakością a wydajnością renderingu Over-sampling – rendering obrazu do render targetów o rozdzielczości przekraczającej rozdzielczość widoku Własny filtr post-process – wykrywanie krawędzi a później ich wygładzenie W DirectX 10 możliwy dostęp bezpośrednio do próbek MSAA – możliwość przeprowadzenia anti-aliasingu w oparciu o dowolny wzorzec

Filtr wykrywający krawędzie Anti-aliasing w DirectX 9.0c

Brak anti-aliasinguWłączony anti-aliasing

Brak anti-aliasinguWłączony anti-aliasing

Alpha-blending jest koszmarem! Standardowe podejście nie działa Istniejące rozwiązania mają liczne wady Rozwiązania Rendering wszelkich półprzezroczystych obiektów po narysowaniu pozostałych Depth-peeling lub A-Buffer (praktycznie tylko w przypadku DirectX 10)

Wszystkie render targety zwykle odpowiadają rozdzielczości ekranu Wiele odczytów i zapisów do tekstur Rozwiązanie Nierysowanie całoekranowych prostokątów Scissor-test – wykonywany dużo wcześniej niż na konceptualnym diagramie w DirectX SDK – możliwość odrzucenia całych fragmentów przed wykoniem pixel shadera Stencil-test (uruchamiany później) – pixel shader musi być wykonany, a zatem test jest mniej przydatny

Diagram konceptualny DirectX SDK 9.0c

Scissor-test Zwykła projekcja świateł do przestrzeni ekranu może wygenerować zbyt duże prostokąty oraz artefakty związane z umiejscowieniem kamery w bryle otaczającej światła Alternatywa: zastosowanie algorytmu zaproponowanego przez Lengyela

Algorytm Lengyela Konstrukcja czterech płaszczyzn przechodzących przez punkt, w którym umieszczona jest kamera i stycznych do bryły otaczającej światła Wyznaczenie przecięcia płaszczyzn z płaszczyzną obrazu Punkty przecięcia to szukane współrzędne prostokąta dla scissor testu

Optymalizacja wydajności

Sumowanie wpływu świateł Odrzucanie świateł, które w małym stopniu wpływają na wygląd sceny Pakowanie Wektory normalne – jeśli obliczenia wykonywane są w przestrzeni widoku to wszystkie trójkąty front- faced mają ten sam znak, a back-faced – przeciwny Możliwe jest zastosowanie twierdzenia Pitagorasa - przechowywanie tylko 2 współrzędnych Zamiast całego wektora położenia przechowywanie jedynie długości wektora położenia w przestrzeni widoku (głębokości piksela)

Pakowanie wektora położenia float3 eyeVec = float3(IN.position.x * aspect, IN.position.y, invTanHalfFov); float3 P = normalize(eyeVec) * depth;

Zwykle bezproblemowa Zastosowanie HDRI Efekty post-process można traktować jako światła globalne Łańcuch renderingu upraszcza się do dwóch faz Konieczność dobrego zaplanowania G-Bufora Przeprojektowanie może się wiązać z koniecznością przerobienia większości shaderów

Podsumowanie

ZaletyWady Wydajne rysowanie bardzo dużej liczby świateł Niemal doskonały batching - lepszy oferują jedynie bufory świateł Wysoka elastyczność Łatwa integracja z modułem renderującym Duże zużycie pamięci karty graficznej (zwykle kilkadziesiąt MB) Fill-rate bound Problemy z anti- aliasingiem Problemy z alpha- blendingiem Bardzo wysokie wymagania sprzętowe