Własny silnik graficzny. Część IV: krwawienie kolorów i miękkie cienie.

30.11.2010 - Robert Kraus
TrudnośćTrudnośćTrudnośćTrudność

Część I    Część II    Część III    Część IV   

Czym będziemy się zajmować?

Zrezygnujemy teraz z obsługi transmisji i odbicia lustrzanego. Skupimy się wyłącznie na idealnie rozproszonym odbijaniu światła, a nasz program będzie potrafił obliczać odbicie rozproszone światła pochodzącego nie tylko wprost ze źródła światła, ale również światła odbijanego od różnych obiektów. Dzięki temu otrzymamy nowe, ciekawe efekty.

Zmodyfikujemy nasz program (który obsługiwał ścieżki typów E(S|T)*DL) tak, aby obsługiwał wyłącznie ścieżki typów E(D*)L. Poniższa ilustracja prezentuje efekty tej zmiany.

Po lewej stronie fragment obrazu wygenerowanego programem, który pisaliśmy do tej pory. Posługiwaliśmy się w nim tzw. światłem punktowym, przez co mieliśmy efekt cieni o ostrych krawędziach (działo się tak dlatego, że światło punktowe jest albo zasłonięte albo widoczne w całości, stąd gwałtowne przeskoki z pełnego oświetlenia do pełnego cienia). Po prawej stronie fragment obrazu wygenerowanego zmodyfikowaną metodą, w którym rezygnujemy ze światła punktowego na rzecz świateł powierzchinowych. Prowadzi to do miękkich cieni gładko przechodzących od pełnego naświetlenia do pełnego cienia (dzieje się tak dlatego, że światło powierzchniowe może być zasłonięte tylko w części). Ponadto nie musimy już źródłom światła nadawać właściwości ambient (światło tła), gdyż to właśnie ścieżkom typu ED(D+)L odpowiadają za poprawną symulację tego zjawiska. Dodatkowo teraz światło tła będzie bardziej dokładne (zróżnicowane w zleżności od kąta padania) oraz otrzymamy efekt tzw. krwawienia kolorów, w którym powierzchnia barwi się kolorem obiektu sąsiadującego. Modyfikacja, którą będziemy wprowadzać do naszego kodu stworzy algorytm o nazwie śledzenie ścieżek (ang. path tracing lub też monte carlo path tracing).

Zmiany jakich dokonamy w celu uzyskania nowej funkcjonalności będą bardzo bardzo niewielkie - dodamy jedynie dwie krótkie procedury i zmodyfikujemy nieznacznie procedurę $ traceRay $.

Losowanie kierunków odbijania

Teraz przyjrzyjmy się jak wygląda scenariusz naszego obliczania oświetlenia. Startujemy z punktu $ x_0 $ (bedącego kamerą) i trafiamy promieniem w punkt $ x_1 $. Losujemy kierunek z półsfery wokół punktu $ x_1 $, a następnie śledzimy promień w tym wylosowanym kierunku, trafiamy w punkt $ x_2 $, dla którego musimy zrobić to samo co dla punktu $ x_1 $, itd. Dla każdego piksela obliczamy wiele w ten sposób losowanych ścieżek światła i obliczamy średnią arytmetyczną uzyskanych wyników.

Kiedy kończy się opisany powyżej proces?
1) Kiedy trafimy w świecącą powierzchnię.
Zakładamy, że powierzchnia emitująca światła nie jest odbijająca. Powierzchnie świecące na ogół są na tyle jasne, że dodanie właściwości odbijania nie spowoduje widocznych efektów.
2) Kiedy promień nie trafia w żaden obiekt na scenie.
Nie trafiliśmy w źródło światła, ani w obiekt, od którego można by się odbić, więc nasza ścieżka niesie zerowe natężenie światła.
3) Kiedy uznamy, że głębokość rekursji jest już zbyt duża. Teoretycznie może się zdarzyć, że bardzo długo (lub w nawet nieskończoność) nasz promień będzie się odbijał pomiędzy obiektami sceny. Zauważmy jednak, że im więcej odbić (czyli im większa długość przebytej ścieżki), tym mniejsze natężenie światła jakie potencjalnie może płynąć po takiej ścieżce. Największy wpływ na jakość obrazu mają na ogół ścieżki o długościach $ 1 $, $ 2 $ oraz $ 3 $, stąd śmiało możemy przyjąć, że całkowicie ignorujemy ścieżki o długościach np. większych od $ 5 $. Wprowadzimy w ten sposób pewien błąd oszacowania oświetlenia, ale będzie on na tyle mały, że nie spowoduje widocznych, niepożądanych efektów.

Wyniki renderingu

Słaba zbieżność w oszacowaniu oświetlenia będzie się objawiać ziarnistym szumem. Przyjrzyjmy się kilku przykładom pokazującym jak poprawia się jakość obrazu wraz z rosnącą ilością próbek (losowanych ścieżek światła).

1 ścieżka na piksel

10 ścieżek na piksel

1000 ścieżek na piksel

100 000 ścieżek na piksel

Tutaj obliczenie 100 000 ścieżek na piksel w rozdzielczości 600 x 600 trwało kilkanaście godzin na procesorze o taktowaniu 1.5 GHz. Istnieją rozszerzenia tej metody, które potrafią uzyskać pożądaną jakość obrazu wykorzystujące zaledwie kilkadziesiąt lub kilkaset ścieżek na piksel.

Alternatywna scena

Nasz algorytm daje jeszcze jedną ciekawą możliwość, oprócz miękkich cieni i krwawienia kolorów możemy w łatwy sposób zasymulować oswietlenie pochodzące z atmosfery. Wystarczy umieścić w scenie świecącą sferę o bardzo dużym promieniu i umieścić w jej środku wszystkie inne obiekty sceny.

100 ścieżek na piksel

50 000 ścieżek na piksel

50 000 ścieżek na piksel

4
Twoja ocena: Brak Ocena: 4 (4 ocen)

Copyright © 2008-2010 Wrocławski Portal Informatyczny

design: rafalpolito.com