Implementierung eines bidirektionalen Path Tracers auf GPUs

Transkript

1 Implementierung eines bidirektionalen Path Tracers auf GPUs BACHELOR THESIS zur Erlangung des Grades Bachelor of Science in Computer Science Vorgelegt von: Philipp Frericks (Matrikelnr ) 1. Betreuer: Prof. Dr. André Hinkenjann 2. Betreuer: M.Sc. Thorsten Roth Abgabe der Arbeit:

2 Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig durchgeführt und abgefasst habe. Quellen, Literatur und Hilfsmittel, die von mir benutzt wurden, sind als solche gekennzeichnet. Sankt Augustin, den i

3 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Grundlagen und Begrisdenitionen Grundlagen der physikalisch basierten Bildsynthese Geometrische Grundlagen Physikalische Gröÿen Begrie und Konventionen Physikalisch basierte Bildsynthese Rendergleichung & Messgleichung Pfadintegral Monte Carlo Rendering Monte Carlo Methode Importance Sampling Multiple Importance Sampling Russian Roulette Sampling Path Tracing Bidirektionales Path Tracing Verfahren Vergleich mit PT GPGPU & OptiX GPGPU OptiX Verwandte Arbeiten Eziente Nutzung der SIMD-Architektur Speicher Implementierung Bestehender Path Tracer Details der Implementierung Bewertung ii

4 Inhaltsverzeichnis iii 4.2 Zielsetzung Umsetzung Auswertung der Ergebnisse Beispielszenen Performanz Strahlen pro Sekunde Frames pro Sekunde Konvergenz und Robustheit Streets of Asia Conference Room (Conf1) - Indirekte Beleuchtung Conference Room (Conf2) Ring - Kaustiken Schlussfolgerungen Visueller Vergleich Zusammenfassung und Ausblick 60 Literaturverzeichnis 62

5 Abbildungsverzeichnis 2.1 Beziehung zwischen geometrischen Maÿeinheiten Vollständiger Transportpfad Diuse, annähernd spekulare und kombinierte BRDF Bildebene Messfunktion im Pfadraum Importance Sampling Skizze Importance Sampling gemäÿ BRDF und in Richtung der Lichtquellen Ergebnis des Multiple Importance Sampling Vertex Sampling Vollständiges PT-Sample Berechnung des Beitrages von impliziten und expliziten Pfaden beim PT Vollständiges BDPT-Sample Kaustik OptiX-Szenengraph Suboptimale Auslastung der Recheneinheiten einer GPU Verbesserte Auslastung der Hardware durch Pfaderneuerung Stufen des Wavefront-Ansatzes Grasche Benutzeroberäche Flussdiagramm der Anwendung Payload eines PT und BDPT Pfades im Vergleich Konvergierte Beispielszenen Strahlen pro Sekunde bei wachsender maximaler Pfadlänge Frames pro Sekunde bei wachsender maximaler Pfadlänge Konvergenz und Robustheit in SoA2, Rekursionstiefe 2 & SoA2 nach 500 Samples pro Pixel im Vergleich, Rekursionstiefe 2 & Konvergenz und Robustheit in SoA2, Rekursionstiefe Conference Room (Conf1) nach 1000 Samples pro Pixel im Vergleich, Rekursionstiefe 2 & Conference Room (Conf1) nach 1000 Samples pro Pixel im Vergleich, Rekursionstiefe Konvergenz und Robustheit in Conf2, Rekursionstiefe iv

6 Abbildungsverzeichnis v 5.10 Conference Room (Conf2) nach 600 Samples pro Pixel im Vergleich, Rekursionstiefe Konvergenz und Robustheit in der Ring-Szene, Rekursionstiefe Ring nach 600 Samples pro Pixel im Vergleich, Rekursionstiefe Visueller Vergleich von PT und BDPT nach 10 Sekunden Visueller Vergleich von PT und BDPT nach 60 Sekunden

7 Tabellenverzeichnis 5.1 Strahlen pro Sekunde bei wachsender maximaler Pfadlänge Frames pro Sekunde bei wachsender maximaler Pfadlänge vi

8 Kapitel 1 Einleitung Die Bildsynthese ist ein essentieller Bestandteil der Computergrak. Im Kontext dieser Arbeit bezeichnet Bildsynthese (Rendering) die Erzeugung eines zweidimensionalen Bildes aus der Beschreibung einer dreidimensionalen Szene aus der Sicht eines Betrachters (vgl ). Dabei wird in erster Linie die Verteilung von Licht innerhalb der betrachteten Szene simuliert. Zu diesem Zweck existieren verschiedene Verfahren, die jeweils einen Mittelweg zwischen Performanz und physikalischer Korrektheit darstellen. In Fällen, in denen eine hohe Bildwiederholungsrate wichtiger ist als die physikalisch korrekte Beleuchtung einer Szene, können eine Reihe von Beleuchtungseekten häug nicht, oder nur durch aufwendige Vorverarbeitung (Preprocessing) dargestellt werden. Dies betrit in der Hauptsache Eekte, die durch indirekte Beleuchtung entstehen. Beispiele hierfür sind Schatten, Spiegelungen, Kaustiken oder das sogenannte color bleeding, das Ausbluten von Farben auf benachbarte Flächen. Um die Resultate der indirekten Beleuchtung im Ergebnisbild zu erhalten, muss ein Simulationsverfahren gewählt werden, welches die Ausbreitung von Licht in einer Szene physikalisch korrekt simuliert. In diesen Fällen wird von globaler Beleuchtung gesprochen. Das Ziel solcher Verfahren ist es, ein Bild der betrachteten Szene zu generieren, das von einer Fotograe derselben Szene nicht mehr zu unterscheiden ist. Ein solches Verfahren ist das sogenannte Path Tracing (im Folgenden PT). Hierbei werden Strahlen vom Standpunkt des Betrachters in die Szene geschossen und innerhalb der Szene reektiert, bis eine Lichtquelle getroen wird. Auf diesem Weg wird Licht von der Lichtquelle durch die Szene zum Auge des Betrachters transportiert (vgl. 2.3). Eine Erweiterung dieses Verfahrens ist das bidirektionale Path Tracing (im Folgenden BDPT). Zusätzlich zu den Strahlen vom Betrachter, werden dabei auch Strahlen von den Lichtquellen in die Szene verfolgt und mit den Strahlen vom Betrachter verbunden. Auf diese Weise lassen sich einige besonders schwierige Beleuchtungsszenarien zum Teil deutlich besser simulieren (vgl. 2.4). Nachfolgend wird auf die Motivation und Zielsetzung dieser Arbeit eingegangen. In Kapitel 2 werden umfangreich die theoretischen Grundlagen der physikalisch basierten Bildsynthese vermittelt. Dazu gehören unter anderem auch Monte Carlo Methoden, sowie die theoretische Betrachtung von PT und BDPT. Abschlieÿend wird eine Einführung in die 1

9 Kapitel 1 Einleitung 2 Besonderheiten von GPGPU (General Purpose Computation on Graphics Processing Unit) und dem in dieser Arbeit verwendeten Ray Tracing Framework OptiX von NVIDIA gegeben. Kapitel 3 behandelt verwandte Arbeiten und zeigt auf, wie die betrachteten Verfahren modiziert werden können, um im Zusammenspiel mit den vorgestellten Technologien maximale Performanz zu erreichen. In Kapitel 4 geht es um die Anwendung der in Kapitel 2 und 3 eingeführten Methoden. Konkret wird die Implementierung des Path Tracers vorgestellt, der die Grundlage für diese Arbeit ist. Im Anschluss werden Ziele für die Erweiterung zu einem bidirektionalen Path Tracer festgelegt und deren Umsetzung erläutert. In Kapitel 5 ndet eine Auswertung der Ergebnisse dieser Arbeit statt. Es werden die Implementierungen, soweit möglich, miteinander verglichen. Zuletzt werden in Kapitel 6 ein Fazit gezogen und mögliche weitere Schritte erörtert. 1.1 Motivation Das Verfahren des bidirektionalen Path Tracing ist in der Theorie bereits 1993 von Eric P. Lafortune und Yves Willems eingeführt worden (vgl. [Lafortune u. Willems 1993]). Aufgrund der benötigten Rechenleistung ist es jedoch erst in den letzten Jahren möglich geworden, auf aktueller Consumer-Hardware Bilder in vertretbarer Zeit zu erzeugen. Diese Entwicklung ist vor allen Dingen der Einführung von GPGPU, der Auslagerung allgemeiner Berechnungen auf die GPU, zu verdanken (vgl. 2.5). Während es bereits mehrere GPUbasierte Path Tracer gibt, sind nach Kenntnis des Autors zur Entstehungszeit dieser Arbeit nur wenige bidirektionale Path Tracer vollständig auf GPUs implementiert. Dabei handelt es sich in erster Linie um Ergebnisse wissenschaftlicher Arbeiten (vgl. [Novak et al. 2010] und [van Antwerpen 2011a]). Die Ergebnisse der genannten Arbeiten haben gezeigt, dass die Implementierungen von BDPT auf GPUs selbst optimierte Implementierungen auf der CPU bezüglich der Geschwindigkeit um eine Gröÿenordnung übertreen. Problematisch ist allerdings, dass GPUs sich in ihrer Architektur wesentlich von CPUs unterscheiden und eine dementsprechende Anpassung der implementierten Algorithmen notwendig ist. [Novak et al. 2010], [van Antwerpen 2011a], [van Antwerpen 2011b] und [Laine et al. 2013] präsentieren Maÿnahmen, um eine möglichst hohe Performanz zu erreichen (vgl. Kapitel 3). Es wäre wünschenswert, durch die Verwendung moderner Hardware und die Anwendung der in den Arbeiten vorgestellten Optimierungen zu einer interaktiven Beleuchtungssimulation zu gelangen, die Bilder in fotorealistischer Qualität annähernd in Echtzeit generiert. 1.2 Zielsetzung Ziel dieser Arbeit ist die Erweiterung eines bestehenden Path Tracers zu einem bidirektionalen Path Tracer. Dabei soll eine Antwort darauf geben werden, ob und wie ein bidirektionaler Path Tracer ezient auf einer GPU implementiert werden kann. Da es sich bei

10 Kapitel 1 Einleitung 3 BDPT um eine Form der Monte Carlo Integration handelt, sind die erzeugten Bilder zu Beginn verrauscht und konvergieren nur langsam zu einem rauschfreien Ergebnisbild. Wie diese Konvergenzzeit minimiert werden kann, ohne das Ergebnis zu verfälschen, wird eines der behandelten Themen dieser Arbeit sein. Ein Kernthema der Arbeit wird dagegen der Vergleich zwischen dem bestehenden Path Tracer und der bidirektionalen Variante sein. Es soll geprüft werden, ob durch die Erweiterung die in bestimmten Fällen zu erwartende Reduzierung der Konvergenzzeit eintritt. Die Implementierung des bidirektionalen Path Tracers im Rahmen dieser Arbeit soll dabei in erster Linie als Entwurf und Grundlage für eine spätere Vervollständigung dienen und erhebt keinen Anspruch auf umfassende Funktionalität oder Fehlerfreiheit. Es sollen jedoch bereits erste Bilder generiert und mit dem zugrunde liegenden Path Tracer verglichen werden (vgl. Abschnitt 4.2).

11 Kapitel 2 Grundlagen und Begrisdenitionen Dieses Kapitel bietet einen Einblick in die Theorie der physikalisch basierten Bildsynthese. Zunächst werden mathematische und physikalische Grundlagen und Gröÿen, sowie einige Begrisdenitionen und Konventionen vermittelt, die im weiteren Verlauf dieser Arbeit eine Rolle spielen werden. Anschlieÿend wird das Monte Carlo Rendering untersucht, welches die Basis für PT und BDPT bildet. Dann werden die jeweiligen Algorithmen im Detail erläutert und eine Einführung in die Architektur und Programmierung von GPUs gegeben. 2.1 Grundlagen der physikalisch basierten Bildsynthese Bevor die Algorithmen des PT oder BDPT im Detail erläutert werden können, müssen zunächst einige mathematische und physikalische Grundlagen vermittelt werden. Da es sich um physikalisch basierte Bildsynthese handelt und eine annähernd korrekte Simulation der Ausbreitung von Licht das primäre Ziel der Arbeit ist, werden einige Gröÿen aus dem Bereich der Optik herangezogen. Des Weiteren werden Begrie deniert und Konventionen vereinbart, die im Rahmen dieser Arbeit gelten sollen Geometrische Grundlagen PT und BDPT sind strahlbasierte Verfahren zur Beleuchtungssimulation. Auÿerdem wird die Szene meist durch geometrische Objekte beschrieben. Um die hier behandelten Sachverhalte nachzuvollziehen, werden Grundkenntnisse der linearen Algebra vorausgesetzt. An dieser Stelle sind deshalb nur die Begrie Raumwinkel und projizierter Raumwinkel näher erläutert. Der Raumwinkel beschreibt allgemein die Gröÿe des Raumbereichs, der von einem Kegelmantel aufgespannt wird. Dabei hängt die Gröÿe des Raumwinkels von der Grundäche des 4

12 Kapitel 2 Grundlagen und Begrisdenitionen 5 jeweiligen Kegels ab. Die Beziehung zwischen Fläche, Raumwinkel und projiziertem Raumwinkel wird in Abbildung 2.1 dargestellt. da(x) ist die Grundäche des Kegels, dσ( ω) ist der zugehörige Raumwinkel und dσ ( ω) ist der projizierte Raumwinkel. Abbildung 2.1: Beziehung zwischen den Einheiten Fläche, Raumwinkel und projiziertem Raumwinkel; Quelle: [van Antwerpen 2011d] Die Umrechnung zwischen den jeweiligen Einheiten ist deniert durch dσ ( ω) = ω n dσ( ω) = G(x x ) da(x) (2.1) G(x x ) heiÿt der geometrische Faktor und ist deniert als G(x x ) = V (x x ) ω n ω n x x 2 (2.2) V (x x ) ist der sogenannte Sichtbarkeitsfaktor. Er ist 1, wenn die Punkte x und x direkt verbunden werden können, ohne dabei ein anderes Objekt zu schneiden, und sonst Physikalische Gröÿen Da es sich bei Licht um eine Form der Strahlung handelt, bietet dieser Abschnitt einen Überblick über einige Gröÿen der Radiometrie. Strahlungsuss (engl. ux): Strahlungsuss oder Lichtstrom Φ bezeichnet eine Strahlungsmenge Q pro Zeiteinheit dt und wird in Watt angegeben. Φ = dq dt (2.3)

13 Kapitel 2 Grundlagen und Begrisdenitionen 6 Bestrahlungsstärke und Abstrahlungsstärke (engl. irradiance und radiosity bzw. radiant exitance): Die Bestrahlungsstärke oder Beleuchtungsstärke E bezeichnet den auftreenden Strahlungsuss pro Einheitsäche da. Emittiert eine Fläche Strahlung, wird die Gröÿe des Strahlungsusses pro Einheitsäche Abstrahlungsstärke B oder M genannt. E = dφ da B = M = dφ da (2.4) (2.5) Strahlungsintensität (engl. radiant intensity): Die Strahlungsintensität oder Lichtstärke I ist der Strahlungsuss pro Einheitsraumwinkel dω. I = dφ dω (2.6) Strahlungsdichte (engl. radiance oder luminance): Die Strahlungsdichte oder Leuchtdichte L ist der Strahlungsuss pro Einheitsäche pro Einheitsraumwinkel. Damit repräsentiert die Strahlungsdichte praktisch den Strahlungsuss innerhalb eines einzelnen (Licht-)Strahls. L(x, ω) = dφ dω da ω N x (2.7) L(x, ω) ist dabei die Strahlungsdichte vom Punkt x in Richtung ω und N x ist die Oberächennormale im Punkt x. Die Strahlungsdichte ist die am häugsten auftretende Gröÿe im Kontext der physikalisch basierten Bildsynthese. Insbesondere die Strahlungsdichte wird im Folgenden häug eine zu bestimmende Gröÿe sein. Um in korrekten physikalischen Einheiten zu arbeiten und eine Basis zum Vergleich mit anderen Renderern zu haben, werden z.b. die Intensitäten von Lichtquellen im dieser Arbeit zugrunde liegenden Path Tracer in den entsprechenden oben genannten Gröÿen deniert Begrie und Konventionen Um Missverständnissen vorzubeugen und häug verwendete, aber im allgemeinen Sprachgebrauch wenig verbreitete Begrie einmalig klar zu denieren, folgen nun zunächst einige Angaben zu den betroenen Inhalten. Die betrachteten Verfahren sind strahlbasiert. Ein Strahl ist im Kontext dieser Arbeit immer die kürzeste Verbindung zwischen zwei Oberächenpunkten der Szenengeometrie. Er

