Bericht: Raytracing in Spielen

Vorwort

Im vergangenen November berichteten wir in einer Meldung [1] über das von Daniel Pohl im Rahmen seiner Diplomarbeit entwickelte „Quake 4: Raytraced“ auf Basis von OpenRT und, der Name sagt es bereits, Quake 4. Clou des Ganzen waren die Grafikberechnung mittels Echtzeit-Raytracing und eine außergewöhnliche Skalierungsfähigkeit auf Multi-Core-Plattformen. In diesem Artikel möchte Daniel Pohl den aktuellen Stand der Entwicklung von Echtzeit-Raytracing anhand einiger Beispiele auf ComputerBase näher beleuchten und auch eine kleinen Ausblick auf die zukünftige Entwicklung geben. Wir wünschen viel Spaß bei der Lektüre.

Einleitung

Stellen Sie sich ein Computerspiel in der Qualität vor, wie man sie aus den Kinofilmen der „Herr der Ringe“-Reihe kennt: Absolut realistische Beleuchtung, Details wie im echten Leben, überzeugende Haut in den Gesichtern der computeranimierten Darsteller und vieles mehr.

Eine der Techniken, die zur Erzeugung der Bilder für die Kinofilme benutzt wurden, ist das so genannte „Raytracing“. Dabei handelt es sich um eine alternative Rendering-Technologie zu der in aktuellen Grafikkarten für Desktop-PCs und Konsolen verwendeten Methode zur Bilderzeugung. Viele Jahre lang wurde dieser alternative Algorithmus nur im Bereich Offline-Rendering benutzt und die Berechnung eines Bildes für Filme nahm – und nimmt teilweise immer noch – mehrere Tage in Anspruch.

Im Jahre 2002 wurde Echtzeit-Raytracing auf dem PC durch die Grafikbibliothek OpenRT ermöglicht. Interaktive Frameraten wurden in hohen Auflösungen möglich, indem man mehrere PCs über ein herkömmliches Ethernet-Netzwerk verband und die Rechenleistung der Rechner so vereint wurde. Nun, fünf Jahre später, ist es dank der Fortschritte in der CPU-Entwicklung möglich, auf einem einzelnen PC Raytracing mit komplexen Szenen und Beleuchtungsverfahren ablaufen zu lassen, wenn auch derzeit noch in recht geringen Auflösungen. Doch mehr Details dazu später.

Raytracing

Wie funktioniert Raytracing? Der Reihe nach! Zuerst wird eine Szenerie im dreidimensionalen Raum festgelegt. Diese soll in dem folgenden Beispiel eine Lichtquelle (in der Skizze als Glühbirne dargestellt) und verschiedene geometrische Objekte enthalten: Eine Kugel, ein Dreieck und einen Würfel.

Für die Lichtquelle wurden gewisse Attribute festgelegt. Beispielsweise ihre Intensität und Farbe und die von der Distanz zwischen Lichtquelle und beleuchtetem Objekt abhängige Abschwächung der Intensität. Für die grüne Kugel soll in einem Shader-Programm festgelegt sein, dass sie grün ist und eine Oberfläche aus reflektierendem Material besitzt. Ferner wird darin überprüft, ob der betrachtete Punkt auf der Kugel beleuchtet ist, oder sich im Schatten befindet. Das Shader-Programm des roten Dreiecks definiert kein außergewöhnliches Material. Die Farbe ist Rot. Zusätzlich testet das Programm, ob der relevante Punkt auf dem Dreieck von der Lichtquelle beleuchtet wird.

Um ein Bild zu Erzeugen, das von der Position des Spielers und dessen Blickrichtung abhängig ist, wird eine virtuelle Kamera in die Szene gesetzt. Sie repräsentiert das Auge des Betrachters.

Der Raytracing-Algorithmus selbst ist ziemlich einfach:

