ZFX + Developia

Geschätze ZFX'ler :)
Kann mir jemand von euch erklären, weshalb es (meinem Wissen nach) nach wie vor keine Spiele gibt, die zur Grafikdarstellung Echtzeit-Raytracing einsetzen?
Früher war klar, dass dafür schlicht die Rechenleistung der Systeme nicht ausreichend war.

Nur:
Es ist über den Daumen gepeilt 10 - 12 Jahre her, als ich von ersten gelungenen Experimenten gelesen habe, welche das Spiel Quake3 Arena auszugsweise in eine Raytracing-Engine portiert hatten. Das war, glaube ich, ein Student Namens Daniel Pohl (http://www.q3rt.de/). Sein Experiment lief, wenn ich mich richtig erinnere, auf einem Cluster-Verbund von AMD Athlon Prozessoren.

Jetzt meine konkrete Frage: Wenn das damals auf einem solchen Verbund gelaufen ist, müsste dann sowas heute nicht mit regulären 3D-Beschleuniger-Karten auf konventionellen PC-Systemen vergleichbar flüssig laufen?
Ich würde mal vermuten, dass der Geschwindigkeitszuwachs von 3D-Beschleuniger aus 2006 zu Karten aus 2017 höher als Faktor 10 sein dürfte.
Lassen sich diese Raytracing-Algorythmen nicht auf 3D-Beschleunigern ausführen, oder an was liegt es, dass man hier nicht viel weiter ist als damals (mein Eindruck jedenfalls)?

Gruss starcow

Jetzt meine konkrete Frage: Wenn das damals auf einem solchen Verbund gelaufen ist, müsste dann sowas heute nicht mit regulären 3D-Beschleuniger-Karten auf konventionellen PC-Systemen vergleichbar flüssig laufen?

Bestimmt. In der DAMALIGEN Qualität halt ;)

Nun hat sich Computergrafik ja seitdem auch ein klitzekleineswenig weiter entwickelt. Und im Moment ist eben PBR mit Realtime GI State of the Art :)

Es gibt da durchaus Fortschritte. Z.B. den hier: https://home.otoy.com/render/brigade/showcase/ Man sieht daran aber auch prima, warum es immer noch nicht real einsatzfähig ist. Die Primary Hits, also der erste Strahl von der Kamera hinein in die Szene, ist aktuell und evtl. sogar prinzipiell viel besser mit Rasterizing machbar. Secondary Rays sind dann der spannende Teil. GPUs und damit alle Echtzeit-Engines fangen an der Stelle an zu schummeln, zu cachen, vorauszuberechnen. Und wie man an obigem Link sieht, müssen Echtzeit-Raytracing-Engines genauso schummeln, sonst reicht es aktuell einfach immer noch nicht.

Und möglicherweise, zumindest nach meiner persönlichen Ansicht, wird es immer so bleiben, dass Rasterizing plus kluge Tricks das Raytracing schlägt. Es ist einzig die elegante Schlichtheit eines Raytracers, die immer noch die Leute fasziniert und zu weiteren Experimenten anregt. Egal, welches Problem Du hast, mit mehr Rays kannst Du es erschlagen. Verlockend einfach, aber nicht für den täglichen Einsatz geeignet. Und daher nicht in Spielen zu sehen.

Tatsaechlich kann ab einer gewissen Geometriedichte uebrigends durchaus Ray Tracing auch Rasterisierung schlagen, wenn es um Primary Hits geht. Aber das Grundproblem hat Schrompf absolut getroffen: Strahlenverfolgung ist heute in Echtzeit absolut kein Problem mehr, aber bis jetzt weiss damit schlicht niemand etwas Sinnvolles anzufangen, das bei vergleichbarer Performance in irgendeiner Weise an die Qualität etablierter rasterbasierter Techniken herankommt.

