RayTracing - kann mir jemand erklären...

[starcow]

Guten Abend Zusammen :-)

Vielleicht kann mir da von euch jemand weiterhelfen... :-)

Und zwar frage ich mich wiedermal wieso ich dauernd so lange auf meine Bilder warten muss, wenn ich sie mit MetalRay rausrendere. Irgendwie kann ich einfach nicht ganz verstehen, wieso diese Raytracing Geschichte nach wie vor unglaublich lange dauert.
Ich hab jetzt 18 Lichtquellen auf meinem Set. Alle diese Lichter werfen 100% hartkantige Schatten und Global-Illumation ist ausgeschaltet. Der Polycount liegt bei ca. knapp einer Million. Spiegelungen und rechenintensive Shader (bis auf AmbientOC) gibts eigentlich nicht.
Ich meine, müsste sowas heutzutage nicht in Echtzeit berechnet werden können? Wo liegt den da genau das Problem, das man diese RayTracing Algorithmen nicht einfach quasi auf die GPU auslagert? Und bis auf die Schatten ist ja alles bereits heutzutage Problemlos in Echtzeit berechenbar, wie es mir jedenfalls scheint (vielleicht mal abgesehen vom sehr guten AntiAliasing).
Mittlerweile sehen die Bilder aus den neusten Game-Engines ja dermassen realisitsch aus, das ich mich echt frage, ob ich künftig nicht einfach meine Filme und Visualisierungen etc. in einer solchen Game-Engine berechnen lassen soll.
Die Lichtsetzung z.b kostet dermassen viel Zeit. Und das eigentlich vorallem darum, weil man dauernd auf die Bilder warten muss. Wenn ich mir überlege wie schön es doch wäre, das Licht einfach in Echtzeit zu platzieren und zu justieren... waaaaaaa! :mrgreen:

Gruss starcow

[Schrompf]

Tja... zum Einen ist MentalRay ein komplett anderer Ansatz - physikbasiertes Rendering ist auch heutzutage noch kein Pappenstil, und mit x Lichtquellen und Ambient Occlusion müssen da schnell Aber-Milliarden Strahlen verschickt werden. Zum schnellen Ausrendern einer Testszene ist das definitiv nix.

Zum Anderen - und jetzt setze ich mich potentiell in die Nesseln - ist RayTracing meiner Meinung nach prinzipiell benachteiligt. Der Aufwand pro Pixel ist höher als beim Rasterizing, und zwar *egal* welche Optimierungen Du ansetzt. Die gängige Propaganda meint ja, dass mit der richtigen Beschleunigungsstruktur die Komplexität auf O(log n) sinkt, was Rasterizer ja nie hinkriegen... bla. Im Endeffekt ist ein sauber arbeitendes LOD-System genauso O(log n), wenn es für die erwartete Anzahl überdeckter Bildschirmpixel das richtige LOD rausholt. Im Endeffekt gibt es für jeden Trick, der Raytracing etwas fixer macht, auch eine Entsprechung für den Rasterizer. Nur dass der Raytracer prinzipiell für die selbe Aufgabe immer länger braucht.

Der große Trick beim Raytracing, also die Faszination, warum die Technik immer wieder hochkommt, ist meiner Meinung nach die Einfachheit für den Programmierer. Egal was Du an Effekten erreichen willst, es läuft immer darauf hinaus, noch ein paar Strahlen mehr pro Pixel zu verfolgen. Die eigentliche Intelligenz kommt beim Raytracing erst dann zum Einsatz, wenn man die Beschleunigungsstrukturen anfängt, die ja bitter nötig sind, damit man noch zu Lebzeiten ein Bild auf den Schirm kriegt. Und da rotieren die kleinen grauen Zellen dann, wenn es darum geht, parallele Strahlen zusammenzufassen und Nodes mit Sub-Referenzen in Cache Lines zu quetschen. Mit all diesen Tricks kann man mächtig was rausholen aus den enorm komplexen Rechenzeitmonstern, was die heutigen CPUs sind. Nur *muss* man das auch rausholen, weil schon die theoretisch berechnete Rechenleistung vom Hersteller nicht ausreichen würde, um Raytracing sinnvoll nutzen zu können.

Ok, der letzte Vergleich ist ein wenig garstig. Rasterizer wären wohl auch astronomisch komplexe Coder-Fresser, wenn wir sie selbst schreiben müssten. Stattdessen gibt es dafür aber dedizierte Hardware, in der all diese Intelligenz schon drin steckt.