1. Von der virtuellen Kamera aus werden für jedes Pixel des zu berechnenden Bildes so genannte Primärstrahlen geschossen.
   
   
2. Für jeden Strahl wird der Schnittpunkt hitpoint_primary mit der Szenerie errechnet. Dieser ergibt sich, indem man dem Primärstrahl von seiner Ausgangsposition in seine Richtung so lange folgt, bis er auf ein Objekt trifft. In diesem Beispiel ist dies die grüne Kugel. Wir wollen im Folgenden nur diesen einen Strahl weiter betrachten.
   
   
   
   
   
3. Das Shader-Programm des getroffenen Objekts, hier das der grüne Kugel, wird aufgerufen.
   
   
4. Darin wird zuerst die festgelegte Farbe, hier grün, als Basis für weitere Berechnungen genommen.
   
   
5. Da zuvor festgelegt wurde, dass das Material reflektierend sein soll, schießt nun das Shader-Programm einen Reflexionsstrahl vom Schnittpunkt_{Primärstrahl} aus in die reflektierte Richtung.
   
   
6. Der Reflexionsstrahl trifft ein Objekt (hier das rote Dreieck) an der Stelle Schnittpunkt_{Reflexionsstrahl}.
   
   
   
   
   
7. Das Shader-Programm des roten Dreiecks wird aufgerufen.
   
   
8. Um für dieses Shader-Programme festzustellen, ob der betrachtete Punkt beleuchtet ist – also ob Licht bis zu diesem Punkt vordringt –, wird vom Schnittpunkt_{Reflexionsstrahl} in die Richtung der Lichtquelle ein so genannter Schattenstrahl geschossen.
   
   
   
   
   
9. Es wird mit dem Schattenstrahl festgestellt, dass sich ein Objekt (im Beispiel die grüne Kugel) zwischen Schnittpunkt_{Reflexionsstrahl} und der Lichtquelle befindet.
   
   
10. Im Shader-Programm des roten Dreiecks wird daher keine Beleuchtung dazu addiert, wodurch der Punkt einen schattigen Bereich repräsentiert.
    
    
11. Das Shader-Programm des roten Dreiecks gibt also lediglich das im Material als Farbe definierte Rot an das Shader-Programm der grünen Kugel zurück.
    
    
12. Nun befindet man sich wieder im Shader-Programm der grünen Kugel. Die erhaltene Farbe, hier Rot, wird auf den bisherigen Farbwert, Grün, addiert. Abschließend soll noch festgestellt werden, ob der Punkt auf der Kugel beleuchtet wird. Dazu wird ein Schattenstrahl vom Schnittpunkt_{Primärstrahl} in die Richtung der Lichtquelle geschossen.
    
    
    
    
    
13. Durch den Schattenstrahl wird festgestellt, dass sich kein Objekt zwischen Schnittpunkt_{Primärstrahl} und der Lichtquelle befindet.
    
    
14. Ein aus den Attributen der Lichtquelle (Intensität, Distanz) errechneter Wert wird zur bisherigen Farbe des Pixels auf der grünen Kugel addiert.
    
    
15. Der fertig berechnete Farbwert wird an die Kamera gegeben und stellt nun einen Pixel des gerenderten (sichtbaren) Bildes dar: Ein von der Lichtquelle erleuchtetes Pixel der grünen Kugel, auf dem sich ein rotes, nicht erleuchtetes Pixel des Dreiecks spiegelt.

Für ein effizientes Raytracing benutzt man eine Beschleunigungsstruktur, in die die gesamte Geometrie der 3D-Szene gespeichert wird. Dies kann beispielsweise ein BSP-Baum sein. Durch die Verwendung dieser Technik verursacht der ohnehin im fertigen Bild nicht sichtbare blaue Würfel keinen zusätzlichen Berechnungsaufwand.

Quake 3: Raytraced

