Wojciech Toman. Dotychczasowe podejście do oświetlenia Idea deferred shadingu Typowe problemy wraz z propozycjami rozwiązania Optymalizacja wydajności.

Prezentacja na temat: "Wojciech Toman. Dotychczasowe podejście do oświetlenia Idea deferred shadingu Typowe problemy wraz z propozycjami rozwiązania Optymalizacja wydajności."— Zapis prezentacji:

1 Wojciech Toman

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

3 Dotychczasowe podejście

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ł

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

6 Idea deferred shadingu

7 Rozbicie renderingu na dwie fazy: Geometrii Oświetlenia

8 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

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

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 G- Buforze jest indeks materiału

11 Kolor rozpraszania Przykład zawartości G-Bufora

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

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

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

15 światło

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

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

18 Problemy

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

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

21 Brak anti-aliasinguWłączony anti-aliasing

22 Brak anti-aliasinguWłączony anti-aliasing

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)

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

25 Diagram konceptualny DirectX SDK 9.0c

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

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

28 Optymalizacja wydajności

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 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)

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

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

32 Podsumowanie

33 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