Spiele wie Wolfenstein 3D nutzen zur Grafikberechnung ein Verfahren namens Raycasting – man berechnet pro Bildpunkt, welches Objekt auf welcher Position sichtbar ist. Dazu stellt man bei Wolfenstein fest, welcher "Wandwürfel" am nächsten ist (was bei Wolfenstein nur einmal pro Pixelspalte berechnet werden muss). Bei Doom 1 und 2 wird schon etwas komplexere Geometrie geboten, was eine Unterteilung der Szene notwendig machte, um nicht pro Pixel die komplette Geometrie abklappern zu müssen. Raytracing führt das ganze weiter, in dem der Lichtstrahl nach dem ersten Treffer auf ein Objekt weiter verfolgt wird. Hiermit lassen sich auch Effekte wie Lichtbrechung, Spiegelung und Schattenwurf erzeugen.

Nun ist Spiegelung (z. B. im blankpolierten Parkettboden) selbst auf Konsolen wie einer Playstation 2 zu sehen. Lichtbrechung gibt es unter anderem in Half-Life 2 und viele moderne Spiele zeigen längst komplexere Schatten als nur einen dunklen "Blob" an. Was ehemals Raytracing-Domäne war, wird also in Teilen längst auch mittels gewöhnlicher Rastergrafik geboten.

Die Universität des Saarlandes stellte nun auf der CeBIT 2007 ihre Fortschritte auf dem Weg dar, Vollbild-Raytracing in Echtzeit zu realisieren. Zwar wird in Dingen Rastergrafik derzeit auch daran geforscht, nur bestimmte Effekte zu raytracen, doch die Universität des Saarlandes will die gesamte Szene mittels Raytracing und ganz ohne Rasterung berechnen. Dabei findet die Forschung und Entwicklung an drei Fronten statt, die auf die wir kurz eingehen wollen.

Mit Hilfe neuer Algorithmen will die Universität des Saarlandes die Berechnungszeit eines Strahls auf der CPU auf 1000 Takte reduziert bekommen haben. An der zweiten Front, einer GPU-Lösung (via CUDA auf einem G80) koste die gleiche Berechnung zwar etwa 15000 Takte, die Performance sei der CPU trotzdem um Faktor 2 bis 8 überlegen. Zu guter Letzt wurde auch das Raytracing auf einem FPGA (Chip mit programmierbaren Logik-Schaltung) bei 66 MHz gezeigt. Allerdings zeigten die Demos – wenn überhaupt – nur einfachste prozedurale Texturen und in Bewegung kein Anti-Aliasing (weder innerhalb von Texturen noch an Kanten).

Durch die vorherige Presse dachten wir, die Universität des Saarlandes wolle das 3D-Rendering für Spiele ablösen, doch im Gespräch zeigte sich, dass der Augenmerk vor allem auf Industriekunden liegt. Bei einem Autorennspiel müsse es nur gut aussehen, bei VW, Airbus oder Boeing hingegen müsse es korrekt aussehen. Um eine der heutigen Rastergrafik adäquate Grafikqualität in Bezug auf Kanten und Texturen zu bieten, und zusätzlich vielleicht noch korrektes Motion Blur (also temporales Anti-Aliasing) zu berechnen, steigt der Aufwand gegenüber der auf der CeBIT gezeigten Lösung allerdings um Faktor 10 bis 100. Das wollen wir nun etwas einordnen.

Für Rastergrafik wurde bekanntlich von 3dfx der erste erfolgreiche dedizierte Chip entwickelt, um die für gefilterte Texturen erforderliche Bandbreite zu Verfügung zu stellen (auch die Filter-Rechenleistung war damals in der CPU noch nicht vorhanden, doch reine Rechenleistung steigt schneller als die verfügbare Bandbreite). Strahlenverfolgung ist überwiegend rechenlastig und sehr gut parallelisierbar – wann die zehn- bis hundertfache Leistung für hochqualitatives Raytracing zur Verfügung steht, ist also auch nur noch eine Frage der Zeit – wie gesagt steigt die arithmetische Rechenleistung schneller als die Speicherbandbreite. Außerdem sind Hardware-Entwicklungen wie die Cell-CPU für Raytracing durchaus zu gebrauchen. Würde man den eigens entworfenen Raytracing-Chip mit Hilfe eines modernen Fertigungsprozesses als ASIC bauen, wäre eine ASIC-Multicore-Lösung bei hoher Taktfrequenz möglich.

