ZFX + Developia

Hallo alle zusammen!

Wir sind im Moment dabei in[w]tech soetwas wie HeightFog einzubauen. Damit meinen wir soetwas hier:


Da man sonst nicht wirklich etwas darüber findet haben wir im Moment den Algorithmus aus einem Crytek-Paper eingebaut:
http://developer.amd.com/media/gpu_asse ... _Games.pdf (Seite 16-17)

Dabei haben wir 3 Voraussetzungen:

• Es sollte eine exponentielle Funktion sein
• Die Kamera muss den Nebel verlassen können, bzw. in ihn eintauchen können
• Die Höhe des Nebels muss mit einem Parameter verstellbar sein (Y-Position eines Objektes in der Welt)

Die Punkte 1 und 2 werden von der im Paper beschriebenen Methode erfüllt. Punkt 3 nach einigen Modifikationen auch, jedoch nicht ganz so, wie wir es haben möchten.

Es sieht etwa so aus: Bei Punkt A wäre etwa unser Objekt, welches die Höhe anzeigen soll. So wie es jetzt ist.
Bei Punkt B sollte es aber eigentlich sein. Jeder, der das schon mal im UDK gemacht hat wird wissen wovon ich rede. Der Nebel soll praktisch genau an der Y-Position des Objektes anfangen.

Glaube für Wasser könnte man so etwas auch gut gebrauchen. Hat das schon mal jemand gemacht, oder kennt jemand eine Formel, mit der das Möglich wäre?
Oder weiß jemand gar wie man die Crytek-Formel dahingehend anpassen kann?

Oh boy here we go again!

Also, erst einmal, um die Begrifflichkeiten klar zu kriegen: Wir haben ein wie auch immer geartetes Nebelvolumen, der Einfachheit halber hier mal eine Bounding Box. Da drin haben wir einen Sichtstrahl \($\mathbf C$\), der

• an einer bestimmten Stelle \($\mathbf o$\) startet. Dieser Punkt \($\mathbf o$\) liegt auf der Oberfläche des Bounding Volumes, falls die Betrachterposition außerhalb des Nebelvolumens liegt, ansonsten innerhalb des Nebelvolumens.
• an einer bestimmten Stelle \($\mathbf o + \mathbf d$\) endet. Dieser Punkt liegt auf einer Oberfläche eines Objektes im Nebel, wenn der Sichtstrahl mit diesem Objekt im Nebel kollidiert. Ansonsten liegt er auf der Oberfläche des Bounding Volumens.

Zusätlich haben wir die Höhe \($z_0$\) (im gleichen Koordinatensystem wie die übrigen Punkte) gegeben, über der wir eine exponentiell verteile Nebeldichte haben wollen, und darunter eine konstante Nebeldichte. Graphisch sieht das ganze also wie folgt aus:



Dann will ich anmerken, WTF warum schreibt der Carsten Wenzel da (Folie 16) ein Ringintegral, das ist ein Kurvenintegral, aber die Kurve (der Sichtstrahl) ist doch nicht geschlossen. Naja, egal.

