Screen Space Directional Occlusion

[RazorX]

Servus,

ich arbeite mich momentan durch das Paper zu Screen Space Directional Occlusion (http://www.mpi-inf.mpg.de/~ritschel/Papers/SSDO.pdf) und habe leider ein paar Verständnisprobleme bezogen auf die Implementierung. Fangen wir also mal an: Es handelt sich hierbei um zwei Dinge, einmal um den eigentlichen Occlusion-Faktor und zum anderen der indirekten Beleuchtung. Gegeben sei folgende Formel zur direkten Beleuchtung:

\(\[
L_{dir}(P) = \sum_{i=1}^N \frac{p}{\pi} L_{in}(\omega_i) V(\omega_i) cos(\theta_i) \delta\omega
\]\)

Das geschulte Auge erkennt, dass dies eine erweiterte Gleichung der SSAO Formel ist:

\(\[
A(P) = \sum_{i=1}^N V(\omega_i) cos(\theta_i) \delta\omega
\]\)

Die Erweiterung liegt also darin den BRDF Term mit einer Beleuchtungsfunktion für den Samplevektor \($\omega_i$\) und dem Occlusion Term zu multiplizieren. In dem Paper ist nun die Rede von einem Environment-Map Loopup oder der Auswertung der Beleuchtungsgleichung für Punktlichtquellen. Diesen Punkt verstehe ich noch nicht ganz, muss ich nun hier wirklich für jede Lichtquelle den Sample Punkt \($P + \omega_i$\) auswerten? Wie werden dann Schatten von den Lichtquellen behandelt, oder ist es egal, da es sich eh nur um eine Approximation handelt? Mal davon abgesehen, dass wir dabei dann noch eine Summe bekommen würden und die Berechnung von SSDO nicht mehr konstant wäre sondern abhängig von der Anzahl dynamischer Lichter.

Weiter gehts mit der indirekten Beleuchtung:

\(\[
L_{ind}(P) = \sum_{i=1}^N \frac{p}{\pi} L_{pixel}(1 - V(\omega_i)) \frac{A_s cos(\theta_{s_i}) cos(\theta_{r_i})}{d_i^2} \delta\omega
\]\)

Gemäß der Notation des Papers wird nun also auf Pixel (Beleuchtete Szene nehme ich mal an) als Lichtquelleninformation zugegriffen und für alle nicht verdeckten Sample reflektiert. Ferner steht in dem Paper, dass beide Gleichungen durch zwei Passes realisiert werden, was für mich nicht ganz einleuchtend ist, denn sie sind eigentlich nicht voneinander abhängig. In einem anderen Paper (http://www.cescg.org/CESCG-2011/papers/ ... Istvan.pdf) wird in der zweiten Gleichung statt \($L_{pixel}$\) die Funktion \($L_{dir}$\) verwendet, wo es natürlich wiederrum Sinn machen würde.

Wäre cool wenn mir da mal einer ein bisschen den Ausweg aus dem Irrgarten zeigen könnte.

Mit freundlichem Gruß
RazorX

[CodingCat]

In dem Paper ist nun die Rede von einem Environment-Map Loopup oder der Auswertung der Beleuchtungsgleichung für Punktlichtquellen. Diesen Punkt verstehe ich noch nicht ganz, muss ich nun hier wirklich für jede Lichtquelle den Sample Punkt \($P + \omega_i$\) auswerten? Wie werden dann Schatten von den Lichtquellen behandelt, oder ist es egal, da es sich eh nur um eine Approximation handelt? Mal davon abgesehen, dass wir dabei dann noch eine Summe bekommen würden und die Berechnung von SSDO nicht mehr konstant wäre sondern abhängig von der Anzahl dynamischer Lichter.

Globale Schatten bekommst du damit natürlich nicht hin. Wenn du für Punktlichter zusätzliche Ambient-Light-Farben definierst und diese Lichter mit der Verdeckung verrechnest, willst du vermutlich auch gar keine Schatten, denn sonst hättest du wieder normale direkte Beleuchtung. Im anderen Fall geht es weniger um Ambient Occlusion als um die Korrektur von Schatten an den Kontaktstellen. Es handelt sich also um eine Ergänzung traditioneller Shadow-Mapping-Methoden, bei denen mangels ausreichender Genauigkeit/Auflösung gerne ein Depth Bias eingeführt wird, welches oftmals zu Löchern im Schatten an Kontaktstellen der Geometrie führt. Dort kannst du mit Samples im Screen Space entlang eines Liniensegments in Richtung des jeweiligen Lichtes nun in einem sehr begrenzten Rahmen genauere lokale Schatten berechnen und damit die Löcher stopfen. Siehe Abschnitt Screen Space Shadow Correction.

Gemäß der Notation des Papers wird nun also auf Pixel (Beleuchtete Szene nehme ich mal an) als Lichtquelleninformation zugegriffen und für alle nicht verdeckten Sample reflektiert. Ferner steht in dem Paper, dass beide Gleichungen durch zwei Passes realisiert werden, was für mich nicht ganz einleuchtend ist, denn sie sind eigentlich nicht voneinander abhängig. In einem anderen Paper (http://www.cescg.org/CESCG-2011/papers/ ... Istvan.pdf) wird in der zweiten Gleichung statt \($L_{pixel}$\) die Funktion \($L_{dir}$\) verwendet, wo es natürlich wiederrum Sinn machen würde.

Ich denke nichts anderes ist hier gemeint, d.h. \($L_{pixel} = L_{dir} + ...$\) (also direkte + ambiente Beleuchtung, ggf. mit Contact Shadow Correction etc.).

[RazorX]

Verstehe ich das also richtig, dass im ersten Schritt alle Lichtquellen nochmal ausgewertet werden müssen? Also etwas in der Form:

\(\[
L_{dir}(P) = \sum_{i=1}^N \frac{p}{\pi} L_{in}(\omega_i) V(\omega_i) cos(\theta_i) \delta\omega \\
L_{in}(\vec{\omega}) = \sum_{j=1}^M (\vec{\omega} * \vec{l}_j) * color_{ambient_j}
\]\)

wodurch wir folgende Gleichung erhalten:

\(\[
L_{dir}(P) = \sum_{i=1}^N \frac{p}{\pi} (\sum_{j=1}^M (\vec{\omega_i} * \vec{l}_j) * color_{ambient_j}) V(\omega_i) cos(\theta_i) \delta\omega
\]\)

(Entfernung ist der Einfachheithalber bewusst nicht reingerechnet)

Sorry, bin momentan ein wenig verunsichert da ich den Überblick in den letzen beiden Tagen ein wenig verloren habe.

[CodingCat]

Ja, wenn du die ambiente Beleuchtung durch Punktlichter einzeln (richtungsabhängig) verschatten willst, musst du selbstverständlich auch die entsprechenden Punktlichter einzeln betrachten. Es bietet sich an, das in einem Deferred Shading Renderer direkt bei der Berechnung der Beleuchtung durch das jeweilige Licht zu tun, dann kannst du damit auch gleich noch die Kontaktschatten korrigieren und musst die Lichter nicht später noch einmal anfassen. Schlussendlich wird man derlei Berechnungen vermutlich auf wichtige Lichter im Einflusskreis derselben beschränken, um den Berechnungsaufwand nicht unnötig in die Höhe zu treiben.