Bisher war es so, dass die Rastergrafik-Performance durch ein zu hohes Geometrie-Detail gekillt wurde, denn jedes Dreieck muss behandelt werden – selbst das pure Wegwerfen unsichtbarer Dreiecke kostet etwas Zeit. Geometrisches Level-of-Detail (LOD) ist ein bis heute nicht befriedigend gelöstes Problem beim Rasterverfahren.

Moderne Raytracing-Algorithmen skalieren in ihrer Leistung mit der Geometrie nur logarithmisch. Das heißt, für eine doppelte Geometrie ist weniger als die doppelte Rechenleistung notwendig – de fakto skaliert die Framerate nur mit der Zielauflösung, (fast) unabhängig von der Komplexität des berechneten Modells. Dies hat einige angenehme Nebeneffekte, zum Beispiel dass man auf geometrisches Level-of-Detail verzichten kann, jedenfalls aus Performance-Sicht (zur Aliasing-Vermeidung ist dann doch ein geometrisches LOD anzuraten).

Man rechnet beim Raytracing die Farbe pro Bildpunkt aus und bestimmt nicht mehr pro Dreieck und Pixel die Farbe. Das heißt auch, dass es keinen Overdraw gibt. Beim Raytracing ist außerdem zu jedem Zeitpunkt die gesamte Szene bekannt. Beim Raster-Verfahren ist hingegen nur das aktuelle Dreieck in Betrachtung (ältere Dreiecke liegen fertig gerastert im Framebuffer, ihre Geometrie ist verloren – was nachfolgend für Dreiecke kommen, ist noch nicht bekannt). Rasterverfahren, die unsichtbare Pixel gar nicht erst zeichnen, müssen hierfür die komplette Geometrie kennen – auf der Kyro wird sie zwischengespeichert und ausgewertet (den Kacheln zugeordnet und auf Z getestet – außerdem wird pro Pixel gespeichert, welches Dreieck sichtbar ist, um den zweiten Pass zu vermeiden).

Auf anderen Karten ist eine Zwei-Pass-Lösung notwendig, bei der zuerst der Z-Buffer gerendert wird und anschließend mit derselben Geometrie die Farbe bestimmt wird. Solche Umstände kann man sich beim Raytracing sparen – wobei der natürlich der Grundnachteil bleibt, dass auch einfache Szenen per se viel rechenaufwändiger sind als würde man sie mittels Rasterung rendern.

Dass man statische Geometrie in eine Baumstruktur so einordnen kann, dass sich pro Ray relativ schnell die unsichtbaren Objekte wegschneiden lassen bzw. dass sich eine intelligent entwickelte Baumstruktur sehr schnell durchsuchen lässt, ist einsichtig. Die Universität des Saarlandes will nun auch erhebliche Fortschritte bei dynamischer Geometrie erzielt haben. Wie das genau funktionieren soll ist uns nicht klar, andererseits wären wir auch nicht auf die Idee gekommen, bestimmte dynamische Sachen wie sich im Wind wiegende Baumwipfel über eine Transformation des Strahles (und nicht der Geometrie) zu realisieren. Das kann echte dynamische Geometrie natürlich nicht überall ersetzen.

Als "Heiligen Gral" kann man die Schattenberechung sehen. Korrekter Schattenwurf erfordert die Kenntnis der gesamten Geometrie. Ob es nun Shadowmaps oder Stencilschatten sind: Man muss hierfür in einem Extra-Pass einen Z-Buffer berechnen. Beim Raytracing kommen die Schatten ganz von selbst, da nicht beleuchtete Flächen bei der Strahlenverfolgung von vornherein keine Farbe (oder eben nur den Ambient-Light-Anteil) zurückgeben. Denn beim Raytracing kann man schnell überprüfen, ob eine Lichtquelle an einem beliebigen Punkt verdeckt ist. Auch der Einfluss halbdurchsichtiger Objekte lässt sich ausrechnen, ähnliches ist beim Rasterverfahren mit Image-based Lighting nur umständlich via Textur-Projektion zu machen. Auch korrekte Spiegel-Effekte oder Lichtbrechungs-Effekte sind mit Raytracing (bis zu einer endlichen Iterationstiefe) kein Problem.