Für Filme nutzt man übrigens auch Mental Ray - allerdings wird dann für jeden interessanten Effekt am Ende das Raytracing doch wieder rausgeschmissen und durch einen Basteleffekt ersetzt, der mit Rasterizing auch funktionieren würde. Hab ich jedenfalls irgendwo gelesen, aber frag mich nicht, wo.

[TGGC]

Eine GPU ist ja grundsaetzlich schnell genug um auch Raytracing in Echtzeit darzustellen. Durch ihre Architektur kann man sie einfach nur nicht gut genug skalieren lassen, so dass ein solcher Ansatz nicht auf allgemeinen Aufgaben uebertragbar ist. Wir haben damit ja auch schon experimentiert, z.b. hier:
[youtube]cJPv3TAEAcM[/youtube]

[Blue Cobold]

Klar, eine GPU kann das schon in Echtzeit. Aber möglichst nicht mit einer Million Polygone und zweistelliger Anzahl Lichtquellen.

[Schrompf]

Ich finde diesen Effekt wundervoll. Da wird die Szene praktisch komplett in einer Reihe Formeln mit Parametern beschrieben, und entsprechend glänzen moderne Grafikkarten dabei, die Formeln abermillionenfach jedes Frame auszurechnen. Nur leider ist das nicht übertragbar auf Starcows Frage. Die Gesamtkomplexität der Szene im Video ist vielleicht ein paar hundert Byte bestenfalls, während Starcow ja gerne Multi-Megabyte-Szenen dargestellt haben will.

[Artificial Mind]

Ich möchte hier mal kurz Ray Tracey's Blog anmerken ( http://raytracey.blogspot.de/ ).
Dort werden immer mal wieder Videos von dem Brigade bzw. Octane Renderer vorgestellt, welche Real-time Path Tracing machen.
Die sind schon relativ weit würde ich behaupten.

[TGGC]

Klar, eine GPU kann das schon in Echtzeit. Aber möglichst nicht mit einer Million Polygone und zweistelliger Anzahl Lichtquellen.

Die Gesamtkomplexität der Szene im Video ist vielleicht ein paar hundert Byte bestenfalls, während Starcow ja gerne Multi-Megabyte-Szenen dargestellt haben will.

Das Problem ist nicht die Komplexitaet oder Entropie der Szenen. Da oben gibt es ja auch ziemlich viele Details. Das Problem ist wie man die fuer den aktuellen Strahl wichtigen Details findet. Anders ausgedrueckt, man muss fuer jeden Strahl erstmal die richtige Formel finden. Das kann man fuer eine spezielle Szene einfach loesen, aber im Allgemeinen Fall wird es kompliziert.

[starcow]

Erstmal danke für diesen Einblick.
Nur wo liegt den der Vorteil von RayTracing - jetzt in Bezug auf meine Szene? Spiegelungen sind da keine Vorhanden, GI ist ausgeschaltet und die Schatten sind alle 100% hartkantig. Was dann noch bleibt ist einfaches Texutrmapping (inkl. Specularmaps) sowie AmbientOC (wofür es ja offensichtlich auch schon Real-Time Lösungen gibt).
Einzig bei den Schatten wüsste ich nicht, ob man die so in RealTime (mit welcher Methode auch immer) berechnen könnte. Ist diese feine Auflösung der Schatten den das Problem?

Gruss starcow

[Blue Cobold]

Für Ambient-Occlusion ist mir keine Real-Time-Lösung bekannt. Lediglich eine Annäherung über Screen-Space-Ambient-Occlusion, was aber was ganz anderes ist als Ambient-Occlusion.
Wie gesagt, reduzier die Polygone Deiner Szenen oder die Lichter. Immerhin muss jeder Strahl da auf 18 Lichtquellen und 1kk Polys testen, die eventuell Schatten erzeugen könnten. Mich würde auch interessieren, ob der Raytracer alle Deine Daten im Ram halten kann, denn falls das Programm swappen muss, bist Du ganz schnell jenseits von gut und böse.

[starcow]