14 Kapitel 2 Grundlagen und Begrisdenitionen 7 ist deniert durch einen Stützpunkt und einen Richtungsvektor. Die Schnittpunkte zwischen einem Strahl und einer Oberäche werden Vertex genannt. Ein Pfad entsteht, wenn mehrere Vertices durch Strahlen miteinander verbunden sind. Dabei startet ein Pfad immer entweder beim Betrachter (im Folgenden auch Auge oder Kamera) oder bei einer Lichtquelle. Pfade von der Kamera werden Kamerapfade genannt, Pfade von einer Lichtquelle Lichtpfade. Verbindet ein Pfad Auge und Lichtquelle, so wird von einem vollständigen Transportpfad gesprochen. Abbildung 2.2 zeigt einen solchen Pfad der Länge fünf. Die Länge eines Pfades bestimmt sich aus der Anzahl seiner Vertices. Wie in Abbildung 2.2 zu erkennen ist, verläuft ein Pfad immer zum Auge. Über einen vollständigen Transportpfad wird Licht transportiert, welches zum nalen Ergebnisbild beiträgt. Abbildung 2.2: Vollständiger Transportpfad der Länge 5; Quelle: [van Antwerpen 2011c] Trit ein Strahl auf eine Oberäche, so ndet eine Interaktion zwischen den beiden statt. Wie im nächsten Abschnitt erläutert, sind die Interaktionsmöglichkeiten im Rahmen dieser Arbeit auf Reexion, Brechung und Absorption beschränkt (vgl ). Dabei gibt es zwei grundlegende Möglichkeiten der Reexion. Wird ein auftreender Strahl bezüglich der Oberächennormale im Schnittpunkt ideal reektiert, liegt eine spekulare Reexion vor. Dieses Verhalten ist z.b. bei perfekten Spiegeln zu beobachten. Wird der auftreende Strahl hingegen aufgespalten und das einfallende Licht in alle Richtungen der Halbkugel über dem Oberächenpunkt reektiert, handelt es sich um eine diuse Reexion. Abbildung 2.3 zeigt, wie durch die Kombination dieser beiden Materialeigenschaften ein komplexes Reexionsverhalten modelliert werden kann. Abbildung 2.3: Diuse und annähernd spekulare Reexionen können zu einem neuen, komplexeren Verhalten kombiniert werden; Quelle: [van Antwerpen 2011c] [Heckbert 1990] führt eine Notation für Transportpfade ein, die auf regulären Ausdrücken beruht. L bezeichnet dabei den Anfangspunkt eines Pfades auf einer Lichtquelle. Es folgt eine Reihe von diusen und spekularen Reexionen, die entweder mit D oder mit S notiert werden. E steht für den letzten Vertex des Pfades, welcher im Auge bzw. auf der Kameralinse des Betrachters liegt. Der reguläre Ausdruck zur Generierung jedes beliebigen

15 Kapitel 2 Grundlagen und Begrisdenitionen 8 Pfades lautet demnach L(S D) E. [Veach 1997] erweitert die Notation um eine komplexere Behandlung von Vertices auf Kameras und Lichtquellen. Die Notation nach [Heckbert 1990] wird im weiteren Verlauf dieser Arbeit verwendet werden, um Pfade mit bestimmten Eigenschaften zu klassizieren Physikalisch basierte Bildsynthese Bei der physikalisch basierten Bildsynthese geht es, im Kontext dieser Arbeit, um die Erzeugung eines virtuellen Fotos aus der Beschreibung einer dreidimensionalen Szene, unter Berücksichtigung physikalischer Gesetze. Dabei werden häug Einschränkungen in Kauf genommen, um den Aufwand der Simulation so gering wie möglich zu halten. In dieser Arbeit wird etwa davon ausgegangen, dass sich Licht nur in Form von Strahlen mit einheitlicher Wellenlänge ausbreitet. Eekte auf Grundlage der Wellenoptik, wie zum Beispiel die Polarisation, oder Eekte, die auf verschiedenen Wellenlängen des sichtbaren Lichts basieren, können daher nicht simuliert werden. Des Weiteren wird davon ausgegangen, dass sich Licht im Vakuum ausbreitet und unendlich schnell bewegt (vgl. [van Antwerpen 2011c]). Unter Vernachlässigung komplexerer Eekte wie participating media oder subsurface scattering beschränkt sich die Interaktion von Licht mit der Szene auf Reexion, Brechung und Absorption des Lichtes an den Oberächen der Szenengeometrie. Wie genau sich einfallendes Licht beim Auftreen auf eine Oberäche verhält, muss in der Beschreibung der Szene für jede Oberäche festgelegt werden. [Nicodemus 1965] schlägt zur Beschreibung der Materialeigenschaften einer Oberäche die Bidirectional Reectance Distribution Function (im Folgenden BRDF) f r = (x, ω o, ω i ) vor. Dabei ist x ein Punkt auf einer Oberäche der Szene, ω i ist die Einfallsrichtung des Lichtes und ω o die Richtung, in die das Licht reektiert wird. f r ist der Bruchteil des einfallenden Lichtes, der nach ω o reektiert wird. Da die Interaktion zwischen Licht und Szene im Kontext dieser Arbeit auf die Interaktion an der Oberäche der Szenengeometrie beschränkt ist, reicht es, die Objekte der Szene durch ihre Oberäche zu beschreiben. Hierzu werden in der Regel Dreiecksnetze verwendet. Eine weitere Gröÿe in der Beschreibung der Szene sind die Lichtquellen. Sie können ebenfalls Teil der Geometrie sein, aber auch körperlos, etwa in Form von Punktlichtquellen oder Environment Maps. Für jede Lichtquelle muss festgelegt werden, wie viel Licht sie in einer bestimmten Richtung oder an einem bestimmten Punkt abstrahlt. Auÿerdem wird zur Berechnung eines Bildes der Szene eine Kamera benötigt. Diese repräsentiert den Betrachter und kann beliebig komplex modelliert werden. Durch die Simulation eines Linsensystems lassen sich Eekte wie eine Vignettierung oder Schärfentiefe erzeugen. In dieser Arbeit wird jedoch eine einfache Lochkamera verwendet werden.

16 Kapitel 2 Grundlagen und Begrisdenitionen Rendergleichung & Messgleichung [Veach 1997] hat gezeigt, dass im Rahmen der physikalisch basierten Bildsynthese jedes Pixel des erzeugten Bildes als Strahlungssensor betrachtet werden kann. Die Bildebene bendet sich dabei zwischen Kamera und Szenengeometrie und ist unterteilt in ein Raster, das letztlich die Pixel des entstehenden Bildes repräsentiert. Abbildung 2.4 verdeutlicht dies. Jeder Oberächenpunkt, der von der Kamera durch die Bildebene hindurch sichtbar ist, sendet Strahlung aus, die im Ergebnisbild gesammelt wird. [Kajiya 1986] stellt mit der sogenannten Rendergleichung eine Formel auf, die beschreibt, wie viel Licht von einem Oberächenpunkt x in eine Richtung ω o ausgestrahlt wird. Abbildung 2.4: Nur Licht, welches durch die Bildebene die Kamera trit, trägt zum Ergebnisbild bei; Quelle: [Lafortune u. Willems 1993] Ein Oberächenpunkt x sendet die Strahlung L o (x, ω o ) in Richtung ω o aus. Diese Strahlung besteht aus der emittierten Strahlung L e (x, ω o ) und der reektierten Strahlung L r (x, ω o ). L o (x, ω o ) = L e (x, ω o ) + L r (x, ω o ) (2.8) L e (x, ω o ) ist nur dann ungleich null, wenn es sich bei der entsprechenden Oberäche um eine Lichtquelle handelt. L r (x, ω o ) ist die Menge an Strahlung L i (x, ω i ), die im Punkt x aus allen Richtungen ω i Ω der Halbkugel S über dem Punkt x einfällt und nach ω o reektiert wird. Es gilt demnach L r (x, ω o ) = Ω L i (x, ω i ) f r (x, ω i, ω o ) dσ ( ω i ) (2.9) Aus Gleichung 2.8 und Gleichung 2.9 ergibt sich die Rendergleichung: L o (x, ω o ) = L e (x, ω o ) + L i (x, ω i ) f r (x, ω i, ω o ) dσ ( ω i ) (2.10) Ω Die Rendergleichung besagt, wie viel Strahlung bzw. Licht einen Oberächenpunkt in einer

17 Kapitel 2 Grundlagen und Begrisdenitionen 10 bestimmten Richtung verlässt. Tatsächlich soll jedoch festgestellt werden, wie viel Licht aus einer bestimmten Richtung auf ein Pixel trit. Dazu führt [Veach 1997] die Sensoremp- ndlichkeit W j (x, ω i ) für jedes Pixel j der Bildebene I ein. Diese Funktion gibt an, wie viel der einfallenden Strahlung aus Richtung ω i im Punkt x auf der Bildebene zum Ergebnisbild beiträgt. Im Fall einer Lochkamera ist W j (x, ω i ) immer gleich eins. Die Gesamtmenge der einfallenden Strahlung auf einem Sensor (Pixel) j wird durch die Messgleichung (measurement equation) beschrieben. I j = IxS W j (x, ω i ) L i (x, ω i ) da I (x) dσ ( ω i ) (2.11) Sowohl die Rendergleichung als auch die Messgleichung integrieren über die Halbkugel S über einem Punkt x. Dementsprechend wird in beiden Gleichungen nur reektierte Strahlung beachtet. Um transparente Materialien zu simulieren, ist auch die Berechnung von Strahlung notwendig, die durch Brechung im Punkt x emittiert wird. Des Weiteren können beide Gleichungen um Komponenten für den Lichttransport innerhalb eines Mediums ergänzt werden. Diese Erweiterungen werden an dieser Stelle nicht berücksichtigt, können aber zum Beispiel in [Pharr u. Humphreys 2004] nachgelesen werden. Die bisher vorgestellten Gleichungen sind in der Einheit des projizierten Raumwinkels formuliert. Um im weiteren Verlauf dieser Arbeit leichter mit den beiden Gleichungen arbeiten zu können, werden sie gemäÿ Gleichung 2.1 zu Funktionen über einer Fläche umgeformt. Die Rendergleichung integriert dann nicht mehr über Richtungen, sondern über alle Punkte der Szenengeometrie M. Die Messgleichung integriert über die Bildebene I. L o (x x ) = L e (x x ) + L i (x x ) f r (x x x ) G(x x ) da(x) (2.12) M Gleichung 2.12 wird die Dreipunktform der Rendergleichung genannt. Sie beschreibt, wie viel Strahlung den Oberächenpunkt x in Richtung x verlässt. f r (x x x ) gibt dabei den Bruchteil des Lichtes an, der vom Punkt x im Punkt x eintrit und in Richtung x reektiert wird. Die entsprechend umgeformte Messgleichung lautet: I j = IxM W j (x x) L i (x x) G(x x ) da(x) da(x ) (2.13) Physikalisch basierte Bildsynthese befasst sich damit, diese Messgleichung für jedes Pixel der Bildebene zu lösen (vgl. [van Antwerpen 2011d]).

18 Kapitel 2 Grundlagen und Begrisdenitionen Pfadintegral Die Rendergleichung (Gleichung 2.12) ist rekursiv in dem Sinne, dass L i auf der rechten Seite des Gleichheitszeichens L o für ein anderes Punktepaar entspricht. Es kann also ein Teil der Gleichung immer wieder durch die Gleichung selbst ersetzt werden. Gleichung 2.14 zeigt dies an einem Beispiel. L o (x 1 x 0 ) = L e (x 1 x 0 ) + L e (x 2 x 1 ) f r (x 2 x 1 x 0 ) G(x 2 x 1 ) da(x 2 ) M + f r (x 2 x 1 x 0 ) L i (x 3 x 2 ) f r (x 3 x 2 x 1 ) G(x 3 x 2 ) da(x 3 ) M M G(x 2 x 1 ) da(x 2 ) (2.14) Die erste Zeile der Gleichung entspricht der Strahlung, die direkt von x 1 nach x 0 emittiert wird. Die zweite Zeile beinhaltet die Strahlung, die durch genau eine Reexion von x 2 über x 1 nach x 0 gelangt. In der dritten Zeile ist die Strahlung, die über mindestens zwei Reexionen nach x 0 gelangt, zusammengefasst (vgl. [van Antwerpen 2011c]). Nach [Veach 1997] lässt sich die Rendergleichung rekursionsfrei schreiben als L o (x 1 x 0 ) = L e (x 1 x 0 ) + k=2 M k l(x 0 x 1 x 2...x k ) da(x 2 )...da(x k ) (2.15) Darin ist l : i=2 M i+1 R die Strahlungsussfunktion, deniert als l(x 0 x 1 x 2...x k ) = k 1 i=1 f r (x i+1 x i x i 1 ) G(x i x i+1 ) L e (x k x k 1 ) (2.16) In dieser Gleichung wird für jede Anzahl i an Reexionen separat die in x 0 eintreende Strahlung evaluiert. Die Sequenz x i...x 0 stellt einen vollständigen Transportpfad dar, über den Licht von x i nach x 0 gelangt. Die Integration über alle Pfade der Länge i liefert die Strahlung, die über alle Pfade der Länge i nach x 0 gelangt. Werden alle möglichen Pfadlängen aufsummiert, ergibt sich die Gesamtstrahlung, die in x 0 eintrit. Mit Hilfe dieser Schreibweise kann die Messgleichung als Integral über allen Transportpfaden geschrieben werden. Ein Transportpfad X k der Länge k besteht dabei aus einer Folge von Vertices x 0...x k I M k. Der Vertex x 0 liegt dabei in der Bildebene I und alle Weiteren auf der Szenengeometrie M. Die Menge aller Transportpfade der Länge k ist deniert als Ω k = I M k und der gesamte Pfadraum ist deniert als Ω = i=1 Ω i.

19 Kapitel 2 Grundlagen und Begrisdenitionen 12 Eine verkürzte Schreibweise für Gleichung 2.13 ist I i = f i (x 0, x 1 ) da(x 0 ) da(x 1 ) (2.17) I M Darin ist f i (x 0, x 1 ) die Messfunktion, deniert als f i (x 0, x 1 ) = W i (x 1 x 0 ) L i (x 1 x 0 ) G(x 0 x 1 ) (2.18) Die Kombination aus Gleichung 2.16 und Gleichung 2.18 liefert eine alternative Messfunktion f i : Ω R, welche über dem gesamten Pfadraum deniert ist. f i (x 0...x k ) = W i (x 1 x 0 ) G(x 0 x 1 ) = W i (x 1 x 0 ) k 1 j=0 k 1 j=1 k 1 G(x j x j+1 ) f r (x j+1 x j x j 1 ) G(x j x j+1 ) L e (x k x k 1 ) j=1 f r (x j+1 x j x j 1 ) L e (x k x k 1 ) (2.19) Abbildung 2.5 verdeutlicht, wie die Messfunktion auf einen Beispielpfad der Länge fünf anzuwenden ist. Gleichung 2.17 kann unter Verwendung von Gleichung 2.19 über dem gesamten Pfadraum formuliert werden (vgl. [van Antwerpen 2011d]). I i = Ω f i (X) dω(x) (2.20) Diese Funktion gilt es mit den Methoden der folgenden Abschnitte zu lösen. Abbildung 2.5: Vollständiger Transportpfad der Länge 5 mit angewandter Messfunktion im Pfadraum; Quelle: [van Antwerpen 2011c]

20 Kapitel 2 Grundlagen und Begrisdenitionen Monte Carlo Rendering In diesem Abschnitt wird untersucht, wie die Messgleichung für jedes Pixel des Ergebnisbildes gelöst werden kann. Dazu wird zunächst die Monte Carlo Methode vorgestellt, mit deren Hilfe das Integral über der Messfunktion angenähert werden kann. Anschlieÿend werden die Optimierungsmethoden Importance Sampling und Multiple Importance Sampling betrachtet, die auf eine schnellere Konvergenz der Monte Carlo Methode abzielen Monte Carlo Methode Um die Messgleichung aus dem vorangegangen Abschnitt lösen zu können, wird ein numerisches Integrationsverfahren benötigt, da die Gleichung über dem hochdimensionalen Pfadraum Ω deniert ist und die Messfunktion möglicherweise nicht kontinuierlich ist. Ein geeignetes Verfahren ist die Monte Carlo Methode nach [Metropolis u. Ulam 1949]. Diese Methode bestimmt zufällige Stichproben des Integrals, um dessen Wert zu approximieren. Im Fall der Messgleichung bestehen diese Stichproben aus zufällig generierten Transportpfaden. Vorausgesetzt wird eine Wahrscheinlichkeitsdichtefunktion p (engl. probability density function; PDF). Mit Hilfe dieser Funktion kann die Wahrscheinlichkeit für ein Ergebnis des Zufallsexperiments ermittelt werden. Es werden dann N Stichproben (Samples) X 1...X N Ω auf Basis von p generiert und zu einem Schätzwert gemittelt: Î i = 1 N N j=1 f i (X j ) p(x j ) (2.21) Der Erwartungswert E p [f(x)] einer Funktion f ist deniert als das arithmetische Mittel der Summe der Produkte der Funktion über einer Verteilung von Werten p(x). E p [f(x)] = D f(x) p(x) dx (2.22) Entspricht der Schätzwert der Monte Carlo Integration dem Erwartungswert, also dem im Durchschnitt korrekten Ergebnis, spricht man von einem erwartungstreuen (unbiased) Schätzer (estimator). Die Abweichung des Schätzwertes vom erwarteten Resultat wird in der Varianz ausgedrückt. Diese ist deniert als die quadratische Abweichung der Resultate eines Zufallsexperiments vom Erwartungswert. V [f(x)] = E[f(x) E[f(x)] 2 ] (2.23) Eine hohe Varianz bedeutet eine hohe Abweichung vom Erwartungswert. Da der Schätzwert für jedes Pixel unabhängig bestimmt wird, zeigt sich die Varianz im Ergebnisbild als Rauschen. Die Qualität der Schätzung verbessert sich mit der Anzahl der Samples N gemäÿ O( N) (vgl. [Pharr u. Humphreys 2004]). Die mathematischen Grundlagen der

