ZFX + Developia

Zudomon hat geschrieben:Wie bei der Vorlage auch... allerdings hab ich noch kein Specular drin.

12.png

Für noch kein Specular sieht das aber stark reflektierend aus :)

Krishty hat geschrieben:

Zudomon hat geschrieben:Wie bei der Vorlage auch... allerdings hab ich noch kein Specular drin.

12.png

Für noch kein Specular sieht das aber stark reflektierend aus :)

Müsste das Messing-Dingen da nicht sonst auch noch weiß reflektieren?

Weiß nicht; ist *dein* Renderer :)

Messing ist doch gelblich, weil es Blau weniger reflektiert als andere Wellenlängen, oder? Ähnlich Kupfer in diesem Diagramm:



Das weiße Licht sollte also hell gelblich sein. Bzw. warum in einen Raytracer über „Specular“ einbauen und nicht direkt Physically-Based Materials?

Du hast Recht! War mein Denkfehler. Bei Metall hat man ja gar keine weißen Lichtreflexe wenn das Material eingefärbt ist.
Es dauert bei mir aber auch noch, bis ich das alles wirklich Begriffen habe.

Bei einem Pathtracer kannst du tatsächlich relativ einfach Specular erzeugen: Du erzeugst sowohl einen perfekt reflektierten strahl als auch einen perfekt diffusen strahl und interpolierst dann die beiden mit einem materialwert. Damit hast du zwischen diffus, glossy, unscharfer und perfekter reflektion alles dabei

MasterQ32 hat geschrieben:Bei einem Pathtracer kannst du tatsächlich relativ einfach Specular erzeugen: Du erzeugst sowohl einen perfekt reflektierten strahl als auch einen perfekt diffusen strahl und interpolierst dann die beiden mit einem materialwert. Damit hast du zwischen diffus, glossy, unscharfer und perfekter reflektion alles dabei

Das hab ich sogar schon genauso drin. Allerdings bin ich mir recht unschlüssig, wie das genau aussehen müsste... denn bei normalen Diffusen Materialien da gibt es doch auch diese Specularreflexe... also soweit ich das bisher verstehe, hat man bei einem solchen Material alles Diffuse, aber in Reflektionsrichtung wird dann viel Licht "gespiegelt"... allerdings wird das dann nicht mit der Textur eingefärbt... ach mist. Ich bräuchte echt mal einen Aufbaukurs.

Momentan grüble ich darüber, ob man mit Reprojection ein bisschen weiter kommt... also bei dem letzten Bild mit den Kugeln kann man sich ja schon schön interaktiv bewegen, bei einer Moderaten Auflösung von 500x400. Allerdings stört halt, dass sich dann das Bild immer so aufbaut.

Also das Reprojektion funktioniert nicht wirklich gut, weil die Positionen im nächsten Frame sich leicht von den im vorherigen unterscheiden und dadurch der Content verschwimmt... außerdem müsste man vielleicht dann noch auf Normalen usw. achten, hatte das nur mal mit Positionen getestet.

Hier hab ich mal ein Video, damit man sich ein Bild vom aktuellen Stand machen kann, ohne Reprojektion. Aber ich brauche Ideen, um das noch performanter zu bekommen. Wobei ich auch eigentlich schon recht zufrieden sein könnte, als ich mit dem Projekt angefangen hatte, konnte ich nen 150 Poly Hasen anzeigen lassen.

[youtube]9ECyYEmO9yY[/youtube]

Ich hab irgendwie kein Plan, wie ich weiter machen soll. Wenn man einmal Blut geleckt hat... :P :lol:

Ich finde die Schnellansicht mit den harten Schatten ehrlich gesagt schon ziemlich cool.

Ich finde es spannend Dein Projekt zu verfolgen Zudomon!
Ist Dein konkretes Ziel die RayTracing Technik in irgendeiner Form Echtzeit tauglich hinzubekommen, um sie dann in einem weiteren Schritt für Dein Stone Quest Projekt einzusetzen?

Mich würde ganz grundsätzlich interessieren, wieso sich diese RayTracing Algorithmen nicht mittels einer GPU beschleunigt lösen lassen.
Ist das ein Problem der Komplexität? Mit anderen Berechnungen klappt das ja auch.

Mal abgesehen von Reflexionen und Kaustiken, müsste doch die reine Schattenberechnung per RayTracing heute in Echzeit umsetzbar sein...?

Gruss starcow

Mich würde ganz grundsätzlich interessieren, wieso sich diese RayTracing Algorithmen nicht mittels einer GPU beschleunigt lösen lassen.

