531. GPU Raytracing
- < Vorheriges Bild
- 531. GPU Raytracing
- Nächstes Bild >
von Noobody
Gepostet am Freitag, 19. Februar 2010
Das Bild wurde 45 Mal bewertet.Du musst eingeloggt sein, um eine Bewertung abgeben zu können.
Nach Kauf eines neuen Computers reizte es mich, die Grafikkarte ein wenig auszureizen und schrieb kurzerhand einen GLSL-Shader, der per Raymarching beliebige Funktionen rendern kann. Dank Shader Model 4.0 ist Integer-Arithmetik nun auch auf der Grafikkarte verfügbar, was es mir ermöglichte, eine Implementation von Perlin Noise/FBM zu schreiben. In Normalsprache heisst das, dass von den Wolken bis zum Terrain alles prozedural generiert ist. Man könnte sich also unendlich in alle Richtungen bewegen und käme trotzdem nicht an eine Stelle, die einer anderen ähnelt.
Die Normalen sind teilweise ein wenig verkorkst, was daran liegt, dass ich nicht fähig war, die Ableitung von der verwendeten Funktion zu bilden. Für gewöhnliche Brownsche Bewegung ist die Ableitung schnell gefunden, aber ich baute hier eine Variante ein, um Erosion zu simulieren. Sieht ganz schick aus, aber ist unmöglich abzuleiten. Darum sind im Bild manche Stellen schwarz, die es eigentlich nicht sein sollten, aber seis drum
Renderzeit ca. 18 Minuten bei einer Auflösung von 2048x1563, einem Primärstrahl und einem Schattenstrahl (Strahlenschrittweite jeweils 0.0001), Camerarange ca. 70 Einheiten und 12 Noise-Iterationen. Kurz: Tonnenweise Berechnungen. Da die GPU aber unübertreffbar bei parallelisierbaren Prozessen ist, ist es trotzdem noch vergleichsweise schnell.
Der Fragmentshader ist hier zu finden.
Die Normalen sind teilweise ein wenig verkorkst, was daran liegt, dass ich nicht fähig war, die Ableitung von der verwendeten Funktion zu bilden. Für gewöhnliche Brownsche Bewegung ist die Ableitung schnell gefunden, aber ich baute hier eine Variante ein, um Erosion zu simulieren. Sieht ganz schick aus, aber ist unmöglich abzuleiten. Darum sind im Bild manche Stellen schwarz, die es eigentlich nicht sein sollten, aber seis drum
Renderzeit ca. 18 Minuten bei einer Auflösung von 2048x1563, einem Primärstrahl und einem Schattenstrahl (Strahlenschrittweite jeweils 0.0001), Camerarange ca. 70 Einheiten und 12 Noise-Iterationen. Kurz: Tonnenweise Berechnungen. Da die GPU aber unübertreffbar bei parallelisierbaren Prozessen ist, ist es trotzdem noch vergleichsweise schnell.
Der Fragmentshader ist hier zu finden.
- < Vorheriges Bild
- 531. GPU Raytracing
- Nächstes Bild >
Kommentare
- 1, 2 › »
BlitzMax. In BB hätte ich wohl kaum GLSL benutzen können
(Dienstag, 2. März 2010 um 21:17 Uhr)
Von Megamag
Sieht toll aus, wie man es von dir gewohnt ist
Darf man Fragen, welche Blitz-Version du benutzt hast?
Darf man Fragen, welche Blitz-Version du benutzt hast?
(Dienstag, 2. März 2010 um 21:08 Uhr)
Von ComNik
Ich drücks mal so aus: Endlich das passende Wallpaper
Sieht sehr cool aus,
lg
ComNik
Sieht sehr cool aus,
lg
ComNik
(Montag, 1. März 2010 um 18:36 Uhr)
Von Noobody
Das Bild in 2048x1536 gibts hier zu finden.
Da Raytracing sehr gut skalierbar ist (sprich: n mal mehr Input = ca. n mal längere Laufzeit), wäre es bei 1024x768 ziemlich genau 4 Mal so schnell, also 5 Minuten.
Danke für das Lob
Da Raytracing sehr gut skalierbar ist (sprich: n mal mehr Input = ca. n mal längere Laufzeit), wäre es bei 1024x768 ziemlich genau 4 Mal so schnell, also 5 Minuten.
Danke für das Lob
(Montag, 1. März 2010 um 16:57 Uhr)
Von #Reaper
Das ist ja mal echt genial o_O
Ich verstehe zwar noch geschätzt weniger als 10% von dem, was du sagst, aber ich bin begeistert.
Wo gibt es denn das Bild in voller Auflösung (2048x1563)? Und wie lange bräuchte es eigentlich ca. bei vielleicht niedrigerem wie 1024x768? Vermutlich wäre es nicht viel schneller nehme ich an.
Ich beneide dich und einige andere hier um ihr Wissen. Da fühlt man sich ja noch wie ein absoluter Anfänger mit geringen PC-Kenntnissen.
MfG
#Reaper
Ich verstehe zwar noch geschätzt weniger als 10% von dem, was du sagst, aber ich bin begeistert.
Wo gibt es denn das Bild in voller Auflösung (2048x1563)? Und wie lange bräuchte es eigentlich ca. bei vielleicht niedrigerem wie 1024x768? Vermutlich wäre es nicht viel schneller nehme ich an.
Ich beneide dich und einige andere hier um ihr Wissen. Da fühlt man sich ja noch wie ein absoluter Anfänger mit geringen PC-Kenntnissen.
MfG
#Reaper
(Sonntag, 21. Februar 2010 um 19:46 Uhr)
Von DjDETE
genial
(Samstag, 20. Februar 2010 um 15:09 Uhr)
Von mpmxyz
Nicht schlecht...
Aber es gibt Optimierungsmöglichkeiten.
Wenn man so z.B. die Zufallsberechnung leicht ändert, könnte man erst schauen, ob der Strahl in einem größerem Gebiet überhaupt auf einen Berg treffen kann und sonst den Strahl etwas weiter bewegen.
Im Moment schätze ich den Aufwand auf ca. eine Billion Schritte ohne Schatten.
mfG
mpmxyz
Aber es gibt Optimierungsmöglichkeiten.
Wenn man so z.B. die Zufallsberechnung leicht ändert, könnte man erst schauen, ob der Strahl in einem größerem Gebiet überhaupt auf einen Berg treffen kann und sonst den Strahl etwas weiter bewegen.
Im Moment schätze ich den Aufwand auf ca. eine Billion Schritte ohne Schatten.
mfG
mpmxyz
(Samstag, 20. Februar 2010 um 10:01 Uhr)
Von Xaymar
Ich mein ich krieg den Bluescreen beim kompilieren, nicht beim einbinden. Hab aber rausgefunden, dass der Compiler in den Windows Speicher schreiben wollte.
(Samstag, 20. Februar 2010 um 00:49 Uhr)
Von Noobody
Ein Bluescreen? Von einer... Textdatei?
Auch wenn du ihn versucht hast einzubinden, sollte er gar nicht erst laufen. Da fehlen eigentlich noch ein Vertexshader und passende Texturkoordinaten.
Auch wenn du ihn versucht hast einzubinden, sollte er gar nicht erst laufen. Da fehlen eigentlich noch ein Vertexshader und passende Texturkoordinaten.
(Freitag, 19. Februar 2010 um 22:09 Uhr)
Von Xaymar
Hmm, ich hab SH4.0/GLSL4.0 und trotzdem läuft das ding nur mit nem Bluescreen als resultat. Braucht man vlt noch was, von dem ich gerade nicht weiß?
Von Noobody