Im Jahre 2004 habe ich im Rahmen meiner Studienarbeit an einem der ersten Computerspiele gearbeitet, die Raytracing zum Darstellen der Szene benutzen. Als Basis wurden dabei die Daten (Levels, Spielermodelle, Sounds, …) aus „Quake 3“ benutzt. Es war beeindruckend zu sehen, wie einfach Spezialeffekte mit Raytracing zu programmieren waren, die mit der herkömmlichen Grafiktechnologie, genannt „Rasterisierung“, wesentlich mehr Zeit und Arbeit in Anspruch genommen hätten. So ließen sich beispielsweise dynamische und pixelgenaue Echtzeit-Schatten mit nur etwa zehn Zeilen Code wie in der Einleitung beschrieben implementieren.

Das Erzeugen von Schatten ohne störende Artefakte ist in vielen Computerspielen immer noch ein Problem (auch wenn es hier bereits Ausnahmen gibt, die es gut hinbekommen). Hier einige Negativbeispiele von Spielen, die alle im Jahre 2006 veröffentlicht wurden. Da die Schatten lediglich über Annäherungen in eine Textur hinein berechnet werden, kommt es durch die Begrenzung der Auflösung dieser Textur zu sichtbaren Artefakten. Es sind die einzelnen Pixel der so genannten „Shadow Map“ sichtbar. Somit wird der eigentlich erhoffte Effekt der realitätsgetreueren Darstellung durch Schatten gedämpft.

Ein weiterer Vorteil von Raytracing ist, dass man wesentlich mehr Polygone mit einem vergleichsweise zur Rasterisierung geringen Einfluss auf die Framerate benutzen kann. Nach dem Motto „Pimp up your Level“ habe ich einige Wände und Böden aus Quake 3 mit wesentlich mehr Details versehen. Anstatt nur zwei Dreiecke für eine Wand zu benutzen, kamen gleich 5.000 zum Einsatz.

Das Ergebnis: Obwohl die Komplexität der Geometrie in dem modifizierten Quake-3-Level sechsmal so hoch war, verringerte sich die Framerate unter Einsatz von Raytracing lediglich um 25 Prozent. Unter Einsatz von Rastarisierung würde der Geschwindigkeitsverlust ein Vielfaches bedeuten.

Besonders interessant ist die Berechnungskomplexität beim Erzeugen des Bildes in Abhängigkeit von der Anzahl an Dreiecken. Durch die Verwendung des BSP-Baums ist der Einfluss logarithmisch, bei der Rasterisierung dagegen linear.

Man sieht, dass Raytracing (grün) einen gewissen Grundaufwand hat, der bei einer geringen Anzahl an Dreiecken im Vergleich mit der Rasterisierung (rot) hoch ist. Hat man jedoch wesentlich mehr Geometrie in der Szene, so ist es ab dem Schnittpunkt S effizienter, Raytracing anstatt Rasterisierung zum Erzeugen des Bildes zu benutzen. Welchen Wert S genau hat, ist unbekannt und implementierungsabhängig (spekulativ wird oft der Bereich von 1 bis 10 Millionen Dreiecken genannt). Jedoch ist abzusehen, dass mit immer weiter steigendem Detailgrad in Computerspielen dieser Punkt irgendwann erreicht werden wird.

Andere Spezial-Effekte in Quake 3: Raytraced [3] sind Glas, Spiegelungen-in-Spiegelungen, Kameraportale und Bodennebel.

Um Quake 3: Raytraced in Action zu sehen, können Sie sich die folgenden beiden Videos ansehen:

• Video 1 [4]
• Mirror 1 [5]
• Mirror [6]

• Video 2 [7]
• Mirror 1 [6]
• Mirror 2 [8]

Quake 4: Raytraced

Für meine Diplomarbeit wollte ich analysieren, wie sich ein moderner 3D-Shooter aus dem Jahre 2005 mit Raytracing verhält. Zu diesem Zweck wurde „Quake 4“ von den Firmen „Raven Software“ und „id Software“ gewählt.