Hi Blue Cobold
Es ging mir eigentlich eher weniger darum, wie ich jetzt meine Szene irgendwie optimiert kriege. Weder am Polycount, noch an den Lichter werd ich was ändern können. Und die Rendertime von ~10min Pro Frame in 2k ist in diesem Sinne "normal" und zu erwarten gewesen (swappen braucht mein Rechner da noch nicht).
Für mich war eher die Frage, wo den konkret die Qualitätsunterschiede im Vergleich zu Realtime auszumachen sind. Am Texturmapping kanns ja wohl kaum liegen. Ebenso wenig an den Lichtqullen (sofern man die Schatten deaktiviert). AmbientOC naja... In einem Vergleich las ich eben, das der Unterschied zwischen "echtem" AmbientOC und SSAOC eher marginal sei und die Technik bis auf die reduzierten Samples so ziemlich die selbe sei. (Aber vielleicht kannst du das etwas genauer beschreiben, wo da der grosse Unterschied ist - was mich interessieren würde).
Der Umstand, das ich hier 1 Frame pro 10 Minuten gerendert kriege und das mit Echtzeitlösungen vergleiche, die 60 Frames _pro_ Sekunde gerendert bekommen, gibt mir schon irgendwie zu denken. ;-)
Ich meine das ist ein Faktor von 36'000!
Und ne 36'0000 mal längere Rendertime nur wegen _hartkantigen_ Schatten? Ich meine, es ist nunmal offensichtlich so, aber ganz verstehen kann ich es trotzdem nicht. :-)

[Schrompf]

Ich weiß nicht, womit Mental Ray für die Ambient Occlusion arbeitet, aber die wird so weit weg von SSAO sein, dass ein Vergleich nutzlos ist. Richtige Ambient Occlusion muss die ganze Szene oder substanzielle Teile davon betrachten, um zu funktionieren. Schalte sie doch einfach mal ab und schau, wie lange es dann rechnet.

Außerdem ist Mental Ray nach meinem Verständnis ein Physical Based Renderer. Es kann also gut sein, dass der schon für jeden einzelnen Stahl anstatt einem Strahl gleich x Strahlen pro Spektralfarbe verschickt, um mögliche frequenzabhängige Brechungseffekte mitzubekommen. Da liegen Welten zwischen dem und einem Spiele-Renderer.

[Blue Cobold]

In einem Vergleich las ich eben, das der Unterschied zwischen "echtem" AmbientOC und SSAOC eher marginal sei und die Technik bis auf die reduzierten Samples so ziemlich die selbe sei. (Aber vielleicht kannst du das etwas genauer beschreiben, wo da der grosse Unterschied ist - was mich interessieren würde).

Nein. Die visuellen Unterschiede sind je nach Szene oder Qualität der SSAO-Umsetzung gut bis schlecht. Sie sehen nett aus in Spielen, SSAO ist aber dennoch Welten von echtem AO entfernt. SSAO arbeitet halt mit einem Shader auf den Z-Werten der fertigen Szene (grob gesagt). Ambient Occlusion hingegen schießt für jeden Strahl, der irgendwo auftrifft (also nicht für jedes Pixel, sondern für jeden Strahl) 2 bis 2000 Strahlen wild durch die Gegend und berechnet daraus die Helligkeit an diesem Punkt. Ich weiß nicht wie MentalRay das macht, aber die "normalen" Renderer von 3DSMax haben für AO einen Regler für die Anzahl Strahlen. Je mehr, desto besser. Mit 10-20 braucht man da eigentlich nicht anfangen, das sieht sehr verrauscht aus. Bei 100-200 ist es schon deutlich besser. Aber da überlege man sich, dass das einen Komplexitäts-Faktor von eben 100-200 OHNE jedwede Reflektion bedeutet, also nur eine Rekursionstiefe von 1 für den Raytracer.

Ich kenne auch keinen Raytracer, der 1kk eigenständige Polygone in Echtzeit handhaben könnte. Ich denke daher nicht, dass die selbe Szene auf einer GPU per Rasterizing gerendert noch mit hübschen 60 FPS laufen würde.

[starcow]

Ich weiß nicht, womit Mental Ray für die Ambient Occlusion arbeitet, aber die wird so weit weg von SSAO sein, dass ein Vergleich nutzlos ist. Richtige Ambient Occlusion muss die ganze Szene oder substanzielle Teile davon betrachten, um zu funktionieren. Schalte sie doch einfach mal ab und schau, wie lange es dann rechnet.

Gute Idee! Das werd ich nachher mal austesten