Raytracing eignet sich hervorragendst für GPU-Implementierung, besser noch sogar als Rasterization. Ich denke auch, dass Zudo das ganze eh in einem Pixel Shader oder Computer Shader untergebracht hat.

MasterQ32 hat geschrieben:

Mich würde ganz grundsätzlich interessieren, wieso sich diese RayTracing Algorithmen nicht mittels einer GPU beschleunigt lösen lassen.

Raytracing eignet sich hervorragendst für GPU-Implementierung, besser noch sogar als Rasterization. Ich denke auch, dass Zudo das ganze eh in einem Pixel Shader oder Computer Shader untergebracht hat.

Naja; das primäre Tracing lässt sich ganz gut lösen. Die GPU ist aber bei Speicherzugriffen auf Lokalität angewiesen (am besten jeder Thread einen Pixel versetzt, so wie bei Texturen/Back Buffers), und spätestens bei Reflexionen kann man das vergessen weil die Strahlen zu weit streuen. Da gibt es dann auch wieder Methoden zur Entwirrung, aber spätestens dann ist es Entwicklung auf sehr hohem Niveau.

Zudomon hat geschrieben:

MasterQ32 hat geschrieben:Bei einem Pathtracer kannst du tatsächlich relativ einfach Specular erzeugen: Du erzeugst sowohl einen perfekt reflektierten strahl als auch einen perfekt diffusen strahl und interpolierst dann die beiden mit einem materialwert. Damit hast du zwischen diffus, glossy, unscharfer und perfekter reflektion alles dabei

Das hab ich sogar schon genauso drin. Allerdings bin ich mir recht unschlüssig, wie das genau aussehen müsste... denn bei normalen Diffusen Materialien da gibt es doch auch diese Specularreflexe... also soweit ich das bisher verstehe, hat man bei einem solchen Material alles Diffuse, aber in Reflektionsrichtung wird dann viel Licht "gespiegelt"... allerdings wird das dann nicht mit der Textur eingefärbt... ach mist. Ich bräuchte echt mal einen Aufbaukurs.

Wie viel sagt dir das Zauberwort BRDF denn? Das ist eigentlich ein sehr fundamentales Konzept mit dem man genau dieses Problem beschreiben und lösen kann. Ist dann auch kein dreckiger Hack wie das angesprochenen '´zwischen perfekt diffus und perfekt specular interpolieren', aber nicht notwendigerweise komplizierter.

Also wo das Projekt letztendlich hin geht weiß ich nicht.
Wenn man da wirklich noch den ein oder anderen Trick einsetzen kann, damit es performanter wird, wäre schon interessant. Aber Echtzeit ist wohl wirklich erstmal nicht möglich. Mich reizt es ja eben so sehr, weil man die Probleme wie Reflektion/Refraktion/Indirektes Licht/Schatten usw. auf Pixelebene löst.
Klar wäre es geil, SQ mal damit gerendert zu sehen, aber da mache ich mir erstmal keine großen Hoffnungen.
Aber vielleicht kann man das ein oder andere Feature hinausdestilieren und dann woanders verwenden.

Hier sind keine Compute Shader am Werk, weil das ganze immernoch auf DX9 mit PS3.0 läuft.

@Starcow
Ich denke, das große Problem, was die GPUs mit Raytracing haben, ist der Unterschied der Szenenberechnung. Während man beim Rasterizing alles sequentiell berechnet, muss beim Raytracing quasi die ganze Szene immer zur Verfügung stehen. Beim Primärstrahl gehen die Strahlen noch relativ gebündelt durch die Szene, aber anschließend fliegen die wirklich so kreuz und quer, dass man da kaum noch was koherent machen kann. Und für indirektes Licht muss dann nicht nur die Szenengeometrie überall verfügbar sein, sondern eben auch sämtliche Texturen.

Zudomon hat geschrieben:Während man beim Rasterizing alles sequentiell berechnet

Kurze Korrektur: Die Hardware muss das nur einhalten, falls sich zwei Dreiecke überlagern. Da das die meisten Dreiecke NICHT tun, ist die meiste Rasterisierung parallel.

Krishty hat geschrieben:

Zudomon hat geschrieben:Während man beim Rasterizing alles sequentiell berechnet

Kurze Korrektur: Die Hardware muss das nur einhalten, falls sich zwei Dreiecke überlagern. Da das die meisten Dreiecke NICHT tun, ist die meiste Rasterisierung parallel.