21 Kapitel 2 Grundlagen und Begrisdenitionen 14 Monte Carlo Integration sowie verschiedene Methoden zur Erzeugung und Verwendung von Dichtefunktionen werden in [Pharr u. Humphreys 2004] ausführlich behandelt Importance Sampling Importance Sampling bezeichnet eine Technik, die dazu beiträgt, die Varianz der Monte Carlo Methode signikant zu verringern. Die Stichproben aus dem Pfadraum werden, wie im letzten Abschnitt beschrieben, gemäÿ einer Wahrscheinlichkeitsdichtefunktion p erzeugt. Dabei kann grundsätzlich jede Dichtefunktion gewählt werden, solange f(x) p(x) für f(x) 0 endlich ist. Die Varianz ist jedoch umso geringer, je konstanter f(x) p(x) für alle Samples X ist. Ideal wäre demnach eine Dichtefunktion, die proportional zu f(x) ist. Das Ziel des Importance Sampling ist es, p annähernd proportional zu f zu wählen. Im Kontext der Bildsynthese hat eine gute Wahl von p die Eigenschaft, hauptsächlich Transportpfade zu generieren, die einen wichtigen Beitrag zum Schätzwert leisten. Ein Beispiel hierfür wäre, Lichtquellen entsprechend ihrer Helligkeit im Vergleich zur gesamten Helligkeit aller Lichtquellen einer Szene mit unterschiedlicher Wahrscheinlichkeit bei der Berechnung der Beleuchtung einzubeziehen (vgl. [Pharr u. Humphreys 2004]) Multiple Importance Sampling Das Importance Sampling verfolgt das Ziel, eine Dichtefunktion p zu nden, die annähernd proportional zum Ergebnis der Messfunktion f ist. Da f jedoch über den gesamten Pfadraum stark variieren kann, gestaltet es sich häug schwierig, eine solche Dichtefunktion für den gesamten Pfadraum zu nden. Leichter ist es, je nach Situation verschiedene Dichtefunktionen zu wählen. Abbildung 2.6 und Abbildung 2.7 verdeutlichen dies. Zwei Abbildung 2.6: Sampling gemäÿ der BRDF und in Richtung der Lichtquelle; Quelle: [van Antwerpen 2011d]

22 Kapitel 2 Grundlagen und Begrisdenitionen 15 häug verwendete Sampling-Techniken sind das Sampling gemäÿ der BRDF im Punkt x und das Sampling in Richtung der Lichtquelle. Je nach Gröÿe und Position der Lichtquelle, und je nach Oberächenbeschaenheit im Punkt x, liefern beide Methoden Ergebnisse mit verschieden groÿer Varianz. Wird etwa von einer spekularen Oberäche eine explizite Verbindung zu einer kleinen Lichtquelle erzeugt, so ist die Wahrscheinlichkeit für den resultierenden Pfad äuÿerst gering, da die Wahrscheinlichkeit, dass die Lichtquelle genau innerhalb des (sehr) kleinen Raumwinkels der spekularen Reexionsrichtung liegt, gering ist. Aus der gleichzeitig starken direkten Beleuchtung des Punktes x resultiert eine hohe Varianz. Abbildung 2.7 zeigt vier verschieden groÿe Lichtquellen, die vier verschieden diuse Oberächen beleuchten. Im linken Bild ndet die Beleuchtung gemäÿ der lokalen Reexionseigenschaften der Oberächen statt, im rechten Bild wird explizit die Lichtquelle gesamplet. Je nach Oberäche und Lichtquelle lassen sich die Stärken und Schwächen jeder Methode deutlich im Ergebnisbild erkennen. Ziel des Multiple Importance Sampling (MIS) (a) Sampling gemäÿ BRDF (b) Sampling der Lichtquellen Abbildung 2.7: Vergleich zwischen den Importance Sampling Methoden. Links: Sampling gemäÿ der lokalen Oberächeneigenschaften. Rechts: Sampling der Lichtquellen. Es zeigt sich, dass die Stärken und Schwächen beider Methoden häug komplementär sind. Eine Kombination beider Techniken durch Multiple Importance Sampling ist naheliegend; Quelle: [Veach 1997] nach [Veach 1997] ist es, für verschiedene Bereiche des Pfadraumes Ω verschiedene Dichtefunktionen, also Sampling-Methoden, zu verwenden, und diese so zu kombinieren, dass wiederum ein erwartungstreuer Schätzer resultiert. Dazu führt [Veach u. Guibas 1995] eine Gewichtungsfunktion w i (X) ein, mit der der Beitrag eines Transportpfades gemäÿ der verwendeten Sampling-Methode gewichtet wird. Für diese Gewichtungsfunktion gelten zwei Voraussetzungen:

23 Kapitel 2 Grundlagen und Begrisdenitionen 16 f(x) 0 n w i (X) = 1 i=1 p i (X) = 0 w i (X) = 0 (2.24) Nach diesen Voraussetzungen muss es mindestens eine Sampling-Methode geben, die ein Sample X erzeugen kann, wenn f(x) ein positives Ergebnis liefern würde. Auÿerdem müssen sich die Gewichtungen aller Samples, die durch mehr als eine Methode erzeugt werden können, zu eins addieren. Es werden nun nicht mehr alle N Samples nach der selben Methode erzeugt, sondern es wird jedes Sample X i,j anhand der Dichtefunktion p i erzeugt. Sei n die Anzahl der Sampling-Methoden und n i die Anzahl der Samples, die nach der Methode 1 i n erzeugt wurden, dann gilt: Î = n 1 n i n i=1 i j=1 w i (X i,j ) f(x i,j) p i (X i,j ) (2.25) Meist wird zur Aufteilung der Samples auf die verschiedenen Methoden der Pfadraum partitioniert. Die Unterteilung des Pfadraumes in n xe Partitionen Ω i, 1 i n, in denen jeweils ausschlieÿlich die Dichtefunktion p i verwendet wird, heiÿt Stratied Sampling, wenn die Gewichtungsfunktion w i (X) deniert ist als 1, wenn X Ω i w i (X) = 0, sonst (2.26) Eine solche Partitionierung ist jedoch selten optimal und immer auf eine bestimmte Szene ausgelegt. Stattdessen kann die Partitionierung des Pfadraumes dynamisch vorgenommen werden. Ein Sample wird dabei immer nach der Dichtefunktion erzeugt, nach der die Wahrscheinlichkeit zur Erzeugung dieses Samples am gröÿten ist. [Veach 1997] nennt dieses Verfahren die maximium heuristic. 0, wenn p i (X) < p j (X) i > j für alle j w i (X) = (2.27) 1, sonst Nach [Veach 1997] ist die maximum heuristic ein Spezialfall der power heuristic w i (X) = p i (X) β n j=0 p j(x) β (2.28) Für β = 1 heiÿt w i (X) die balance heuristic. [Veach 1997] hat bewiesen, das die balance heuristic die beste Kombinationstechnik ist, soweit keine weiteren Informationen verfügbar sind. Abbildung 2.8 zeigt die selbe Szene wie Abbildung 2.7, diesmal mit den durch die balance heuristic kombinierten Sampling-Methoden.

24 Kapitel 2 Grundlagen und Begrisdenitionen 17 Abbildung 2.8: Sampling gemäÿ der BRDF und in Richtung der Lichtquelle, kombiniert durch die balance heuristic; Quelle: [Veach 1997] Russian Roulette Werden Stichproben des Pfadintegrals mit Hilfe von Monte Carlo Methoden erzeugt, handelt es sich um Zufallsexperimente. Während der Erzeugung eines Transportpfades X werden nacheinander Vertices auf der Oberäche der Szenengeometrie zufällig ermittelt und verbunden. Die Generierung eines Pfades endet, wenn eine maximale Länge erreicht ist oder ein spezielles Ereignis eintritt, welches zur Terminierung eines Pfades führt. Eine Technik, die die Laufzeit der Pfadgenerierung verkürzt, ohne dabei das Ergebnisbild zu verfälschen, wird russian roulette genannt. Dabei wird nach jedem Pfadabschnitt zufällig entschieden, ob der Pfad fortgesetzt oder terminiert wird. Der Beitrag des betreenden Pfades zum Gesamtbild kann bei dieser Entscheidung berücksichtigt werden. Dadurch werden keine Pfade weiterverfolgt, deren Beitrag unter eine gewisse Mindestgrenze gesunken ist. Umgekehrt kann die Wahrscheinlichkeit, dass ein Pfad weiterverfolgt wird, in dessen Beitrag zur Beleuchtung integriert werden. Auf diese Weise können Pfade, die zu besonders schwierigen Beleuchtungseekten führen und daher selten erzeugt werden, angemessen zum Ergebnisbild beitragen Sampling In den letzten Abschnitten wurde diskutiert, auf welche Weise das Pfadintegral durch Monte Carlo Methoden ezient approximiert werden kann. Ein zentraler Aspekt war dabei die zufällige Generierung von Transportpfaden oder Samples. Dieser Abschnitt gibt einen kurzen Überblick über die Techniken zur Generierung solcher Samples.

25 Kapitel 2 Grundlagen und Begrisdenitionen 18 Ein Transportpfad stellt eine Verbindung zwischen Auge und Lichtquelle dar, über die Licht durch die Szene transportiert wird. Dementsprechend benden sich die beiden äuÿeren Vertices eines solchen Pfades im Auge des Betrachters bzw. auf einer Lichtquelle. Diese Vertices werden für gewöhnlich zufällig auf den entsprechenden Oberächen gewählt. Die Wahrscheinlichkeit dafür, diese Vertices zu erzeugen, ist demnach auf eine Fläche bezogen. Alle weiteren Vertices benden sich auf der Szenengeometrie. Es gibt im Allgemeinen drei Methoden, diese Vertices zu erzeugen. Abbildung 2.9 stellt diese Methoden vor. Vorausgesetzt, dass die beiden Vertices x i 1 und x i+1 bekannt sind, kann der Vertex x i erzeugt werden, indem er entweder unabhängig von den beiden anderen Vertices direkt auf der Szenengeometrie gewählt wird (oben links), oder indem er ausgehend von einem der beiden benachbarten Vertices ermittelt wird (z.b. Sampling gemäÿ der BRDF des benachbarten Vertex, untere Hälfte von Abbildung 2.9). Abbildung 2.9: Sampling-Techniken für den Vertex x i. Direkt auf einer Oberäche (oben rechts), von einem vorhergehenden Vertex aus (unten links), oder von einem nachfolgenden (unten rechts); Quelle: [van Antwerpen 2011d] Der Unterschied der Sampling-Techniken liegt in der Einheit der Wahrscheinlichkeiten P. Wird ein Vertex direkt auf einer Oberäche erzeugt, so ist die Wahrscheinlichkeit bezogen auf die Einheitsäche da. Beim sogenannten forward oder backward sampling ist die Wahrscheinlichkeit in der Regel bezogen auf den projizierten Raumwinkel. Um die in den letzten Abschnitten eingeführte Wahrscheinlichkeit p(x) für einen kompletten Pfad zu erhalten, müssen die Wahrscheinlichkeiten alle pro Einheitsäche formuliert werden. Dies führt zum Auftreten des Geometrie-Terms G (vgl. Gleichung 2.2) in den Fällen, in denen von einem anderen Vertex aus gesamplet wird. Die im Folgenden beschriebenen Algo-

26 Kapitel 2 Grundlagen und Begrisdenitionen 19 rithmen verwenden alle eine der in Abbildung 2.9 vorgestellten Methoden zu Erzeugung von Transportpfaden. [van Antwerpen 2011d] behandelt ausführlich die Konvertierung von Wahrscheinlichkeiten bei der Pfadgenerierung, die z.b. auch je nach Kameramodell und Erzeugung des ersten Vertex vom Auge aus eine Rolle spielt. 2.3 Path Tracing In den vorhergehenden Abschnitten wurde erläutert, auf welche Weise die Messgleichung durch das zufällige Generieren von Samples angenähert werden kann. Beim PT handelt es sich um einen Algorithmus, der die bisher vorgestellten Grundlagen zur Erzeugung von Samples nutzt. Dieser Algorithmus soll nun kurz erläutert werden. Abbildung 2.10: Ein vollständiges PT-Sample; Quelle: [van Antwerpen 2011d] Das Path Tracing ist hervorgegangen aus [Cook et al. 1984] und ist das älteste erwartungstreue Verfahren zur globalen Beleuchtung. Anstatt, wie in der Realität, die Verteilung des Lichts von der Lichtquelle aus zu simulieren, starten die Transportstrahlen bei der Kamera und werden rückwärts durch die Szene verfolgt. Dieses Vorgehen hat den Vorteil, dass tatsächlich alle simulierten Strahlen zum Betrachter führen. Der erste Vertex eines Transportpfades wird auf der Oberäche der Kameralinse erzeugt. Die Wahrscheinlichkeit, diesen Vertex zu generieren, ist also auf die Einheitsäche bezogen. Anschlieÿend wird ein Strahl erzeugt, dessen Startpunkt der erste Vertex ist. Die Richtung wird aus dem Schnittpunkt mit der Bildebene in einem bestimmten Pixel ermittelt. Der Strahl wird durch die Szene verfolgt und mit der Geometrie geschnitten, um den nächsten Vertex zu erhalten. Dieser liegt zwar auf der Szenengeometrie, die Wahrscheinlichkeit, diesen Vertex zu samplen, hängt jedoch von dem gewählten Schnittpunkt in der Bildebene ab und muss dementsprechend von der Einheitsbildschirmäche in die Einheitsäche umgerechnet werden (vgl. [van Antwerpen 2011d]). Im weiteren Verlauf des Algorithmus wird der Transportpfad durch das samplen weiterer Vertices verlängert, bis er auf eine Lichtquelle trit und endet. Da das Verfolgen von Strah-

27 Kapitel 2 Grundlagen und Begrisdenitionen 20 Abbildung 2.11: Der Unterschied im Beitrag zwischen impliziten Pfaden (oben) und expliziten Pfaden (unten) liegt lediglich im Beitrag des letzten Vertex; Quelle: [van Antwerpen 2011d] len durch die Szene einen hohen Berechnungsaufwand erfordert, besteht ein PT-Sample aus Ezienzgründen aus mehreren korrelierten Pfaden. Von jedem Vertex des erzeugten Pfades wird eine explizite Verbindung zu einer Lichtquelle generiert, bevor der Pfad anschlieÿend verlängert wird. Solche Pfade heiÿen explizit und haben stets die Signatur E(D S) DL, da die explizite Verbindung von einem spekularen Vertex aus eine Wahrscheinlichkeit von null hätte (vgl. Abbildung 2.7). Abbildung 2.10 zeigt ein vollständiges PT-Sample. Bei der Verlängerung eines Pfades wird die Richtung des nächsten Strahls meist durch die BRDF im aktuellen Vertex bestimmt. Ob ein Pfad verlängert wird, hängt von dem im letzten Abschnitt erläuterten russian roulette ab. Dabei ieÿt in der Regel die Wichtigkeit des aktuell verfolgten Pfades, also dessen Beitrag zum Gesamtbild, in die Entscheidung über dessen Fortführung mit ein. Umgekehrt werden Strahlen, die trotz geringer Chancen im russian roulette fortgeführt werden, automatisch stärker gewichtet. Transportpfade, deren letzter Vertex zufällig auf einer Lichtquelle liegt (ohne dass diese explizit gesamplet wurde), heiÿen implizite Pfade. Der Unterschied zwischen expliziten und impliziten Pfaden liegt in

28 Kapitel 2 Grundlagen und Begrisdenitionen 21 der Einheit der Wahrscheinlichkeit, mit der der letzte Vertex generiert wurde. Bei expliziten Pfaden wird zufällig ein Punkt auf einer Lichtquelle gewählt. Dessen Wahrscheinlichkeit ist also bereits bezogen auf die Einheitsäche und bedarf keiner weiteren Konvertierung mehr. Wird eine Lichtquelle implizit getroen, so beruht die Wahrscheinlichkeit dafür auf dem projizierten Einheitsraumwinkel und muss gemäÿ Gleichung 2.1 umgerechnet werden. Die Wahrscheinlichkeit, einen expliziten bzw. impliziten Pfad zu erzeugen, ist demnach: i 1 P (x 0,..., x i, z) = P A (x 0 ) P A (x j x j+1 )P A (z) j=0 k 1 P (x 0,..., x k ) = P A (x 0 ) P A (x i x i+1 ) (2.29) Dabei ist P A (x) die Wahrscheinlichkeit x zu samplen, bezogen auf die Einheitsäche. Die Berechnung des Beitrages eines Transportpfades zum Gesamtbild ist in Abbildung 2.11 dargestellt. i=0 2.4 Bidirektionales Path Tracing Das Thema dieser Arbeit ist die Implementierung eines bidirektionalen Path Tracers. In diesem Abschnitt wird deshalb der Algorithmus des BDPT kurz erläutert. Dabei soll der Fokus auf der Idee des Verfahrens und dessen Vorteilen gegenüber dem PT liegen. Für eine detaillierte Betrachtung der Berechnung von Wahrscheinlichkeiten und Pfadbeiträgen zum Ergebnisbild sei auf [Veach 1997], [van Antwerpen 2011c] und [van Antwerpen 2011d] verwiesen Verfahren Der im vorigen Abschnitt vorgestellte PT-Sampler verfolgt Strahlen durch die Szene ausschlieÿlich aus Richtung des Betrachters. In Fällen, in denen Lichtquellen von einem Groÿteil der Szenengeometrie aus nicht sichtbar sind (Szenen mit einem hohen Anteil indirekter Beleuchtung), können nur selten explizite Verbindungen zu den Lichtquellen generiert werden. Aus diesem Grund konvergiert das Ergebnisbild nur sehr langsam zu einem rauschfreien Resultat. BDPT ergänzt das PT um die Generierung von Pfaden von der Lichtquelle aus. Unabhängig voneinander werden ein Pfad von der Kamera aus in die Szene verfolgt, und einer von einer Lichtquelle. Anschlieÿend werden die beiden Pfade an ihren Enden miteinander verbunden. Auf diese Weise entsteht wiederum ein vollständiger Transportpfad. Wie schon beim PT, besteht ein Sample beim BDPT aus mehreren korrelierten Transportpfaden. Abbildung 2.12 zeigt ein solches vollständiges BDPT-Sample. Es entsteht durch die

