Spherical Harmonics-based lighting - prośba o przybliżenie tematu

[Lucek]

Witam! Rzadko piszę pytania na forum, ale zaciekawiła mnie wyżej wymieniona technika i nie mogłem się powstrzymać. Przeczytałem enigmatyczne opisy, które możecie znaleźć tutaj oraz tutaj i szczerze mówiąc daleki jestem od zrozumienia zasady działania tej rzekomo przełomowej techniki. Czy mógłbym prosić szanownych bywalców o wytłumaczenie mi krok po kroku o co tutaj chodzi? Symek?

Dziękuję z góry za pomoc:)

[SYmek]

W pryncypiach sprawa jest bardzo prosta, w szczegółach jak widać niekoniecznie. SH są na tyle proste, że - jak pewnie wiesz - daje się je stosować w realtime w grach (ale mowa tu o najprostszym komponencie, czyli świetle rozproszonym). I dla gier jest najwięcej przykładów w sieci (w tym działające dama).

 

Harmoniki sferyczne, to proste funkcje opisane na kuli: czyli podajesz dwa parametry (azymut i elewacja) i dostajesz wartość funkcji ( w tym przypadku natężenie światła przychodzącego z danego kierunku). Funkcje te są dobrze opisane, mają wiele tyleż pożytecznych, co egzotycznych właściwości (ortogonalność) a zabawa z SHL sprowadza się do tego, aby za pomocą ich liniowych kombinacji jak najwierniej opisać promieniowanie w scenie 3D.

 

Mówiąc inaczej, jak wiesz, jest taki program HDRI Studio, w którym ręcznie robisz hdrki do oświetlenia swojej sceny. Świecenie techniką SH, to właśnie automatyczne sprowadzenie *całego* światła w scenie do takiej kolorowej hdri, tyle tylko, że to nie będzie mapa binarna, jak hdri, ale funkcja analityczna (czyli wzór matematyczny), a właściwie ich seria (np siedem), które w możliwie wierny sposób opisują charakter światła w scenie - będąc jednocześnie prostymi wyrażeniami matematycznymi. Cały urok takich patentów jak SH (albo falki) sprowadza się do tego, że potrafią opisywać bardzo skomplikowane zjawiska w szalenie prosty i kompaktowy sposób.

 

Ma to swoje konsekwencje dla wydajności algorytmu, od oczywistego obniżenia ilości cykli procesora w stosunku do śledzenia promieni, do prowadzania obliczeń na danych mieszczących się jednocześnie w cache'u procesora, co ma niebagatelne znacznie dla jego wydajności.

 

Używa się tego od dawna, także w grach, działa bardzo szybko, tyle tylko, że w swej istocie SHL jest silnie biasową techniką kompresji i interpolacji danych, a więc w czasach unbiasowych + fizycznych rendererów jest to technika w odwodzie. Koniec końców SH reprezentują skomplikowaną wielowymiarową funkcję (światło albo radiacje w scenie) za pomocą serii prostych, dwuwymiarowych funkcji, ale ta reprezentacja jest z natury niedokładna.

 

Czym dokładnie dysponuje WETA, pewnie mało kto wie (ja na pewno nie :) ), ale w point based lighting w PRManie także używa SH. Cała scena zapisana zostaje do brickmapy (czyli trójwymiarowego renderu z voxeli), a potem dla każdego bucketa zostają policzone harmoniki sferyczne dla światła rozproszonego i odbitego i również zapisane w mapie w taki sposób, że można te wartości sumować (octree).

 

Czyli jeśli na jakiś obiekt w scenie pada światło z kierunku X, to zamiast wysyłać tam serię promieni wewnątrz stożka (solid angle), sprawdzamy w mapie odpowiedni poziom octree, który sumuje harmoniki sferyczne dla danej szerokości stożka. Dostajemy wartość światła z danego kierunku i koniec. Im stożek węższy (odbicie ostrzejsze), tym głębszy poziom octree musimy odwiedzić, ale też więcej harmonik sferycznych musimy mieć zapisanych, żeby reprezentować ostre odbicie. Ponieważ harmoniki są lekkie, mówimy o kilkudziesięciu liczbach, które należy odczytać z brickmapy, aby obliczyć pełną wartość GI dla danego punktu w scenie.

 

Zasadniczym atutem tej techniki (kto wie, czy nie jedynym dzisiaj) jest to, że nie wymaga ona ŻADNEGO śledzenia promieni. W praktyce można się wspierać jakimiś promieniami (jak WETA z panta ray), ale nie jest to konieczne. A jak wiemy, ray tracing / path tracing etc jest super skuteczny jak długo nasza scena mieści się w pamięci RAM. Jeśli się nie mieści, śledzenie promieni nie pozostawia żadnych możliwości. Z punktu widzenia programowania i optymalizacji, każda operacja na strukturze akceleracji wymaga przechowywania jej w pamięci w całości (gigabajty) oraz niszczenia cache'u (ładowania do niego nowych fragmentów drzewa). Dla firmy, która robi zawsze największe z możliwych filmów w danym czasie, nie jest specjalnie wygodne :)

 