Als weiterer Arbeitsbereich wurden Algorithmen erfunden, um eine Kollisionserkennung über Strahlen zu ermöglichen. Eine polygongenaue Kollisionserkennung für Schusswaffen wurde 2004 in dem Spiel „Doom 3“ implementiert und war zu dieser Zeit eine Neuheit im Gaming-Bereich. Mit Raytracing kann man dies sehr einfach implementieren. Für sogenannte Direct-Hit-Waffen kann man beispielsweise das Ziel durch einen einzigen Strahlschuss polygongenau feststellen. Dies funktioniert dabei mit genau den gleichen Mechanismen und Datenstrukturen wie die Bestimmung des Farbwerts beim Rendern des Bildes. Es ist also kein zusätzlicher Programmieraufwand nötig, um diesen Test gegen die gesamte Szene inklusiver aller darin vorkommenden dynamischen Objekte (z. B. umherfliegende Raketen) durchzuführen. Es kann also davon ausgegangen werden, dass die polygongenaue Treffererkennung in allen Spielen, die Raytracing benutzen, automatisch mit enthalten sein wird.

Für das Spielermodell wurde eine Kugel (Bounding Sphere) um den Spieler herum benutzt, die wie bei einem Radar durch viele einzelne Strahlen approximiert wurde. Dabei wird beispielsweise festgestellt, ob der Spieler zu nahe an ein Objekt (z. B. eine Wand) gelaufen ist. Das Vorgehen dabei ist, dass eine Bewegung von der alten Position des letzten Frames zu der Position des aktuellen Frames nur dann erlaubt wird, wenn jeder der Strahlen eine minimale Länge von X (in Q4RT: 32) hat. Das bedeutet also, dass sich vom Zentrum des Spielers aus mit dem Abstand X kein weiteres Kollisionsobjekt befinden darf. Nähere Details zu den Algorithmen gibt es in der GameStar/Dev (Ausgabe 04/2006).

Nun möchte ich Ihnen einen interessanten Spezialeffekt noch näher vorstellen: Wasser. Wie man es aus der Natur kennt, sollte dieses die Umgebung spiegeln und es sollte möglich sein hindurch zu sehen, wobei sich das Licht selbstverständlich brechen sollte. Bewegtes Wasser sollte nicht komplett flach aussehen. Man ist daran gewohnt, Höhenunterschiede in den Wellen zu sehen. Ich möchte hier einige Beispiele von Wasser in Spielen der letzten Jahre zeigen. Natürlich war es notwendig diese „Optimierungen“ vorzunehmen, damit das Spiel schnell genug gerendert werden konnte. Dies soll daher keine Kritik an den Spielen oder den Herstellern sein. Es soll lediglich aufzeigen, wie Wasser heutzutage in einigen Spielen aussieht, was daran fehlt und wie es in Spielen mit Raytracing aussehen könnte.

Das Wasser in „Quake 4: Raytraced [9]“ wird folgendermaßen dargestellt: Um eine Reflexion oder eine Refraktion von Licht vorzunehmen, wird der auf den Wasser-Shader auftreffende Strahl entsprechend der Normale an dieser Auftreffposition gespiegelt bzw. gebrochen. Hat man nun eine flache Ebene für das Wasser definiert, so ist die Normale an allen Punkten dieser Ebene gleich. Um jedoch auch Welleneffekte zu bekommen, wurde ein animiertes Set an Texturen benutzt, welches in RGB-Farben kodierte Normalen enthält, die anstatt der geometrischen Normale – die überall auf dem Wasser gleich wäre – benutzt werden. Dementsprechend werden der Reflexions- und der Refraktionsstrahl an dieser neuen Normale gespiegelt bzw. durch die Wasseroberfläche hindurch gebrochen. Das Ergebnis:

Beispiele aus Q4RT gibt es in diesem Video zu sehen:

• Video [10]
• Mirror 1 [11]
• Mirror 2 [12]
• Mirror 3 [13]

Performance