29 Kapitel 2 Grundlagen und Begrisdenitionen 22 explizite Verbindung von jedem Vertex des Augenpfades mit jedem Vertex des Lichtpfades. Ein Transportpfad x 0...x k kann demnach durch k + 1 bidirektionale Sampling-Strategien Abbildung 2.12: Ein vollständiges BDPT-Sample; Quelle: [van Antwerpen 2011d] erzeugt werden. Dabei werden die ersten s Vertices als Teil des Kamerapfades erzeugt, und die übrigen t = k s Vertices als Teil des Lichtpfades. Jede dieser Strategien hat eine unterschiedliche Wahrscheinlichkeitsverteilung innerhalb des Pfadraumes. Die Wahrscheinlichkeit, einen Transportpfad X mit s Vertices auf dem Kamerapfad zu erzeugen, ist p s (X). Jede Sampling-Strategie repräsentiert eine Form des Importance Sampling. Für ein optimales Sampling müssen diese Strategien mittels MIS kombiniert werden. [Veach u. Guibas 1995] leitet dafür die Gewichtungsfunktion w S (X) her als w s (X) = p s (X) β k i=0 p i(x) β (2.30) Dies entspricht der power heuristic. In der Praxis kommt jedoch meist die balance heuristic mit β = 1 zum Einsatz Vergleich mit PT BDPT ist eine Verbesserung des PT. Aufgrund der unidirektionalen Pfadgenerierung lassen sich beim PT einige fortgeschrittene Beleuchtungseekte nicht, oder nur nach sehr langer Laufzeit simulieren. Ein Beispiel dafür sind Szenen mit einem hohen Anteil an indirekter Beleuchtung. Ist eine Lichtquelle vom Groÿteil der Szenengeometrie aus nicht direkt sichtbar, so können keine expliziten Verbindungen erzeugt werden. Dies führt zu einer hohen Varianz im Ergebnisbild, die nur sehr langsam geringer wird. Durch die zusätzliche Generierung eines Lichtpfades gelangt mehr Licht von einer Lichtquelle aus in die Szene. Für ausschlieÿlich indirekt beleuchtete Stellen der Geometrie besteht dann eine höhere Chance, über einen Transportpfad Licht zu empfangen (vgl ). Ein weiteres Beispiel für einen Beleuchtungseekt, der durch PT nur schwer simuliert werden kann, sind Kaustiken. Abbildung 2.13 stellt eine Kaustik dar. Eine Kaustik entsteht allgemein durch Transportpfade mit der Signatur EDS L. Kaustiken resultieren demnach

30 Kapitel 2 Grundlagen und Begrisdenitionen 23 Abbildung 2.13: Eine Kaustik entsteht durch Brechung oder perfekte Reexion; Quelle: [Veach 1997] aus dem Transport über eine Reihe von spekularen Reexionen, gefolgt von einer diusen Oberäche. Da die meisten Transportpfade beim PT durch explizite Verbindungen entstehen, und eine Lichtquelle nur selten explizit von einer spekularen Oberäche gesamplet werden kann (vgl. 2.3), führen Kaustiken in durch PT generierten Bildern zu hoher Varianz. Wird hingegen wie beim BDPT ein Teil des Pfades von einer Lichtquelle aus erzeugt, so stellen Pfade mit dieser Signatur nicht länger ein Problem dar (vgl ). Um jedoch z.b. Pfade der Signatur ESDSL zu erzeugen, werden Verfahren wie das Metropolis Light Transport- oder das Progressive Photon Mapping-Verfahren benötigt, die dem BDPT in bestimmten Beleuchtungssituationen überlegen sind. Sogenannte SDS-Pfade repräsentieren gespiegelte Kaustiken und sind durch BDPT ebenso schwer darstellbar, wie Kaustiken beim PT. Ziel dieser Arbeit ist es unter anderem, Implementierungen des PT und BDPT daraufhin zu vergleichen, ob die theoretisch vorhandenen Vorteile des BDPT sich in der Praxis feststellen lassen. 2.5 GPGPU & OptiX Seit der Entwicklung der Rendergleichung nach [Kajiya 1986] und der Algorithmen zur Erzeugung zufälliger Samples im Pfadraum gab es eine Vielzahl von Implementierungen mit dem Ziel, physikalisch basierte Bildsynthese zu betreiben. Trotz aller Optimierungen an Code und Algorithmen, besteht jedoch erst seit wenigen Jahren die Möglichkeit, physikalische Bildsynthese in hohen Auösungen interaktiv und annähernd in Echtzeit auf Consumer-Hardware zu realisieren. Der Hauptgrund für diese Entwicklung liegt in der Verbreitung des GPGPU durch NVIDIA CUDA (Compute Unied Device Architecture) seit Da die zur Lösung der Messgleichung notwendigen Samples für jedes Pixel unabhängig erzeugt werden, bergen Algorithmen zur physikalischen Bildsynthese ein hohes Maÿ an Parallelität. GPUs sind in ihrer Architektur traditionell auf SIMD (Single Instruction Multiple Data) ausgelegt, bieten demnach also scheinbar ideale Voraussetzungen für

31 Kapitel 2 Grundlagen und Begrisdenitionen 24 die Implementierung von z.b. PT und BDPT. Sie unterscheiden sich dabei jedoch in einigen Punkten signikant von der Architektur einer CPU. Auf diese Unterschiede wird im folgenden Abschnitt eingegangen (vgl. [nvidia 2013]). Anschlieÿend wird das Ray Tracing Framework Optix von NVIDIA kurz vorgestellt, auf dem der in dieser Arbeit zu erweiternde Path Tracer basiert (vgl. [nvidia 2012]). Kapitel 3 geht auf die Herausforderungen der Implementierung von PT und BDPT auf GPUs ein und stellt Optimierungsvorschläge ausgewählter wissenschaftlicher Arbeiten vor GPGPU CPU und GPU unterscheiden sich sehr in ihren angedachten Verwendungsarten. Während die CPU daraufhin optimiert ist, eine einzelne Aufgabe (ein Programm) möglichst schnell zu verarbeiten und nur vergleichsweise selten einen Kontextwechsel zu einem anderen Programm durchzuführen (etwa zum Zweck des simulierten Multi-Tasking), ist eine GPU dazu bestimmt, möglichst viele gleichartige, vergleichsweise kleine Programme gleichzeitig abzuarbeiten. Zu diesem Zweck verfügt eine moderne GPU über bis zu 2688 Rechenkerne (GeForce GTX TITAN, Stand: August 2013). Dabei werden jeweils 32 solcher Rechenkerne zu sogenannten Warps zusammengeschlossen, um sich einen einzelnen Instruction Pointer zu teilen. Alle Threads innerhalb eines Warps führen also den selben Code auf unterschiedlichen Daten aus. Beinhaltet dieser Code eine Fallunterscheidung, so kann es vorkommen, dass einige Threads innerhalb eines Warps einen anderen Ausführungspfad wählen als die Übrigen. Dieser Fall wird Warp Divergence genannt. Die zwei (oder mehr) unterschiedlichen Ausführungspfade werden dann serialisiert, was bedeutet, dass jeweils einige der Threads, und damit der Rechenkerne, inaktiv sind. Eine solche Situation gilt es für eziente Hardwarenutzung zu vermeiden. Ein weiterer Unterschied zwischen CPU und GPU liegt in der Philosophie der Kontextwechsel. Auf der CPU müssen die wenigen verfügbaren Register, die der gerade aktive Prozess belegen kann, beim Kontextwechsel auf einer anderen Ebene der Speicherhierarchie gesichert werden. Erst danach kann ein anderer Prozess gestartet oder fortgeführt werden. GPUs arbeiten nach der Philosophie des Stream Computing. Dabei wird davon ausgegangen, dass zu jedem Zeitpunkt genug Arbeit (in Form von zu bearbeitenden Warps) in einem Pool existiert. Stoÿen die Threads eines gerade aktiven Warps auf eine Stelle im Code, die mit einer gröÿeren Latenz verbunden ist (etwa ein Zugri auf den Hauptspeicher, s.u.), so werden sie vorübergehend inaktiv und stellen die Rechenkerne einem anderem Warp aus dem Pool zur Verfügung. Um diese Kontextwechsel möglichst ezient durchführen zu können, hat jeder Thread innerhalb des Pools seine eigenen Register. Die Gröÿe des Pools und damit die Fähigkeit, Latenzen durch schnelle Kontextwechsel zu verbergen, hängt also von der Anzahl der von jedem Thread belegten Register ab. Es empehlt sich demnach, den Programmcode so zu gestalten, dass jeder Thread möglichst wenige Register verwen-

32 Kapitel 2 Grundlagen und Begrisdenitionen 25 det. Gleichzeitig ist es empfehlenswert, Zugrie auf den Hauptspeicher nach Möglichkeit zu vermeiden. Die Speicherhierarchie einer GPU unterscheidet sich maÿgeblich von der einer CPU. Durch die sehr groÿe Anzahl an Registern und den dadurch ermöglichten schnellen Kontextwechseln entfällt die Notwendigkeit besonders schneller Hauptspeicherzugrie. Diese gehen deshalb mit einer sehr hohen Latenz einher, bieten jedoch auch eine besonders groÿe Bandbreite. Insbesondere ältere Hardware erfordert zusammenhängende Zugrie auf den Hauptspeicher. Greifen zwei Threads innerhalb eines Warps nicht auf benachbarte Speicherstellen zu, so werden die Zugrie serialisiert und die ohnehin schon groÿe Latenz vervielfacht. Neuere Modelle lockern die Anforderung an Speicherzugrie, es ist allerdings trotzdem empfehlenswert, die Zugrismuster nicht willkürlich zu wählen. Mehrere Warps werden zu sogenannten Blöcken zusammengefasst, die sich einen vergleichsweise kleinen lokalen Speicher mit niedrigen Zugriszeiten teilen. Die Kommunikation zwischen Warps kann über diesen Speicher erfolgen. Zwischen zwei Blöcken kann jedoch nur über den Hauptspeicher kommuniziert werden OptiX Abbildung 2.14: Der Szenengraph der in Kapitel 4 vorgestellten Implementierung. Die Knoten unterhalb der LightGroup stehen für eine einzelne Lichtquelle. Ebenso kann es mehrere parallele Instanzen der Knoten unterhalb der GeometryGroup auf der rechten Seiten geben. OptiX von NVIDIA ist ein Ray Tracing Framework, das auf CUDA basiert und von der hardwarenahen Programmierung abstrahiert. Es bietet Methoden und Datenstrukturen für

33 Kapitel 2 Grundlagen und Begrisdenitionen 26 Anwendungen, die auf der Verfolgung von Strahlen und deren Schnitt mit beliebigen Objekten aufbauen. Im Hauptprogramm auf der CPU wird zunächst der sogenannte Kontext initialisiert. In diesem Kontext werden alle Elemente deniert, die während der GPUbasierten Strahlverfolgung eine Rolle spielen. Buer werden verwendet, um Speicher auf der GPU zu reservieren und Daten zwischen GPU und CPU auszutauschen. Ein Beispiel für einen Buer ist das Ergebnisbild, das auf der GPU berechnet wird und über die CPU in die weitere Verarbeitung bis hin zur Anzeige transportiert wird. Des Weiteren lassen sich über den Kontext Variablen denieren, die auf der GPU verwendet werden, aber in der Hauptanwendung auf der CPU manipuliert werden können. Ein Beispiel hierfür ist die Kameraposition. Durch Geometrieknoten werden die Objekte der Szene beschrieben. Diese Objekte sollen später mit Strahlen geschnitten werden. Zur Beschreibung der Interaktion von Geometrie und Strahlen können Materialien deniert werden. Auÿerdem existieren Transformationsknoten, die einer Gruppe von Objekten zugewiesen werden können. Eine Manipulation dieser Knoten wirkt sich auf alle assoziierten geometrischen Objekte aus. Die gesamte Szene wird durch einen Szenengraphen repräsentiert. Abbildung 2.14 zeigt den allgemeinen Szenengraphen der in Kapitel 4 vorgestellten Implementierung gemäÿ der in [nvidia 2012] gewählten Darstellung. Zuletzt wird eine Reihe von Programmen deniert. Für jeden Abschnitt der Strahlverfolgung gibt es einen Programmtyp. Das Programm zur Strahlgenerierung bildet den Einstiegspunkt auf der GPU. In diesem Programm wird im Rahmen dieser Arbeit die Kamera simuliert. Das bedeutet, dass dort alle Transportpfade beginnen. In einer Schleife werden dann die Pfade verlängert bis sie terminieren, und das Ergebnis in einem Buer hinterlegt. Wird im Kameraprogramm ein Strahl in die Szene ausgesendet, so wird für jedes Objekt der denierten Geometrie ein Schnittprogramm ausgeführt. In diesem Programm wird berechnet, ob der gerade verfolgte Strahl ein Objekt getroen hat. Da diese Schnitttests den Groÿteil der Rechenzeit in Anspruch nehmen, bietet OptiX Beschleunigungsstrukturen. Diese Strukturen dienen dazu, möglichst viele Objekte der Szene von vornherein von den Schnitttests auszuschlieÿen, wenn der Strahl nicht in deren Nähe kommt. Abbildung 2.14 zeigt, dass im Rahmen dieser Arbeit Beschleunigungsstrukturen für die Szene verwendet werden. Dabei handelt es sich um sogenannte Bounding Volume Hierarchies (BVH). Nach den Schnitttests steht für jeden Strahl das Objekt und der Punkt fest, in dem der am wenigsten weit entfernte Schnitt aufgetreten ist. Für jeden Strahl-Objekt-Schnitt wird dann das Materialprogramm des betreenden Objektes aufgerufen. Dort wird evaluiert, ob und in welche Richtung der Pfad weiterverfolgt wird, und wie viel des transportierten Lichtes absorbiert wird. Trit ein Strahl kein Objekt, so wird ein Hintergrundprogramm ausgeführt, das im Standardfall den Pfad beendet. Nach der Beendigung eines Materialprogrammes steht die Richtung des nächsten Pfadabschnittes fest und der Programmuss beginnt im Kameraprogramm von Neuem.

34 Kapitel 3 Verwandte Arbeiten Die Implementierung von PT und BDPT auf GPUs scheint auf den ersten Blick naheliegend und eine beinahe triviale Aufgabe zu sein, da die Algorithmen ein hohes Maÿ an Parallelität ermöglichen. Aufgrund der hardwaretechnischen Eigenschaften einer GPU ergeben sich jedoch mehrere Probleme, die die Ezienz einer solchen Implementierung entscheidend beeinussen. Für eine performante Implementierung müssen diese Eigenschaften bei der Anwendung der Algorithmen berücksichtigt werden. Dieses Kapitel stellt daher wissenschaftliche Arbeiten vor, die sich mit den Herausforderungen einer auf GPUs ausgelegten Implementierung physikalisch basierter Bildsynthese befassen. 3.1 Eziente Nutzung der SIMD-Architektur Beim PT werden Transportpfade durch die Szene erfolgt um die Verteilung von Licht zu simulieren. Diese Pfade haben je nach Teilszene und Wichtigkeit, auch durch die Möglichkeit der zufälligen Terminierung durch russian roulette, unterschiedliche maximale Längen. Am einfachsten lässt sich die Parallelität des Algorithmus nutzen, indem ein Thread für jedes Sample gestartet wird. Solche Threads sind, wie in Abschnitt 2.5 erläutert, zu Gruppen von je 32 Threads zusammengefasst und führen den selben Code aus. Terminieren einige dieser Threads vorzeitig, so sind sie bis zur Beendigung des letzten Threads innerhalb eines Warps inaktiv. Die Rechenleistung der GPU wird nicht vollständig genutzt. BDPT ist von diesem Problem noch stärker betroen, da auch die Verbindungen zwischen Kamera- und Lichtpfad je Sample meist in einem Thread generiert werden. Haben die Pfade in jedem Sample eine unterschiedliche Länge, muss jeder Thread verschieden viele Verbindungen erzeugen. [Novak et al. 2010] adressiert das Problem der frühzeitigen Terminierung von Pfaden. Pfade, die im nächsten Iterationsschritt nicht fortgeführt würden, werden vor dieser nächsten Iteration erneuert. Dabei wird allerdings kein vollständig neuer Pfad von der Kameralinse aus erzeugt, sondern der erste Vertex auf der Szenengeometrie des gerade terminierten 27