Zur Vereinfachung definieren wir uns erst mal:
\($$\begin{align}
\text{Sichtstrahl:} & \mathbf{v}(t) = \mathbf{o} + t\mathbf{d} \\
\text{Setze:} & z(t) = \mathbf{v}(t), \ z(0) = \mathbf{o}_3, \ z(1) = (\mathbf{o} + \mathbf{d})_3, \ z'(t) = \mathbf{d}_3\end{align}$$\)Nachdem wir so unseren Sichtstrahl definiert haben, definieren wir die Nebeldichte als:
\($$f(x, y, z) = \begin{cases} b \cdot \mathrm e^{-c \cdot (z-z_0)}, & \text{falls } z > z_0 \\ b, & \text{sonst} \end{cases}$$\)Damit hätten wir auch die Nebeldichte definiert. Nun müssen wir einfach die Nebeldichte entlang des Sichtstrahls integrieren. Dazu berechnen wir erst einmal das \($t_0$\), s.d. \($\mathbf v(t_0) = z_0$\) ist (a.k.a. der Parameter für den Kollisionspunkt zwischen Sichtstrahl und \($z_0$\)-Ebene). Dann berechnen wir einfach das Kurvenintegral:
\($$
\begin{align}
\displaystyle \int_\mathbf{C} f(\mathbf{v}) \, \mathrm d \mathbf v
&= \displaystyle \int_0^1 f\big(\mathbf{v}(t)\big) \cdot \|\mathbf{v}'(t)\| \, \mathrm dt \\
&= \displaystyle \int_0^1 f(\mathbf{o} + t\mathbf{d}) \cdot \|\mathbf{d}\| \, \mathrm dt \\
&= \displaystyle \int_0^{t_0} b \cdot \|\mathbf{d}\| \, \mathrm dt + \int_{t_0}^1 b \cdot \mathrm e^{-c \cdot (z(t)-z_0)} \cdot \|\mathbf{d}\| \, \mathrm dt \\
&= t_0 \cdot b \cdot \|\mathbf{d}\| + \bigg[ \displaystyle \frac{b \cdot \|\mathbf{d}\|}{-c \cdot z'(t)} \cdot \mathrm e^{-c \cdot (z(t)-z_0)} \bigg]_{t_0}^1 \\
&= t_0 \cdot b \cdot \|\mathbf{d}\| + \displaystyle \frac{b \cdot \|\mathbf{d}\|}{-c \cdot \mathbf{d}_3} \cdot \bigg( \mathrm e^{-c \cdot (z(1)-z_0)} - \mathrm e^{-c \cdot (z(t_0)-z_0)} \! \bigg)
\end{align}$$\)Mit den vorherigen Definitionen können wir das noch vereinfachen:
\(\begin{align}
\displaystyle \int_\mathbf{C} f(\mathbf{v}) \, \mathrm d \mathbf v
&= t_0 \cdot b \cdot \|\mathbf{d}\| + \displaystyle \frac{b \cdot \|\mathbf{d}\|}{-c \cdot \mathbf{d}_3} \cdot \Big( \mathrm e^{-c \cdot \big((\mathbf{o} - \mathbf{d})_3-z_0 \big)} - 1 \! \Big) \\
&= b \cdot \|\mathbf{d}\| \cdot \big(t_0 - \frac{1}{c - \mathbf{d}_3} \big) \cdot \Big( \mathrm e^{-c \cdot \big((\mathbf{o} - \mathbf{d})_3-z_0 \big)} - 1 \! \Big)
\end{align}\)Die final wahrgenommene Nebelfarbe verhält sich exponentiell zur integrierten Nebeldichte, d.h.:
\($$F\big(\mathbf{v}(t)\big) = \mathrm e^{-\int_\mathbf{C} f(\mathbf{v}) \, \mathrm d \mathbf{v}}$$\)Ja und das ist es eigentlich. Die kniffligste Sache an der ganzen Geschichte ist eigentlich die korrekte Berechnung von \($\mathbf o$\), \($\mathbf d$\) und \($t_0$\). Eventuell musst du \($\mathbf o$\) und \($\mathbf d$\) vertauschen, s.d. die Strecke \($\mathbf o$\) bis \($\mathbf v(t_0)$\) immer im konstanten Dichtebereich verläuft, und die Strecke \($\mathbf v(t_0)$\) bis \($\mathbf o$\) + \($\mathbf d$\) immer im exponentiellen (erkennbar via einem einfachen Ebenentest mit der \($z_0$\)-Ebene). Das ganze in HLSL zu gießen sollte nun eigentlich möglich sein (siehe auch Folie 17).

Ich hoffe, ich habe nicht all zu viele Fehler eingebaut; ich bin dankbar für jede Korrektur. ;)

Wow. Das muss jetzt erstmal durchgearbeitet werden ;)

Mir ist auch gerade aufgefallen, dass die (von dir auch als Vorgabe angegebene) Modellierung der Nebeldichte als Exponentialverteilung eigentlich blöd ist: Da ja der Grenzwert \($\mathrm e^{-x}$\) für \($x \to \infty$\) sich ja 0 nur asymptotisch annähert, wird man auf jeden Fall eine sichtbare Grenzschicht haben (d.h. z.B. auf der Oberseite der obigen Bounding Box ist die Dichte 0.1, und weil die Bounding Box dann ja endet, und somit dort auch nichts mehr rasterisiert wird, fällt die Dichte außerhalb der Bounding Box abrupt auf 0).

Aber der Wenzel hat's ja auch so modelliert. (Schon wieder: Warum?)

Da kann man sich also stattdessen auch eine Übergangsfunktion mittels trigonometrischer Funktionen basteln (gut integrierbar), oder man nimmt ein Polynom (auch gut integrierbar, siehe z.B. hier). ;)