Warum aber sieht man bisher kein Raytracing in kommerziellen Spielen? Das Problem dabei ist in erster Linie noch immer die Geschwindigkeit. Das Berechnen der Effekte alleine über die CPU ist nicht so schnell wie bei der Nutzung einer eigens für diesen Zweck entwickelte Hardware, so wie es bei aktuellen Grafikkarten mit dem Rasterisierungs-Algorithmus der Fall ist. Aber die Entwicklung der CPUs geht schnell voran. Vergleicht man die verfügbare Rechenleistung für Q3RT im Jahre 2004 und mit der derzeit aktuellen Hardware, liegt der Faktor höher als vier. Die neue Quad-Core-CPU von Intel befindet sich auf dem Markt und die Effizienz bei der gleichen Taktrate hat sich seitdem um etwa 30 Prozent verbessert. Ein großer Vorteil von Raytracing ist, dass es sich perfekt für Parallelisierung eignet.

Wie in der Einleitung beschrieben, wird für jedes Pixel des Bildes ein Strahl durch die 3D-Szene geschossen. Rendert man nun ein Bild in der Auflösung 640×480, so hat man etwa 300.000 Strahlen. Jeder von diesen kann unabhängig von den anderen berechnet werden. Das bedeutet: Man kann beispielsweise das Bild in vier Teile aufteilen und jeden Core der Quad-Core-CPU einen eigenen Bereich ausrechnen lassen, ohne auf Zwischenergebnisse der anderen Cores warten zu müssen. Daher skaliert die Performance mit der Anzahl der Cores in Quake 4: Raytraced in Verbindung mit OpenRT auf Intels Quad-Core-Prozessor „Core 2 Extreme QX6700“ (ComputerBase-Test [14]) hervorragend. Die folgenden Benchmarks wurden in einer Auflösung von 256×256 im Quake-4-Level „Over The Edge (Q4DM7)“ mit voller Beleuchtung (98 Lichtquellen) vorgenommen.

Bilder pro Sekunde 4 Kerne 16,9 2 Kerne 8,6 1 Kern 4,4 Angaben in Bildern pro Sekunde (FPS)

Skalierungsfaktor 4 Kerne 3,84 2 Kerne 1,96 1 Kern 1,00 Angaben in Faktor

Probleme

Leider gibt es nicht nur Vorteile durch Raytracing. Derzeit gibt es Geschwindigkeitsprobleme beim Rendern von dynamischen, komplett zufälligen Änderungen in 3D-Szenen, die nicht vorherberechnet werden können. Doch die Forschungen in diesem Gebiet gehen weiter und im Bereich der Dynamik von Skeletal-Animation (z. B. bei Spielermodellen) gibt es bereits vielversprechende Lösungen [15].

Zukunft

Raytracing hat das Potenzial, die weitläufig eingesetzte Rendering-Technologie auf Desktop-PCs zu werden. Die Anzahl der CPU-Kerne steigt und Prototypen einer Spezialhardware für Raytracing [16] zeigen beeindruckende Ergebnisse bezüglich der Geschwindigkeit: Mit einem mit 90 MHz getakteten Prototypen konnte in etwa die Geschwindigkeit eines virtuellen Pentium 4 mit 10 GHz erreicht werden. Eine für den Massenmarkt angefertigte Karte könnte höher getaktet werden, mehrere Raytracing-Cores in einer GPU enthalten, mehrere GPUs auf einer Karte besitzen und man könnte mehrere dieser Karten in einen Rechner einbauen. Schon ist man sehr schnell bei flotten Frameraten in hohen Auflösungen.

Es ist immer noch ein weiter Weg, bis die Grafik in Computerspielen wie in den „Herr der Ringe“-Kinofilmen aussieht, aber wir nähern uns und haben eine spannende Zeit vor uns!

Über den Autor

Daniel Pohl [17], 26 Jahre alt, hat vor kurzem sein Informatik-Studium an der Universität Erlangen mit Erfolg abgeschlossen. Jetzt sucht er einen Arbeitsplatz im Bereich der Computerspiele-Industrie oder einen Sponsor für eine Fortsetzung der Forschungen an Spielen mit Raytracing.