Außerdem ist Mental Ray nach meinem Verständnis ein Physical Based Renderer. Es kann also gut sein, dass der schon für jeden einzelnen Stahl anstatt einem Strahl gleich x Strahlen pro Spektralfarbe verschickt, um mögliche frequenzabhängige Brechungseffekte mitzubekommen. Da liegen Welten zwischen dem und einem Spiele-Renderer.

Ok. Einerseits leuchtet das zwar "technisch" ein, andererseits frage ich mich, wo man das dann tatsächlich im Bild sehen kann.
Vielleicht ist mein Verständnis von Bild-Synthese doch ein gutes Stück zu Navi, aber ich bin bis jetzt davon ausgegangen das das ganze eigentlich auf ein paar Haupt-Aspekte reduziert werden kann, die zu 99.9% für das Bild-Ergebnis verantwortlich sind.

1) Ich habe zweidimensionale Flächen (Texturen) die im dreidimensionalen Raum perspektivisch korrekt projeziert werden müssen.
2) Lichtquellen (Abhängig von ihrem Wirkungsbereich und Winkel) dunkeln/hellen die Polygone auf respk. ab. (Schatten sind hier bewusst weggelassen)

-> Bis zu diesem Punkt kann doch heutzutage nahezu jeder Renderer Physikalisch Korrekte Ergebnisse liefern. Mit Szenen die Polygon Anzahlen im 7-Stelligen Bereich aufweisen.
Wenn man die Schatten einfach weglässt, dürfte es ja nicht besonders rechenintensiv sein, die Auswirkung einer Lichtqulle auf ein Polygon physikalisch korrekt wiederzugeben. Daher ist es doch bis zu diesem Zeitpunkt absolut irrelevant, ob ich das ganze mit MentalRay oder OpenGL rendere. Das Ergebnis müsste nach Adam Ries doch das selbe sein. Vielleicht hat Mental Ray ja die viel aufwendigeren Textur-Filter Methoden (ich weiss es nicht), ob das nun ein ungeschultes Auge überhaupt erkennen kann, ist dann die andere Frage.
Das selbe beim Licht. Auch hier müsste doch ein in Echtzeit berechnetes Polygon sich mittels OpenGL physikalisch korrekt beleuchten lassen. Licht nimmt im Quadrat ab, Einfallswinkel etc. - das dürfte doch bei einem Standard Material (100% Diffus) keine grosse Sache sein.
Auch hier müsste man doch sagen können: Ob RayTracing oder Rasterizer - das Ergebnis ist das selbe.
Also bitte korrigiert mich wenn ich das falsch sehe.

Ergebnis bezogen kann ich also sagen, das es eigentlich nur noch um die Darstellung der Schatten geht. Und da verstehe ich nicht, wieso man keine Echtzeitlösung hat, die die selbe Qualität wie Raytracing bietet. Und ich spreche hier nich von Softshadows oder ähnlichem.

vielleicht sollte ich mal ein paar Testbilder posten... Dann sagt ihr bestimmt, das dies ohne Probleme in Echtzeit berechenbar wäre :-D

[Artificial Mind]

Nur mal so nebenbei: mehrere 10-Millionen Polygone mit jeweils 18 Lichtquellen (forward, kein zPre) sind auch ohne Schatten mit einem Rasterizer schwierig. Der braucht da auch schnell mehrere Sekunden pro Frame (obwohl es massiv parallelisiert ist).

[Schrompf]

Probier es aus, Starcow. Ich mag nicht weiter spekulieren.

[Blue Cobold]

Ich glaub da hat auch jemand keine Vorstellung, was Raytracing eigentlich ist und wie GPUs Polygone rasten. Die letzte lange Anwort von starcow ist jedenfalls so abstrus, dass ich gar nicht wüsste, wo ich zuerst widersprechen soll und wie lange die ganzen Erklärungen wohl dauern würden.
Schnapp Dir ein paar Erklärungen von Google, was Raytracing eigentlich ist und wie es arbeitet. Projektion von 3D-Polygonen auf eine 2D-Fläche ist es jedenfalls nicht.

[starcow]

Ich glaub da hat auch jemand keine Vorstellung, was Raytracing eigentlich ist und wie GPUs Polygone rasten. Die letzte lange Anwort von starcow ist jedenfalls so abstrus, dass ich gar nicht wüsste, wo ich zuerst widersprechen soll und wie lange die ganzen Erklärungen wohl dauern würden.
Schnapp Dir ein paar Erklärungen von Google, was Raytracing eigentlich ist und wie es arbeitet. Projektion von 3D-Polygonen auf eine 2D-Fläche ist es jedenfalls nicht.

