ZFX + Developia

Bisher läuft die Lichtberechnung echt flott, als Minimum-Gerät das ich unterstützen möchte, hab ich mich auf die GTX 1050 bzw. M1 GPU festgelegt. Im Moment läuft es auf der M1 mit circa 5-6ms, ist also noch Luft nach oben für teure Dinge wie Spiegelungen etc.

Um das selbst auf dem letzten Dreckstoaster zum laufen zu kriegen, würde ich dann tatsächlich noch einen Upscaler hinzufügen. Viel Performance geht im Moment für die Primary Rays für den Gbuffer drauf. Der Gbuffer braucht auf der M1 2-3ms während die Lichtberechnung rund 3ms beansprucht.

Den Gbuffer hochskalieren ist es glaub ich nicht wert, das wird sehr wahrscheinlicher richtig scheiße aussehen, durch die feine Geometrie stark flackern und mein TAA kaputt machen.
Lediglich die Lichtberechnung hochskalieren würde sich da glaub schon mehr anbieten. Da bin ich mir aber noch nicht sicher, wie genau ich das mache, evtl. einen einfachen bilateralen Upscaler mit Tiefen- und Normalenprüfung oder so.

Hab mal eine MagicaVoxel Szene reingeschmissen und dann jeden Voxel mit einer einfachen Sand Simulation ausgestattet:

Bei großen glatten Flächen wirkt die Beleuchtung irgendwie falsch. Aber wenn man das vermeidet ist es eine hübsche Sache :)

Ja, die Ambient Occlusion hat immer noch Eigenschattierung. Aber nuja, kann man ja auch zum Stil erklären, so wie als ob die Materie ne innere Streuung hätte, so wie Wachs.

Jup das mit der Selbst-Okklusion ist echt ne nervige Sache da die richtigen Parameter zu finden. Im Moment muss ich je nach Szene die Cone Einstellungen manuell nachjustieren, das geht auf Dauer natürlich gar nicht.

Hier nochmal die Schrittgröße und Maximal Distanz der Cones angepasst:

Hab eine Schaltungs-Simulation eingebaut:

Hier ein kleiner Explosions Test:

Wirkt auf mich mehr wie Verwitterung.
Vermutlich wird nur ein Kreis auf der Oberfläche "rausgesprengt", was etwas seltsam wirkt.
Genauso seltsam finde ich es ehrlich gesagt, dass das Material danach einfach starr runter rieselt und wieder eine feste Wand bildet.

Wenn es wie Sand wäre, würde es auch zur Seite fließen, wenn es starrer wäre, würde es bleiben wo es ist und es würde ein Krater zurückbleiben.

Die Velocity muss ich nochmal anpassen, dass ist ein kleiner Test um vor allem die Performance bei vielen sich ändernden Zellen zu demonstrieren. Gerade bei der vertikalen Velocity fällt es auf, dass sie gecapped ist, daher sieht es so aus, als würden Zellen einfach starr runterfallen, anstatt immer weiter zu beschleunigen.

Lord Delvin hat geschrieben: ↑30.04.2022, 12:33 Wenn es wie Sand wäre, würde es auch zur Seite fließen, wenn es starrer wäre, würde es bleiben wo es ist und es würde ein Krater zurückbleiben.

Jup, dem Material hier hab ich lediglich die Verwertung von Velocity eingebaut. Dem Material hätte man sicher auch noch gut weitere Falling Sand Eigenschaften hinzufügen können. Wäre alles Sand, dann wäre das gesamte Gebäude halt direkt in sich zusammengebrochen^^

In gewissen Grenzen. Wenn man Sand machen will, würde ich eine Regel in der Art von "Wenn neben mir ein leeres Feld ist und das darunter auch leer ist, dann fließe ich in das leere Nachbarfeld" einführen. Das Problem ist natürlich, dass das Update dann erheblich teurer ist, als wenn man nur nach unten prüft und so eine Art Gravitation simuliert.