35 Kapitel 3 Verwandte Arbeiten 28 Pfades als Ausgangspunkt genommen. Dadurch wird verhindert, dass die wenigen terminierten Pfade eines Warps längere Abschnitte von Code ausführen müssen, der sich von dem der übrigen Threads unterscheidet. Um dennoch einen Anti-Aliasing Eekt zu erhalten, für den mehrere Strahlen von der Kamera durch jedes Pixel gesendet werden müssen, wird die Anzahl der Pfaderneuerungen pro Sample limitiert. [Novak et al. 2010] führt dazu die Parameter T r und T c ein. T r bezeichnet die Länge der Phase, in der Pfade erneuert (regeneriert) werden. Dabei ist T r die Anzahl an Vertices, die für jedes Sample während dieser Phase erzeugt werden. Ist diese Zahl für jedes Sample erreicht (was für alle Samples gleichzeitig geschieht), so endet die Regenerationsphase. Es folgt die closing phase T c, in der lediglich der gerade verfolgte Pfad jedes Samples bis zu seiner Terminierung verfolgt wird. T c bezeichnet dabei die Anzahl an Reexionen, die in dieser Phase maximal auftreten dürfen. Wurde ein Pfad danach noch nicht durch russian roulette beendet, so wird der Abbruch erzwungen. Dieses Vorgehen verhindert, dass einige wenige Pfade den Beginn einer neuen Iteration zu lange verzögern können, verfälscht aber auch zumindest theoretisch das Ergebnis der betroenen Stichproben. Abbildung 3.1 verdeutlicht die geringe Nutzung der verfügbaren Recheneinheiten bei einer nicht angepassten Implementierung. Abbildung 3.2 zeigt die Nutzung der Hardware in den beiden Phasen nach [Novak et al. 2010]. Abbildung 3.1: Anzahl der aktiven Threads (grün) und aller Threads (rot) in zwei Beispielszenen im Vergleich. Das Verhältnis zwischen den beiden Werten liefert den Anteil aktiver Threads und liegt zwischen 32% und 35%; Quelle: [Novak et al. 2010] Abbildung 3.2: Die Auslastung der Hardware in den Phasen nach [Novak et al. 2010]. Die Farben repräsentieren die verschiedenen Generationen von Pfaden in einem Sample; Quelle: [Novak et al. 2010]

36 Kapitel 3 Verwandte Arbeiten 29 [van Antwerpen 2011a] greift das Konzept der Pfaderneuerung auf und verbessert das Verfahren in einigen Punkten. Dabei wird die Eigenschaft von NVIDIA CUDA genutzt, nach der Arbeitsaufträge (Threads) in einem sogenannten Stream, einer Art Warteschlange, zur Bearbeitung vorgehalten werden. Terminiert ein Thread, weil der dort verfolgte Pfad terminiert, so wird der Thread aus dem Stream entfernt. Am Ende des Streams wird ein neuer Thread eingestellt, der wiederum ein eigenes Sample erzeugt. Durch diese Stream Compaction genannte Technik, benden sich innerhalb eines Warps stets nur aktive Threads. Dabei wird, bis auf die Endphase des Verfahrens, der Threadpool immer bei einer konstanten Gröÿe gehalten, um Latenzen durch Kontextwechsel verstecken zu können. Die Einreihung neuer Threads am Ende des Streams hat auÿerdem den Vorteil, dass diese Threads gemeinsam in einen Warp sortiert werden können. Da bei der Neugenerierung eines Samples zunächst anderer Code ausgeführt wird als bei der Verlängerung eines Pfades, entfällt die serialisierte Ausführung der entsprechenden Codeblöcke. Zudem haben die sogenannten Primärstrahlen alle eine ähnliche Richtung, was sich positiv auf die Speicherzugrie während der Schnitttests mit der Szenengeometrie auswirkt. Neben der Stream Compaction stellt [van Antwerpen 2011a] ein Verfahren zur ezienteren Auswertung der Verknüpfungen zwischen Kamera- und Lichtstrahlen beim BDPT vor. Wie bereits erwähnt, führen unterschiedliche Pfadlängen zu unterschiedlich vielen Verknüpfungen je Sample, und dadurch zu unterschiedlichen Laufzeiten der entsprechenden Threads. [van Antwerpen 2011a] startet daher einen Thread für jede einzelne Verknüpfung. Ein Problem bei diesem Ansatz ist die Tatsache, dass zur Berechnung der MIS-Gewichtungen für gewöhnlich alle Vertices eines Samples benötigt werden. Diese Schwierigkeit kann durch eine alternative Berechnung der MIS-Gewichtungen umgangen werden, die in 3.2 beschrieben wird. Die Implementierung von PT, BDPT und MLT (Metropolis Light Transport) auf GPUs nach [van Antwerpen 2011a] ist die nach Einschätzung des Autors zur Entstehungszeit dieser Arbeit ezienteste Form der Umsetzung der genannten Algorithmen. 3.2 Speicher [van Antwerpen 2011a] erwähnt bereits, dass die Verfolgung von Strahlen mit einheitlicher Richtung, bzw. Strahlen, die die Beschleunigungsstruktur der Szene ähnlich traversieren, bezüglich der Zugrie auf den Hauptspeicher vorteilhaft ist. Eine solche Kohärenz liegt während der Simulation physikalisch korrekter Beleuchtung allerdings nur während der Verfolgung der Primärstrahlen vor. Der Aufwand, alle weiteren Strahlen gemäÿ ihrer Richtung zu sortieren, hebt den Nutzen dieser Maÿnahme auf moderner Hardware in der Regel wieder auf. In diesem Abschnitt wird daher lediglich erläutert, wie die Ezienz einer Implementierung nach [Laine et al. 2013] anhand eines sogenannten Wavefront-Ansatzes mit geringer Registerbelegung gesteigert werden kann, und wie sich der benötigte Platz im Hauptspeicher einer GPU nach [van Antwerpen 2011b] reduzieren lässt.

37 Kapitel 3 Verwandte Arbeiten 30 In den Implementierungsdetails von [van Antwerpen 2011a] deutet sich bereits eine Softwarearchitektur an, die in [Laine et al. 2013] als Wavefront-Ansatz bezeichnet wird. Kern dieser Arbeit ist die Überlegung, dass die naive Portierung einer CPU-Implementierung auf die GPU zu einer äuÿerst schlechten Performanz führen würde. Ein Programm für die CPU kann ohne weiteres aus mehreren tausend Zeilen zusammenhängendem Code bestehen. Dieser Ansatz ist für GPUs ungeeignet. Wie in Abschnitt 2.5 erwähnt, bestimmt sich die Gröÿe des Threadpools nach der Anzahl der von einem einzelnen Thread benötigten Register. Ist die Menge an Code, die ein Thread auszuführen hat zu groÿ, so besteht die Gefahr, dass auch eine groÿe Anzahl an Registern pro Thread benötigt wird. In diesem Fall ist der Threadpool verhältnismäÿig klein und groÿe Latenzen können nicht durch Kontextwechsel verborgen werden. Eine weitere Gefahr groÿer Programme sind zudem Fallunterscheidungen in gröÿerem Umfang. [Laine et al. 2013] nennt hierfür im Kontext der Bildsynthese die Auswertung von Materialeigenschaften. Je nach Oberäche wird die Interaktion von Geometrie und Strahlen anders berechnet. Besteht dieser Abschnitt des Programmes aus einer Folge von Fallunterscheidungen, so werden nie alle Threads gleichzeitig aktiv sein. Beide eben genannten Probleme werden durch den Wavefront-Ansatz erheblich entschärft. Dabei werden die verschiedenen Schritte der Beleuchtungssimulation auf jeweils eigene, kleinere Programme verteilt, die lediglich einige Ergebnisse untereinander austauschen können. So können etwa Pfadgenerierung, Strahlverfolgung, Auswertung einer Objektinteraktion, Pfaderneuerung und die Verknüpfung von Pfaden durch jeweils eigene Programme realisiert werden, die nacheinander ausgeführt werden. Jedes Programm ist dann auf eine Aufgabe spezialisiert und beinhaltet lediglich nicht signikante Fallunterscheidungen, während es gleichzeitig möglichst wenige Register verwendet. Abbildung 3.3 zeigt die Struktur einer Implementierung des PT-Algorithmus nach dem Wavefront-Ansatz in [Laine et al. 2013]. Abbildung 3.3: Die Stufen des Wavefront-Ansatzes in einer PT-Implementierung. Jedes grüne Element repräsentiert ein eigenes Programm. Die Pfeile verdeutlichen den Ablauf, über die Queues können Programme Ergebnisse und Arbeitsaufträge kommunizieren; Quelle: [Laine et al. 2013]

38 Kapitel 3 Verwandte Arbeiten 31 Um nach der Generierung von Kamera- und Lichtpfaden alle Vertices miteinander verbinden zu können, und um während dieser Verbindungen die MIS-Gewichtungen für alle resultierenden Transportpfade berechnen zu können, werden alle erzeugten Vertices eines BDPT-Samples benötigt. Das bedeutet zum einen, dass alle diese Vertices im Speicher der GPU gehalten werden müssen, und zum anderen, dass der Berechnungsaufwand der Verbindung zweier Vertices von der Länge der jeweiligen Pfade abhängt und damit zu ungleicher Last innerhalb der Threads führt. Um alle Vertices im Speicher zu behalten, muss dieser im Voraus angefordert werden. Demnach können für jeden Pfad nur eine bestimmte maximale Anzahl an Vertices erzeugt werden. Diese Begrenzung der Pfadlänge führt zur Verfälschung des Ergebnisses. Gleichzeitig bieten GPUs nur begrenzte Speicherkapazitäten, in der z.b. auch die Beschreibung der Szene Platz nden muss. [van Antwerpen 2011b] stellt ein alternatives Verfahren zur Berechnung der MIS-Gewichtungen vor. Bei diesem Verfahren werden bei der Erzeugung eines Pfades zusätzliche Werte für jeden Vertex berechnet, die später dazu verwendet werden können, die Verbindung zweier Vertices ohne Einbeziehung aller anderen Vertices des Samples zu gewichten. Dieses Vorgehen ermöglicht die Berechnung einer Verbindung in einem eigenen Thread, ohne Speicherzugrie auf andere Vertices. Dennoch würde bei Anwendung des originalen BDPT- Algorithmus zunächst ein Kamera- und ein Lichtpfad für jedes Sample erzeugt und die Verbindungen anschlieÿend durchgeführt. Dazu müssten alle Vertices nach wie vor gespeichert werden. [van Antwerpen 2011b] beschreibt deshalb eine Modikation des Algorithmus, die Streaming Bidirectional Path Tracing (SBDPT) genannt wird. Dabei wird für jeden Vertex des Lichtpfades ein neuer Kamerapfad erzeugt und die Pfade nach jeder Verlängerung des Kamerapfades verbunden. Dadurch entfällt die Notwendigkeit, mehr als die gerade aktuellen Vertices eines Pfades zu speichern. Die Speicheranforderungen dieses Verfahrens sind allein bestimmt durch die Anzahl gleichzeitig erzeugter Samples und in der Regel auf aktueller Hardware kaum relevant.

39 Kapitel 4 Implementierung Nachdem in den letzten Kapiteln ausführlich die Grundlagen der physikalisch basierten Bildsynthese, sowie deren geeignete Implementierung auf GPUs disktutiert wurde, befasst sich dieses Kapitel mit der Umsetzung der Theorie in die Praxis. Dazu wird zunächst die bestehende Implementierung eines Path Tracers auf Basis von OptiX näher untersucht. Anschlieÿend werden Ziele für die Erweiterung zu einem bidirektionalen Path Tracer festgelegt und abschlieÿend deren Realisierung beschrieben, bzw. die dabei auftretenden Probleme erörtert. 4.1 Bestehender Path Tracer Der Path Tracer, der die Ausgangsbasis für diese Arbeit bildet (im Folgenden der Path Tracer), wurde im Zuge eines Projektes (IVAB) zur realistischen, interaktiven Vorschau von Inneneinrichtungen in Häusern entwickelt (vgl. [Institute of Visual Computing 2013]). Die Implementierung erfolgte unter Verwendung von OptiX. Im Folgenden werden einige Details der Implementierung betrachtet und hinsichtlich ihrer GPU-konformen Umsetzung und Eignung als Grundlage für einen bidirektionalen Path Tracer bewertet Details der Implementierung Der dieser Arbeit zugrunde liegende Path Tracer ist in das umfangreiche Postprocessing Framework GrIP eingebunden (vgl. [Roth et al. 2011]). Dieses Framework übernimmt unter anderem die Generierung einer graschen Benutzeroberäche, welche die Parametrisierung der Anwendung erlaubt. Somit können zur Laufzeit eine Reihe von Optionen, wie etwa die maximale Rekursionstiefe oder die Helligkeit und Position bestimmter Lichtquellen, durch Schieberegler verändert werden. Abbildung 4.1 zeigt einen Screenshot der generierten Oberäche. Die einzelnen Tabs repräsentieren verschiedene Funktionen des Postprocessing Frameworks. Das ausgewählte Tab beinhaltet die Parameter der hier beschriebenen Bildsyntheseverfahren, die während der Laufzeit verändert werden können. Zusätzlich existiert 32

40 Kapitel 4 Implementierung 33 eine Möglichkeit der Steuerung über ein Gamepad. Mit diesem kann primär die Position und Ausrichtung der Kamera modiziert werden, sodass eine Szene interaktiv betrachtet werden kann. Abbildung 4.1: Die grasche Benutzeroberäche des Postprocessing Frameworks GrIP. Über die Schieberegler lassen sich Parameter der Anwendung zur Laufzeit verändern. Bei der Erzeugung von Samples zur Approximation der Messgleichung handelt es sich um Zufallsexperimente. Tatsächlich müssen an mehreren Stellen im Programm zufällige Entscheidungen getroen werden. Zu diesem Zweck bieten die meisten Programmiersprachen bereits Funktionen, mit denen sich vermeintlich zufällige Zahlen oder Zahlenfolgen erzeugen lassen. Der Nachteil dieser Funktionen ist die Tatsache, dass die erzeugten Zufallszahlen meist nicht gleichmäÿig über einen bestimmten Bereich verteilt sind, sondern zu Ballungen neigen. Dies führt im Kontext der physikalisch basierten Bildsynthese zu einer längeren Konvergenzzeit. Um diesen Nachteil zu vermeiden, verwendet der Path Tracer eine eigene Funktion zur Erzeugung von Zufallszahlen. Dabei handelt es sich um die Sobol-Sequenz nach [Sobol 1967] aus der Familie der sogenannten low discrepancy sequences. Die Implementierung der Funktion wurde aus dem Renderer Cycles der Modelliersoftware Blender übernommen. Details zu Sobol-Sequenz und low discrepancy sequences sind in [Pharr u. Humphreys 2004] oder [Waechter 2007] zu nden.

41 Kapitel 4 Implementierung 34 Das Hauptprogramm, welches auf der CPU abläuft, verbindet nicht nur die einzelnen Komponenten wie die Steuerung und das Postprocessing Framework mit dem Path Tracer, es initialisiert und verwaltet auch den Kontext der OptiX-Anwendung. Das bedeutet, es werden alle Elemente der Anwendung im Hauptprogramm deniert und geladen, und zu einem ausführbaren Paket kombiniert. Von besonderer Bedeutung ist dabei der sogenannte Einstiegspunkt. Dabei handelt es sich um das OptiX-Programm, das den Startpunkt der Programmausführung auf der GPU bildet. Im Falle des vorliegenden Path Tracers fällt es diesem Programm zu, Primärstrahlen entsprechend dem Kameratyp zu generieren und deren Verfolgung durch die Szene anzustoÿen. Nach dem Ermitteln von Schnittpunkten und deren Auswertung gemäÿ der lokalen Oberächeneigenschaften in anderen Programmen, erzeugt das Kameraprogramm für jeden nicht terminierten Pfad den nächsten Strahl, oder beendet ihn durch russian roulette. Sind alle Pfade terminiert, wird ihr jeweiliger Beitrag zum entsprechenden Pixel berechnet und einige zusätzliche Ergebnisse für das Postprocessing Framework ermittelt. Daraufhin ist das Kameraprogramm beendet. Das Hauptprogramm auf der CPU startet es nach der eventuellen Aktualisierung der Parameter durch den Benutzer erneut, solange bis der Benutzer das Programm beendet. Wie in Unterabschnitt erklärt, ist eine Anwendung in OptiX in mehrere Programme unterteilt. An dieser Stelle werden davon lediglich einige Wenige näher betrachtet. Ein Miss-Programm deniert das Vorgehen in dem Fall, dass ein Strahl alle Objekte der Szene verfehlt. Der Path Tracer unterstützt die Verwendung von Environment Maps. Diese fungieren als eine spezielle Lichtquelle, so dass Strahlen, die die Szenengeometrie verfehlen, wie solche behandelt werden, die implizit eine Lichtquelle getroen haben. Eine weitere Kategorie von Programmen sind die Materialprogramme. Diese beschreiben die Interaktion von Strahlen und Oberächen. Der Path Tracer unterscheidet dabei sehr allgemein zwischen Lichtquellen und sonstigen Objekten. Es existieren also zwei Materialprogramme. Wird eine Lichtquelle getroen, berechnet das entsprechende Programm die emittierte Strahlung und terminiert den Pfad. Wird ein anderes Objekt getroen, so verzweigt sich der Programmuss je nach Art der Oberäche in die Behandlung von Brechung, sowie spekularer oder diuser Reexionen, und berechnet die Richtung des nächsten Strahls sowie die Werte von BRDF und PDF. Der Path Tracer unterstützt Punktlichtquellen, Environment Maps und eine gerichtete Lichtquelle in Form einer Sonne. Flächenlichtquellen in Form von Kugeln sind prinzipiell verfügbar, waren aber zum Zeitpunkt dieser Arbeit nicht funktionsfähig implementiert. Diverse Parameter zu Environment Maps und der Sonne lassen sich über die grasche Benutzeroberäche zur Laufzeit anpassen. So kann z.b. der Zyklus der Sonne simuliert werden.

