spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Man muss mindestens zwei Sachen unterscheiden:
- Gewisse Spezialeffekte wie die Augen der Menschen oder ein Kopfsteinpflaster in der näheren Umgebung (sagen wir 5-10 Meter).
- Die gesamte Szene in Raytracing zu berechnen

Zum ersten:
Hier ist m.E. keine Frage, dass das kommen wird, sondern nur wann es zum Standardpool an Algorithem gehört. Es läßt such gut in Shadern umsetzen, aber man kann einfach "Fallback" Algorithmen implementieren, sodass es auf den modernsten Grafikkarten super aussieht, aber diese eben nicht unbedingt benötigt werden. Der Algorithmus ist in Demos zumindest vo ATI getestet, gut beschrieben und IIRC ist auch Source Code vorhanden. Das heisst nicht, dass jedes Spiel dies benutzen wird, aber eben die bei denen mehr Aufwand getrieben wird und bei denen die entsprechenden Effekte benötigt werden, z.B. ein Spiel bei dem man in mittelalterlichen Städten rumrennt.

Zum zweiten:
Ich hab mal ausgerechnet, dass man einen Faktor von 10 hoch 10 braucht um komplexe Szenen in Echtzeit mit Raytracing zu rendern. Das ist aber schon sehr lange her und sicherlich ist - logarithmisch gedacht - ist schon mehr als die Hälfte dieses Faktors an Geschwindigkeit ereicht. Wenn man die Raytracingfunktionalität in "Produktions" Hardware giesst, kann man den Faktor vielleicht sogar schon erreichen.

Wenn man aber eine solche Karte macht, so würde es zunächst keine Software dafür geben, sodass ein Henne und Ei Effekt entsteht. Denkt an die erste 3D Grafikkarte zurück, nämlich die NV1 / "The Edge" von nVidia. Diese hat super Funktionalität geboten, bis hin zu Patches, war aber ein solcher Flop, dass ich mich noch heute wundere wie nVidia das überlebt hat. Insofern ist meine Vermutung, dass eine solche Funktionalität auf einer "normalen" Grafikkarte integriert wird. Grob gesagt denke ich, es wird entweder eine eigene Funktionseinheit sein, die aber auf das VRAM, das Interface etc gemeinsam mit dem Scanlinerenderer zugreift, oder aber es wird intern die Shadereinheiten ausnutzen, so wie ja z.B. schon die Fixed Function Pipeline durch Shader emuliert wird. DAS besondere bei der Implementation von Raytracing in Hardware ist ja die hohe Parallelität; Ein Pixel muß nicht von anderen abhängen. Parallelität ist aber in GPUs bereits wesentlich höher als in CPUs und auch einfacher zu machen als in der "general purpose" CPU. Ein FGPA kann benutzt werden um zu zeigen es geht und es geht mit relativ wenig Aufwand (Transistoren) und es ist sehr schnell. Aber "endgültige" Hardware hat wesentlich mehr Leistung.

Man darf aber nicht denken, das Raytracing eine perfekte Bildqualität erreicht und die Physik genau simuliert. Es ist vielmehr so, dass ein grosser Teil der Lichtstrahlen in Wirklichkeit NICHT nach Einfallswinkel = Ausfallswinkel reflektiert wird. Die Formel beschreibt nur das Maximum der abgestrahlten Energie. Gerade bei matten Oberflächen ist der peak aber relativ breit und das diffus reflektierte Licht wichtig. Dies kann man wiederum gut mit Radiosity berechnen. Es gibt daher mehrere Möglichkeiten eine raytracer für Spiele zu benutzen:
1. Eine Spiel"landschaft" zu entwerfen, die eben genau einen Raytracer braucht. So wie z.B. Toystory über Spielzeug handelte weil Plastik sehr gut gerendert werden konnte. D.h. die Story an die Technik anpassen bzw. eine entsprechende wählen.
2. Spezialeffekte zu dem Raytracer hinzufügen, z.B. weiche Schatten. Also nicht so viel anders wie momentan auch die Grafik gemacht wird, ein grundlegendes Prinzip plus etliche "Tricks".
3. In dem Teil wird Radiosity bzw ähnliche Verfahren wie Precomputed Radiance Transfer gleich von Anfang an mit implementiert.