Edit: Ninja'd. Bei Wenzel's Methode hat man auf jedenfall keine sichtbare Grenzschicht. Das einzig blöde an seinem Algorithmus war eben, dass man die Höhe des ganzen schlecht so verändern konnte wie wir es wollten.
Vielleicht bleib ich auch einfach dabei und sag es geht halt nicht anders :P

-------

Ich bin mir noch nicht sicher was genau o ist. Könntest du das nochmal genauer ausführen? Muss ich das wechseln von der Kamera-Position zur Oberfläche per-Pixel machen?
Muss ich diese Oberfläche sowie t_0 durch Raycasting rausfinden?
(So mache ich es im Moment, es sieht halt nicht besonders richtig aus)

Ist d einfach die Worldspace-Position meiner Pixel?
Ist d Index 3 die Z-Koordinate des Vektors d? (Bei mir ist Y oben) Oder was bedeutet der Index?

Was genau ist b? Die Dichte?

Integralrechnung machen wir leider jetzt erst im Unterricht, bin ja auch erst in der 12. Klasse. Deswegen brauch ich noch ein wenig Hilfe beim Verstehen, wobei mir die ganzen etwas schwammig definierten Variablen mehr Probleme breiten.

Deine unterste Formel hab ich so übersetzt: Brauche ich mein ausgerechnetes "f" überhaupt noch irgendwo?

Tut mir leid, dass ich den Beitrag so sehr zusammengewürfelt ist. Sollte langsam ins Bett ;)

Und nur noch ganz kurz, bevor ich auch ins Bett gehe: Ich würde erst einmal die Annahme aufweichen, dass man nur ein Nebelvolumen hat, denn ich würde es in zwei unterteilen. Eben einem Nebelvolumen mit konstanter Dichte, und einem Nebelvolumen mit exponentiell verteilter Dichte.