42 Kapitel 4 Implementierung Bewertung Die Verwendung von OptiX als Grundlage für die Implementierung eines Path Tracers bietet diverse Vorteile. Das Framework bietet eine Vielzahl an Funktionen, von grundlegenden mathematischen Operationen über Beschleunigungsstrukturen bis hin zur Strahlverfolgung, deren Implementierung dem Programmierer somit erspart bleibt. Des Weiteren ermöglicht OptiX eine automatisierte Verteilung der Anwendung über mehrere GPUs, inklusive Lastverteilung. Zu guter Letzt abstrahiert OptiX von der hardwarenahen Programmierung in CUDA. Die Anpassung des Codes an neue GPU-Generationen und die damit verbundene regelmäÿig notwendige Wartung entfällt also. Die Aufteilung der einzelnen Schritte des PT-Algorithmus in mehrere OptiX-Programme entspricht exakt der Idee des Wavefront-Ansatzes nach [Laine et al. 2013]. Ob OptiX diesen Umstand jedoch zur Steigerung der Ezienz nutzt, kann an dieser Stelle nicht beantwortet werden. Nachteilig wirken sich denitiv die unterschiedlichen Ausführungspfade im universellen Materialprogramm auf die Nutzung der verfügbaren Recheneinheiten aus. Zudem werden keine Maÿnahmen gegen terminierte Pfade getroen. Insgesamt setzt der Path Tracer nur wenige der im vorigen Kapitel genannten Optimierungsstrategien um. Hinsichtlich des Wavefront-Ansatzes muss auf OptiX vertraut werden. Durch eine Aufsplittung der verschiedenen Materialtypen könnten jedoch mehr spezialisierte Programme geschaen werden, die insbesondere auch weniger Register verwenden müssten. Fraglich ist allerdings, ob eine Realisierung der Maÿnahmen aus Kapitel 3 überhaupt durchführbar ist. Die Reduzierung der Anzahl verwendeter Register ist ebenso wie die Stream Compaction in [van Antwerpen 2011a] eine hardwarenahe Operation, die in OptiX nicht zwangsläug durchführbar ist. Lediglich die weniger optimale Pfaderneuerung nach [Novak et al. 2010] könnte ergänzt werden. Bezüglich der Eignung als Ausgangsbasis für einen bidirektionalen Path Tracer kann festgehalten werden, dass der Path Tracer mit nur wenig Aufwand zumindest zu einer grundlegenden Variante des BDPT erweitert werden kann. Die Optimierungsstrategien nach [van Antwerpen 2011a] und [van Antwerpen 2011b] sind dabei jedoch ebenfalls nicht zwangsläug realisierbar, da vor allem die alternative Berechnung der MIS-Gewichtungen und die parallele Auswertung aller expliziten Verknüpfungen von Kamera- und Lichtpfad nur durch hardwarenahe Programmierung ezient umgesetzt werden können. In diesem Fall müssen die Vor- und Nachteile der Verwendung von OptiX abgewägt werden. Im Kontext dieser Arbeit überwiegt die Möglichkeit einer vereinfachten und damit schnellen Implementierung, da aus Zeitgründen ohnehin bestenfalls ein Prototyp geschaen werden kann.

43 Kapitel 4 Implementierung Zielsetzung Aus zeitlichen Gründen kann es nicht Ziel dieser Arbeit sein, einen bidirektionalen Path Tracer zu implementieren, der fehlerfrei die physikalisch basierte Bildsynthese mit allen in dieser Arbeit vorgestellten Optimierungen realisiert. Vielmehr soll damit begonnen werden, eine Basis zu schaen, auf deren Grundlage über diese Arbeit hinaus eine solche Implementierung angestrebt werden kann. Es müssen also Ziele deniert werden, deren Erreichung im Rahmen dieser Arbeit realistisch ist, und durch die zu Zwecken der Auswertung eine erste lauähige Version des bidirektionalen Path Tracer angestrebt wird. Diese Ziele werden im Folgenden aufgeführt. Das primäre Ziel der Implementierung im Rahmen dieser Arbeit ist eine erste lauähige Version eines bidirektionalen Path Tracers, die erste Bilder zum Vergleich zwischen PT und BDPT generiert. Dabei soll diese Implementierung so gestaltet werden, dass eine spätere Vervollständigung und Optimierung möglich ist. Zur Erreichung dieses Zieles muss demnach mindestens eine Lichtquellenart so erweitert werden, dass Pfade bei den entsprechenden Lichtquellen starten können. Des Weiteren muss das Programm, welches den Einstiegspunkt auf der GPU bildet, die Generierung von Lichtpfaden neben der bisherigen Generierung von Kamerapfaden unterstützen und eine Möglichkeit bieten, diese Pfade miteinander zu verknüpfen. Alle weiteren Programme und Funktionen des Path Tracers müssen, falls notwendig, an die speziellen Anforderung des BDPT angepasst werden. Um möglichst schnell zu einem ersten Ergebnis zu gelangen, wird zu Beginn eine naive und in keiner Form optimierte Version des BDPT implementiert werden. Das bedeutet nicht nur, dass keines der in Kapitel 3 genannten Optimierungsverfahren angewendet wird, sondern auch, dass vorerst auf die optimale Gewichtung von Sampling-Techniken durch die balance heuristic verzichtet wird. Stattdessen werden alle Samples einer Technik gleich gewichtet. Dies führt ebenfalls zu einem erwartungstreuen Ergebnis, bietet aber in der Regel eine langsamere Reduzierung der Varianz im Ergebnisbild. Wünschenswert ist der direkte Vergleich von PT und BDPT zur Laufzeit. Es soll deshalb eine Möglichkeit gefunden werden, über ein Eingabegerät zur Laufzeit zwischen den beiden Implementierungen zu wählen. Alle implementierten Funktionen sollen nach Möglichkeit die Theorie korrekt umsetzen, um ein erwartungstreues Ergebnis zu erhalten. Fehler in der Implementierung sollen, soweit zeitlich möglich, vor Abschluss der Arbeit gefunden und korrigiert werden. Dies hat Vorrang vor der Erweiterung um zusätzliche Funktionalität.

44 Kapitel 4 Implementierung Umsetzung Am einfachsten lassen sich Lichtpfade von Punktlichtquellen aus generieren. Aus diesem Grund wurde die Klasse der Punktlichtquellen um Funktionen ergänzt, die Position und Richtung eines Primärstrahls liefern. Da diese Methoden auch zur Generierung von Primärstrahlen bei anderen Lichtquellentypen aufgerufen werden müssen, sobald diese unterstützt werden, macht es Sinn, ein Interface für alle Lichtquellen zu denieren, welches diese Methoden vorschreibt. Dies bleibt aber der zukünftigen Ergänzung der Implementierung überlassen. Abbildung 4.2: Im Flussdiagramm ist der Ablauf der Anwendung grob dargestellt. Die Schritte 4 bis 7 werden für jeden erzeugten Strahl durchgeführt. Grüne Elemente sind neu entstanden, blau-grüne mussten angepasst werden. Sobald die Möglichkeit der Generierung von Primärstrahlen gegeben ist, muss ein eigener Einstiegspunkt für den bidirektionalen Path Tracer angelegt werden. Dieser kann zunächst groÿe Teile des Einstiegspunktes des Path Tracers wiederverwenden, etwa um den Kamerapfad zu generieren. Zusätzlich muss die Generierung des Lichtpfades implementiert werden. Dieser unterscheidet sich jedoch lediglich in der Erzeugung der ersten Vertices von einem Kamerapfad, sodass auch hier bereits vorhandener Code wiederverwendet werden kann. Eine Neuerung im Vergleich zum Path Tracer ist der Umstand, dass zumindest für eine naive Implementierung des BDPT alle Vertices der erzeugten Pfade gespeichert werden müssen. Die aktuelle Implementierung legt zu Beginn der Pfaderzeugung Speicherplatz für bis zu acht Vertices pro Pfad an. Diese Beschränkung der Pfadlänge ist ein Mittelweg zwischen Speicherverbrauch und Verfälschung des Ergebnisses. Bei kleinen Szenen oder auf

45 Kapitel 4 Implementierung 38 GPUs mit einem groÿen Hauptspeicher, kann die Anzahl der Vertices pro Pfad noch erhöht werden. Acht Vertices pro Pfad führen jedoch schon zu einer maximalen Länge von 16 für einen vollständigen Transportpfad, was in den meisten Szenen ausreichend ist. Für jeden Vertex müssen neben seiner Position und Oberächennormalen auch Informationen über die Richtung einfallender und reektierter Strahlen gespeichert werden. Des Weiteren Daten über die Eigenschaften der Oberäche und weitere, bei der Berechnung des Strahlungsusses relevante Informationen. Während der Generierung von Pfaden entfällt das explizite Verbinden des letzten Vertex zu einer Lichtquelle. Auch an anderen Stellen müssen Details verändert werden. Abbildung 4.2 stellt grob den Ablauf der Anwendung dar. Durch Benutzereingaben kann der Einstiegspunkt verändert werden. Grüne Elemente sind neu implementiert worden, blau-grüne mussten angepasst werden. Die Anpassungen betreen auf der GPU in erster Linie die in OptiX verwendeten Datenstrukturen zur Kommunikation zwischen einzelnen Programmen, die der Payload eines Strahls genannt werden. Diese Datenstrukturen ermöglichen die Weitergabe von Werten, die in einem bestimmten Abschnitt der Implementierung ermittelt wurden, an andere Programme des OptiX-Kontext. Dem Programmierer steht es frei, diese Datenstruktur für jeden Strahl zu denieren. Da beim BDPT während der Auswertung der Verbindungen zwischen Kamera- und Lichtstrahlen einige Informationen verwendet werden müssen, die beim PT z.b. nur in den Materialprogrammen Anwendung nden, müssen diese Daten nun über den Payload an andere Programme weiterverteilt werden. Abbildung 4.3 zeigt die Strukturen des Payloads beim PT und BDPT im Vergleich. Die Gröÿe des Payloads beträgt beim PT 111 Byte pro Sample. Bei einer Auösung von 1024x768 Pixel müssen demnach 83,25 Megabyte reserviert werden. Beim BDPT beträgt die Gröÿe des Payloads 1267 Byte pro Sample. Im Vergleich zum PT müssten demnach für die selbe Auösung 950,25 Megabyte reserviert werden. Insgesamt verbraucht der bidirektionale Path Tracer also deutlich mehr Ressourcen als der zugrunde liegende Path Tracer. Für jedes BDPT-Sample werden im Vergleich zum Path Tracing nicht nur deutlich mehr Daten erhoben, sondern auch mehr Strahlen verfolgt. Die Tatsache, dass aufgrund der naiven Implementierung des Algorithmus die SIMD-Ezienz eher gering ist, führt jedoch dazu, dass im Vergleich zum Path Tracer weniger Strahlen pro Sekunde verfolgt werden (vgl ). Um zur Laufzeit zwischen PT und BDPT wählen zu können, wurde im Hauptprogramm auf der CPU ein Parameter ergänzt, der darüber entscheidet, welcher Einstiegspunkt auf der GPU gewählt wird. Dieser Parameter kann vom Benutzer über das Gamepad verändert werden. Somit können PT und BDPT direkt in der Anwendung miteinander verglichen werden. Eine grundlegende Funktion des BDPT konnte in der Implementierungsphase dieser Arbeit nicht fertig gestellt werden. Dabei handelt es sich um die sogenannten impliziten Lichtpfade

46 Kapitel 4 Implementierung 39 struct PerRayData_ bdpt { optix :: float3 radiance ; optix :: float3 origin ; optix :: float3 direction ; optix :: float3 normal ; optix :: float3 normal_ geometric ; optix :: float3 texcol ; float dotproduct ; float pdf ; float hitdist ; optix :: float3 f; bool directillumination ; unsigned int seed ; int depth ; bool done ; unsigned int numcastrays ; bool background ; struct PerRayData_ pt { optix :: float3 radiance ; optix :: float3 origin ; optix :: float3 direction ; optix :: float3 normal ; optix :: float3 normal_ geometric ; optix :: float3 texcol ; float dotproduct ; float pdf ; float hitdist ; optix :: float3 f; bool directillumination ; unsigned int seed ; int depth ; bool done ; unsigned int numcastrays ; bool background ; float phong_ exp ; float ni ; optix :: float3 kd ; optix :: float3 ks ; unsigned int bsdf_ type ; Vertex_ bdpt vertices [9]; unsigned int vertice_ count ; }; (a) BDPT }; (b) PT Abbildung 4.3: Der Payload eines BDPT Pfades muss um Informationen über lokale Oberächeneigenschaften eines Schnittpunktes erweitert werden. Auÿerdem werden die Vertices für jeden Pfad gespeichert. Jeder Vertex hat eine Gröÿe von 124 Byte. oder Kaustik-Pfade. Diese Pfade entstehen, wenn Vertices des Lichtpfades direkt mit der Kamera verbunden werden. Der Beitrag dieser Pfade zum Ergebnisbild ist primär für die Entstehung von Kaustiken verantwortlich. Um diese Pfade zu erhalten, muss eine explizite Verbindung zwischen den Vertices des Lichtpfades und der Kamera hergestellt und der Schnittpunkt mit der Bildebene ermittelt werden. Erst dieser Schnittpunkt liefert Auskunft über das Pixel, zu dem der erzeugte Pfad einen Beitrag leistet. Die Berechnung dieses Pixels und des entsprechenden Beitrages konnte nicht rechtzeitig fehlerfrei implementiert werden und wurde deshalb vorübergehend auskommentiert (vgl ).

47 Kapitel 5 Auswertung der Ergebnisse Neben einer ausführlichen Betrachtung von PT und BDPT hinsichtlich der Implementierung auf GPUs und einer ersten Umsetzung dieser Theorie in die Praxis, ist ein weiterer Hauptaspekt dieser Arbeit der Vergleich zwischen PT und BDPT. Zu diesem Zweck wird in diesem Kapitel der Path Tracer mit der ersten Version des bidirektionalen Path Tracers verglichen. Dabei werden vier Beispielszenen herangezogen, die unterschiedliche Anforderungen an die beiden Verfahren stellen. Diese Szenen werden im nächsten Abschnitt vorgestellt. Anschlieÿend werden die Implementierungen anhand verschiedener Messdaten auf ihre Leistungsfähigkeit und Robustheit hin untersucht. Zuletzt werden Beispiele für die Konvergenzgeschwindigkeit der beiden Verfahren betrachtet, da diese Eigenschaft in der Praxis die gröÿte Rolle spielt. Alle Ergebnisse wurden auf einer GeForce GTX 670 GPU von NVIDIA ermittelt. 5.1 Beispielszenen Die Vorteile von BDPT gegenüber dem PT sind die bessere Darstellung von Kaustiken und die deutlich schnellere Konvergenz in Szenen mit einem hohen Anteil indirekter Beleuchtung. Beide Fälle protieren von der insgesamt robusteren Realisierung der physikalisch korrekten Beleuchtungssimulation des BDPT. Deutlich weniger protieren Szenen mit einem hohen Anteil direkter Beleuchtung, oder insgesamt Szenen mit einem geringen Anteil gegenseitiger Verdeckung. Der Vergleich des Path Tracers mit dem bidirektionalen Path Tracer erfolgt anhand von vier Beispielszenen, die jeweils unterschiedliche Beleuchtungssituationen besonders hervorheben. Abbildung 5.1 zeigt Bilder dieser Szenen, erzeugt mit dem bidirektionalen Path Tracer. Alle Beispielszenen werden ausschlieÿlich durch eine einzelne Punktlichtquelle beleuchtet. Dies führt mitunter zu einer unnatürlichen Beleuchtung der Szene, ist aber für einen fairen Vergleich zwischen Path Tracer und bidirektionalem Path Tracer notwendig, da Letzterer keine anderen Lichtquellen unterstützt. Streets of Asia 2 (im Folgenden auch SoA2, oben links) ist eine Szene im Freien. Die Lichtquelle ist mittig oberhalb der Szene platziert. Der 40