Naja, eigentlich ist mir im wesentlichen schon klar, wie das Prinzip der Strahlenverfolgung funktioniert. Und ich kann mir auch gut vorstellen, weshalb es eine weile dauert, wenn ich X-Millionen Ray's von der Kamera heraus in die Szene schiessen muss.
Darum ging es mir auch gar nicht. Mich hätte die Diskussion interessiert, ab wann Raytracing gar keinen Sinn macht, weil ich mit einer anderen Methode die selben Resultate in Echzeit bekommen würde.
Wieso du aber meine Antwort gleich als abstrus bezeichnest, kann ich nicht nachvollziehen. Ich bin der Meinung das man daraus mehr oder weniger ablesen kann, worum es mir ging. Und erlichgesagt fühle ich mich jetzt bisschen als Dummkopf und oder als jemand ohne Engagement (der zu bequem ist sich mal schnell par Doc's durchzulesen) von dir abgestempelt.
Wieso sprichst du den plötzlich von mir in der dritten Person?
Aber nichts für ungut. Es war nicht meine Absicht hier irgend wen zu nerven.

Gruss starcow

[TGGC]

Merk dir einfach Folgendes:
In normalen Spielen wird der Vorgang eines Maler simuliert. Der sagt z.b. ich male erst einen blauen Hintergrund. Dann male ich eine Hauswand mit Steintextur. Da die von der Sonne wegzeigt, ist die dunkel. Jetzt male ich ein Hausdach mit roten Ziegel, das zeigt zur Sonne und ist deswegen heller usw.

Dein Raytracer hingegen simuliert die Aufnahme eines Fotos mit einer Kamera in dem es den Film nimmt und von da aus den potentiellen Weg eines Lichteilchens verfolgt, bis er irgendwann vielleicht auf eine Lichtquelle trifft.

Das direkt zu vergleichen ist ziemlich nutzlos.

[starcow]

Merk dir einfach Folgendes:
In normalen Spielen wird der Vorgang eines Maler simuliert. Der sagt z.b. ich male erst einen blauen Hintergrund. Dann male ich eine Hauswand mit Steintextur. Da die von der Sonne wegzeigt, ist die dunkel. Jetzt male ich ein Hausdach mit roten Ziegel, das zeigt zur Sonne und ist deswegen heller usw.

Dein Raytracer hingegen simuliert die Aufnahme eines Fotos mit einer Kamera in dem es den Film nimmt und von da aus den potentiellen Weg eines Lichteilchens verfolgt, bis er irgendwann vielleicht auf eine Lichtquelle trifft.

Das direkt zu vergleichen ist ziemlich nutzlos.

Ein guter und einprägsamer Vergleicher TGGC, danke :-)
Auch wenn ich mich hier total blamiere, muss ich doch nochmal nachfragen:

Ich möchte nur die Ergebnisse vergleichen - (also nur die Pixel aus dem das gerenderte Bild besteht).
Ist es den per se ausgeschlossen, das ich mit beidem Methoden zum selben Ergebnis komme?

Schlussendlich füttere ich den Renderer ja mit dem selben Typ an Daten.
- Texturen
- Lichter

Wenn ich jetzt unter Bestimmten Bediungen die Ergebnisse gleich ausfallen würden (oder nahezu gleich, so das mit dem Auge kein Unterschied mehr auszumachen ist), dann wäre das doch eine sehr interessante Frage. Vorallem wenn das eine Bild x-1000 mal schneller gerendert wäre.
So könnte man dann auch sagen, das bei bestimmten Szenen es total "unwirtschaftlich" ist ein RayTracer einzusetzen.

Ausprobieren kann ich es leider nicht, da ich nur MentalRay habe...

Gruss starcow

[dot]

Wenn du beim Raytracer nur bis zum ersten Treffer gehst, dann ist das Ergebnis beider Methoden völlig gleich. Und dann man kann aber z.B. auch so Dinge machen wie erst rasterisieren und in der Berechnung der Farbwerte der einzelnen Pixel dann aber Raytracing einsetzen...

[TGGC]

Wenn ich jetzt unter Bestimmten Bediungen die Ergebnisse gleich ausfallen würden (oder nahezu gleich, so das mit dem Auge kein Unterschied mehr auszumachen ist), dann wäre das doch eine sehr interessante Frage.