Am Ende rendert man dann beide Volumen (nach Betrachterentfernung sortiert). (Das ist ein einfacher Painter's-Algorithm am Ende, d.h. man beschränkt sich auf disjunkte, konvexe Nebelvolumen (wenn nur ein Volumen, ist die Konvexität egal), was aber in der Praxis kaum Einschränkungen mit sich bringt. Und falls CodingCat jetzt mit OIT kommt: Nein, dass geht auch nicht, weil man Liniensegmente statt einzelner Pixel verfolgen müsste. Das ist alles nur eine Seitenbemerkung, warum schreibe ich das überhaupt hier? Egal, löschen werde ich das jetzt nicht.)

Das Integral für das Volumen mit konstanter Nebeldichte gibt ja bereits im Wenzel aufgelöst, das Integral für die exponentiell verteilte Nebeldichte kann ich morgen noch mal herleiten, sollte aber sehr einfach werden. Mit der Unterteilung in zwei Volumen spart man sich die explizite Bestimmung von \($t_0$\). (Ansonsten müsstest du einen Zusatz-Pass rendern, in dem du nur die \($z_0$\)-Trennebene rausrenderst.)

Zur Berechnung von \($\mathbf o$\) und \($\mathbf d$\): Das ist auch alles im Wenzel beschrieben (Folie 21 ff.). Die Punkte \($\mathbf o$\) und \($\mathbf o$\) + \($\mathbf d$\) sind einfach die Endpunkte des Liniensegments, das durch das Nebelvolumen geht. Alles in Weltkoordinaten! Dabei kann es vorkommen, dass \($\mathbf o$\) oder \($\mathbf o$\) + \($\mathbf d$\) jeweils unabhängig voneinander auf dem Hüllkörper des Nebelvolumens liegen, oder innerhalb des Volumens. Kurzversion:

1. Falls Kameraposition im Nebelvolumen:
   • Setze \($\mathbf o$\) = Kameraposition.
   • Rendere die z-Werte der Back-Faces des Hüllkörpers vom Nebelvolumen in einen Buffer. Zusätlich hast du den z-Buffer, der die Tiefenwerte der übrigen Objekte in der Szene enthält. Lese an der entsprechenden Pixelposition beide Buffer aus, bilde das Minimum, dies ist der z-Wert von \($\mathbf o$\) + \($\mathbf d$\). Rekonstruiere die Weltposition von \($\mathbf o$\) + \($\mathbf d$\), wie es bei Deferred Shading üblich ist.
2. Falls Kameraposition nicht im Nebelvolumen:
   • Rendere Front-Faces des Hüllkörpers vom Nebelvolumen. Lese an der entsprechenden Pixelposition den Buffer aus, dies ist der z-Wert von \($\mathbf d$\). Rekonstruiere die Weltposition von \($\mathbf o$\), wie es bei Deferred Shading üblich ist.
   • Siehe 1. zur Berechnung von \($\mathbf o$\) + \($\mathbf d$\).

Damit hast du \($\mathbf o$\) und \($\mathbf o$\) + \($\mathbf d$\) berechnet. Wie schon gesagt, die Berechnung von \($t_0$\) erübrigt sich, wenn man das Volumen in zwei Volumen aufteilt. Beide Volumen werden gerendet (back-to-front) und geblendet.

Andre hat geschrieben:Ist d Index 3 die Z-Koordinate des Vektors d? (Bei mir ist Y oben) Oder was bedeutet der Index?

Ja, genau das ist sie.

Andre hat geschrieben:Was genau ist b? Die Dichte?

Das müsstest du den Wenzel fragen. \($b$\) ist einfach ein Proportionalitätsfaktor von der Dichte. Ähnlich \($c$\), nur dass \($c$\) im Exponent auftaucht. Darüber würde ich mir keinen Kopf machen, sondern das sind einfach benutzerdefinierte Parameter, damit es am Ende gut aussieht.

Andre hat geschrieben:Bei Wenzel's Methode hat man auf jedenfall keine sichtbare Grenzschicht.

Naja, vielleicht für deinen jeweiligen Fall nicht sichtbar. Ich muss nur die Höhe der z.B. Bounding Box kleiner machen (anschauungshalber auf 1 Zentimeter), und du wirst eine Grenzschicht sehen. Egal wie hoch du nun die Bounding Box machst, das prinzipielle Problem bleibt bestehen (dass der Term nur asymptotisch gegen Null geht), daher bräuchte man eine unendlich Hohe Bounding Box. In der Praxis kann man sich mit einer genügend hohen Box zufrieden geben, da die Differenz zur 0 eben verschwindend gering wird. Aber saubere Lösungen sehen meiner Meinung nach anders aus. Vor allem ist es nicht sehr benutzerfreundlich. (Der tiefere Grund könnte die physikalische Modellierung von Partikeldiffusion in unendlich langen Zylindern sein.)

Ich sollte vielleicht noch sagen, dass ich das nie implementiert habe, geschweige denn zuvor den Wenzel-Artikel gelesen habe. Aber mittlerweile bin ich im akademischen Paper-Lesen doch halbwegs geübt.

Herleitung des Integrals für die exponentielle Verteilung morgen, sollte aber einfach sein.

eXile hat geschrieben:Und falls CodingCat jetzt mit OIT kommt: Nein, dass geht auch nicht, weil man Liniensegmente statt einzelner Pixel verfolgen müsste.

Bitte? Mal davon abgesehen, dass es in diesem Fall absolut keinen Sinn ergibt, wäre doch schon der Aufwand sämtlicher OIT-Varianten um ein Vielfaches höher, als einfach die zwei Volumina zu sortieren. ;-)