Man sollte vielleicht noch anfügen, dass trotzdem mehr und mehr Techniken aus dem Monte Carlo Lichttransport, der ja in der Regel das ist, was Leute landläufig als Realismus durch Ray Tracing bezeichnen, in Echtzeit-Anwendungen hinüber wandern. So hat insbesondere das heute fast ubiquitäre Temporal Anti-Aliasing, also das Aggregieren mehrerer Stichproben über viele Frames hinweg, die Anwendung einiger stochastischer Verfahren beispielsweise zur Integration volumetrischer Beleuchtung und Absorption in Echtzeit ermöglicht, ohne untragbar viele Stichproben in jedem einzelnen Frame nehmen zu muessen. Leider hat jedes Lichttransportphaenomen da seine eigenen Anforderungen bezueglich Reprojektion alter Information in neue Frames, die dieses Vorgehen im Allgemeinen nichttrivial machen. Ein paar schoene Dinge sieht man hier in der Unreal Engine. Auch für Schattenberechnung kommen mehr und mehr hybride Ansätze auf, die langfristig aufgrund der Anforderung irregulärer Abtastung bei dennoch weitestgehend kohärenten und damit effizient testbaren Schattenstrahlen zur Integration von vollem klassischem Ray Tracing in einigen Engines führen könnten. Derzeit nutzt die Unreal Engine für distante weiche Schatten sog. Cone Tracing von niedrigaufgelösten Signed Distance Field-Approximationen der Szene, das auch schon mehr klassischem Ray Tracing ähnelt. Weiterhin werden schon länger im Bildraum Strahlen für Ambient Occlusion, Reflexionen, und neuerdings auch für präzisere Detail-Schatten verfolgt.

Ok, sehr interessant! Danke für eure Einschätzung.

Schrompf hat geschrieben:https://home.otoy.com/render/brigade/showcase/ Man sieht daran aber auch prima, warum es immer noch nicht real einsatzfähig ist.

Du meinst das Bildrauschen, nehm ich mal an. Was ist den die Ursache, dass es teilweise rauscht, teilweise die Grafik aber auch total sauber dargestellt wird?
Es scheint mir auch, dass die Entwickler überzeugt davon sind, das RayTracing die Methode der Zukunft sein wird - auch in Echtzeit-Anwendungen. Diese Einschätzung teilst du aber nicht, richtig?

Ich höre immer wieder, das bei RayTracing der Polycount praktisch keine Rolle mehr spielt. Müsste das nicht im Umkehrschluss bedeuten, dass wir mit zunehmender technischer Entwicklung irgendwann den Punkt erreichen werden, bei welchem das Rasterizing-Verfahren mehr Leistung (aufgrund des Polycounts) braucht, als die einfachere RayTracing-Render-Methode?

Gruss starcow

starcow hat geschrieben:

Schrompf hat geschrieben:https://home.otoy.com/render/brigade/showcase/ Man sieht daran aber auch prima, warum es immer noch nicht real einsatzfähig ist.

Du meinst das Bildrauschen, nehm ich mal an. Was ist den die Ursache, dass es teilweise rauscht, teilweise die Grafik aber auch total sauber dargestellt wird?
Es scheint mir auch, dass die Entwickler überzeugt davon sind, das RayTracing die Methode der Zukunft sein wird - auch in Echtzeit-Anwendungen. Diese Einschätzung teilst du aber nicht, richtig?

Direkte Beleuchtung (hell) ist ja nicht schwer zu berechnen, schaffst du in jedem Spiel in Echtzeit. ;) Wenn Du jetzt anfängst, aus allen Richtungen mehrfach gestreutes indirektes Licht einzusammeln, ist es hingegen ploetzlich ueberhaupt nicht mehr klar, in welcher Richtung Du eigentlich idealerweise danach suchen solltest, wenn Du nur endlich viele Stichproben zur Verfüngung hat. So global kann man das überhaupt nicht wissen, also schießt man halt einfach mal für jeden Pixel irgendwo hin, und trifft mal hellere, mal dunklere Teile der Szene. Der Mittelwert entspricht dann ungefähr dem tatsächlichen indirekten Licht (korrekt wäre er für unendlich viele Stichproben), aber für eine kleinere Zahl von Stichproben kann der je nachdem, wie unterschiedlich hell verschiedene Teile der Szene sind, nunmal stark variieren.

starcow hat geschrieben: Ich höre immer wieder, das bei RayTracing der Polycount praktisch keine Rolle mehr spielt. Müsste das nicht im Umkehrschluss bedeuten, dass wir mit zunehmender technischer Entwicklung irgendwann den Punkt erreichen werden, bei welchem das Rasterizing-Verfahren mehr Leistung (aufgrund des Polycounts) braucht, als die einfachere RayTracing-Render-Methode?

