Raytracing in Spielen II: Das Reich der Strahlen macht Fortschritte

 7/8
Daniel Pohl
117 Kommentare

Beispiel 1

Lasst uns ein typisches Spieleszenario aus Quake 4 mit einer zusätzlichen, spiegelnden Kugel, die sich weit weg vom Auge des Betrachters befindet, annehmen:

Raytracing vs. Rasterisierung
Raytracing vs. Rasterisierung

Man könnte nun alles außer der Kugel mittels Rasterisierung rendern und nur Raytracing auf die Kugel anwenden. Um dies zu tun, benötigt man dennoch:

  • Einen schnellen Raytracer
  • Aktuelle Beschleunigunsstrukturen (z.B. BSP-Baum, BVH-Tree, ...) für die gesamte Szene

Wenn die Spielwelt sehr komplex ist, dann wird man vermutlich mehr Dreiecke rasterisieren als man Strahlen benötigt hätte, um dies zu tun – ein reiner Raytracer wäre also effizienter gewesen. Doch lassen wir diese Annahme einmal außen vor, so haben wir in diesem Szenario unter der Annahme, dass der Rasterisierer alle Sichtbarkeitstests auflöst, alle Primärstrahlen „gespart“.

Beispiel 2

Der obige Screenshot sieht ziemlich langweilig aus, da er keinerlei Beleuchtung und Schatten berücksichtigt. In dem unteren Beispiel ist nun jeder Pixel mit durchschnittlich drei bis fünf Lichtquellen gleichzeitig beleuchtet.

Raytracing vs. Rasterisierung
Raytracing vs. Rasterisierung

Wenn man Raytracing benutzt, um alle Schatten korrekt zu berechnen, dann würde jeder Pixel einen Primärstrahl und vier Schattenstrahlen benötigen. Würde man stattdessen Rasterisierung benutzen, um die gleiche Bildqualität zu erzeugen, würde man nur den einen Primärstrahl „sparen“. Die Ansätze der Rasterisierung in Bezug auf Korrektheit und Genauigkeit sind bei Schatten, Spiegelungen und Brechungen nicht akkurat genug. Speziell wenn man danach strebt, immer höhere Bildqualitäten zu erreichen, dann verpufft die Einsparung durch Rasterisierung für die Sichtbarkeitsberechnung (also anstatt Primärstrahlen) immer mehr.