Wenn ich mir das gerade richtig vorstelle ist es mit ein Feld nach unten und zwei Felder nach unten für sowas wie Sand gut. Für eine Flüssigkeit, die eine Ebene bilden kann braucht man vermutlich eine Art Druckpropagation.

Keine Ahnung ob dich so Gedanken überhaupt reizen :)

Wie der Titel des Projekts schon sagt, ist das hier eine Falling Sand Engine. Sand war bereits eine der ersten Materialien, die implementiert wurden, und die Regeln dafür sind wirklich einfach:
- Wenn Zelle direkt/diagonal darunter eine geringere Dichte hat als die eigene, dann tausche dich mit der Zelle

Hier ein älteres Video, als die Engine noch 2D war (mit Gravitation, Velocity und Sand-Verhalten):


Interessant wird es, sobald ich Spielern erlauben kann, eigene Materialien zu definieren. Spieler haben hierbei Zugriff auf die direkten Nachbarn einer Zelle, und haben außerdem die Möglichkeit, 8-bit an beliebigen Daten in der Zelle zu speichern (nützlich für z.B. deinen Fall, um Druck zu modellieren).

Die Schnittstelle, um eigene Materialien zu definieren, wird nicht über eine klassische Programmier-Schnittstelle gelöst (zumindest vorerst nicht), sondern über ein modulares Welten System.

Hierbei können Spieler 32^3 große Sub-Welten erstellen. Diese Sub-Welten haben "Input Pins" an den Außenflächen der Welt, worüber die Informationen der Nachbaren abgefragt werden können, und diese als z.B. Stromsignal in die Welt übertragen werden. Außerdem können Output Pins hinzugefügt werden, z.B. um die eigene Welt dann entsprechend der Inputs zu bewegen, zu löschen, ein Stromsignal auszugeben, oder ähnliches. Eine Sub-Welt ist zwar 32^3 Voxel groß, belegt allerdings nur 1 Voxel/Zelle in einer normalen Welt. Sub-Welten können weitere Sub-Welten in sich beinhalten und verwenden (daher das Wort "modular"). Eine Sub-Welt kann z.B. auch eine logische Schaltung (AND, XOR etc.) sein, oder eine Schaltung beinhalten, welche auf weiteren Sub-Welt Schaltungen basiert.

Nochmal das BRDF überarbeitet und ein bisschen Post-Processing hinzugefügt:

Stochastischen Tiefen-Effekt hinzugefügt:

Wirklich sehr cooles Projekt!!!

Kannst du etwas zum Stochastischen Tiefen-Effekt sagen? Das klingt sehr spannend und ich finde nichts brauchbares dazu. :)

Noch einen einfachen exponentiellen Nebel eingebaut und dem Himmel eine gestreute Sonne verpasst. Der stochastische Tiefeneffekt ist temporal leider noch nicht ganz stabil, sieht man vor allem an Stellen, wo die Geometrie sehr fein ist. Das liegt daran, das ich den Tiefeneffekt mit in mein TAA gebe, allerdings ist das white Noise das ich verwende temporal zu instabil und bricht die Akkumulation. Anstatt white Noise könnte ich vielleicht mal blue noise oder stratifiziertes white noise probieren.

Peng hat geschrieben: ↑08.05.2022, 14:41 Wirklich sehr cooles Projekt!!!

Kannst du etwas zum Stochastischen Tiefen-Effekt sagen? Das klingt sehr spannend und ich finde nichts brauchbares dazu. :)

Danke dir!

Prinzipiell ist die Idee bei meinem DoF, abhängig der Distanz eines Pixels zur Kamera, Nachbar Pixel in einem Kreismuster auszulesen. Damit erhältst du eine einfaches Blur für die Tiefe, allerdings nur sehr grob. Um das Blur zu unterstützen verwende ich zusätzlich noch lineare Textur Filterung und Mip Level 0-2, je nach gewünschter Intensität des Blur. Bis zu diesem Punkt, hat man zwar ein Blur für die Tiefe, bekommt aber viele Artifakte. Es würde helfen, die Anzahl der Nachbar Pixel die man ausliest zu erhöhen, das ist aber schlecht skalierbar und wird extrem langsam.