Wie gesagt, Ray Tracing kann ab einer gewissen Menge von Geometrie effizienter sein, wobei es da eher um die bereits angesprochene Dichte (Polygone pro (Sub-)Pixel) geht, als die Gesamtmenge von Polygonen, bzw. Größe der Szene. Problematisch ist dann, dass das so mehr oder weniger nur für statische Geometrie gilt. Sobald in jedem Frame erstmal Beschleunigungsstrukturen aktualisiert werden müssen, damit man effizient Strahlen testen kann, ist rein von der Komplexität her der Vorteil praktisch direkt dahin. Ob das in der Praxis dann insgesamt noch effizienter ist, hängt wohl stark vom Einzelfall ab, insbesondere der Menge zu aktualisierender Geometrie.

Ich finde gerade keine Originalversion vom Video, aber das hier sollte auch tun:

https://www.youtube.com/watch?v=Kg-aGO8Wvx8

Was daran so beeindruckend ist, ist nicht, dass es so unglaublich viele Dreiecke gibt. Das war vor 10 Jahren oder so ein Problem, aber heute kommt es viel mehr darauf an, wie man die Dreiecke anmalt. Dieser scheinbar relevante (weil irgendwie so griffige) Vorteil des 'endlich viele Dreiecke' beim Raytracing ist es letztendlich also gar nicht.
Was die Demo aber beeindruckend macht, ist die tolle Beleuchtung. Ich bin mir nicht 100%ig sicher, aber ich meine, dass die Hauptidee dabei war, globale Beleuchtung für jeden Oberflächenpunkt (aus welcher Richtung kommt wie viel Licht) per Raytracing vorzuberechnen und in speziellen Texturen zu speichern. Das mag für so eine Szene stundenlang rechnen, aber danach kann man es halt in Echtzeit durch Polygonbasierte Verfahren rendern. Man kombiniert also die Vorteile beider Verfahren (nur Raytracing kann globale Beleuchtung exakt berechnen, aber das dauert eben). Insofern setzt es sich schon irgendwie durch, aber vielleicht nicht so, wie man vor 15 Jahren dachte.

Wie bei 2:00 die Reflexionen vom Clipping gefressen werden ist aber nicht so schön :) Ist doch Cone Tracing durch ein Signed Distance Field, oder? Und das Clipping (bzw. Fade-out) geschieht, damit man an Stellen, die eigentlich hochaufgelöst spiegeln müssten, die Blockbildung nicht sieht, oder?

Falls ja, muss man dafür auch nicht stundenlang rechnen – in der Demo mit der zerstörbaren Stadt haben sie das in Echtzeit vorgeführt.

Jonathan hat geschrieben:[...] Die Hauptidee dabei war, globale Beleuchtung für jeden Oberflächenpunkt (aus welcher Richtung kommt wie viel Licht) per Raytracing vorzuberechnen und in speziellen Texturen zu speichern. [...] Insofern setzt es sich schon irgendwie durch, aber vielleicht nicht so, wie man vor 15 Jahren dachte.

Macht das nicht Valves "Source-Engine" schon seit Jahren so? Bloß, dass die das nicht "per vertex" macht sondern in eine recht schlecht aufgelöste Light-Map speichert. Aber das Problem beim vorberechnen ist ja sowieso, dass die Beleuchtung dann statisch ist.

In dem Unreal Video die Reflektionen sind im Screen Space. Alles was nicht im Screen Space liegt muss also ausgefadet werden. Per VoxelGI kriegt man grobe/diffuse Reflexionen quasi "umsonst" mit, da müsste man dann auch nicht die Beleuchtung statisch baken.

Aaaah, das ergibt Sinn (und ist noch viel mehr fake). Am Rande: Die Stühle/Tische/Schränke schweben über dem Boden; also genau da, wo Reflexion am wichtigsten ist, fehlt sie.

ich finds geil, dass die die Lizenzen an Schulen und Unis kostenlos rausgeben. So kommt das Ding schneller ins Rollen. Wer freut sich noch krass auf VR mit der Engine?