Was genau "wäre doch eine sehr interessante Frage"?

So könnte man dann auch sagen, das bei bestimmten Szenen es total "unwirtschaftlich" ist ein RayTracer einzusetzen.

Ja koennte man. Und bei bestimmten ist genau das Umgekehrte der Fall (wie z.b. bei dem im Video gezeigten). Und nun?

[starcow]

Wenn du beim Raytracer nur bis zum ersten Treffer gehst, dann ist das Ergebnis beider Methoden völlig gleich. Und dann man kann aber z.B. auch so Dinge machen wie erst rasterisieren und in der Berechnung der Farbwerte der einzelnen Pixel dann aber Raytracing einsetzen...

Ok, gut zu wissen.

Wenn ich jetzt unter Bestimmten Bediungen die Ergebnisse gleich ausfallen würden (oder nahezu gleich, so das mit dem Auge kein Unterschied mehr auszumachen ist), dann wäre das doch eine sehr interessante Frage.

Was genau "wäre doch eine sehr interessante Frage"?

Die Interessante Frage wäre dann für mich, wo diese Grenze liegt. Oder salop ausgedrückt: Wenn ich gewisse Aspekte im Gestalten der Szene beachte, kann ich mir sicher sein, das später optisch keinen Unterschied erkennbar ist, wenn ich vom Raytrace Renderer auf einen GPU-Rasterzier welchslen würde.

So könnte man dann auch sagen, das bei bestimmten Szenen es total "unwirtschaftlich" ist ein RayTracer einzusetzen.

Ja koennte man. Und bei bestimmten ist genau das Umgekehrte der Fall (wie z.b. bei dem im Video gezeigten). Und nun?

Das war mir nicht klar. Weil ich in meiner Unwissenheit bislang immer davon ausgegangen bin, das ein Bild das per RayTracing gerechnet wurde immer erkennbar "besser" aussieht. :mrgreen:

[dot]

Ein Grundproblem mit deiner Fragestellung ist, dass "Ray Tracing" und "Rasterisierung" beide extrem weit gefasste Überbegriffe sind. "Ray Tracing" bezeichnet erstmal nur eine Klasse von Algorithmen, die eben auf der Idee, Strahlen in eine Szene zu schicken basieren. Von allen möglichen Verfahren zur Bildsynthese bis zur wissenschaftlichen Simulation zur Schallausbreitung ist da alles drin. Gleich wie "Rasterisierung" so ziemlich jeden Algorithmus bezeichnen kann, der kontinuierliche Dinge auf ein diskretes Signal abbildet.

Bei "Rasterisierung" ist ja noch relativ klar, was genau du meinst, aber "Ray Tracing" kann im Kontext mit Grafik irgendein extrem simples Ding sein das Bilder generiert, die aussehen wie aus den 80ern, genauso wie ein wahnsinnig komplexes Teil, das photorealistic Rendering betreibt. "Ray Tracing" ist einfach nicht gleich "Ray Tracing" und wie du dir sicher denken kannst, fällt es schwer, da dann irgendwelche allgemeinen Aussagen zu treffen. Ray Tracing und Rasterisierung überschneiden sich in ihren Anwendungen zwar ein wenig, stehen aber eigentlich nicht wirklich in direkter Konkurrenz zueinander, sondern ergänzen sich viel eher. Es macht also eigentlich von vornherein nicht unbedingt soviel Sinn, darüber zu diskutieren, welches Verfahren nun ab wann genau "besser" ist, als das für dich vielleicht im Moment den Anschein haben mag...

[starcow]

Ein Grundproblem mit deiner Fragestellung ist, dass "Ray Tracing" und "Rasterisierung" beide extrem weit gefasste Überbegriffe sind. "Ray Tracing" bezeichnet erstmal nur eine Klasse von Algorithmen, die eben auf der Idee, Strahlen in eine Szene zu schicken basieren. Von allen möglichen Verfahren zur Bildsynthese bis zur wissenschaftlichen Simulation zur Schallausbreitung ist da alles drin. Gleich wie "Rasterisierung" so ziemlich jeden Algorithmus bezeichnen kann, der kontinuierliche Dinge auf ein diskretes Signal abbildet.