Für diesen Fall ist nun stochastisches Sampling nützlich, da man hiermit über Zeit Nachbar Pixel über eine relativ große Distanz akkumulieren kann. Anstatt in einem fixen Kreismuster auszulesen, werden die Pixel nun leicht "gejittert". Das Depth of Field wird erst horizontal, dann vertikal (mit einem Ping-Pong Prinzip) ausgeführt, und anschließend in ein TAA eingespeist um das Noise vom jittern temporal zu akkumulieren.

Es gibt sicherlich bessere Methoden, meine ist allerdings recht einfach zu implementieren und läuft vor allem sehr schnell.

Hm, ich mag Tiefenunschärfe. Normalerweise ist die sackteuer, Du hast sie über viele Frames verteilt, klingt gut. Die Bilder sehen jedenfalls fett aus, das TAA bringt halt die üblichen Probleme mit sich, aber die sieht man auf Bildern halt nicht :)

Schrompf hat geschrieben: ↑08.05.2022, 20:03 Hm, ich mag Tiefenunschärfe. Normalerweise ist die sackteuer, Du hast sie über viele Frames verteilt, klingt gut. Die Bilder sehen jedenfalls fett aus, das TAA bringt halt die üblichen Probleme mit sich, aber die sieht man auf Bildern halt nicht :)

Nice, danke dass es so gut ankommt^^

Absolut, TAA richtig hinzubekommen ist echt schmerzhaft. Mein TAA funktioniert gerade so gut genug um Noise zu schlucken und eine grobe Kantenglättung zu produzieren. Ich hau am Ende noch FXAA drüber, weil mein TAA in ein paar Fällen leider immer noch kaputt geht.

Noch ein kleines Update bzw. ein Versuch, prozedurale Noise beim tracen der Sub-Voxel anzuwenden. Beim heutigen Erstellen von Texturen wird viel mit Noise gearbeitet. Da hab ich mich gefragt, ob ich das evtl. auch bei mir machen könnte. Ein netter Nebeneffekt hierbei ist, dass es weniger auffällt, dass das ganze nur Sub-Voxel sind, da sich die Noise über einzelne Sub-Voxel Volumen hinweg verteilt. Evtl. kann man das ganze noch ausweiten, um z.B. auch die Farben der einzelnen Voxel zu verändern.

Die letzten beiden Screenshots sehen verflucht geil aus. Der Detailgrad ist auch für das, was man an Voxeldaten so kennt, verflucht hoch. Gefällt mir.

Danke! Den Detailgrad kann ich eventuell noch auf das doppelte hoch bringen. Momentan läuft die Engine auf höchsten Grafik-Settings auf einer GTX 1050 mit circa 110 FPS. An dieser Hardware orientiere ich mich und will möglichst nicht unter 90 FPS fallen.

Ich bin schon echt gespannt was ein Designer mit der Engine rausholen könnte. Das Modell für die Szene hab ich mir aus MagicaVoxel geklaut, weil ich fürs modellieren echt ungeeignet bin.
Falls jemand eine MagicaVoxel Szene hat die er testen möchte, unterstütze Szenen Größen sind 64^3, 128^3 und 256^3, und die Datei muss im xraw-Format sein.

Sehr hübsch :)

thx!

Noch GPU beschleunigte Partikel eingebaut:

Die sehen knuffig aus

Ja sind schön fluffig, fast schon wie Zuckerwatte^^

"Das Fenster kotzt!" :D
Ne, macht sich sehr gut.

Hab an dem modularen Schaltungssystem angefangen. Dieses System wird es ermöglichen, über 32^3 große "Modul Welten" Verhalten visuell zu programmieren.

Ein Modul ist wie folgt aufgebaut:
- 26 Input Pins, um aus der darüber liegenden Welt Informationen zu erhalten
- 26 Output Pins, um in die darüber liegende Welt Informationen auszugeben