Bei Raster-Grafik lassen sich Einfachreflektionen mittels einem Extra-Renderpass und Cubemapping annähern, Spiegel-in-Spiegel-Effekte würden allerdings ultraaufwändig. Lichtbrechung ist mit Pixelshadern im Prinzip machbar, aber nur innerhalb desselben Dreiecks (oder derselben zusammenhängenden Fläche wie Fächer oder Streifen) einfach. "Pixelshader"-Verfahren sind auch beim Raytracing möglich, wobei unter "Shader" hier ein Unterprogramm verstanden wird, welches zur Berechnung der Farbe (bzw. Farbänderung) beim Auftreffen des Strahls auf einem Objekt ausgeführt wird. Der Vorteil beim "Ray-Shader" besteht darin, dass auch für diesen Shader die Kenntnis der kompletten Szene vorliegt. Was sich damit an Effekten realisieren ließe, ist noch zu erforschen.

Bisher behandeln die Saarland-Raytracing-Lösungen an Geometrie nur Dreiecke. Im Prinzip wäre es möglich, auch Kugeln oder Freiformflächen mathematisch exakt zu berechnen, dies ist jedoch bisher nicht implementiert – und wird vielleicht in der Praxis auch nie notwendig sein, da sich alles hinreichend genau in Dreiecke zerlegen lässt und das Geometriedetail fast nur noch eine Frage des Speichers ist.

Indirekte Beleuchtung und Flächenlichtquellen lassen sich laut der Universität des Saarlandes mittels Raytracing berechnen, indem nach einem bestimmten Verfahren zusätzliche Punktlichtquellen erzeugt werden, die dann für ein Zurückstrahlen erhaltener Energie sorgen. Die dazugehörige Demo lief in Bewegung entweder höchst ruckelig oder mit starkem Aliasing, zeigte aber im Standbild – ohne Bewegung wurden Lichtberechnung und der weiche Schattenwurf verfeinert – dass es tatsächlich möglich ist, einigermaßen korrekte weiche Schatten zu berechnen.

Heutige Rasterverfahren müssen unheimlich tricksen, um den Eindruck weicher Schatten zu bieten – wobei es sich dabei immer nur um Approximationen handelt: Shadowmaps haben Präzisionsprobleme bei bestimmten Winkeln. Immerhin haben Entwickler schon Methoden entwickelt, beim Rendering weicher Raster-Schatten die Performance zu verbessern (in dem nur im Randbereich in voller Auflösung gesampelt wird). Gerasterte Stencilschatten sind korrekt, haben aber harte Ränder und sind in Echtzeit nur bei vergleichsweise grober Geometrie möglich.

"Normales" Raytracing hat ebenfalls harte Schatten, und die Konkurrenz in Form neuer Direct3D10-GPUs bietet die Möglichkeit, transformierte Geometrie zwischenzuspeichern, was die für Stencil-Schatten erforderliche Zweipass-Lösung beschleunigt. Das Problem des begrenzten Geometriedetails bleibt vorerst, da die Shadowvolumes oft von der CPU berechnet werden. Doch wie gesagt gibt es GPU-seitig Verbesserungen und man kann Shadow Volumes auch im Vertex oder Geometry Shader berechnen.

Auch softe Stencil-Schatten sind (mittels mehreren Passes) im Prinzip möglich, in der Praxis aber aus Performancegründen indiskutabel. Beim Raytracing sind Softshadows, die nicht nur soft aussehen, sondern korrekt sind, zwar auch aufwändig – aber auf absehbare Zeit in Echtzeit möglich.

Ein weiteres Gebiet in der Raytracing-Echtzeit-Entwicklung ist die Darstellung volumetrischer Licht-Effekte – beim Echtzeit-Rastering nur als Fake denkbar. Im Prinzip lässt sich mittels Raytracing alles berechnen, wenn das physikalische Verhalten des echten Lichtes bekannt ist. Natürlich hat das seinen Preis in Form sehr vieler Rechenschritte und eines hohen Speicherbedarfs (für Geometrie und den Stack zur Berechung mehrerer Einflüsse auf einen Lichtstrahl). Wie weit sich das treiben lässt – ob man zum Beispiel dereinst nicht mit RGB-Farben sondern mit einem Lichtspektrum rechnet – ist noch überhaupt nicht abzusehen, denn die ernsthafte Forschung für Echtzeit-Raytracing hat gerade erst begonnen.