[Projekt] GPU Pathtracer

[Zudomon]

Habs nun korrigiert und in doppelter Qualitität auf 1024x1024, was dann schon mit 234 Sekunden zu Buche schlägt. Die Bandings sind trotzdem nicht ganz verschwunden.

[marcgfx]

sieht echt geil aus. wie stark hat eigentlich die geometrie komplexität auswirkungen auf die renderzeit? könnte man mit der technik ein game mit ein paar würfeln mit brauchbaren fps realisieren?

[Zudomon]

Also ich habe das Gefühl, dass trotz Beschleunigungsstruktur die Dreieckszahl schon extrem Einfluss auf die Renderzeit hat. Das Zimmer hat auch über 330k Polys.
Soweit ich das bisher verstanden habe, ist beim Raytracing auch generell nicht das Problem, die Berechnungen zu machen, sondern die ganzen Cache misses. Es wird ja kreuz und quer durch die Szene geschossen und somit auch von überall aus den Texturen gelesen.
Speziell Wüfel/Kugeln sind ja da auch noch ein Sonderfall. Eine Box berechnen ist wesentlich schneller, als 12 Dreiecke.

Wie gesagt, ich denke, es läuft eh auf was hybrides raus, weil das so einfach zu langsam ist. Allerdings wollte ich erstmal soweit ich kann an dem Pathtracing selbst optimieren.

[Jonathan]

Wie generierst du denn deine Pfade? Hast du irgendein Monte-Carlo-Sampling implementiert? Machst du etwas in Richtung Importance-Sampling?

[Zudomon]

Ja, Monte-Carlo, aber statt für jeden Pixel, für alle die gleiche Richtung... zumindest in den oberen Leveln bleibt es so korehenter.
Importance hab ich jetzt mehrmals probiert, aber irgendwie verfälscht das seltsamerweise das Ergebnis.
Naja, da muss ich nochmal schauen...

Es konvergiert auch wesentlich schneller, wenn eben nicht nur alles weiß ist.
512x512, etwa 2 Sekunden Renderzeit:

[Zudomon]

Könnte es sein, dass ich das Importance Sampling versehentlich schon drin habe und deswegen nicht nach cos gewichten muss?

In der Hemisphere Sampling ich wie folgt:

Code: Alles auswählen

     u1:=random;
     u2:=random*2*pi;

     r:=sqrt(u1);
     x:=r*cos(u2);          // Tangent
     y:=r*sin(u2);          // Binormal
     z:=sqrt(max(1-u1,0));  // Normalenrichtung

Die Decke scheint mir nämlich zu Dunkel in den Ecken:

So würde es ohne Cosinusreduzierung ausehen:

Welches davon allerdings richtiger ist, kann ich nicht beurteilen... :?

[Zudomon]

Hier nochmal zwei Bilder, wo nochmal alles weiß ist... d.h. Reflektion liegt bei 80%
Die Frage auch hier, welches ist "richtiger". Wie gesagt, könnte sein, dass ich durch das Strahlenerzeugen im Vorfeld schon den Cosinusterm indirekt mit rein rechne.

Constant:

Cosinus:

Welches der beiden ist eurer Meinung nach das echtere Bild?

[Krishty]

das sind eher Benchmarks für Upsampling und JPEG-Kompression ;) Ich kann NICHTS an Details erkennen.

[Sternmull]

Lade die Szene doch einfach mal in Blender und vergleiche deine Ergebnisse mit denen des Cycles-Renderers. Der hat auch eine CUDA-Implementierung, da hast du also auch gleich einen Performance-Vergleich für die GPU-Implementierung.

[Jonathan]

das sind eher Benchmarks für Upsampling und JPEG-Kompression ;) Ich kann NICHTS an Details erkennen.

dito, lad die doch bitte in Zukunft als png's hoch.

[Zudomon]

das sind eher Benchmarks für Upsampling und JPEG-Kompression ;) Ich kann NICHTS an Details erkennen.

dito, lad die doch bitte in Zukunft als png's hoch.

Okay, mach ich.

Lade die Szene doch einfach mal in Blender und vergleiche deine Ergebnisse mit denen des Cycles-Renderers. Der hat auch eine CUDA-Implementierung, da hast du also auch gleich einen Performance-Vergleich für die GPU-Implementierung.

Ich komme mit Blender gar nicht klar... hab die Szene zumindest importiert und die Fenster raus geschnitten um es dann wieder zu exportieren. Mit Müh und Not hab ich ein Licht rein bekommen, welches ich dann mit Cycles rendern konnte, was dann gar keine Schatten geworfen hat sondern nur irgendwie indirektes Licht.