48 Kapitel 5 Auswertung der Ergebnisse 41 Abbildung 5.1: Die Beispielszenen zum Vergleich von PT und BDPT. Streets of Asia 2, Conference Room (von auÿen beleuchtet), Conference Room (von innen beleuchtet) und ein Ring. gewählte Blickwinkel führt zu einem hohen Anteil direkt beleuchteter Flächen. Durch die O enheit der Szene ist nicht mit vielen langen Transportpfaden zu rechnen. Beim ference Room Con- handelt es sich um eine (beinahe) geschlossene Szene. Lediglich am oberen Ende der Lamellen vor den Fenstern links im Bild besteht eine Verbindung nach auÿen. In der Szene oben rechts in Abbildung 5.1 ist die Lichtquelle auÿerhalb des Raumes platziert (im Folgenden auch Conf1 ). Die gesamte Szenengeometrie wird demnach indirekt beleuchtet. Dieser Spezialfall konvergiert selbst beim BDPT nur sehr langsam. Das Bild in Abbildung 5.1 wurde nach anderthalb Stunden aufgenommen. Im Vergleich zu einem Bild nach einer Stunde gab es nur eine kaum sichtbare Veränderung. Unten links ndet sich die selbe Szene, diesmal durch eine Punktlichtquelle im Inneren des Raumes beleuchtet (im Folgenden auch Conf2 ). Aus der Position der hellen Re exionen auf Boden, Decke und rechter Wand lässt sich die ungefähre Position der Lichtquelle schätzen. Der Ring (un- ten rechts) generiert eine Kaustik und dient zum Vergleich dieses Beleuchtungsphänomens zwischen PT und BDPT.

49 Kapitel 5 Auswertung der Ergebnisse Performanz Dieser Abschnitt vergleicht die Performanz beider Implementierungen anhand zweier Messgröÿen. Da beide Verfahren strahlbasiert sind und die Verfolgung von Strahlen durch die Szene den mit Abstand gröÿten Teil der Rechenzeit in Anspruch nimmt, bietet sich die Anzahl der verfolgten Strahlen pro Sekunde als Vergleichsgröÿe an. Weniger für den direkten Vergleich der Implementierungen geeignet, aber für weitergehende Betrachtungen dennoch interessant, ist die Anzahl der Frames pro Sekunde. Ein Frame ist in diesem Kontext de- niert als ein vollständiges Ausführen des Kameraprogramms (vgl. Unterabschnitt 4.1.1). Nach jedem Frame wurde demnach für jedes Pixel des Ergebnisbildes genau ein Sample erzeugt Strahlen pro Sekunde Die Anzahl der Strahlen pro Sekunde ist neben dem rein visuellen Vergleich der Ergebnisbilder die aussagekräftigste Vergleichsgröÿe zweier strahlbasierter, physikalischer Bildsyntheseverfahren. Da die Verfolgung von Strahlen durch die Szene den gröÿten Anteil an der Rechenzeit eines solchen Verfahrens hat, ist es das Ziel einer jeden Implementierung, die Anzahl der Strahlen pro Sekunde zu maximieren. Darauf zielen letztlich auch die meisten der in Kapitel 3 genannten Optimierungen ab. Für den Beitrag zum Ergebnisbild werden stets vollständige Samples herangezogen, so dass ein Vergleich der erzeugten Samples pro Sekunde zunächst ebenfalls naheliegend erscheint. Schon aus den Beschreibungen der Algorithmen in Abschnitt 2.3 und Abschnitt 2.4, sowie den Abbildung 2.10 und Abbildung 2.12 geht jedoch hervor, dass ein BDPT-Sample in der Regel einen gröÿeren Berechnungsaufwand erfordert als ein PT-Sample, weshalb dieser Vergleich nicht sehr aussagekräftig wäre. BDPT PT Rekursionstiefe SoA2 Conf1 Conf2 Ring SoA2 Conf1 Conf2 Ring Tabelle 5.1: Strahlen (in Mio.) pro Sekunde, in den vier Beispielszenen und bei wachsender Rekursionstiefe. Zu beachten ist die Tatsache, dass die maximale Pfadlänge beim BDPT dem Doppelten der Rekursionstiefe entspricht.

50 Kapitel 5 Auswertung der Ergebnisse 43 Tabelle 5.1 zeigt die in den vier Beispielszenen gemessenen Durchschnittswerte der Strahlen pro Sekunde bei verschiedenen maximalen Pfadlängen. Alle Werte sind in Millionen angegeben. Beim BDPT gelten die Maximalwerte jeweils für Kamera-, als auch für Lichtpfade, so dass eine Rekursionstiefe von vier beim BDPT bereits Pfade mit einer Maximallänge von acht zur Folge haben kann. Dieser Umstand ist beim Vergleich der Werte zu beachten. Es lässt sich deutlich erkennen, dass die Zahl der Strahlen pro Sekunde bei wachsender maximaler Pfadlänge in allen Szenen abnimmt. Dies ist auf die schlechtere Auslastung der Hardware durch bereits beendete Pfade zurückzuführen. Ein weiterer Faktor könnte die geringere Kohärenz der verfolgten Strahlen nach mehreren Reexionen sein. Die Diagramme in Abbildung 5.2 visualisieren die Entwicklung der Messdaten jeweils für BDPT und PT. Strahlen pro Sekunde (in Mio.) SoA2 Conf1 Conf2 Ring SoA2 Conf1 Conf2 Ring Maximale Pfadlänge Maximale Pfadlänge (a) BDPT (b) PT Abbildung 5.2: Strahlen pro Sekunde (in Mio.) bei wachsender Rekursionstiefe. Besonders auällig ist die Tatsache, dass die Anzahl der Strahlen beim Umschalten von zwei auf drei Rekursionsschritte im Vergleich sehr drastisch sinkt. Dies ist ebenfalls auf die geringere Kohärenz der Sekundärstrahlen, sowie darauf zurückzuführen, dass erst nach dem zweiten Rekursionsschritt russian roulette zur zufälligen Beendigung eines Pfades eingesetzt wird. Im Allgemeinen kann die Anzahl der Strahlen pro Sekunde beim PT und BDPT nur für eine bestimmte Szene verglichen werden, da diese Gröÿe vom betrachteten Ausschnitt der Szene, von der Position der Lichtquelle und der Komplexität der Szene (z.b. der Anzahl der Dreiecke) abhängt. Dennoch zeigen Szenen eines bestimmten Typs häug eine ähnliche Entwicklung bei zunehmender Pfadlänge.

51 Kapitel 5 Auswertung der Ergebnisse 44 Die Szenen SoA2 und Ring zeigen ein ähnliches Verhalten bei zunehmender Pfadlänge. Grund dafür ist die Oenheit der beiden Szenen. Die Anzahl der Strahlen pro Sekunde konvergiert bereits bei einer geringen maximalen Pfadlänge. Bei jeder Verlängerung eines Pfades besteht eine groÿe Chance, alle Objekte der Szene zu verfehlen. In solchen Fällen wird ein Pfad beendet. Beim Ring führt diese Eigenschaft bereits nach zwei bis drei Rekursionsschritten zur Beendigung aller Pfade, in der SoA2-Szene existieren auch noch einige wenige Pfade, die eine gröÿere Länge erreichen. Sowohl bei der Auswertung der Verbindungen zwischen Kamera- und Lichtpfad beim BD- PT, als auch bei der Generierung expliziter Verbindungen zur Lichtquelle beim PT, wird zunächst ermittelt, ob eine solche Verbindung aufgrund der lokalen Reexionseigenschaften der beteiligten Punkte einen signikanten Beitrag leisten würde. Erst wenn diese Bedingung erfüllt ist, wird ein Strahl generiert, um die Sichtbarkeit der beiden Punkte zu evaluieren. Das Wissen um diese Eigenschaft ermöglicht die weitere Auswertung der Messwerte. Abbildung 5.2 zeigt, dass Conf2 beim PT eine höhere Performanz erreicht als Conf1. Verändert hat sich in diesem Fall nur die Position der Lichtquelle. Da die Lichtquelle in Conf1 auÿerhalb des Raumes, und damit auf der Rückseite sowohl der linken Wand als auch der Decke liegt, werden explizite Verbindungen zur Lichtquelle von einem Groÿteil der Punkte auf diesen Flächen in Conf1 nicht generiert. Die vorhergehende Auswertung der Oberächeneigenschaften ndet jedoch statt, wodurch das Verhältnis zwischen Auswertung einer BRDF und generierten Strahlen negativ beeinusst wird. In Conf2 bendet sich die Lichtquelle an einer von den meisten Oberächenpunkten der Szene erreichbaren Position (aufgrund der BRDF), sodass keine negative Beeinussung der Anzahl der Strahlen pro Sekunde auftritt. Das selbe Phänomen müsste auch zu einer höheren Performanz von Conf2 beim BDPT führen. Hier werden jedoch in Conf1 deutlich mehr Strahlen pro Sekunde generiert. Dies ist dadurch zu erklären, dass ein sehr groÿer Anteil der von der Lichtquelle aus erzeugten Strahlen keine Szenengeometrie trit. Die Auswertung des Miss-Programmes ist sehr viel weniger aufwendig als die Auswertung eines Materialprogrammes, wodurch eine Vielzahl der generierten Strahlen einen vergleichsweise geringen Aufwand verursacht. Dies amortisiert nicht nur den beim PT zu beobachtenden Eekt, sondern übertrumpft ihn in seiner Wirkung um ein Vielfaches. Fakt ist allerdings, dass die verantwortlichen Strahlen keinerlei Nutzen bei der Approximation der Beleuchtung haben. Generell zeigen die Ergebnisse aus Abbildung 5.2, dass beide Verfahren bei identischer maximaler Pfadlänge in etwa gleich viele Strahlen pro Sekunde generieren. In allen Szenen auÿer Conf2 protiert BDPT von Lichtstrahlen, die keine Szenengeometrie treen. Dies gleicht den prinzipiell etwas gröÿeren Berechnungsaufwand des Verfahrens wieder aus. Dennoch leidet BDPT bei einer naiven Implementierung an einer gröÿeren Anfälligkeit für suboptimale Hardwarenutzung. Die Szenen SoA2, sowie Conf1 und Conf2 sind von einer derartigen Problematik kaum betroen. Die Ring-Szene hingegen hebt die Anfälligkeit des

52 Kapitel 5 Auswertung der Ergebnisse 45 BDPT deutlich hervor. Der Unterschied bezüglich der Strahlen pro Sekunde ist hier äuÿerst signikant. Diese Tatsache ist der Verbindungsphase des BDPT geschuldet. Alle Vertices der Kamera- und Lichtpfade liegen entweder in der selben Ebene, oder auf dem spekularen Ring. Eine explizite Verbindung dieser Vertices wird damit äuÿerst unwahrscheinlich. Dennoch werden von der Implementierung zunächst alle potentiellen Verbindungen auf Basis ihrer BRDFs bewertet. Dieser Mehraufwand entfällt beim PT. Letztlich kann die Untersuchung der Strahlen pro Sekunde dabei helfen, Szenen zu kategorisieren und die verwendeten Verfahren auf ihre Eignung zur Beleuchtung solcher Szenentypen hin zu untersuchen und zu vergleichen. Auÿerdem kann die sorgfältige Interpretation der Messergebnisse Schwachstellen eines Algorithmus oder einer Implementierung aufdecken. Die Ergebnisse dieses Abschnitts lassen die Schlussfolgerung zu, dass das PT besonders bei sehr einfachen Szenen mit einem hohen Anteil direkter Beleuchtung dem BDPT theoretisch überlegen wäre, wenn eine gerichtete Lichtquelle verwendet würde. Gleichzeitig zeigen sie, dass der Mehraufwand beim BDPT in der Praxis häug jedoch kaum ins Gewicht fällt. Eine oene Frage bleibt zu diesem Zeitpunkt, ob die Anzahl der Strahlen pro Sekunde eine Auskunft über die Konvergenzgeschwindigkeit eines Verfahrens geben kann Frames pro Sekunde Die Anzahl der Frames pro Sekunde ist im Kontext dieser Arbeit gleichbedeutend mit der Anzahl der Samples, die ein Verfahren für jedes Pixel erzeugt. Da ein Sample beim BDPT in der Regel aus mehr Pfaden besteht und auch sonst in seiner Berechnung etwas komplexer ist, kann beim BDPT eine deutlich geringere Anzahl an Frames pro Sekunde erwartet werden als beim PT. Hinzu kommt der Umstand, dass die betrachteten maximalen Pfadlängen beim BDPT sowohl für den Kamera-, als auch für den Lichtpfad eines Samples gelten. Demnach kann ein Transportpfad bei einer maximalen Pfadlänge von drei beim BDPT insgesamt eine Länge von sechs erreichen, beim PT hingegen nur die Hälfte. Tabelle 5.2 zeigt die durchschnittlich gemessenen Werte der Implementierungen in den vier Testszenen, jeweils für verschiedene maximale Pfadlängen. Auf den ersten Blick ist zu erkennen, dass beim PT in allen Szenen zum Teil deutlich höhere Werte erreicht werden. Dieses Ergebnis bestätigt die eingangs formulierte Vermutung. Es kann jedoch aus der Anzahl der Frames pro Sekunde kein Rückschluss auf die Konvergenzgeschwindigkeit eines Verfahrens gezogen werden, da ein BDPT-Sample aufgrund seines gröÿeren Umfangs in der Regel einen Beitrag zum Ergebnisbild leistet, der weniger Rauschen verursacht als ein PT-Sample (vgl. 5.3). Die Anzahl der Frames pro Sekunde kann also im Kontext dieser Arbeit kein Maÿ für die Güte eines bildgebenden Verfahrens sein. Dennoch ist die Betrachtung dieser Gröÿe von Interesse.

53 Kapitel 5 Auswertung der Ergebnisse 46 BDPT PT Rekursionstiefe SoA2 Conf1 Conf2 Ring SoA2 Conf1 Conf2 Ring Tabelle 5.2: Frames pro Sekunde, in den vier Beispielszenen und bei wachsender Rekursionstiefe. Zu beachten ist die Tatsache, dass die maximale Pfadlänge beim BDPT dem Doppelten der Rekursionstiefe entspricht. Da die hier verglichenen Implementierungen für eine interaktive Verwendung vorgesehen sind, ist die Anzahl der Frames pro Sekunde insofern interessant, als dass sie Auskunft über die Qualität der Interaktion gibt. Da eine Interaktion, hier in erster Linie das Bewegen der Kamera durch die Szene, nur zwischen zwei Frames möglich ist, bzw. die Schrittgröÿe der Kamerasteuerung von der Anzahl der Frames abhängt, führt eine höhere Anzahl an Frames pro Sekunde zu einer wesentlich verbesserten Steuerung. Des Weiteren wird für jedes Sample genau ein Strahl durch das betreende Pixel generiert. Die Anzahl der Strahlen, die von der Kamera durch ein Pixel führen, ist maÿgeblich für die Qualität der Kantenglättung (anti aliasing) im Ergebnisbild. Während der Verwendung der beiden Implementierungen zeigte sich, dass die Interaktion besonders in komplexen Szenen mit niedrigen Framezahlen beim PT deutlich üssiger und präziser war als beim BDPT. Bezüglich der zu erwartenden besseren Kantenglättung beim PT zeigte sich zwischen den beiden Verfahren kein sichtbarer Unterschied. Dies kann darauf zurückgeführt werden, dass selbst in trivialen Szenen erst nach fünfzig bis hin zu einigen hundert Samples pro Pixel ein Bild resultiert, dass der konvergierten Form annähernd ähnelt. Diese Zahl reicht völlig aus, um eine gute Kantenglättung zu gewährleisten. Abbildung 5.3 visualisiert die Messdaten aus Tabelle 5.2. Beim Vergleich mit Abbildung 5.2 fällt eine starke Ähnlichkeit der Messkurven auf, zumindest was die Form der einzelnen Kurven betrit. Die Ähnlichkeit der Kurven legt die Vermutung nahe, dass die Anzahl der Frames pro Sekunde von der Anzahl der Strahlen abhängt. Tatsächlich beeinusst die Anzahl der Strahlen pro Sekunde die Anzahl der Frames, da bei weniger Strahlen die Generierung eines Samples verlangsamt wird. Dieser Zusammenhang folgt allerdings keiner festen Regel. In Abbildung 5.2 lag die Kurve für Conf2 beim PT noch oberhalb von Conf1. Ebenso hat sich die Kurve für Conf2 beim BDPT in Abbildung 5.3 vergleichsweise weit nach unten verschoben. Diese Unterschiede können nicht durch die Entwicklung der Strahlen pro Sekunde erklärt werden.

