Transcript Deferred shading jako wydajna technika o*wietlenia
Slide 1
Wojciech Toman
Slide 2
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
Slide 3
Dotychczasowe podejście
Slide 4
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ł
Slide 5
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
Slide 6
Idea deferred shadingu
Slide 7
Rozbicie renderingu na dwie fazy:
◦ Geometrii
◦ Oświetlenia
Slide 8
Właściwości geometryczne sceny 3D są
renderowane do kilku render targetów
◦ Render-targety te noszą nazwę G-Bufora (ang. GBuffer), bufora geometrii
◦ Użycie mechanizmu MRT (ang. Multiple Render
Target)
◦ Zwykle duża głębia dla zachowania precyzji
przechowywanych danych
Slide 9
Renderowane dane
◦
◦
◦
◦
◦
◦
◦
Kolor rozpraszania
Wektory normalne
Informacje o położeniu pikseli
Specular
Glow
Ambient-term
Itd.
Slide 10
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 GBuforze jest indeks materiału
Slide 11
Przykład zawartości G-Bufora
Kolor rozpraszania
Slide 12
Przykład zawartości G-Bufora
Wektory normalne w przestrzeni widoku
Slide 13
Przykład zawartości G-Bufora
Odwrotność głębokości pikseli w przestrzeni widoku
Slide 14
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
Slide 15
światło
Slide 16
Przykład oświetlonej sceny
Kilka kolorowych świateł punktowych wykorzystujących specular
Slide 17
Przykład oświetlonej sceny
Kilka kolorowych świateł punktowych wykorzystujących specular oraz
atmospheric scaterring
Slide 18
Problemy
Slide 19
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
Slide 20
Anti-aliasing w DirectX 9.0c
Filtr wykrywający krawędzie
Slide 21
Brak anti-aliasingu
Włączony anti-aliasing
Slide 22
Brak anti-aliasingu
Włączony anti-aliasing
Slide 23
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)
Slide 24
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
Slide 25
Problemy – Fill–rate bound
Diagram konceptualny DirectX SDK
9.0c
Slide 26
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
Slide 27
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
Slide 28
Optymalizacja wydajności
Slide 29
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 frontfaced 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)
Slide 30
Pakowanie wektora położenia
float3 eyeVec = float3(IN.position.x * aspect, IN.position.y, invTanHalfFov);
float3 P = normalize(eyeVec) * depth;
Slide 31
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
Slide 32
Podsumowanie
Slide 33
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
Zalety
Duże zużycie pamięci
karty graficznej
(zwykle kilkadziesiąt
MB)
Fill-rate bound
Problemy z antialiasingiem
Problemy z alphablendingiem
Bardzo wysokie
wymagania sprzętowe
Wady
Wojciech Toman
Slide 2
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
Slide 3
Dotychczasowe podejście
Slide 4
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ł
Slide 5
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
Slide 6
Idea deferred shadingu
Slide 7
Rozbicie renderingu na dwie fazy:
◦ Geometrii
◦ Oświetlenia
Slide 8
Właściwości geometryczne sceny 3D są
renderowane do kilku render targetów
◦ Render-targety te noszą nazwę G-Bufora (ang. GBuffer), bufora geometrii
◦ Użycie mechanizmu MRT (ang. Multiple Render
Target)
◦ Zwykle duża głębia dla zachowania precyzji
przechowywanych danych
Slide 9
Renderowane dane
◦
◦
◦
◦
◦
◦
◦
Kolor rozpraszania
Wektory normalne
Informacje o położeniu pikseli
Specular
Glow
Ambient-term
Itd.
Slide 10
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 GBuforze jest indeks materiału
Slide 11
Przykład zawartości G-Bufora
Kolor rozpraszania
Slide 12
Przykład zawartości G-Bufora
Wektory normalne w przestrzeni widoku
Slide 13
Przykład zawartości G-Bufora
Odwrotność głębokości pikseli w przestrzeni widoku
Slide 14
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
Slide 15
światło
Slide 16
Przykład oświetlonej sceny
Kilka kolorowych świateł punktowych wykorzystujących specular
Slide 17
Przykład oświetlonej sceny
Kilka kolorowych świateł punktowych wykorzystujących specular oraz
atmospheric scaterring
Slide 18
Problemy
Slide 19
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
Slide 20
Anti-aliasing w DirectX 9.0c
Filtr wykrywający krawędzie
Slide 21
Brak anti-aliasingu
Włączony anti-aliasing
Slide 22
Brak anti-aliasingu
Włączony anti-aliasing
Slide 23
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)
Slide 24
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
Slide 25
Problemy – Fill–rate bound
Diagram konceptualny DirectX SDK
9.0c
Slide 26
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
Slide 27
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
Slide 28
Optymalizacja wydajności
Slide 29
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 frontfaced 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)
Slide 30
Pakowanie wektora położenia
float3 eyeVec = float3(IN.position.x * aspect, IN.position.y, invTanHalfFov);
float3 P = normalize(eyeVec) * depth;
Slide 31
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
Slide 32
Podsumowanie
Slide 33
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
Zalety
Duże zużycie pamięci
karty graficznej
(zwykle kilkadziesiąt
MB)
Fill-rate bound
Problemy z antialiasingiem
Problemy z alphablendingiem
Bardzo wysokie
wymagania sprzętowe
Wady