Allerdings hab ich nochmal genau nach dem Importance Sampling gesucht und auch gesehen, dass ich den Cosinus-Term wohl also auch schon vorher mit einfließen lasse, also das ganze dann im nachhinein nicht mehr skalieren muss.
Aber das Ergebnis scheint noch falsch zu sein. Wobei ich glaube, dass das Licht immer noch nicht richtig streut. Vor allem da oben rechts sieht es falsch aus, wo der Schatten des Schrankes die Wand trifft.

[Zudomon]

Nachdem ich nun die Lichtquelle auch mal per Hand versetzen kann, sehe ich nun, dass da definitiv die Hemisphäre nicht richtig gesampelt wird! :o

Das Licht sitzt hier hinter dem Monitor... an der hinteren Ecke hat man direktes Licht... aber nach oben breitet es sich irgendwie nur in eine Richtung aus... der Geier weiß warum :lol:

[Zudomon]

Die Sampeltextur war falsch... hatte da R und B Kanal vertauscht.

[marcgfx]

für mich sieht lustigerweise alles korrekt aus. zumindest glaube ich zu verstehen wie die ergebnisse entstehen würden.

dort wo der schatten die wand trifft wird die obere wand von der unteren wand abstrahlung beleuchtet, bzw. nicht beleuchtet weil die untere wand im schatten ist.


hier sieht es für mich so aus, als ob die lichtquelle etwas weiter links ist. dies würde erklären wieso rechts weniger licht aus dem spalt nach oben gestrahlt wird.


kann mich natürlich brutal irren, aber ich will nur sagen, die ergebnisse gefallen mir alle und ich würde nicht auf den gedanken kommen, dass da was falsch ist ;)

[Zudomon]

kann mich natürlich brutal irren, aber ich will nur sagen, die ergebnisse gefallen mir alle und ich würde nicht auf den gedanken kommen, dass da was falsch ist ;)

Das ist das schlimme, dass man immer denkt, es seit korrekt und gar nicht an Fehler denkt.
Hatte aber dann versucht, farblich die Hemisphäre anzeigen zu lassen (ähnlich wie die Normalen) und da hab ich dann gemerkt, dass die Werte nicht stimmen.

Hier ist noch eins, welches 1005 Sekunden Renderzeit hatte, auf 1024². Das ist schon extrem lang. Das Problem bei diesem Bild ist, dass die Lichtpfade nur selten durch das Fenster fallen, deswegen dauert das konvergieren dann so lange. Hier würde wohl Metropolis Light Transport helfen, aber ich glaube, so weit werde ich nicht mehr kommen.

[Zudomon]

1024², 21 Sekunden

Bei dem hab ich jetzt nicht gemessen...

[Krishty]

Danke; jetzt kann ich viel mehr erkennen :)

Ich würde da weniger aufs Auge vertrauen und direkt messen, wie beim Vorschlag mit Blender. Ich hörte, eine sehr große Spieleschmiede hat erst nach einem Jahr gemerkt, dass das Gamma in ihrer Ambient Occlusion falsch war, und als sie es dann korrigiert haben, sah alles schlechter aus als vorher weil nun schon die ganze Pipeline um den Fehler herumkonstruiert war ;)

Machst du eigentlich ausschließlich Lambert oder hast du auch schon mit glänzenden Reflexionen gespielt?

[Zudomon]

Momentan nur Lambert... das ist auch eher alles nur zusammengehackt. Keine echte Engine hinter... z.B. ist da jetzt, weil ich nur den Haufen Dreiecke habe, die Farbe der Wände über Shader eingefärbt. Also je nachdem, wo die Koordinaten liegen. Aber das rumspielen macht einfach so viel Spass.

In 512x512 komme ich übrigens in dieser bescheidenen Qualität aber immerhin auf 6-8 FPS.

Das hier ist dann direkt mit DX gerendert (1024² etwa 1380 FPS):

Und mit einfach geraytraced Schatten (etwa 130 FPS):

[Krishty]

Um Schatten zu raytracen gibt es aber auch deutlich schnellere Ansätze, die die Kohärenz der Strahlen und die Rasterisierungs-Hardware ausnutzen. GPU Gems hatte da mal was.

[Zudomon]

Um Schatten zu raytracen gibt es aber auch deutlich schnellere Ansätze, die die Kohärenz der Strahlen und die Rasterisierungs-Hardware ausnutzen. GPU Gems hatte da mal was.

Finde das so auf an hieb nicht. Aber mir ging es ja auch darum, endlich nicht mehr so viele rasterizing Tricksereien machen zu müssen.


Nun kann ich Bilder auch in FullHD produzieren... 55 Sekunden:

[Zudomon]

Ich habe heute morgen eingebaut, dass ich mal mit nem richtigen CPU Pathtracer vergleichen kann (also Szenendaten davon übernehmen), und musste feststellen, dass ich bisher aber alles andere als ein "brauchbares" Ergebnis generiere... wahrscheinlich liegt es daran, dass ich für jede Strahleniteration jeweils die gleichen Reflektionswinkel benutze. Naja, aber das das Ergebnis so derbe scheiße ist, ist mir vorher irgendwie nicht aufgefallen.

