Raytracing-Alternativen?

[huha]

Morgen!

Kurze Frage:

Es gibt ja verschiedene Arten, 3d-Szenen zu rendern. Eine davon ist ja das Raytracing, das zwar recht brauchbare Resultate liefert, aber auch etwas langsam ist.
Welche Alternativen gibt es, weshalb sind die schneller und welche Probleme kommen da auf?
Wie rendern moderne 3d-Grafikkarten die Szenen?

Danke!

-huha

[RLZ]

Bevor dir keiner antwortet mach ich das mal noch schnell ;)

Also moderne Grafikkarten sind Rasterizer, die das Bild durch Projektion der Objekte (genaugenommen üblicherweise Dreiecke, da diese nur konvex sein können) auf eine Ebene. Sie sind schnell durch.... viel Geld und Entwicklungsarbeit die reingesteckt wurde. Vorallem bei relativ wenig Polygonen ist das ganze schnell.

Dann fällt mir noch "Tile-based Defered Rendering" ein. Wobei ich mich mit der Erklärung jetzt auf Glatteis begebe (hab mich noch nicht wirklich mit beschäftigt ;) ). Dabei wird das ganze Bild in kleine Tiles aufgeteilt. Für jeden Pixel wird Strahl (wie beim Raytracing) geschossen und das ERSTE getroffene Objekt bestimmt. Da diese Kacheln nacheinander abgearbeitet werden kann man einen sehr kleinen und schnellen Z-Buffer im Chip selber benutzen. Sehr schnell, weil sehr viel weniger unnötig berechnet wird. Nachteil ist vorallem beim Szenenmanagment und bei den fehlenden Herstellern, die daran entwickeln.

Zu guter Letzt bleibt halt noch Raytracing, dass du scheinbar schon kennst und mir bestimmt erklären kannst warum es zu langsam sein soll? ;)

[Demirug]

Deine TBDR Erklärung ist so nicht ganz richtig. Pro Kachel arbeit das Teil auch wieder als Rasterizer. Da dabei aber im internen Framebuffer keine entgültigen Farben sondern nur Verweise auf das Dreieck gespeichert werden müssen nach dem Rasterisieren nur für die sichtbaren Dreieckspixel auch wirklich die Farbe berechnet werden. Das war jetzt die Kurzfassung. Irgendwo im Forum sollte es eine Rheie von ausführlicheren Erklärungen geben.

[marco42]

Original geschrieben von huha
Morgen!

Kurze Frage:

Es gibt ja verschiedene Arten, 3d-Szenen zu rendern. Eine davon ist ja das Raytracing, das zwar recht brauchbare Resultate liefert, aber auch etwas langsam ist.
Welche Alternativen gibt es, weshalb sind die schneller und welche Probleme kommen da auf?
Wie rendern moderne 3d-Grafikkarten die Szenen?

Danke!

-huha

Ach, Raytracing muss gar nicht mal so langsam sein. Es gibt sogar Echtzeit-Raytracing mit Hilfe von Clustern. Das Teure beim Raytracing sind die Schnittberechnungen, da gibt es aber sehr viele Moeglichkeiten zu tricksen.

Dann gibt es da noch Photontracing(ist praktisch forward raytracing), Rayosity, distributed raytracing etc. Das kann man dann noch miteinander kombinieren.

Der Unterschied liegt eigentlich eher in lokalen zu globalen Modellen. Erstes ist zB ein Rasterizer und zweiteres ist zB Raytracer. Gobale Modelle muessen halt die ganze Scene kennen, und dass ist halt aufwendiger und deswegen ist Raytracing auch teurer.

[RLZ]

Original geschrieben von Demirug
Deine TBDR Erklärung ist so nicht ganz richtig. Pro Kachel arbeit das Teil auch wieder als Rasterizer. Da dabei aber im internen Framebuffer keine entgültigen Farben sondern nur Verweise auf das Dreieck gespeichert werden müssen nach dem Rasterisieren nur für die sichtbaren Dreieckspixel auch wirklich die Farbe berechnet werden. Das war jetzt die Kurzfassung. Irgendwo im Forum sollte es eine Rheie von ausführlicheren Erklärungen geben.

Mhh ok
War ja unter Vorbehalt ;)

Ach, Raytracing muss gar nicht mal so langsam sein. Es gibt sogar Echtzeit-Raytracing mit Hilfe von Clustern. Das Teure beim Raytracing sind die Schnittberechnungen, da gibt es aber sehr viele Moeglichkeiten zu tricksen.