Bei "Rasterisierung" ist ja noch relativ klar, was genau du meinst, aber "Ray Tracing" kann im Kontext mit Grafik irgendein extrem simples Ding sein das Bilder generiert, die aussehen wie aus den 80ern, genauso wie ein wahnsinnig komplexes Teil, das photorealistic Rendering betreibt. "Ray Tracing" ist einfach nicht gleich "Ray Tracing" und wie du dir sicher denken kannst, fällt es schwer, da dann irgendwelche allgemeinen Aussagen zu treffen. Ray Tracing und Rasterisierung überschneiden sich in ihren Anwendungen zwar ein wenig, stehen aber eigentlich nicht wirklich in direkter Konkurrenz zueinander, sondern ergänzen sich viel eher. Es macht also eigentlich von vornherein nicht unbedingt soviel Sinn, darüber zu diskutieren, welches Verfahren nun ab wann genau "besser" ist, als das für dich vielleicht im Moment den Anschein haben mag...

Ok, das klingt schon schlüssig. Da wirst du bestimmt auch recht haben, dass man diese Fragen wohl so gar nicht stellen kann - bzw. das sie so nur wenig Sinn ergibt.
Da ist dann meine Vorstellung des Rendering-Prozess wohl doch noch viel zu wage und sicher teils auch falsch.

Erneut aufgekommen ist bei mir diese Frage, als ich Bilder aus den neusten Game-Engines und Grafik-Engines zum ersten mal gesehen habe.
Da musste ich mich schon ernsthaft fragen, wieso ich (und andere Grafiker die ich so kenne) für ne kurze Sequenz nach wie vor min. 1 - 2 Tage warten müssen, wenn solche Engines mitlerweile nahezu fotorealisitsche Ergebnisse in Echtzeit liefern können.
Ein grosser Unterschied zwischen Realtime CutSzenes und "gerenderten" Cinematic's kann ich jedenfalls nicht mehr erkennen. Lediglich vielleicht der etwas reduzierte Polycount ist je nach Situation noch zu erknnen. (hier mal ein Beispiel, was ihr bestimmt schon kennt)
http://www.youtube.com/watch?v=oL21I1t2MO4

Da hat sich dann natürlich eine solche Frage regelrecht "aufgedrängt": Wo den nun noch die Unterschiede zum alten Dinosaurier MentalRay liegen.
Tatsache ist leider, dass ich so oder so in den meisten Fällen auf GI und Softshadows in animierten Sequenzen verzichten muss. Es kostet einfach schlicht zu viel Zeit. Und >1h Render-Time pro Frame mit AreaLights (also Softshadows) und GI+FG ist unter MentalRay leider eher die Regel als die Ausnahme (auch bei eher trvialen Szenen). Da heisst es dann einfach in der Praxis: Kein GI, und nur Harte Schatten.
Nur finde ich, das ohne GI und ohne SoftShadows der Vergleich mit Bildern aus aktuellen Game-Engines (mit dem selben Content) auch nicht mehr so weit weg ist.
Aber um z.b einem Produzenten dann tatsächlich Vorzuschalgen seine Sequenz z.b in Unity rauszurendern, müsste man dann schon sehr genau wissen wo die Unterschiede (rein optisch) liegen. :mrgreen:
Selbst von Laien kriegt man ja zu hören, das die Grafik aus Filmen "eine andere sei" als die von Spielen: "Das schaut toll aus! Das ist bestimmt gerendert!"
Ich frage mich aber, ob diese Aussage heute so überhaupt noch Sinn ergibt.
Weil dem Zuschauer ist es letzenendes ziemlich Egal, ob der Hollywood-Effekt tatsächlich mit der Unity-Engine gerendert wurde, oder mit Arnold. Was entscheidend ist, ist das optische Ergebnis. Und dieses kann man immer miteinander vergleichen.

Gruss starcow

[Chromanoid]

Was Du nicht vergessen solltest ist, dass viele Spiele nur deshalb in Echtzeit so gut aussehen, weil viel Zeit in Vorausberechnung investiert wird. Gerade die Darstellung statischer Geometrie wird dadurch sehr oft gesteigert und das oft mit ähnlichen Mitteln wie beim Filme Rendern. So kann auch das Vorbereiten des "Levels" mehrere Tage Rechnen bedeuten kann. Viele Studios haben deshalb wie in der Visual effects/3D Film Industrie große Rechenzentren. CodingCat hat da neulich mal auf einen sehr interessanten Vortrag verwiesen:
[youtube]ajzmr6g76s8[/youtube]

[dot]