CodingCat hat geschrieben:Bitte? Mal davon abgesehen, dass es in diesem Fall absolut keinen Sinn ergibt, wäre doch schon der Aufwand sämtlicher OIT-Varianten um ein Vielfaches höher, als einfach die zwei Volumina zu sortieren. ;-)

Richtig, richtig. ;) Ich wollte nur sagen, dass bei normaler Transparenz dann die gleichen Einschränkungen wie bei einem Painter's Algorithm gelten (disjunkte und konvexe Objekte), d.h. man kann so etwas nicht einfach back-to-front rendern:



Um das zu umgehen, muss man halt das gleiche machen, wie bei einer BSP-Tree-Generierung: So lange das Nebelvolumen unterteilen, bis man disjunkte, konvexe Volumina herauskriegt. Das ist aber eher ein Spezialfall und kommt erst, wenn der Rest läuft.

Ich wollte noch die Herleitung für die Wenzel-Formel geben:
\($$\begin{align}
\int_0^1 b \cdot \mathrm e^{-c \cdot z(t)} \cdot \|\mathbf{d}\| \, \mathrm dt
&= b \cdot \|\mathbf{d}\| \cdot \int_0^1 \mathrm e^{-c \cdot z(t)} \, \mathrm dt \\
&= b \cdot \|\mathbf{d}\| \cdot \Big[ \frac{1}{-c \cdot z(t)} \cdot \mathrm e^{-c \cdot z(t)} \Big]_0^1 \\
&= b \cdot \|\mathbf{d}\| \cdot \frac{1}{-c \cdot \mathbf{d}_3} \cdot \Big( \mathrm e^{-c \cdot z(1)} - \mathrm e^{-c \cdot z(0)} \Big) \\
&= \frac{b \cdot \|\mathbf{d}\|}{-c \cdot \mathbf{d}_3} \cdot \Big( \mathrm e^{-c \cdot (\mathbf{o} + \mathbf{d})_3} - \mathrm e^{-c \cdot \mathbf{o}_3}\Big) \\
&= \frac{b \cdot \|\mathbf{d}\|}{-c \cdot \mathbf{d}_3} \cdot \mathrm e^{-c \cdot \mathbf{o}_3} \cdot \Big( \mathrm e^{-c \cdot \mathbf{d}_3} - 1\Big) \\
&= b \cdot \mathrm e^{-c \cdot \mathbf{o}_3} \cdot \|\mathbf{d}\| \cdot \frac{1 - \mathrm e^{-c \cdot \mathbf{d}_3}}{c \cdot \mathbf{d}_3} \\
&= b \cdot \mathrm e^{-c \cdot \mathbf{o}_3} \cdot \sqrt{d_1^2 + d_2^2 + d_3^2}\cdot \frac{1 - \mathrm e^{-c \cdot \mathbf{d}_3}}{c \cdot \mathbf{d}_3}
\end{align}$$\)Wenn man das nun mit Folie 16 vergleicht, sieht man, dass die Formeln übereinstimmen. ;) Das war also die Herleitung für das Volumen mit exponentiell verteilter Nebeldichte, nun die „Herleitung“ für die konstante Dichte:
\($$\displaystyle \int_0^1 b \cdot \|\mathbf{d}\| \, \mathrm dt
= \displaystyle b \cdot \|\mathbf{d}\| = b \cdot \sqrt{d_1^2 + d_2^2 + d_3^2}$$\)So und das sind eigentlich die Formeln. Wenn es irgendwie weiterhilft: Ich habe mal die Variablen der Wenzel-Formel mit den HLSL-Variablennamen in Verbindung gebracht:



Das abschließende exp mit dem Minus vor dem cGlobalDensity im HLSL-Code kommt aus der letzten Formel von meinem ersten Post. Die if-Abfrage ist einfach nur eine Vermeidung einer Division durch Null. Bei Fragen, frag! ;)