jakoś tak :)

skk.

Edytowane 10 Czerwiec 2013 przez SYmek

[Lucek]

Dziękuję ci bardzo za wytłumaczenie. Kto miałby wiedzieć jak nie ty;) Spróbuję teraz zgłębić temat nieco bardziej i napisać coś o tym w mojej nieszczęsnej pracy;) Przy najbliższej okazji postaram się poczęstować repem;) pozdrawiam!

[SYmek]

Dziękuję ci bardzo za wytłumaczenie. Kto miałby wiedzieć jak nie ty;) Spróbuję teraz zgłębić temat nieco bardziej i napisać coś o tym w mojej nieszczęsnej pracy;) Przy najbliższej okazji postaram się poczęstować repem;) pozdrawiam!

 

 

O, ja myślę, że chłopaki od gier wiedzą na ten temat sporo więcej ;), naprawdę jest sporo materiałów do realtime, które warto prześledzić.

 

pozdrawiam,

skk.

 

ps powinienem był napisać wyraźnie, chyba to się nie przeniosło w pierwszym poście, że kolejne poziomy harmonik dodają do światła coraz więcej szczegółów, bo odpowiadają za coraz wyższe częstotliwości w oryginalnej funkcji (sygnale, jak by powiedzieli inżynierowie), podobnie jak poziomy falek (wavelets transformation). Dlatego, kilka pierwszych harmonik wystarczy, aby opisać światło rozproszone, które jak nazwa sugeruje, nie zawiera wiele informacji w wysokich częstotliwościach (vide powszechne rozmywanie hdrek przed renderem, żeby wywalić szczegóły, czyli zbędne informacje, które nic nie wnoszą do światła rozproszonego, a zwiększają szum na renderze). Niestety im odbicia ostrzejsze, tym więcej poziomów harmonik jest potrzebnych, aż w końcu przestaje to się opłacać.

[etrom]

W linku do Fxguide ktory podales wyraznie mowia o fakcie ze sferyki harmoniczne sa podobnym konceptem do transformacji Fouriera - sproboj sobie pogooglowac jak wygladaja obrazy po zastosowaniu transformacji Fouriera - przy pewnej dozie bezczlenosci mozna powiedziec ze sa zblurowane, podczas gdy wysokie czestotilwosci to krawedzie.(http://paulbourke.net/miscellaneous/imagefilter/)

Co ciekawe, niskie czestotliwosci da sie uchwycic juz przy pomocy niewielkiej ilosci funkcji bazowych(sin, cos w przypadku Fouriera, no i Harmoniki Sferyczne w drugim). Im wyzsza czestotliwosc tym wiecej funkcji bazowych nam potrzeba (Fourier zakladal ze kazda funkcje da sie przedstawic za pomoca nieskonczonej sumy sinusow i cosinow), ale ze w przypadku harmonik sferycznych chcemy miec rozproszone swiatlo, wlasnie kilka pierwszych w zupelnosci wystarcza, jak napisal SYmek.

[Lucek]

Dzięki chłopaki. Nie mam wykształcenia i umiejętności w tym kierunku i nie piszę niczego podobnego, ale oczywiście rozumiem już zależność pomiędzy złożonością obliczeniową a efektem. Zasada działania tej i innych technik (AO, IBL) po prostu wylądowała w mojej pracy licencjackiej o efektach specjalnych w dziale "cyfrowe oświetlenie". Wielkie dzięki jeszcze raz za pomoc;) Swoją drogą gdybyście mieli coś jeszcze do powiedzenia o trendach w technologiach grafiki/oświetlenia/renderingu itd to chętnie posłucham;)

[etrom]

Ale czy chodzi ci o oswietlenie w realtime, czy jakiekolwiek generowanie obrazu.

Jesli chodzi o realtime, to chyba podstawowa praca teraz jest zaimplementowany UDK voxel cone tracing:

- http://blog.icare3d.org/2012/06/unreal-engine-4-demo-with-real-time-gi.html

Z nowych rzeczy sa tez implementacje path tracingu na gpu

- http://raytracey.blogspot.com/

Generalnie tez polecam popatrzec po autorach, na stronie czlowieka ktorego wspominali w fxguide masz cos takiego

- http://web4.cs.ucl.ac.uk/staff/j.kautz/publications/GISTAR_CGF12.pdf

Praca o state-of-the-art jesli chodzi o GI

[Lucek]

Dzięki;) Praca prawie domknięta, ale zawsze warto poczytać dla samokształcenia;)