Ray Tracing and Gaming – One Year Later

[AnarchX]

One Year Later

This article is intended to be a follow up article to one released about a year ago through PC Perspective. A lot of things have changed since then. Real-time ray tracing for desktop machines is just around the corner.
http://www.pcper.com/article.php?aid=506

Einige können sicherlich schon ahnen von wem der Artikel kommt. :D

[Aquaschaf]

Zu dem Artikel kann man nicht viel sagen. Es müssen immer noch die armen schwebenden Quecksilber-Kugeln herhalten als Argument. Am besten fand ich "Hybrid raytracing/rendering: why it is a bad idea..".

[ScottManDeath]

Jups, und außerdem ist Quake 3/4 nicht wirklich grafisch anspruchsvoll. Im prinzip ne Tech-Demo für Bumpmapping und harte Schatten ;)

Wenn er morgen Crysis mit 60 fps auf 1600x1200 mit allem pi-pa-po und 4x4 SSAA zeigt, ja, dann zugegeben, wäre ich motivierter mich zu Begeistern, aber bis dahin Marketinggeblubber ...

Desweiteren PVS sind nicht das Ende der Fahnenstange was GPU Culling betrifft. Stichwort Predicated Rendering

So oder so, wenn es darum geht das im Schnitt vielleicht 10% aller Pixel Reflektionen haben, dann frag ich mich ob sich das lohnt dafür das brauchbare und recht gut verstandene Rastern aufzugeben.

Ausserdem, darf ich weiche Schatten und Global Illumination sagen :tongue:

[rotalever]

Für mich sah es in dem Artikel nur nach Standbildern aus. Was ist, wenn sich alles bewegt? Was ist mit weichen Schatten?

[Gast]

Was ist mit weichen Schatten?

erstmal garnichts, "standardmäßig" bietet raytracing auch nur harte schatten.

[Spasstiger]

erstmal garnichts, "standardmäßig" bietet raytracing auch nur harte schatten.
Wenn Rechenzeit keine Rolle spielt, sind auch weiche Schatten und indirekte Beleuchtung ohne großen Implementierungsaufwand umsetzbar. Man lässt z.B. einfach viele Strahlen von einem Flächenpunkt weggehen und nicht nur einen in Richtung Lichtquelle. Natürlich vervielfacht sich dadurch der Rechenaufwand, aber man kann so das reale Verhalten von Licht sehr gut nachbilden.

[rotalever]

Da aber Rechenzeit im Echtzeitraytracing eine Rolle spielt...

[Nasenbaer]

Für mich sah es in dem Artikel nur nach Standbildern aus. Was ist, wenn sich alles bewegt? Was ist mit weichen Schatten?
Hab den Artikel nich gelesen aber RayTracing (also einfache Standardverfahren) und weiche Schatten - das wird doch eh nichts. Und GI Verfahren wie PathTracing sind hoffnungslos lahm für Echtzeit. PhotonMapping ist zudem für Animationen nicht geeignet, da es durch "Fleckenbildung" bei bewegten Bildern doof aussieht.

Ich denke mal das bisherige Scanline Rendering ist keine schlechte Wahl und liefert bei höherer Performance wesentlich bessere Bilder als diese Raytracer.

[Coda]

Naja zusammen mit Larrabee und http://graphics.uni-ulm.de/BIH.pdf halte ich es für gar nicht mehr soo unbrauchbar wie früher.

Allerdings bin ich nach wie vor der Meinung, dass der Autor eins übersieht: Es bringt nix Milliarden von Polygonen zu rendern, die einem dann die Augen rausflimmern. Man braucht LOD und dann ist Rasterization zusammen mit Occlussion-Queries auf der GPU auch log(n) (*).

Und selbst wenn man BIHs benützt hat man immer noch ein Problem mit Vertex- und Geometry-Shadern. Man müsste maximale Bounds angeben in der sich die Geometry ändert und dann jedesmal diesen Teil des Trees ändern, wenn es sein kann dass sich die Position des Vertex ändert. Ich bin da nach wie vor skeptisch.

Zudem lassen sich BIHs auch wunderbar als dynamische Szenenstruktur für Rasterization verwenden zusammen mit * verwenden

Und last but not least: Wenn Larrabee so aussieht wie ich glaube lässt sich damit eh beides super machen. Also auch hybrid usw. Kein Grund für einen Krieg - auch wenn es ihn hier natürlich wieder geben wird :usad:

[ScottManDeath]

Wenn man den Tree pro Frame komplett neu baut sind die Shader auch nicht das Problem. Klar kann man wenn man Bounds hat tricksen

[Coda]

Man muss den Tree nicht komplett neu bauen mit BIHs. Man muss sogar nur das neu bauen durch das auch Strahlen gehen. Der Algorithmus hat dabei Laufzeit n*log(n) (ist im wesentlichen Quicksort ähnlich). Das Paper ist wirklich lesenswert.

[Gast]

Hi;

ich bin auf den endgültigen Report über "Hardware for Raytracing" gespannt. Vielleicht findet der Student ja eine (weitere) Möglichkeit Raytracing in Hardware zu beschleunigen. Laut Midterm-Report hat er das zumindest vor:

http://tclab.kaist.ac.kr/~sungeui/SGA/Students/CS780_mid_report_yjs.pdf

Auf dieser Seite findet man übrigens sehr viele Infos über Raytracing: http://tclab.kaist.ac.kr/~sungeui/


Manfred