Um das zu umgehen, muss man halt das gleiche machen, wie bei einer BSP-Tree-Generierung: So lange das Nebelvolumen unterteilen, bis man disjunkte, konvexe Volumina herauskriegt. Das ist aber eher ein Spezialfall und kommt erst, wenn der Rest läuft.

Naja, das Grundprinzip von OIT mittels verketteter Listen ließe sich für wirklich komplexe Volumina durchaus anpassen. Nachdem du alle Eintritts- und Austrittsoffsets des Sichtstrahls in Listen gespeichert und sortiert hast, kannst du diese natürlich auch linear durchgehen, um jeweils Absorption und Streuung zu akkumulieren. Insbesondere für komplexe (eventuell überlappende?) volumetrische Geometrie mit unterschiedlichen Dichteverteilungen könnte dies mit entsprechend erweiterten Listeneinträgen durchaus interessant sein. Allerdings wäre die Implementierung wohl gerade für überlappende Dichtezonen relativ unschön, und bezüglich Effizienz allenfalls für dynamische Geometrie mit vergleichsweise teurer dynamischer konvexer Partitionierung interessant.

Sehe ich auch so. Mit fällt vor allem aber kein praktisch relevanter Effekt ein, bei dem man so etwas implementieren müsste, aber wer weiß was sich Artists alles einfallen lassen …

So, ich denke ich muss den Nebel erstmal für ein paar Tage verschieben. Nächste Woche werd ich mich aber wieder in deine Formeln stürzen können!
Vielen Dank schonmal für die bisherige Hilfe ;)

Und denke an das alte Internet-Motto: Pics or it didn't happen! :-)

Ist das nicht eine alte Q3 Technik?

Ich glaube, das benutzte GL_EXT_fog_coord, damit kann man pro Vertex eine Nebeltiefe anbieten. Ist halt nur pro Vertex, und ist natürlich unflexibler als dieses Verfahren hier auf programmierbarer Hardware, aber ja, im Grunde kann man es schon vergleichen. ;)

Eine andere Quelle meinte aber wiederum, dass alles ganz anders wäre:

http://www.gamedev.net/topic/287308-quake-3-volumetric-fog/ hat geschrieben:Quake3 makes one major assumption that eases the application of volumetric fog: you can enter (look into) the fog only from one side (brushside / "fogplane"). At runtime you determine wether the camera is below the fogplane (i.e. inside the fog) or above the fogplane and use the appropriate math for each case. The fog-application can be done like doing a simple form of texture projection. That means, use "normalized" fog coordinates as texture coordinates in order to index a special fog-texture which contains the fog-density as alpha-value. Then use standard alpha-blending in order to apply the fog to the fogged parts of the scene.

At runtime you determine wether the camera is below the fogplane (i.e. inside the fog) or above the fogplane and use the appropriate math for each case.

Müsste man das nicht sehen? Man kennt das doch noch von älteren Spielen in denen man Schwimmen konnte. Wenn man den Kopf nur so halb aus dem Wasser strecke sah man den Nebel immer wieder aufploppen und auch die "Oberwelt" einnebeln, oder aber man konnte unterhalb der Wasserlinie besser sehen, da der Nebel noch nicht eingeblendet war.

Bei Quake3 gibt es das soweit ich weiß nicht. Spiele auf jeden Fall viel QuakeLive zur Zeit, und dort sind die Übergänge jedenfalls butterweich.
Kann mich nicht erinnern, dass das bei Q3 anders gewesen wäre.

Auch mal ein kleines Update hier: Wir sind dazu übergegangen den Crytek-Nebel nun doch zu verwenden. Die Entscheidung haben wir gefällt, nachdem wir das Design des Nebels im Editor umgedacht haben. Vorher waren wir zu sehr auf das Verhalten der UE3 fixiert, indem es das teil als Actor in der Map gibt. Das fanden wir dann allerdings etwas unnötig, da man das Teil sonst ständig suchen muss, und haben die Einstellungen dann in die Map-Settings verfrachtet.

Ganz umsonst waren deine Mühen allerdings nicht: Du hast mich sicher durch unsere letzte Mathe-Klausur gebracht :D