Wichtige Eigenschaften eines Moduls:
- Ein Modul belegt lediglich 1 Block an Platz, wenn es in einer Welt platziert wird
- Ein Modul kann weitere Module importieren und verwenden

Input Pins konvertieren Informationen in ein Stromsignal um und können vom folgenden Typ sein:
- Power Pin: Gibt anliegende Power des Nachbarn als ein digitales Signal (1 oder 0) hinein
- Dichte Pin: Wenn die Dichte des Nachbarn geringer als die Dichte des Moduls ist, dann wird 1 als Signal übertragen

Output Pins können vom folgenden Typ sein:
- Power Pin: Gibt die eingehende Power in die Welt darüber aus
- Move Pin: Wenn Power drauf ist, dann bewegt sich das Modul in der Welt darüber, entsprechend der Position des Output Pins

Hier ein Beispiel eines Moduls, welches das Verhalten von Sand modelliert. Sand kann vertikal, aber auch diagonal nach unten fallen. In den folgenden Bildern sieht man, wie die Input Pins (in diesem Fall Dichte Sensoren) mit den entsprechenden Output Pins verbunden sind. Die unteren 9 Input und Output Pins werden verwendet.

Als Beispiel, wenn der Block unter dem Modul eine geringere Dichte, als das Modul hat, dann bewegt sich das Modul in der Welt um 1 nach unten. Das gleiche Prinzip findet genauso bei den anderen Pins statt.

Nach rund 2 Wochen des Knobelns hab ich nun endlich einen wichtigen Part implementiert: Rotationen!!1
Das Problem sah erst einfach aus, hat sich dann aber als tatsächlich knifflig rausgestellt. Pro Voxel möchte ich möglichst effizient alle möglichen Rotationen eines Würfels speichern. Ich habe irgendwann bemerkt, dass es bei einem Würfel mit 90° Drehungen nur 24 verschiedene Rotations Möglichkeiten gibt.

Meine Lösung ist nun ein Rotations-System auf allen Axen, die Rotationen selbst belegen lediglich 5-bit pro Voxel (3bit für die Face Rotation, 2bit für "Selbstrotation").



Sowohl design technisch, als auch logisch sind die Rotationen sehr nützlich.
Für die Schaltungen, gibt es nun sehr viel mehr Möglichkeiten, Zeug zu automatisieren.



Und hier die Schaltung des bunten Würfels:
- Wenn von oben Strom reinkommt, dann wird sich einmal um die eigene Achse gedreht (grüner Output Pin in der Mitte)
- Wenn von oben Strom reinkommt, dann wird horizontal Strom ausgegeben (grüner Output Pin außen)

Volumetrisches Licht eingebaut:


Das Sonnenlicht ebenfalls volumetrisch zu machen wäre sicher auch nett.
Ich verwende Cone tracing für meine Schatten und müsste daher beim ray marchen durch den Raum jedesmal einen Shadow Cone schießen, was wahrscheinlich recht teuer wird. Normalerweise verwendet man für volumetrisches Licht ja eine Shadow map, was sehr performant ist, dafür das Ergebnis aber ziemlich fad aussieht.

Ein Vorteil wäre allerdings, dass das volumetrische Sonnenlicht mit Cone tracing dann genauso smooth wäre wie die Schatten selbst mit Penumbra etc.

Für das volumetrische Licht verwende ich gerade sowie schon Cone tracing, allerdings bei weitem nicht so teuer, wie einen Shadow Cone zu schießen, da Shadow Cones über eine große Distanz und mit kleinen Schritten gemarched werden müssen. Bei meinem Lichtvolumen kann ich größere Schritte machen und auch mit deutlich höheren Mip Stufen arbeiten, da das Licht sehr diffus ist.

Hier ein Test wie volumetrisches Sonnenlicht aussehen würde:


Aus irgendeinem Grund geht das volumetrische Licht an den Volumenkanten kaputt, muss ich mir mal genauer anschauen^^

sieht für mich super aus. was genau geht kaputt? ich kann es nicht erkennen.