Fehlt halt nur noch die passende spezialisierte Grafikkarte. Echtzeitraytracing ist auch problemlos auf einem Rechner möglich in garnicht so schlechter Qualität. Mit Tricksereien hat das aber nichts zu tun. Dafür sind die Rasterizer zuständig ;) . Das wird alles schön sauber berechnet.... Ein Problem bei dem ein Cluster leider nichts hilft sind zufällige Speicherzugriffe (z.B. Texturen). Da können die Prozessoren Däumchen drehen. Grafikkarten haben da einen entscheidenten Vorteil bei der Speicheranbindung. Man stelle sich vergleichsweise vor, die Grafikkarte müsste jeden Texturzugriff über AGP durchführen. ;D

[Vedek Bareil]

Original geschrieben von huha
Es gibt ja verschiedene Arten, 3d-Szenen zu rendern. Eine davon ist ja das Raytracing, in diesem Zusammenhang mal eine Frage: in Alan Watt: "3D-Computergrafik" habe ich gelesen, daß Raytracing lediglich für Reflexionen zuständig ist. Raytracing heißt ja frei übersetzt sovielwie Strahlverfolgung und bedeutet, daß die auf einen reflektierenden Gegenstand auftreffenden Lichtstrahlen zu ihren Quellen zurückverfolgt werden, was besonders bei Mehrfachreflexionen sehr aufwendig werden kann.
Mit anderen Aspekten des Renderings, etwa denen, für die gängigerweise Texturen auf Polygonen verwendet werden, hat Raytracing demnach also nichts zu schaffen. Es ist also insbesondere nicht so, daß es das gesamte Rendern einer Szene übernehmen könnte, oder?
So was in der Richtung stand nämlich mal im Handbuch einer Elsa-Grafikkarte...

[Kant]

Original geschrieben von Vedek Bareil
in diesem Zusammenhang mal eine Frage: in Alan Watt: "3D-Computergrafik" habe ich gelesen, daß Raytracing lediglich für Reflexionen zuständig ist. Raytracing heißt ja frei übersetzt sovielwie Strahlverfolgung und bedeutet, daß die auf einen reflektierenden Gegenstand auftreffenden Lichtstrahlen zu ihren Quellen zurückverfolgt werden, was besonders bei Mehrfachreflexionen sehr aufwendig werden kann.
Mit anderen Aspekten des Renderings, etwa denen, für die gängigerweise Texturen auf Polygonen verwendet werden, hat Raytracing demnach also nichts zu schaffen. Es ist also insbesondere nicht so, daß es das gesamte Rendern einer Szene übernehmen könnte, oder?
So was in der Richtung stand nämlich mal im Handbuch einer Elsa-Grafikkarte...
Nun ja....Prinzipiell hat das Raytracing damit zwar wirklich nichts zu tun, aber es gehört trotzdem irgendwie dazu. ;)

Du ermittelst mit dem tracing ja den Punkt im Raum, in dem der Ray auf ein Object trifft. ( Wenn der Strahl reflektiert wurde, wird halt der reflektierte Strahl weiterverfolgt, bis dieser auf einer "soliden" Oberfläche auftrifft. ) An dieser Stelle ist dann das eigentliche raytracing, im Wortsinne, "fertig".
Aber Natürlich ist es mit den Materialeigenschaften des Objectes (seien es Texturen oder Shader), und der gegebenen Treffer-Koordinate im Raum, problemlos möglich den Farbwert an dieser Stelle zu errechnen.

[micki]

Original geschrieben von marco42
Das Teure beim Raytracing sind die Schnittberechnungen..

ich würde mal behaupten dass das teure an raytracing das lesen aus dem speicher ist, weil dann zum einen random im speicher gelesen wird z.b. beim durchgehen eines binary trees und zum anderen beim texturieren grosse mengen an daten verschoben werden müssen und die cpu dann nur aufs ram wartet.

MfG
micki

[MeLLe]

Original geschrieben von Vedek Bareil
[...] habe ich gelesen, daß Raytracing lediglich für Reflexionen zuständig ist. [..]
Mit anderen Aspekten des Renderings [...] hat Raytracing demnach also nichts zu schaffen. Es ist also insbesondere nicht so, daß es das gesamte Rendern einer Szene übernehmen könnte, oder?
[...]
AFAIK bietet gerade Raytracing die besten Möglichkeiten, eine Szene mit höchster Genauigkeit und unter Beachtung aller Aspekte der mmodellierten Welt zu berechnen. Raytracing bedeutet ja nicht, dass nur 100%ige Reflexionen berechnet werden - Raytracing bedeutet vielmehr, dass sämliche Einflüsse, die jegliches Licht in einer Szene hat, berechnet werden. Also nicht nur Spiegelungen, sondern auch die diffuse Lichtreflexion auf einem schlammigen Feldweg, genau wie auf einer staubigen Glühbirne, oder einem Fußball. Die da reflektierten Lichtanteile treffen ja im weiteren Verlauf auch wieder auf andere Objekte, und werden wieder weiter abgeschwächt, farblich verändert (durch das Material), etc ... Dadurch ergibt sich automatisch eine extrem realistische Abbildung, die ein Rasterizer kaum schaffen kann.