So gut die Grafik in deinem Video auch ist, ich bezweifle, dass sie gut genug wäre um z.B. für Kinozuschauer im Jahre 2013 glaubhafte Visual Effects zu produzieren. Es ist eine Sache, wenn alles gerendert ist und eine ganz andere Sache, wenn Dinge z.B. mit Filmmaterial gecomped werden sollen. Wir können viele Effekte heutzutage schon relativ gut in Echtzeit realisieren, aber bei den meisten aufwändigeren Effekten handelt es sich da am Ende des Tages immer noch um billige Fakes von Fakes. Sieht vielleicht auf den ersten Blick überzeugend aus, aber Global Illumination, insbesondere Dinge wie subsurface Scattering, participating Media, selbst Ambient Occlusion oder auch Motion Blur, Depth of Field und sogar einfach nur Schatten sind alles andere als gelöste Probleme...

[TGGC]

Die Interessante Frage wäre dann für mich, wo diese Grenze liegt.

Was genau fuer eine Grenze meinst du?

[Blue Cobold]

Ich denke, dass das ein ganz guter Vergleich ist. So hübsch Bilder aus Spielen auch sind, aber einem Kinozuschauer würde immer auffallen, dass da was nicht stimmt. Wie ich schon sagte, z.B. SSAO ist eben kein raytracing-AO und die Unterschiede sieht man massiv.
Genau die Dinge, die ein Bild hyper-realistisch machen, sind meist leider aber auch die Dinge, die richtig viel Zeit zur Berechnung brauchen und die auf GPUs zwar irgendwie nachgemacht werden können, aber eben nur irgendwie. Es gibt da immer einen mal größeren mal geringeren Unterschied zu den Ergebnissen eines Raytracers. Der Unterschied ist vor allem auch der, dass z.B. Normalmaps und diese ganzen Spielereien auf einer GPU oft vorher erst mit einem Raytracer erzeugt werden, weil eben nur der die ganzen Details und das korrekte Aussehen überhaupt hinbekommt. Diese Maps benutzt man dann in den Spielen, um mehr Details vorzugaukeln, als da sind. Das sieht man dann eventuell aber auch, weil ein Bump-Map-Fußboden plötzlich sehr nass oder wie aus Plastik wirkt.
Am Stärksten fällt es mir persönlich eben immer bei Global Illumination (z.B. AO) auf. Da sind da an Kanten Schatten, wo ein Raytracer keine errechnet hätte oder es fehlen eben dort welche, wo ein Raytracer ein paar hinzugefügt hätte. Speziell in Ecken von Räumen kommt es oft zu merkwürdigen "dunklen Rändern" entlang der Kanten. Das sieht bei einem Raytracer ganz anders aus - in echten Räumen sieht man solche Kanten zudem ebenfalls nie.

[starcow]

Die Interessante Frage wäre dann für mich, wo diese Grenze liegt.

Was genau fuer eine Grenze meinst du?

Ich meinte damit eine Grenze, aber der man hätte sagen können, das die gerenderten Bilder der Szene nun deutlich erkennbare Unterschiede aufweisen - je nachdem ob ich nun eine Game-Engine oder eben MentalRay verwende.

So hätte ich versuchen können möglichst gute Ergebnisse zu erzielen, die nahezu in Echtzeit berechenbar gewesen wären. Oder das ich zumindest wüsste, das ich mit dem Zuschalten von "Parameter X" in den MetalRay Optionen, zwar ein wesentliches besseres Bild bekommen würde, dies aber dann teuer wird, da das Ergebnis in einer Game-Engine doch ein deutlich anderes wäre. So hätte ich dann auch versucht möglichst lange auf dem Pfad "In-Echtzeit-berechenbar" zu wandeln :-).
Aber es hat sich ja herausgestellt, das dies keinen Sinn macht, da die Ergebnisse immer total anders sind und man Bilder aus "Echtzeit-Engines" nicht mit Bilder aus Mental-Ray o.ä. vergleichen kann - egal welchen Parameter ich da zu- oder abschalte.

Gruss starcow

[Schrompf]

Die CryEngine 3 z.B. wirbt explizit mit dem, was Du Dir wünschst: nahezu die selben Ergebnisse wie ein richtiger Raytracer, aber in Echtzeit. Nur müsstest Du da halt wie für ein Spiel modellieren - keine ZBrush-Models direkt in den Renderer hauen, sondern ordentlich unwrappen, Normals backen usw. Die Arbeitsmethoden sind also doch ziemlich unterschiedlich.