Richtiger Phathtracer:

Mein Drecksdingen:

PS: Sorry, diesmal beides JPG... aber ich glaube, man erkennt trotzdem einen dezenten Unterschied. :lol:

[Jonathan]

Hey, das sieht ja fast genau so aus, wie das hier:



https://users.cg.tuwien.ac.at/zsolnai/gfx/smallpaint/

What’s causing this?

The cause of the painterly look is actually a bug – there’s an incorrect usage of the Halton-series with correlating dimensions, and the errors are spread throughout the screen with an equally wrong sampling function. one would wish that every bug could look just as beautiful as this one.

Was ich mir aus all dem mitgenommen habe: Sampling ist schwer! Bei Globaler Beleuchtung muss man sehr kniffelige Integrale lösen, und wenn man es einfach irgendwie probiert, baut man quasi zwangsläufig irgendwelche systematischen Fehler ein. Die Lösung ist, ganz viel Stochastik zu betreiben, und ein richtiges Sampling herzuleiten - sprich zu beweisen, dass es gegen den richtigen Wert konvergiert. Was ein Thema ist, über das Doktorarbeiten geschrieben werden, insbesondere wenn man die richtig netten Optimierungen einbauen will (Metropolis-Light-Transport z.B.).
Die Alternative ist, ganz viel Literatur zu dem Thema zu lesen, weil das ja alles schon längst gelöst und berechnet wurde.

Wie ich vor ein paar Posts schon zu sagen versuchte: Raytracing ist NICHT einfacher als Rasterisierung. Ja, man kann sehr einfach und elegant spiegelnde und brechende Kugeln rendern, aber ab dann steigt die Komplexität sprunghaft an. Und mir scheint fast, als könne man sich bei Rasterizern noch eher um die echt komplizierte Mathematik drücken und könne besser irgendwelche Hacks benutzen, statt mathematisch bewiesen korrekte Lösung implementieren zu müssen.

[Zudomon]

Das ist sogar genau mein Fehler! :D

Ich benutze auch Halton um so mit der Zeit die komplette Hemisphäre zu sampeln. Das Problem ist allerdings, dass diese Haltonserie auch für die reflektierten Strahlen genutzt wird. Also müsste man statt dessen wirklich Zufallsrichtungen nutzen.

Ja, du hast ja Recht, Raytracing ist auch kompliziert. Aber es ist auf eine andere Art und Weise kompliziert finde ich. Man muss halt den ganzen Vorgang richtig einbauen, hat aber dafür nicht mit 100te Sonderfällen allgemein zu kämpfen.

[marcgfx]

Die anderen Bilder sahen auch alle gut aus, krass wie falsch es in diesem neuen Beispiel ausschaut. Liegt es an den Kugeln?

[Zudomon]

Liegt es an den Kugeln?

Ne, glaube eher, weil ich dort kein direktes Licht verwende, sondern ausschließlich indirektes.

Hier nochmal die Zimmer Szene mit der alten und neuen Variante...

Hätte jedenfalls nicht gedacht, dass das so einen Unterschied macht... :lol:

[Krishty]

Neue Variante bedeutet was genau? Der andere Pathtracer? Oder eine korrigierte Version von deinem?

[Zudomon]

Neue Variante bedeutet was genau? Der andere Pathtracer? Oder eine korrigierte Version von deinem?

Achso, sorry, die Information ist wohl irgendwie nicht bis ins Forum durchgedrungen :D
Also das ist jetzt meine korrigierte Version.

Ich versuche nochmal das Problem zu beschreiben:
Vorher hatte ich Halton benutzt um die Hemisphäre immer genauer abzutasten. Jede Strahleniteration bekommt also einen neuen Reflektionswinkel. Allerdings habe ich den dann nicht nur für die Primär-, sondern auch für Sekundärstrahlen usw. benutzt. Jetzt werden wirklich Zufallswinkel genommen, die dann auch in der Strahlentiefe variiert werden. Dadurch sehen die Wände nicht mehr so aus, als ob da dreck wäre, wenn es länger konvergiert ist.

Alt:

Neu: (Allerdings auch 2,5x solange Rechenzeit, damit das Ergebnis brauchbarer ist ;) )

Also ich finde, vor allem an der Zimmerdecke sieht man den weicheren Verlauf...

[Krishty]

Ja; das Ghosting unter dem Fernseher ist komplett verschwunden. Hübsch hübsch!

[marcgfx]

wie sieht denn jetzt die szene mit den kugeln aus?

[Zudomon]

Wie bei der Vorlage auch... allerdings hab ich noch kein Specular drin.