[marco42]

Original geschrieben von micki
ich würde mal behaupten dass das teure an raytracing das lesen aus dem speicher ist, weil dann zum einen random im speicher gelesen wird z.b. beim durchgehen eines binary trees und zum anderen beim texturieren grosse mengen an daten verschoben werden müssen und die cpu dann nur aufs ram wartet.


Octtrees sind AFAIK im Allgemeinen besser. Matuerlich bring schneller Speicher mehr. Aber unterschaetze nicht den Aufwand einer Schnittberechnung. Ich hatte mal etwas an der Schnittberechnung geaendert und danach lief meine Renderer wesentlich schneller, ok, der war nicht optimiert. Wenn du dir mal die Takte anschaust, die so eine Schnittberechnung verbraucht, dann ist das nicht so wenig, vor allem wenn du mit double arbeitest.

Texturen koennen uebrigens auch procedual sein und da hast du dann keine grossen Daten.

Es kommt halt immer darauf an.

[micki]

Original geschrieben von marco42
Octtrees sind AFAIK im Allgemeinen besser. Matuerlich bring schneller Speicher mehr. Aber unterschaetze nicht den Aufwand einer Schnittberechnung. Ich hatte mal etwas an der Schnittberechnung geaendert und danach lief meine Renderer wesentlich schneller, ok, der war nicht optimiert. Wenn du dir mal die Takte anschaust, die so eine Schnittberechnung verbraucht, dann ist das nicht so wenig, vor allem wenn du mit double arbeitest.

Texturen koennen uebrigens auch procedual sein und da hast du dann keine grossen Daten.

Es kommt halt immer darauf an.

ich brauche 6mul,3sub,7add um true oder false zu für ein triangle zu liefern, mit SSE2 kann ich 2 triangles gleichzeitig bearbeiten, ich würd die kosten auf ~30Hz im durchschnitt pro triangle schätzen.
mein VTune zeigt mir aber des öfteren ein paar hundert takte beim zugriff auf ein neues element eines trees an, trotz eigenem memory management. (allokiert gleiche elemente auf 4kbyte bänken.)

welcher tree am effizientestem ist hängt von der implementierung und der scene ab, ich kenne leute die auf BSP trees schwören (ich glaube cinema3d oder lightwave nutzen das?) und einige professoren nutzen clustered binary trees, damit leuchten sie scenen mit mehreren millionen polys in wenigen minuten mit radiosity aus (und da sind viele schnittpunkt berechnungen dabei ;D )

MfG
micki


ps. garantieren kann ich hier nicht für meine angaben zum schnittpunkt-funktions-kosten-umfang, hab den source net hier

[marco42]

Original geschrieben von micki
ich brauche 6mul,3sub,7add um true oder false zu für ein triangle zu liefern, mit SSE2 kann ich 2 triangles gleichzeitig bearbeiten, ich würd die kosten auf ~30Hz im durchschnitt pro triangle schätzen.
mein VTune zeigt mir aber des öfteren ein paar hundert takte beim zugriff auf ein neues element eines trees an, trotz eigenem memory management. (allokiert gleiche elemente auf 4kbyte bänken.)


welcher tree am effizientestem ist hängt von der implementierung und der scene ab, ich kenne leute die auf BSP trees schwören (ich glaube cinema3d oder lightwave nutzen das?) und einige professoren nutzen clustered binary trees, damit leuchten sie scenen mit mehreren millionen polys in wenigen minuten mit radiosity aus (und da sind viele schnittpunkt berechnungen dabei ;D )



Also, das mit den Minuten kenne ich nur mit einer OpenGL Implementierungen. Ansonsten dauert das schon die Faktoren zu berechnen. Ausserdem kommt es dann noch auf die Qualitaet an, die wiederum haengt von der Aufteilung der Flaechen ab.

Alles eine Frage des Trade Offs. Aber ich frage mich, ob wir unbedingt Raytracing brauchen. Du kannst sehr viele Dinge mit einfacheren Mittel hinbekommen. Bestes Beispiel ist Renderman.

Wenn du dann ein lokales Beleutungsmodell implementierst, und dann noch divisionen und/oder trigeometrische Berechnungen drin hast, dann kann dass die Schnittberechnungen schon uebertreffen.

Das Problem mit den binary trees ist halt, dass sobald die Scene dynamisch wird, wird es unangenehm. Es gibt halt nicht die absolute Antwort in der Computer Graphic. Ich wollte nur andeuten, dass du mit einem Octtree selten falsch liegst, wenn du ihm noch Ueberlappungsbereiche gibt.