Ja ich hab mich da schlecht ausgedrückt. Was ich meinte war, dass man ein Objekt rendern kann, ohne dass man Informationen über den Rest der Objekte bzw. die Szene an sich haben muss. Jedes Objekt lebt quasi in seiner eigenen Welt.

Ich hab mich ja gewundert, dass das Backprojection so extrem schlecht funktioniert hat.
Wenn der Frame neu berechnet werden muss, dann wurde zuvor in einem kleinen Bereich gesucht, ob ein alter Pixel nahe an dem neuen liegt. Eigentlich wollte ich es nun rausschmeißen, aber zuvor noch ein letztes mal aktiviert und weil ich den Suchradius aber mal vergrößern wollte, das mit [unroll] aber dann nicht mehr im Shader ging, hab ich mal [loop] rein geschrieben. Also selbst wenn ich den Bereich gleich wähle, ändert dies das Verhalten. Erst dachte ich ja, dass mein Code nicht ganz richtig wäre, aber liegt wohl eher an einem Bug im Effektcompiler. Wie auch immer, sooo unbrauchbar ist das Backprojection dann gar nicht, zumindest ist das Bild bei Veränderungen wesentlich angenehmer.
Das Antialiasing ist da noch etwas unpassend, weil dadurch die Position nicht immer ganz korrekt ist, aber es ist dennoch ganz annehmbar. :D

Hier ist noch ein Video, welches den Unterschied zeigt:

[youtube]4bBUbVvc_60[/youtube]

Was meint ihr? :)
Mein eigentlicher Plan ist allerdings, das Rendern des direkten Lichtes und der Spiegelungen/Lichtbrechungen direkt zu berechnen und das andere dann in irgendeiner Art zu cachen.

Das läuft ja schön flüssig :) mit Backprojektion sieht es für mich genauso gut aus, nur dass es massiv schneller zu sein scheint. Coole Sache!

Auf jedenfall ein interessantes Sideproject!
Vllt hab ich iwas überlesen aber ist dein Pathtracer schon bidirectional? Falls nicht würde das vermutlich schonmal die Konvergenz in weniger geeigneten Szenen enorm beschleunigen (speziell mit multiple importance sampling).

Wirklich bidrectional ist der noch nicht, auch wenn ich finde, dass direkt gegen die Lichtquelle sampeln ja schon in die Richtung geht. Aber falls mal komplexere Szene kommen, ist das eine Überlegung Wert. Multiple Importance Sampling wollte ich einbauen, aber so ganz verstehe ich das Konzept nicht. Also was ich von der Theorie her kapiert habe, ist, dass man entweder gegen die Lichtquelle oder per BRDF sampelt, und je nach Situation eben das eine oder das andere schnell konvergiert, der andere Fall dann nicht und dass man bei MIS dann von beiden Fällen gewichtet etwas nutzt. Aber wie das genau gehen soll ist mir noch schleierhaft.

Also irgendwie scheitert es schon am Licht.
Ich habe mal gemacht, dass die Lampe nur nach oben strahlt. Dabei hatte ich bisher zur Lichtabnahme die Formel 1/(d²+1) benutzt... dabei bleibt dann aber viel Licht auf der Strecke, da anscheinend das +1 fehl am Platz ist. Nehme ich also 1/d², dann sieht es weitaus besser aus. Allerdings kommen dann immer mal Pixel zustande, die so Dicht zwischen Wand und Lichtquelle stehen, dass diese dann ultra viel Energie transportieren und so einige Pixel immer mal wieder extrem aufhellen, was dann auch nicht sooo richtig aussieht. :o

Weiß jemand, was ich da falsch mache?

1/(d²+1)
1/d²

kannst es ja mal mit +0.1 oder +0.01 probieren?
oder das licht muss einfach heller sein :D

Das 1/d² gilt doch nur für Punktlichtquellen. Bei echten Lichtquellen mit Ausdehnung ist bei irgendnem d Schluss.

Schrompf hat geschrieben:Das 1/d² gilt doch nur für Punktlichtquellen. Bei echten Lichtquellen mit Ausdehnung ist bei irgendnem d Schluss.

Öhm ... nein? Ein Photon hat kein Verfallsdatum; es bewegt sich so lange fort, bis irgendwas im Weg ist, das es stoppt.