54 Kapitel 5 Auswertung der Ergebnisse 47 Frames pro Sekunde SoA2 Conf1 Conf2 Ring SoA2 Conf1 Conf2 Ring Maximale Pfadlänge Maximale Pfadlänge (a) BDPT (b) PT Abbildung 5.3: Frames pro Sekunde bei wachsender Rekursionstiefe. Die Tatsache, dass Conf1 beim PT mehr Frames pro Sekunde erzielt als Conf2, obwohl das Verhältnis der Strahlen pro Sekunde dem genau entgegengesetzt ist, erklärt sich aus dem selben Grund, der schon bei der Auswertung von Abbildung 5.2 zum Tragen kam. Aufgrund der Position der Lichtquelle werden in Conf1 einige explizite Verbindungen zu selbiger nicht erzeugt. Dies führt zu einer geringeren Anzahl an Strahlen, beschleunigt jedoch die Berechnung eines Frames. Beim BDPT hat sich die Kurve für Conf2 weit nach unten verschoben. Dieses Verhalten resultiert ebenfalls aus der Platzierung der Lichtquelle im Inneren des Raumes. Für jedes Sample treen nun, anders als in Conf1, sämtliche Strahlen der Lichtquelle auf Szenengeometrie. Durch die Geschlossenheit der Szene verbleiben reektierte Strahlen im Raum, sodass mit sehr langen Transportpfaden zu rechnen ist. Dadurch steigt auch die Anzahl der auszuwertenden Verbindungen zwischen Kamera- und Lichtpfaden stark an. Dies alles führt zu einer sehr niedrigen Framezahl. Zusammenfassend zeigen die Messergebnisse, dass PT für eine interaktive Verwendung tendenziell besser geeignet ist als BDPT. Es konnte auch gezeigt werden, dass die Anzahl der Strahlen pro Sekunde zwar einen Bezug zur Anzahl der Frames hat, diese jedoch nicht ausschlieÿlich bestimmt. Es gilt weiterhin, den Zusammenhang zwischen den bisher betrachteten Messgröÿen und der Konvergenzgeschwindigkeit der Verfahren zu prüfen. Auÿerdem konnte bislang keine Aussage über die Robustheit eines der beiden Verfahren getroen werden. Abschnitt 5.3 wird sich mit diesen Punkten befassen.

55 Kapitel 5 Auswertung der Ergebnisse Konvergenz und Robustheit Dieser Abschnitt befasst sich mit der Untersuchung der Konvergenzgeschwindigkeit von PT und BDPT bezogen auf die Anzahl der erzeugten Samples pro Pixel. Dementsprechend wird der Beitrag eines einzelnen Frames zum Gesamtbild untersucht. Auÿerdem soll die Robustheit beider Verfahren gegenübergestellt werden. Konkret soll verglichen werden, wie konstant die erzeugten Bilder konvergieren, bzw. welchen Einuss eine ungleichmäÿige Konvergenz auf das Ergebnisbild hat. Im Folgenden werden daher verschiedene Bilder der Beispielszenen, sowie zugehörige Messdaten miteinander verglichen. Die Bilder wurden durch jeweils eines der beiden untersuchten Verfahren mit einer festen Anzahl an Samples pro Pixel erzeugt. Der visuelle Vergleich von Bildern nach der selben Laufzeit ndet in Abschnitt 5.4 statt Streets of Asia 2 Zur Ermittlung von Konvergenzgeschwindigkeit und Robustheit eines Verfahrens wurde die Änderung aller Pixel des Ergebnisbildes nach jedem Frame gemessen, und die Werte über das gesamte Bild gemittelt. Das Resultat gibt demnach Auskunft über den Einuss des zuletzt berechneten Frames auf das Gesamtbild. Diese Werte wurden direkt aus der Anwendung heraus visualisiert. Abbildung 5.4 ist das Ergebnis einer solchen Visualisierung. Die x-achse stellt die wachsende Zahl der Samples pro Pixel dar, die y-achse zeigt die gemessenen Werte. Messpunkte des BDPT sind in rot, Werte des PT in grün dargestellt. Abbildung 5.4: Entwicklung der Beiträge einzelner Frames in SoA2, mit steigender Anzahl der Samples pro Pixel. PT (grün) und BDPT (rot) werden jeweils mit einer maximalen Pfadlänge von 4 ausgeführt. Es ist deutlich zu erkennen, dass beide Kurven zu Beginn steil abfallen und dann langsam gegen null konvergieren. Für beide Verfahren wurde eine maximale Pfadlänge von

56 Kapitel 5 Auswertung der Ergebnisse 49 vier gewählt. Durch diese Beschränkung können indirekte Beleuchtungsanteile nur bis zu einer gewissen Grenze ermittelt werden. Es ist zu beobachten, dass die Streuung der Werte beim BDPT signikant geringer ist als beim PT. Diese Streuung kann als Maÿ für die Robustheit eines Verfahrens betrachtet werden und zeigt, dass einzelne Samples beim BDPT deutlich weniger starke Abweichungen voneinander haben als beim PT. Daraus resultiert insgesamt weniger Rauschen. Auÿerdem liegt die Kurve der PT-Werte höher als die des BDPT. Aus dieser Tatsache kann die schnellere Konvergenz des BDPT-Bildes geschlussfolgert werden. Abbildung 5.5 zeigt die mittels BDPT und PT erzeugten Bilder nach 500 Samples pro Pixel bei einer maximalen Pfadlänge von vier. Es ist deutlich zu sehen, dass die Schatten im PT- Bild heller sind als im BDPT-Bild. Insgesamt wirkt die ganze Szene durch vermehrtes color bleeding etwas weniger weiÿ und in der unteren rechten Ecke kann im Fluss eine stärkere Reexion der rechten Wand wahrgenommen werden. Der Unterschied zwischen den beiden Bildern könnte durch eine fehlerhafte Implementierung eines der beiden Verfahren verursacht sein, oder aber auch ein Hinweis auf den nahezu unmöglichen Vergleich der Verfahren bei beschränkten Pfadlängen. (a) BDPT (b) PT Abbildung 5.5: Die Ergebnisbilder beider Verfahren unterscheiden sich in SoA2 bei einer maximalen Pfadlänge von 4 nach 500 Samples pro Pixel deutlich in der indirekten Beleuchtung. Trotz theoretisch gleicher maximaler Pfadlängen ist die Wahrscheinlichkeitsverteilung für Pfade einer bestimmten Länge in beiden Varianten verschieden. PT kann bei einer Rekursionstiefe von vier bereits wesentlich mehr Eekte durch indirekte Beleuchtung wiedergeben als BDPT bei einer Rekursionstiefe von zwei. In der SoA2-Szene gilt diese Einschränkung jedoch nur für die bisher betrachteten, vergleichsweise kurzen maximalen Pfadlängen. Wie die Auswertung der Ergebnisse in Abschnitt 5.2 gezeigt hat, existieren in SoA2 kaum Pfade mit einer Länge oberhalb von vier bis fünf. Abbildung 5.6 stellt daher die Entwicklung der Beiträge von Frames bei einer Rekursionstiefe von acht für beide Verfahren dar. Die Wer-

57 Kapitel 5 Auswertung der Ergebnisse 50 Abbildung 5.6: Entwicklung der Beiträge einzelner Frames in SoA2 bei Rekursionstiefe 8, mit steigender Anzahl der Samples pro Pixel. PT (grün) konvergiert langsamer und streut stärker als BDPT (rot). te dieser Messung können als unverfälscht betrachtet werden. Die Ergebnisbilder beider Verfahren unterscheiden sich nach 500 Samples pro Pixel nur noch minimal in schattigen Bereichen Conference Room (Conf1) - Indirekte Beleuchtung Bei SoA2 handelt es sich um eine Szene im Freien, die vergleichsweise wenig indirekte Beleuchtungsanteile hat. Conf1 dagegen ist explizit so gewählt, dass der Anteil indirekter Beleuchtung möglichst hoch ist. Aufgrund der Tatsache, dass nur ein sehr geringer Anteil der Vertices beim PT direkt mit der Lichtquelle verbunden werden kann, ist dieses Verfahren zur Beleuchtung der Szene nicht geeignet. BDPT protiert hier von der Generierung der Lichtpfade, die ins Innere der Szene gelangen und somit zu einer schnelleren Konvergenz des Bildes beitragen. Die Szene ist jedoch ein Extremfall, der auch BDPT an seine Grenzen stoÿen lässt, da die Anzahl der Lichtpfade, die in den Raum gelangen, genauso gering ist wie die Anzahl der Kamerapfade, die nach auÿen gelangen. Abbildung 5.7 visualisiert die Entwicklung der Beiträge einzelner Frames zum Gesamtbild bei einer maximalen Pfadlänge von vier und zunehmender Zahl an Samples pro Pixel. Die Beobachtung, dass BDPT laut den Messdaten oenbar deutlich schneller konvergiert und weniger stark streut als PT, entspricht dem zu erwartenden Ergebnis. Zwar gibt es auch bei den Samples des BDPT immer wieder Ausreiÿer nach oben, insgesamt liegt der Schwerpunkt aber am unteren Ende des Streubereichs. Das Verhältnis zwischen BDPT und PT wird durch die Betrachtung der zugehörigen Bilder nach jeweils 1000 Samples pro Pixel bestätigt. Dort ist deutlich der Unterschied zwischen den Ergebnissen der beiden Verfahren zu erkennen. PT generiert nur selten Samples, die tatsächlich zur Beleuchtung der Szene

58 Kapitel 5 Auswertung der Ergebnisse 51 (a) Entwicklung der Sample-Beiträge von BDPT (rot) und PT (grün). (b) BDPT (c) PT Abbildung 5.7: Die Ergebnisbilder beider Verfahren unterscheiden sich in Conf1 bei einer maximalen Pfadlänge von 4 nach 1000 Samples pro Pixel deutlich. Die Wahrscheinlichkeitsverteilung von Transportpfaden ist trotz identischer maximaler Pfadlänge sehr verschieden. beitragen. Kann jedoch eine Verbindung zur Lichtquelle generiert werden, so leistet das entsprechende Sample einen hohen Beitrag. Beide Verfahren erzeugen ein ähnlich starkes Rauschen im Ergebnisbild. Da die Wahrscheinlichkeitsverteilung bestimmter Transportpfade jedoch in beiden Fällen sehr unterschiedlich ist, unterscheiden sich auch die Ergebnisbilder stark. Beim PT konzentriert sich ein Groÿteil der Strahlung in der linken Hälfte des Bildes, während die Ausleuchtung beim BDPT etwas gleichmäÿiger ausfällt. Aufgrund dieser vergleichsweise hellen Bereiche tragen die entsprechenden Samples beim PT stark zur Veränderung des Bildes bei, was eine etwas langsamere Konvergenz zur Folge hat. Dennoch ist der Unterschied zwischen beiden Verfahren bezüglich der Konvergenzgeschwindigkeit weniger groÿ, als die sehr fein gewählte Skala der Visualisierung vermuten lässt.

59 Kapitel 5 Auswertung der Ergebnisse 52 Die Kurven für Conf1 in Abbildung 5.3 zeigen, dass es auch bei einer maximalen Rekursionstiefe von acht noch kleine Änderungen in der Performanz gibt, was dafür spricht, dass eine gewisse Anzahl der Transportpfade diese Länge erreicht und wohl auch überschreiten würde. Da für das BDPT in der untersuchten Implementierung allerdings alle Vertices gespeichert werden müssen, ist eine Rekursionstiefe von acht zu diesem Zeitpunkt das Maximum. Eine signikante Änderung der Ergebnisse bei einer höher gelegenen Grenze ist nicht zu erwarten. Abbildung 5.8 zeigt deshalb die Entwicklung der Sample-Beiträge sowie die Ergebnisbilder beider Verfahren bei einer maximalen Rekursionstiefe von acht. (a) Entwicklung der Sample-Beiträge von BDPT (rot) und PT (grün). (b) BDPT (c) PT Abbildung 5.8: Die Ergebnisbilder beider Verfahren unterscheiden sich in Conf1 bei Rekursionstiefe 8 nach 1000 Samples pro Pixel deutlich. Die Beleuchtung der Szene durch BDPT ist gleichmäÿiger, erzeugt aber auch mehr Rauschen. Oensichtlich erzeugt BDPT ein gleichmäÿiger ausgeleuchtetes Bild als PT. Da Pfade, deren erster Vertex in der rechten Hälfte des Bildes liegt, beim PT oenbar seltener eine

60 Kapitel 5 Auswertung der Ergebnisse 53 Verbindung zur Lichtquelle generieren können als Pfade in der linken Hälfte, bleibt diese Seite überwiegend dunkel. Dadurch konvergiert das PT-Bild deutlich schneller. Zusammenfassend kann festgehalten werden, dass BDPT bei der Berechnung von Szenen mit einem hohen Anteil indirekter Beleuchtung mit der selben Anzahl an Samples pro Pixel ein signikant besseres Ergebnis erzielt als PT. Der Vergleich der Ergebnisse bei identischer Laufzeit ndet in Abschnitt 5.4 statt. Der Vergleich mit SoA2 gestaltet sich aufgrund unterschiedlicher Skalen bei der Visualisierung der Sample-Beiträge auf den ersten Blick schwierig. Ein Vergleich von Bildern nach einer identischen Laufzeit wird jedoch zeigen, dass Conf1 aufgrund der vermehrten indirekten Beleuchtung wesentlich langsamer konvergiert als SoA Conference Room (Conf2) Abbildung 5.9: Entwicklung der Beiträge einzelner Frames zum Gesamtbild bei einer Rekursionstiefe von 8, mit steigender Anzahl der Samples pro Pixel. Beide Verfahren streuen deutlich weniger als bei Conf1. Im Gegensatz zu Conf1 bendet sich die Lichtquelle in Conf2 im Inneren des Raumes. Dadurch wird ein Groÿteil der Geometrie direkt beleuchtet. Dieser Umstand kann aus der Visualisierung der Frame-Beiträge in Abbildung 5.9 direkt abgelesen werden. Im Vergleich mit den Kurven aus Conf1 streuen beide Verfahren deutlich weniger, was für ein geringeres Rauschen in den Ergebnisbildern spricht. Die Bilder in Abbildung 5.10 bestätigen diese Interpretation.

61 Kapitel 5 Auswertung der Ergebnisse 54 (a) BDPT (b) PT Abbildung 5.10: Die Ergebnisbilder beider Verfahren unterscheiden sich in Conf2 bei Rekursionstiefe 8 nach 600 Samples pro Pixel deutlich in der Helligkeit. Ursache könnte ein Fehler in der Implementierung des BDPT sein. Der bedeutendste Unterschied zwischen den Ergebnisbildern beider Verfahren besteht in der Helligkeit. Dieser Unterschied ist besonders stark in den schattierten Bereichen sichtbar. Abbildung 5.10 zeigt die Ergebnisbilder bei einer maximalen Rekursionstiefe von acht. Da beide Verfahren oensichtlich zu einem verschiedenen Ergebnis konvergieren, kann an dieser Stelle mit einiger Sicherheit die fehlerhafte Implementierung eines der beiden Verfahren geschlussfolgert werden. Die wahrscheinlichste Erklärung ist eine falsche Berechnung der Gewichtung einzelner BDPT-Samples, wodurch in dieser besonders stark beleuchteten Szene die erwähnten Helligkeitsunterschiede resultieren. Da die Ergebnisbilder in den anderen Szenen zumindest bei einer Rekursionstiefe von acht für beide Verfahren zu nahezu identischen Resultaten konvergiert sind, muss nicht von einer nennenswerten Verfälschung der bisherigen Ergebnisse ausgegangen werden. Der Verlauf der Sample-Beiträge ist in Abbildung 5.9 relativ ähnlich. Auch für uterschiedliche maximale Rekursionstiefen verändert sich dieses Verhältnis nicht in bemerkenswerter Weise. Lediglich die Streuung des PT wird unter Umständen im Vergleich zum BDPT noch etwas gröÿer. Aus diesem Grund entfällt ein weiterer Vergleich. Ursache für die Konstanz und Ähnlichkeit der Messwerte ist die starke direkte Beleuchtung der Szene, aus der eine schnelle Konvergenz und geringes Rauschen resultiert. Die Interpretation der Ergebnisse führt zu dem Schluss, dass Conf2 von keinem der beiden Verfahren besonders protiert Ring - Kaustiken Die Ring-Szene wurde in erster Linie wegen der entstehenden Kaustik ausgewählt. Wie in Unterabschnitt beschrieben, entstehen Kaustiken durch Pfade mit der Signatur

62 Kapitel 5 Auswertung der Ergebnisse 55 EDS L. Diese Pfade können beim PT nur selten erzeugt werden, sodass Kaustiken Rauschen verursachen und nur sehr langsam konvergieren. BDPT ist zur Erzeugung von Kaustiken besser geeignet. Beim Vergleich der beiden Verfahren kann also eine Überlegenheit auf Seiten des bidirektionalen Path Tracers erwartet werden. Abbildung 5.11 visualisiert die Entwicklung der Framebeiträge bei einer Rekursionstiefe von acht, Abbildung 5.12 zeigt die zugehörigen Ergebnisbilder nach 600 Samples pro Pixel. Abbildung 5.11: Entwicklung der Beiträge einzelner Frames zum Gesamtbild bei einer Rekursionstiefe von 8, mit steigender Anzahl der Samples pro Pixel. Beide Verfahren konvergieren sehr schnell und streuen ähnlich gering. (a) BDPT (b) PT Abbildung 5.12: Die Ergebnisbilder beider Verfahren unterscheiden sich bei Rekursionstiefe 8 nach 600 Samples pro Pixel nur geringfügig in der Entwicklung der Kaustik, deren Spiegelung und dem Schatten auf der Innenseite des Ringes. Entgegen den Erwartungen unterscheiden sich die Messdaten in Abbildung 5.11 für beide Verfahren in keinster Weise. Diese Beobachtung gilt auch für Vergleiche beliebiger anderer Rekursionstiefen. Dass sich die Messdaten bei zunehmenden Pfadlängen nicht ändern, liegt