Dass die Pixel nah an der Lampe extrem hell werden, ist prinzipiell richtig. Schrompf hat damit recht, dass man jede Glühbirne als Flächenlichtquelle behandeln muss -- am Ergebnis wird das aber recht wenig ändern, weil die Lampe wahrscheinlich nicht näher an der Wand ist als einige Zentimeter. In deinem Fall erwartest du, dass der Raum recht hell ist -- wie in der Realität. Tatsächlich stammt aber auch in der Realität das meiste Licht, das den Raum flutet, von den Wänden in direkter Nähe der Lampe.

Du könntest eine Gewichtung einbauen, dass helle Stellen mehr virtuelle Photonen streuen, und dunkle Stellen an virtuellen Photonen sparen. Da gibt es aber sicher cleverere Lösungen; ich kenne mich auf dem Gebiet nicht so recht aus.

Vor allem aber Frage ich mich, wie diese hellen Ausreißer zustande kommen, die auch nach langer Berechnung kaum noch weg gehen...

Hast du doch geschrieben?

Zudomon hat geschrieben:Allerdings kommen dann immer mal Pixel zustande, die so Dicht zwischen Wand und Lichtquelle stehen, dass diese dann ultra viel Energie transportieren und so einige Pixel immer mal wieder extrem aufhellen

Wenn du jetzt nur 300 Samples pro Pixel berechnest, werden halt 300 Pixel in deiner Szene extrem hell, weil dort die Energie der Pixel nahe der Lampe landet. Oder verstehe ich dich falsch?

Krishty hat geschrieben:Hast du doch geschrieben?

Zudomon hat geschrieben:Allerdings kommen dann immer mal Pixel zustande, die so Dicht zwischen Wand und Lichtquelle stehen, dass diese dann ultra viel Energie transportieren und so einige Pixel immer mal wieder extrem aufhellen

Wenn du jetzt nur 300 Samples pro Pixel berechnest, werden halt 300 Pixel in deiner Szene extrem hell, weil dort die Energie der Pixel nahe der Lampe landet. Oder verstehe ich dich falsch?

Also das war erstmal nur eine Vermutung. Ob das wirklich daran liegt, weiß ich nicht. Wusste nicht, dass ihr das genauso seht und deswegen dazu nichts geschrieben hattet.

noch ein nicht physikalischer vorschlag. problem scheint ja zu sein, dass eine division durch einen kleinen wert zu grosser helligkeit führt?
evtl. kannst du einfach min(1,1/d^2) benutzen?

marcgfx hat geschrieben:noch ein nicht physikalischer vorschlag. problem scheint ja zu sein, dass eine division durch einen kleinen wert zu grosser helligkeit führt?
evtl. kannst du einfach min(1,1/d^2) benutzen?

Habs ausprobiert, dann ist der Fehler weg, aber es sieht auch fast so aus wie auf dem 1/(d²+1) Bild.

So ganz verstehe ich das Phänomen doch nicht. Also mal angenommen, einige Pixel haben halt extreme Helligkeit, dann doch nur wirklich da, wo das Licht extrem nah an der Fläche ist. Warum behalten denn diese überhellen Pfade ihre Helligkeit? Also was ich meine ist, warum nimmt das Licht von der Lichtquelle zur Oberfläche quadratisch ab? Wenn ich einen Punkt im Raum betrachte, dann hätte dieser doch die Gesamtlänge über die Bounces hinweg die so weit von der Lichtquelle ist, dass es zu dieser Überstrahlung doch gar nicht mehr kommen dürfte.
Ich weiß nicht, ob ich mich vernünftig ausdrücke. Was ja letztendlich passiert ist doch, dass mein Augstrahl auf eine Wand trifft, dieser dann unglücklicherweise in genau die Richtung geworfen wird, wo dann die andere Wand extrem nah an der Lichtquelle steht, dann hab ich auf einmal einen so hellen Pixel. Aber das sollte sich ja, selbst wenn das dann so korrekt ist, mit der Zeit wieder ausgleichen...

Hier steht die Lichtquelle etwas weiter weg... die überstrahlten Pixel kommen aber dennoch zu stande.

Okay, habs... das ist das blöde an Optimierungen... irgendwo schlagen irgendwann Fehler ein, die man vorher nicht vorhergesehen hat.
Für die Energieübertragung pro Pfad habe ich eine RGBA8 Textur verwendet. Nun nutze ich wieder 32F und nun gibt es auch keine Fireflies mehr. Lag also daran, dass wohl die Quantisierung der Energie dazu geführt hat, dass sie bei solchen ausreißern nicht verschwinden konnte. Oder sowas in der Art.

Fies. Aber es sieht jetzt sehr gut aus!