Final Gathering und Radiance Interpolation für indirekte Beleuchtung auf Grafik-Hardware

Transkript

1 Visualisierungsinstitut der Universität Stuttgart Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Final Gathering und Radiance Interpolation für indirekte Beleuchtung auf Grafik-Hardware Maurice Gilden Studiengang: Informatik Prüfer: Betreuer: Prof. Dr. Carsten Dachsbacher Prof. Dr. Carsten Dachsbacher begonnen am: 13. Oktober 2008 beendet am: 14. April 2009 CR-Klassifikation: I.3.3, I.3.7

2

3 Inhaltsverzeichnis 1 Einleitung 7 2 Grundlagen und Vorarbeiten Grafik-Pipeline OpenGL ARB_framebuffer_object EXT_timer_query NV_transform_feedback Radiometrie Globale Beleuchtung GPU-basierte globale Beleuchtung Punktbasiertes Radiance Caching G-Buffers Quasi-Monte Carlo Verteilung Importance Sampling Punktbasierte Geometrie Radiance Cache Berechnung Pyramidal Mapping Pull-Push Final Gathering Radiance Interpolation Implementationsdetails Überblick Attribute Texturen und Buffer Shader Methoden Szenen-Informationen Oberflächenpunkte Cache Update Zyklus Cache Records

4 4.6 Cache Rendering Final Gathering und Radiance Interpolation Darstellung mit direkter Beleuchtung User Interface Debug-Optionen Ergebnisse Performance Speicherbedarf Bilder Zusammenfassung und Ausblick 61 Literaturverzeichnis 63 4

5 Abbildungsverzeichnis 2.1 Rendering-Pipeline quasi-zufällige Punkte quasi-zufällige Punkte Importance Sampling Fälle Pyramidal Mapping Pull-Interpolation Push-Interpolation Szenen-Informationen Oberflächenpunkte Update-Zyklus Importance-Sampling Diagramm Cache Erstellung Final Gathering und Interpolation GUI Vergleichsbilder Cornell-Box Cornell Box mit Kugel Japanraum-Szene Tabellenverzeichnis 2.1 Radiometrische Größen Tabelle aller Texturen Tabelle aller Buffer FPS Messung mit der Office-Szene Timer-Query Messungen Timer-Query Einstellungen

6 5.4 Speicherverbrauch aller Texturen und Buffer Verzeichnis der Listings 2.1 Minimalbeispiel für EXT_timer_query Minimalbeispiel für NV_transform_feedback Verzeichnis der Algorithmen 3.1 Halton Sequenz

7 Kapitel 1 Einleitung Für die interaktive Darstellung virtueller Szenen wird die indirekte Beleuchtung meistens vernachlässigt. Dies liegt vor allem daran, dass die dafür notwendigen Berechnungen bisher mit einem zu hohen Aufwand verbunden sind und die Interaktivität des Programms darunter leiden würde. Die indirekte Beleuchtung ist jedoch ein wesentlicher Bestandteil für fotorealistische Bilder und kann die Glaubhaftigkeit des Bildes wesentlich erhöhen. Globale Beleuchtungsmodelle beschreiben Verfahren in denen die indirekte Beleuchtung mit berechnet wird. Die meisten interaktiven Programme, die solche Verfahren einsetzen, sind jedoch auf gewisse Vereinfachungen angewiesen um die Bilder mit einer ausreichend hohen Framerate berechnen zu können. Zu diesen Vereinfachungen zählen zum Beispiel eine Begrenzung auf sehr einfache Szenen mit wenigen Objekten, oder Szenen mit rein diffusen Flächen. Andere Ansätze berechnen und speichern die indirekte Beleuchtung einmal komplett und greifen auf diese Informationen beim Rendering zurück. Dadurch sind sie aber für dynamische Szenen eher ungeeignet. Aufgabenstellung In dieser Arbeit soll ein Verfahren entwickelt, implementiert und evaluiert werden, das mithilfe moderner Grafik-Hardware eine qualitativ hochwertige und schnelle Lösung der globalen Beleuchtung berechnen kann. Hierzu soll die indirekte Beleuchtung adaptiv abgetastet und anschließend interpoliert werden. Die Aufgabe gliedert sich dabei in folgende Teile: 1. Rendering der Szene in Geometric-Buffers um die Abtastpunkte für die indirekte Beleuchtung zu bestimmen. 2. Abtasten der Szene und Speicherung einer Liste von Punkten, für die die indirekte Beleuchtung berechnet werden soll. Für die Abtastung soll ein kombinierter Kanten-, Tiefen- und Materialparameterfilter verwendet werden. Abtastpunkte sollen über einen Geometrie-Shader gefiltert werden. 7

8 1 Einleitung 3. Punktbasierte, hemisphärische Rasterisierung der Szenengeometrie zur schnellen Berechnung der einfallenden Radiance an den gefilterten Abtastpunkten. 4. Faltung der einfallenden Radiance mit Oberflächen-BRDFs auf der Grafik-Hardware mit Fragment Shadern. 5. Durchführung einer kantenerhaltenden Interpolation der indirekten Beleuchtung im Bildraum. Hierbei soll ein bestehendes Verfahren nach Segovia et al. [SIMP06] verwendet werden. 6. Ausgabe der direkten und indirekten Beleuchtung. Aufteilung der Ausarbeitung Die Gliederung der restlichen Arbeit sieht wie folgt aus. In Kapitel 2 wird zuerst die Rendering-Pipeline und die wichtigsten Aspekte der Hardware-Architektur moderner GPUs erklärt. Danach werden die Grundlagen der globalen Beleuchtung erklärt und einige andere, teils GPU-basierte Verfahren vorgestellt. Kapitel 3 enthält die theoretischen Grundlagen aller wichtigen Schritte des in dieser Arbeit implementierten Verfahrens und Kapitel 4 enthält Details zur Implementierung. Im Kapitel 5 werden die Ergebnisse der Implementierung vorgestellt. Kapitel 6 schließlich gibt eine Zusammenfassung der Arbeit und einen Ausblick für mögliche zukünftige Entwicklungen. 8

9 Kapitel 2 Grundlagen und Vorarbeiten 2.1 Grafik-Pipeline In diesem Kapitel soll zunächst eine kurze Übersicht über die Funktionsweise moderner Grafikkarten gegeben werden. Außerdem soll verdeutlicht werden, welche Vorteile eine Implementierung der in dieser Arbeit verwendeten Algorithmen durch Verwendung dieser Grafik-Hardware hat. Historisch betrachtet waren die ersten 3D-Karten dafür ausgelegt möglichst schnell eine Reihe von Dreiecken zu rendern. Sehr viel mehr Optionen als eine einfache Texturierung gab es nicht, jedoch konnte die Hardware diese einfache Aufgabe wesentlich schneller erledigen als vergleichbare Software, da sie speziell für diese Aufgabe optimiert wurde. Die aktuelle Generation von Grafikkarten besitzt diese Eigenschaft immer noch, jedoch sind die Grafikprozessoren (GPUs) wesentlich vielseitiger Einsetzbar geworden. Im Laufe der Zeit kamen immer mehr Möglichkeiten hinzu, die Vorgänge in der Rendering-Pipeline der GPU zu konfigurieren oder sogar selber zu programmieren. Hier unterscheidet man zwischen der Fixed-Function Pipeline, deren Verhalten nur über Parameter gesteuert werden kann und der programmierbaren Pipeline, deren Verhalten teilweise über Shader-Programme selbst programmiert werden kann. In Abbildung 2.1 ist eine konzeptuelle Ansicht der Rendering-Pipeline für Direct3D 10 kompatible GPUs zu sehen. Die Abschnitte mit abgerundeten Ecken können über Shader programmiert werden. Damit ergeben sich drei unterschiedliche Shader-Typen: Vertex-Shader bekommen als Eingabe immer jeweils einen Vertex sowie Attribute, die mit diesem Vertex verknüpft sind, wie zum Beispiel Texturkoordinaten oder Normalen. Die Hauptaufgabe eines Vertex-Shaders ist meistens, diese Daten zu transformieren. Geometrie-Shader sind die jüngste Shader-Art. Sie bekommen als Eingabe jeweils ein komplettes Primitiv, also ein Dreieck, eine Linie oder einen Punkt, abhängig davon was man gerade rendert. Als Ausgabe werden vom Shader neue Primitive erzeugt. Diese Primitive müssen nicht vom selben Typ sein, wie die Eingangsprimitive, es muss jedoch bei der Shader-Erzeugung festgelegt werden mit welchen Ein- und Ausgabetypen man 9

10 2 Grundlagen und Vorarbeiten Abbildung 2.1: Rendering-Pipeline in Direct3D 10 [D3D08] arbeitet. Es ist außerdem möglich keinen, oder mehr als einen Primitiv zu erzeugen. Innerhalb des Geometrie-Shaders hat man außerdem Zugriff auf benachbarte Vertices. Fragment-Shader (oder Pixel-Shader) werden meist zur Berechnung der Fragment- Farbe und -Tiefe verwendet. Zusätzlich können aber auch weitere Fragment-Daten geschrieben werden. Als Eingabe erhalten diese Shader die an der Fragment-Position interpolierten Vertex-Attribute, die im Vertex- oder Geometrie-Shader erzeugt wurden. Die restlichen Abschnitte können nur über Parameter beeinflusst werden. Diese Abschnitte sind: Der Input-Assembler erzeugt Primitive aus vom Programm übergebenen Daten, oder aus Vertex-Buffer Objekten. Stream-Output ist ein optionaler Abschnitt, über den die erzeugten Primitive wieder zurück in den Grafikspeicher geschrieben werden können. In OpenGL kann hierfür die Transform-Feedback Erweiterung [Ntf] verwendet werden. 10

11 2.2 OpenGL Der Rasterizer ist für das Clipping der Primitive zuständig und erzeugt außerdem die Fragment-Daten, die dann an den Fragment-Shader übergeben werden. Der Output-Merger kombiniert die Ergebnisse des Fragment-Shaders mit den Daten, die in den Framebuffern stehen. Hier finden unter anderem der Depth-Test und Blending statt. Um die einzelnen Pipeline-Schritte möglichst effizient abarbeiten zu können, bestehen moderne GPUs aus einigen hundert Stream-Prozessoren. Diese sind für die Ausführung der Shader zuständig und können für alle drei Shader-Typen eingesetzt werden. Die Zuweisung welcher Prozessor welche Aufgabe übernimmt geschieht automatisch. Dadurch kann die GPU optimal ausgelastet werden. Stream-Prozessoren sind voneinander unabhängig arbeitende Einheiten, die gut dazu geeignet sind große Datenströme parallel zu verarbeiten. Dadurch sind GPUs auch für Aufgabengebiete außerhalb der Grafikberechnung interessant. Diese Gebiete werden allgemein unter dem Begriff General Purpose Computation on Graphics Processing Units, kurz GPGPU, zusammengefasst. Als Programmierschnittstellen kommen dafür zum Beispiel CUDA [CUD] oder OpenCL [Ope] zum Einsatz. 2.2 OpenGL Für die Implementierung wurde die 3D Grafik-API OpenGL [ogl] eingesetzt. Dabei handelt es sich um eine standardisierte Schnittstelle, die mithilfe von Grafikkarten-spezifischen Implementationen verwendet werden kann. Die meisten der Funktionen werden dabei direkt auf der Grafikkarte ausgeführt. OpenGL besitzt eine Vielzahl an Erweiterungen, die nicht zwingend in jeder Implementierung enthalten sein müssen. Diese werden meist von den Grafikkarten-Herstellern entwickelt um spezielle Hardware-Funktionen zugänglich zu machen. Die grundlegende Idee hinter OpenGL ist, die Rendering-Pipeline als Zustandsautomat zu betrachten. Das bedeutet, dass die Eingabedaten, welche in den meisten Fällen aus Vertices oder Pixeln bestehen, anhand vorher eingestellter Zustände manipuliert werden. Zustände bleiben dabei so lange aktiv bis sie wieder geändert werden. Für eine genauere Beschreibung zu OpenGL sei auf andere Literatur verwiesen, wie zum Beispiel das OpenGL Redbook [OSW + 05] oder die offizielle Webseite Die folgenden Abschnitte behandeln die wichtigsten der verwendeten Erweiterungen ARB_framebuffer_object Ein Framebuffer Objekt (FBO, [Afb]) macht es möglich in andere Ziele zu rendern als die normalen, von OpenGL und dem Betriebssystem bereitgestellten, Front- und Back-Buffern. Als Ziele kommen entweder Texturen oder Renderbuffer in Frage. Bei Renderbuffern handelt 11

12 2 Grundlagen und Vorarbeiten es sich um eine weitere Objekt-Art, die durch diese Erweiterung eingeführt wurde. Sie werden genau wie Texturen zur Speicherung von Pixeln verwendet, können ansonsten aber nicht direkt wie Texturen eingesetzt werden. Jedes Framebuffer Objekt besitzt eine Reihe von Attachment -Punkten, an die Texturen oder Renderbuffer angefügt werden können. Diese Attachment-Punkte sind nach ihrer Datenart getrennt. Es gibt je einen für Tiefenwerte und Stencilwerte sowie insgesamt 16 für Farbwerte. Wichtig hierbei ist, dass die verwendeten Texturen und Renderbuffer immer dieselbe Größe haben und vom selben Texturtyp sind. Es ist zum Beispiel nicht möglich eine Cube-Map mit einem 2D Depth-Buffer zu vermischen. Außerdem muss der Attachment-Punkt etwas enthalten, wenn er als Ziel dienen soll. In welchen Farb-Buffer gerendert werden soll, wird über die Funktion gldrawbuffer angegeben, bzw. gldrawbuffers falls es mehrere Buffer sind. Sollen nur Tiefen- oder Stencilwerte geschrieben werden, muss gldrawbuffer mit GL_NONE als Parameter aufgerufen werden. Auch für die Validierung des Framebuffer Objekts mit glcheckframebufferstatus muss vorher mit gldrawbuffer der richtige Attachment-Punkt gewählt werden. Wenn mehrere Farb-Buffer als Ziel angegeben wurden, so kann man im Fragment-Shader über die Variable gl_fragdata[i] in den i-ten Buffer schreiben. Mit Framebuffer Objekten ist es außerdem möglich, diese direkt zurück in den Hauptspeicher auszulesen. Dazu muss über glreadbuffer der entsprechende Attachment-Punkt gewählt werden. Auslesen geht dann über die Funktion glreadpixels EXT_timer_query Wenn man die Zeit messen will, die bestimmte OpenGL-Operationen benötigen, so hat man mit einer Messung auf CPU-Seite das Problem, dass man hierfür sowohl beim Start der Messung als auch beim Ende der Messung sicherstellen muss, dass die Grafik-Pipeline komplett abgearbeitet ist. Ansonsten würde man entweder andere Operationen mit messen, oder zu kurze Zeiten messen, da die Pipeline noch beschäftigt ist. Die Gründe hierfür sind, dass die OpenGL-Befehle nicht synchron zu ihren Funktionsaufrufen im Programm abgearbeitet werden, da für die meisten Funktionen der Funktionsaufruf beendet ist, sobald die Parameter an den Grafiktreiber weitergegeben wurden. Hier setzt die Erweiterung EXT_timer_query [Etq] an. Sie verlagert die Zeitmessung auf die Pipeline-Seite. Hierfür wird ein neues Query-Objekt definiert mit dem man die genaue Zeit messen kann, die alle OpenGL-Operationen zwischen Beginn (glbeginquery) und Ende (glendquery) der Zeitmessung brauchen. Beachten muss man hierbei, dass die Zeit nicht sofort nach Beendigung von glendquery auslesbar ist, sondern erst nach Beendigung aller Operationen, die vor glendquery noch in der Grafik-Pipeline abgearbeitet werden müssen. Die Ergebnisse sollten deshalb nicht direkt nach glendquery ausgelesen werden, sondern erst kurz bevor das Frame komplett gerendert wurde, ansonsten würde man nur unnötige Leerlaufzeiten für die Grafikkarte erzeugen. Ein minimales Beispiel für EXT_timer_query ist im folgenden Listing zu sehen. Die gemessene Zeit ist in Nanosekunden (10 9 s). 12

13 2.2 OpenGL 1 GLint query; 2 GLint available = 0; 3 GLuint64EXT timeelapsed = 0; 4 glgenqueries(1, &query); 5 6 // begin time meassuring 7 glbeginquery(gl_time_elapsed_ext, query); 8 9 // draw stuff // end time meassuring 12 glendquery(gl_time_elapsed_ext); // wait for the results to become available 15 while (!available) { 16 glgetqueryobjectiv(query, GL_QUERY_RESULT_AVAILABLE, &available); 17 } 18 // get timing results 19 glgetqueryobjectui64vext(query, GL_QUERY_RESULT, &timeelapsed); Listing 2.1: Minimalbeispiel für EXT_timer_query NV_transform_feedback Die Erweiterung NV_transform_feedback [Ntf] bzw. EXT_transform_feedback ermöglichen es bestimmte Vertex-Attribute in Buffer-Objekte zu speichern. Falls ein Geometrie-Shader vorhanden sein sollte, werden diese Attribute aus den Ergebnissen des Geometrie-Shaders gelesen. Ansonsten wird der Vertex-Shader verwendet. Gespeichert werden können entweder die Built-In Variablen oder die im Shader definierten Variablen. Im zweiteren Fall kann es vorkommen, dass die Variable eigentlich vom Shader-Compiler wegoptimiert wird. Dies kann verhindert werden mit der Funktion glactivevaryingnv, die vor dem Linken der Shader aufgerufen werden muss. Ein kleines Beispiel, das die Ergebnisse, die in der Variablen position gespeichert werden, in den Buffer tfbuffer speichert, ist im Listing 2.2 zu sehen. Die Anzahl der gespeicherten Werte wird über ein Query-Objekt abgefragt. 1 int loc[1] = {glgetvaryinglocationnv(shader, "position")} 2 gltransformfeedbackvaryingsnv(shader, 1, loc, GL_SEPARATE_ATTRIBS_NV); 3 glbindbufferbasenv(gl_transform_feedback_buffer_nv, 0, tfbuffer); 4 glbegintransformfeedbacknv(gl_triangles); 5 glbeginquery(gl_transform_feedback_primitives_written_nv, query); 6 7 // draw some triangles glendquery(gl_transform_feedback_primitives_written_nv); 10 glendtransformfeedbacknv(); queryavailable = 0; 13 while (queryavailable == 0) { 13

14 2 Grundlagen und Vorarbeiten 14 glgetqueryobjectiv(query, GL_QUERY_RESULT_AVAILABLE, &queryavailable); 15 } 16 glgetqueryobjectuiv(query, GL_QUERY_RESULT, &queryresult); Listing 2.2: Minimalbeispiel für NV_transform_feedback 2.3 Radiometrie Unter Radiometrie versteht man allgemein die Messung von elektromagnetischer Strahlung, wie zum Beispiel Licht. Daher ist es für die Beleuchtungsberechnung wichtig, die unterschiedlichen Größen der Radiometrie zu kennen. Hierbei ist jedoch zu beachten, dass es sich bei diesen Größen um physikalische Größen handelt. Das menschliche Auge nimmt Licht jedoch anders war, da es unterschiedlich stark auf Licht mit unterschiedlicher Wellenlänge reagiert. Für diesen Aspekt ist die Photometrie zuständig, welche hier jedoch nicht behandelt wird. Name Variable SI-Einheit Beschreibung Strahlungsenergie (radiant Q J Die Energie einer Anzahl an Photonen energy) Strahlungsleistung/-fluss P W Strahlungsenergie pro Zeit (radiant flux) Strahlstärke/Strahlungsintensität I W/sr Strahlungsleistung pro Raumwinkel (radiant intensi- ty) Bestrahlungsstärke (irradiance) E W/m 2 Strahlungsleistung pro effektiver Empfängerfläche spezifische Ausstrahlung (radiant exitance/radiosity) M W/m 2 Strahlungsleistung pro effektiver Senderfläche Strahldichte (radiance) L W/(m 2 sr) Strahlungsleistung pro Raumwinkel und pro effektiver Senderfläche Tabelle 2.1: Radiometrische Größen Die wichtigsten radiometrischen Größen sind in Tabelle 2.1 enthalten. Für spätere Abschnitte werden vor allem für die Strahldichte und die Bestrahlungsstärke die englischen Begriffe verwendet. Licht kann allgemein als eine Ansammlung von Photonen betrachtet werden. Jedes einzelne Photon besitzt eine gewisse Energie, deren Größe abhängig ist von der Farbe des Lichts. Da sich die Photonen jedoch meist mit beinahe Lichtgeschwindigkeit bewegen, sind alle weiteren Größen abhängig vom Strahlungsfluss und nicht von der Strahlungsenergie. Der Strahlungsfluss ergibt sich aus Strahlungsenergie pro Sekunde. Der Strahlungsfluss von einem Punkt aus pro Raumwinkel wird als Strahlungsintensität bezeichnet. Dieser kann aus dem Strahlungsfluss berechnet werden durch I = dp/ dω. 14

15 2.3 Radiometrie Der Strahlungsfluss, der auf eine Punkt einer Fläche auftrifft, wird als Bestrahlungsstärke bezeichnet. Berechnet wird sie über E = dp/ da. Eine verwandte Größe ist die spezifische Ausstrahlung, welche proportional zur Bestrahlungsstärke und vom Material der Fläche abhängig ist. Die wichtigste Größe ist die Strahldichte bzw. Radiance. Diese Größe wird normalerweise von Kamerasensoren gemessen. Sie kann als Dichte eines Lichtstrahls interpretiert werden und ist damit weder von der Fläche noch vom Raumwinkel abhängig. Berechnen lässt sie sich entweder aus der Strahlungsintensität oder der Bestrahlungsstärke über: L = 1 cos θ d 2 P da dω = di(θ) da cos θ Die Beleuchtung einer kompletten Szene kann bestimmt werden, indem die Radiance, die in einen Kamerasensor fällt berechnet wird. Die Rendering-Gleichung [Kaj86] drückt genau dies aus. L o (p, v) = L e (p, v) + f ( l, v) Li (p, l) cos θi dω i (2.1) Ω Die Größen dieser Gleichung im einzelnen sind: p: Der zu betrachtende Punkt auf einer Fläche. v: Ein vom Punkt p ausgehender Vektor. Dies kann zum Beispiel ein Vektor zur Kamera sein. l: Ein Vektor zu einer Lichtquelle, wobei hier auch jede andere Fläche eine Lichtquelle darstellt. L o (p, v): Die gesamte vom Punkt p in Richtung v abgestrahlte Radiance. L e (p, v): Die vom Punkt p selbst erzeugte und in Richtung v abgestrahlte Radiance. f ( l, v): Die BRDF für die eingehende Richtung l, und ausgehende Richtung v. L i (p, l): Die Radiance, die aus Richtung l auf den Punkt p fällt. θ i : Winkel zwischen Normale und l am Punkt p. Das Integral betrachtet die einfallende Radiance L i über der kompletten Hemisphäre Ω. Die BRDF gewichtet diese Radiance abhängig von den Vektoren l und v. Zusammen mit der am Punkt p erzeugten Radiance L e ergibt sich damit die ausgehende Radiance L o. Die BRDF ( Bidirectional Reflectance Distribution Function ) gibt abhängig von der Oberfläche und abhängig von den Eingangs- und Ausgangswinkeln einen Gewichtungsfaktor zurück. Dieser Faktor bestimmt, wieviel des Lichts aus einer bestimmten Richtung in eine 15

16 2 Grundlagen und Vorarbeiten bestimmte Richtung reflektiert wird. Die BRDF über die komplette Hemisphäre integriert sollte immer einen Wert ergeben, der maximal 1 sein kann. Das bedeutet es wird nie mehr Licht reflektiert als auf die Fläche fällt und somit gilt der Energieerhaltungssatz. 2.4 Globale Beleuchtung Zur Beleuchtung von Punkten in einer Szene kann man zwei unterschiedliche Beleuchtungsmodelle unterscheiden. Zum einen die lokalen Beleuchtungsmodelle ( local illumination ) und zum anderen die globalen Beleuchtungsmodelle ( global illumination ). Bei der lokalen Beleuchtung wird nur das Verhalten von Licht an Flächen berechnet ohne andere Flächen zu berücksichtigen. Das bedeutet es wird nur direkte Beleuchtung berücksichtigt. Diese Art der Beleuchtung lässt sich relativ schnell berechnen und wird deshalb vorwiegend für interaktive Anwendungen eingesetzt. Bei der globalen Beleuchtung werden für die Beleuchtung einer Fläche zusätzlich auch alle anderen Flächen mit berücksichtigt. Dadurch werden Flächen auch durch indirektes Licht, also durch von anderen Fläche reflektiertes Licht, beleuchtet. Die Berechnungen hierfür sind jedoch deutlich aufwendiger, weshalb globale Beleuchtungsmodelle bisher vor allem in nicht-interaktiven Anwendungen zum Einsatz kommen. Die Rendering-Gleichung 2.1 kann für die lokale Beleuchtung so gedeutet werden, dass die Radiance L i nur für Lichtquellen existiert. Dadurch kann für jeden Punkt auf einer Fläche die Radiance sofort berechnet werden, ohne rekursiv die Radiance anderer Flächen bestimmen zu müssen. Die globale Beleuchtung berechnet in der Theorie die komplette Lösung der Rendering-Gleichung, in der Praxis werden jedoch meistens gewisse Vereinfachungen gemacht um den Aufwand zu senken GPU-basierte globale Beleuchtung Um globale Beleuchtungsberechnung auch in interaktiven Anwendungen einsetzen zu können, müssen starke Vereinfachungen in Kauf genommen werden. Einige der Verfahren erzeugen dabei keine physikalisch korrekten Bilder mehr. Dies wird als Fake Global Illumination bezeichnet. Für das menschliche Auge können solche Verfahren jedoch noch realistisch genug aussehen, um einen guten Kompromiss zu langsameren, aber realistischeren Verfahren zu bieten. Besonders gut geeignet für eine Implementierung auf GPUs sind globale Beleuchtungsmodelle vor allem dann, wenn sie hochparallel berechnet werden können. Einzelne Berechnungen dürfen dazu auch möglichst nicht auf die Ergebnisse anderer, parallel laufender Berechnungen zugreifen, da solche Vorgänge nicht besonders gut mit der Grafikpipeline realisierbar sind. Die folgenden Abschnitte enthalten eine Kurzbeschreibung zu den wichtigsten Verfahren, für die teilweise GPU-basierte Implementierungen existieren. 16

17 2.4 Globale Beleuchtung Radiosity Das Radiosity-Verfahren [GTGB84] ist eines der ältesten Verfahren zur globalen Beleuchtungsberechnung für diffuse Flächen. Die Idee dahinter ist relativ einfach. Die Szene wird zuerst in n kleine Patches aufgeteilt. Dann wird für jedes Paar an Patches ein Formfaktor F ij berechnet, der die Sichtbarkeit der Patches untereinander angibt. Dieser Wert kann von 0 bis 1 gehen und beeinflusst wieviel Licht zwischen den Patches ausgetauscht werden kann. Mithilfe des Formfaktors und der diskreten Radiosity-Gleichung 2.2 kann dann ein lineares Gleichungssystem aufgestellt werden, mit dem die Radiosity B i an jedem Patch i berechnet werden kann. B i = E i + ρ i n j=1 B j F ij, 1 i n (2.2) Der Faktor ρ i gibt den Anteil der Radiosity an, die von einem Patch wieder reflektiert wird. E i ist die Eigenstrahlung eines Patches. Über diesen Wert werden Patches erzeugt, die als Lichtquellen fungieren. Das Verfahren lässt sich auch adaptiv Lösen, indem in jedem Schritt einmal Licht zwischen allen Patches ausgetauscht wird. Dadurch erhält man schneller einen guten Überblick, wie das fertige Ergebnis aussehen wird. Die Änderungen durch folgende Schritte werden immer geringer, so das irgendwann die komplette Lösung der Radiosity-Gleichung erreicht wird oder man das Verfahren beenden kann, da keine nennenswerten Veränderungen mehr auftreten. Das Radiosity-Verfahren ist ein ziemlich rechenintensives Verfahren. Die meiste Zeit wird hierbei für die Berechnung der n2 2 Formfaktoren benötigt. Um trotz dieser Berechnungen noch interaktive Frameraten zu erhalten, muss also entweder die Anzahl der Patches sehr niedrig gehalten werden, oder man berechnet einen Teil im Voraus. Im zweiteren Fall muss jedoch die Szene statisch sein. Eine weitere Möglichkeit ist, die komplette Radiosity für alle Patches einmal zu berechnen und diese Werte zum Rendern der Frames zu verwenden. Hierfür muss die Szene aber auch statisch sein. Carr und Hart [CHH03] lösen das lineare Gleichungssystem auf der GPU, verwenden aber vorberechnete Formfaktoren. Coombe et al. [CHL04] implementieren ein komplettes progressives Radiosity-Verfahren auf der GPU inklusive Formfaktor-Berechnung und adaptives Aufteilen der Patches, erreichen damit aber keine interaktiven Frameraten. Ray Tracing Ray Tracing kann unterschieden werden in klassisches Ray Tracing und Monte Carlo Ray Tracing. Beim klassischen Ray Tracing werden Strahlen für jeden Pixel ausgeschickt und deren Pfad verfolgt. Trifft ein Strahl auf eine spiegelnde Fläche, so wird ein neuer Strahl in 17

18 2 Grundlagen und Vorarbeiten Richtung der Reflektion geschickt. Trifft der Strahl auf eine transparente Fläche, so wird ein neuer Strahl in Richtung des gebrochenen Strahls geschickt. Dies kann auch in Kombination auftreten. Trifft der Strahl auf eine diffuse Fläche, so endet er hier und man kann die Radiance für diesen Strahl berechnen und durch Rückverfolgung des kompletten Pfads bis zum Auge auch für alle anderen Strahlen. Beim Monte Carlo Ray Tracing werden zusätzliche Strahlen ausgeschickt, die nicht in die Richtung der Reflektion/Refraktion gehen. Für die Wahl der Richtung kann entweder ein Importance Sampling mithilfe der Oberflächen-BRDF gemacht werden, oder man schickt die neuen Strahlen in zufällige Richtungen aus. Insgesamt gibt es zwei Arten beim Monte Carlo Ray Tracing. Beim Path Tracing werden für jeden Pixel sehr viele Strahlen abgeschickt. Jeder Strahl beginnt an der Kamera und wird beim Treffen auf einer Fläche nur in eine zufällige Richtung reflektiert. Beim Distribution Ray Tracing wird nur ein Strahl oder eine sehr kleine Menge an Strahlen pro Pixel ausgeschickt. Beim Treffen auf eine Fläche teilt sich jeder Strahl jedoch in viele weitere Strahlen, die in die unterschiedlichen Richtungen abgeschickt werden. Es existieren einige GPU basierte Implementierungen von Ray Tracing für sehr einfache Szenen, jedoch sinkt hier die Performance schnell ab, wenn weitere Objekte in die Szene eingefügt werden. Effizientere Datenstrukturen, wie kd-trees ([FS05] und [HSHH07]) können hier zu einer besseren Performance führen. Allgemein sind jedoch noch keine zu großen Vorteile zu CPU-basierten Verfahren erreicht worden. Es existieren allerdings erste für Ray Tracing entwickelte Hardware-Prototypen [SWS05]. Von NVIDIA wurde außerdem NVIRT angekündigt [NVI09]. Dabei soll es sich um eine auf CUDA aufsetzende API handeln, mit der Ray Casting durchgeführt werden kann. Hiermit sollte auch ein Ray Tracer implementierbar sein. Instant Radiosity Beim Instant Radiosity Verfahren [Kel97] wird die Szene mehrfach aus derselben Kamera- Perspektive, aber mit unterschiedlichen, sogenannten Virtual Point Lights (VPL), gerendert. VPLs werden dabei zuerst an zufälligen Positionen innerhalb der normalen Lichtquellen erzeugt. Die über diese VPLs erzeugten Bilder ergeben zusammen die direkte Beleuchtung. Hierdurch erhält man automatisch weiche Schatten, falls die Lichtquellen in der Szene keine Punktlichtquellen sind. Für die indirekte Beleuchtung werden weitere VPLs erzeugt indem von den Lichtquellen aus Partikel in die Szene geschossen werden. Die Position neuer VPLs ergibt sich aus dem ersten Treffer eines Partikels mit der Geometrie. Jedes Partikel besitzt einen Farbwert, der zuerst der Farbe der Lichtquelle in Richtung des Partikels entspricht. Die Lichtfarbe der neuen VPLs wird dann durch Kombination der Partikelfarbe und der Farbe der Fläche ermittelt. Die mit diesen VPLs gerenderten Bilder entsprechen der indirekten Beleuchtung nach der ersten Reflexion. 18

19 2.4 Globale Beleuchtung Dieser Vorgang lässt sich weiter wiederholen, so dass auch mehrfache Reflexionen berechnet werden. Die Qualität des Ergebnisses hängt im wesentlichen von der Anzahl an Bildern und VPLs ab, die man dafür erzeugt. Keller erwähnt, dass 50 bis 300 VPLs ausreichend wären. Der Aufwand für die Berechnung eines Bildes lag 1997 noch über einige Sekunden. Instant Radiosity zeichnet sich vor allem dadurch aus, dass es einfach auf Graphik-Hardware implementiert werden kann. Jedoch kommt das Standard-Verfahren nur mit diffusen Flächen zurecht. Einfache spekulare Reflexionen können zwar implementiert werden, indem zusätzliche Partikel in Richtung der spekularen Reflexion geschickt werden und ein Spotlight an der Stelle der Reflexion erstellt wird, allerdings steigt dadurch auch der Aufwand für die Berechnung. Für Instant Radiosity existieren eine Reihe von Erweiterungen und Verbesserungen, die vor allem durch die Weiterentwicklung der Grafik-Hardware möglich wurden. Segovia et al. [SIP06] erweitern Instant Radiosity zu Bidirectional Instant Radiosity. Dabei werden zusätzlich zu den VPLs ausgehend von den Lichtquellen noch weitere VPLs ausgehend von den Bildpunkten berechnet. Diese VPLs werden so gewählt, das sie die Pixel direkt beleuchten und das sie durch einen Pfad der Länge 2 mit einer Lichtquelle verbunden sind. Zusätzlich wird in dem Paper Deferred Shading [ST90] verwendet um den Shading-Vorgang auf alle sichtbaren Pixel des aktuellen Frames zu reduzieren. Ein weiteres Paper von Segovia et al. [SIMP06] beschreibt die Aufteilung der G-Buffer für Deferred Shading in n m Sub-Buffer. Für jeden Sub-Buffer wird dann das Shading mit jeweils einem kleinen Teil der VPLs durchgeführt. Durch dieses Vorgehen wird die Pixel Füllrate deutlich reduziert, so dass interaktive Geschwindigkeiten erreicht werden können. Um das dabei entstehende Rauschen zu vermindern kann zusätzlich noch ein kantenerhaltender Gauss-Filter angewendet werden. Eine weitere Erweiterung von Ritschel et al. [RGK + 08] erweitert das Verfahren um Shadow Maps für die VPLs der indirekten Beleuchtung, die zuvor weggelassen wurden. Sie macht sich die Tatsache zunutze, dass für die indirekte Beleuchtung auch sehr ungenaue Shadow Maps ausreichend sind. Anstatt also die komplette Geometrie in eine hochauflösende Shadow Map zu rendern, wie es für das direkte Licht notwendig ist, werden für jedes VPL sehr kleine Shadow Maps erzeugt durch rendern einer punktbasierten Vereinfachung der Geometrie. Dadurch kann eine Framerate von über 10 FPS erreicht werden ohne gleichzeitig größere Artefakte zu erzeugen. Antiradiance Eine der Gründe für den hohen Aufwand bei der globalen Beleuchtungsberechnung liegt darin, dass sehr viele Sichtbarkeitstests durchgeführt werden müssen. Um diese Tests zu vermeiden kann eine neue Größe eingeführt werden, die Antiradiance [DSDD07]. Mithilfe der Antiradiance kann die Rendering Gleichung so umgeformt werden, das man komplett auf explizite Sichtbarkeitstests verzichten kann. 19

20 2 Grundlagen und Vorarbeiten Die Idee hierbei ist, den Fehler, der bei einer Beleuchtungsberechnung ohne Verdeckungen entsteht durch negatives Licht zu kompensieren. Dieses negative Licht, Antiradiance genannt, wird von jeder Fläche abgestrahlt, die von dem normalen Licht bestrahlt wird, und zwar in jeweils dieselbe Richtung. Hierbei werden jedoch ein paar der zuvor zu hellen Flächen mehrfach durch die Antiradiance abgedunkelt, was wiederum durch positive Radiance, die ähnlich abgestrahlt wird wie die Antiradiance, ausgeglichen werden kann. Mehrfache Iterationen dieses Vorgehens ergeben eine Lösung, die näherungsweise mit der Lösung der normalen Rendering Gleichung übereinstimmt. Irradiance und Radiance Caching Beim Irradiance Caching [WRC88] handelt es sich um ein mit Radiosity verwandtes Verfahren, dass jedoch nur die indirekte Beleuchtung für diffuse Flächen berechnet. Hierbei wird außerdem die Irradiance anstatt der Radiosity gespeichert. Ein Vorteil des Verfahrens gegenüber Radiosity ist, dass die Flächen nicht in kleinere Patches aufgeteilt werden müssen. Irradiance Caching kann zusammen mit Ray Tracing Verfahren eingesetzt werden um die Berechnung der indirekten Beleuchtung zu beschleunigen. Irradiance Caching nutzt die Tatsache aus, dass sich die Irradiance auf diffusen Flächen für benachbarte Punkte nur wenig ändert. Für die indirekte Beleuchtung reicht es daher aus, den Irradiance-Wert nur an einigen wenigen Punkten zu berechnen und alles dazwischen aus den bekannten Werten zu interpolieren. Den Irradiance Wert an einem Punkt erhält man durch Sampling der Hemisphäre über dem Punkt. Hierfür kann zum Beispiel Ray Tracing oder Photon Mapping eingesetzt werden. Das Original-Verfahren von Ward ist für eine direkte Implementierung auf der GPU nicht geeignet, da hier der Irradiance Cache nur bei Bedarf erweitert wird und alle Werte in einem Octree gespeichert werden. Für bessere Ergebnisse bei der Interpolation der Irradiance Werte gibt es Erweiterungen des Verfahrens von Ward und Heckbert [WH08], die zusätzlich zur Irradiance noch zwei Gradienten speichern, je einen für Verschiebungen und einen für Rotationen. Mit diesen Gradienten lässt sich die ungefähre Veränderung der Irradiance zwischen den bekannten Cache-Positionen besser vorhersagen, wodurch qualitativ bessere Bilder entstehen und weniger Caches benötigt werden. Für nicht-diffuse Flächen, bzw. BRDFs mit einer höheren Frequenz, kann Radiance Caching [KGPB08] eingesetzt werden. Hierbei werden anstatt einem einzigen Irradiance Wert mehrere Radiance Werte gespeichert. Radiance Caches können zum Beispiel über Hemispherical Harmonics [JeG + ] gespeichert werden. Alternativ können die Radiance-Werte auch direkt gespeichert werden, was aber mit einem höheren Speicherverbrauch verbunden ist. Genau wie für Irradiance Caches kann auch für Radiance Caches eine gradientenbasierte Interpolation der Werte [KGBP08] durchgeführt werden. Durch die Berechnung eines Gradienten kommt man mit weniger Caches aus, benötigt dafür aber mehr Zeit für die Berechnung der Gradienten. 20

21 2.4 Globale Beleuchtung Photon Mapping Photon Mapping [Jen96] ist eine weitere Methode die zur Berechnung der indirekten Beleuchtung eingesetzt werden kann. Hierbei werden zuerst von den Lichtquellen Photonen ausgeschickt, die beim Auftreffen auf eine Fläche entweder von dieser absorbiert, reflektiert oder gebrochen werden. Reflektierte und gebrochene Photonen werden weiterverfolgt, absorbierte Photonen nicht. Für alle Photonen wird die Position und Richtung aus der der Photon kam, sowie die Energie des Photons gespeichert. Die Photon Map kann entweder direkt zur Beleuchtungsberechnung verwendet werden, oder man führt einen Final Gathering Schritt durch. Beim direkten Auslesen werden für jeden Bildpunkt die Photonen in der näheren Umgebung verwendet um einen Radiance-Wert zu berechnen. Für gute Ergebnisse werden hierzu sehr viele Photonen benötigt, sonst kommt es vor, dass die Darstellung entweder verschwommen oder fleckig wirkt wenn zu wenige Photonen in der näheren Umgebung liegen. Beim Final Gathering wird für jeden Bildpunkt die indirekte Beleuchtung aus der Photon Map gelesen, indem für eine Reihe von Photonen berechnet wird, wieviel Licht durch sie auf den Bildpunkt fällt. Die Anzahl der Photonen kann beim Final Gathering niedrig gehalten werden, jedoch ist ein zusätzlicher Schritt zur Berechnung der direkten Beleuchtung nötigt, der zum Beispiel mit Ray Tracing gemacht werden könnte. Photon Mapping wird meistens nur in nicht-interaktiven Anwendungen eingesetzt, da die Berechnungen zu lange dauern. Ein Beispiel für ein komplett auf der GPU implementiertes Verfahren, das Photon Mapping verwendet, wurde in [PDC + 03] vorgestellt. Die Berechnungszeiten liegen jedoch bei einigen Sekunden bis Minuten, abhängig von der Komplexität der Szene. Außerdem fehlt ein Final Gathering, wodurch die nur indirekt beleuchteten Flächen ziemlich verrauscht sind. Ambient Occlusion Ambient Occlusion ist eine Methode mit der der ansonsten konstante ambiente Lichtanteil eines Shading-Verfahrens verändert werden kann. Für die Änderung an einem Punkt ist dabei die umgebende Geometrie verantwortlich. Dazu wird von dem Punkt aus die Hemisphäre über dem Punkt betrachtet indem zum Beispiel einige Strahlen in unterschiedliche Richtungen ausgeschickt werden. Treffen viele dieser Strahlen schon nach kurzer Zeit auf andere Flächen, so wird das ambiente Licht an diesem Punkt abgeschwächt. Treffen die meisten Strahlen erst in einiger Entfernung auf andere Flächen, oder treffen auf gar keine Flächen, so bleibt das ambiente Licht unverändert. Bei der Berechnung des Ambient Occlusion Faktors wird meist zusätzlich eine modifizierte Normale ( bent normal ) berechnet, die anstatt senkrecht von der Fläche weg zu zeigen in die ungefähre Richtung der niedrigsten Verdeckung zeigt. Diese Normale kann für weitere Shading-Operationen verwendet werden. 21

22 2 Grundlagen und Vorarbeiten Durch Ambient Occlusion wird keine echte globale Beleuchtung berechnet. Es sollen damit vielmehr die Verschattungen an Kanten und Fugen simuliert werden, die bei der globalen Beleuchtung entstehen würden. Es wird vor allem dann eingesetzt, wenn echte globale Beleuchtung zu Aufwendig wäre. Das Verfahren ist nicht abhängig von den Lichtquellen der Szene, sondern nur von der Geometrie. Das bedeutet, wenn die Geometrie statisch ist, kann man den Ambient Occlusion Wert vorberechnen und in einer Textur speichern. Für dynamische Szenen gibt es einige Verfahren, die den Occlusion-Faktor zur Laufzeit berechnen können. Diese Verfahren teilen sich auf in Object-Space und Screen-Space Verfahren. Object-Space Verfahren sind in der Regel teurer zur Berechnung, da sie von der Komplexität der Geometrie abhängig sind. Ein Beispiel für eine Object-Space Methode wurde in GPU Gems 2 [Pha05] vorgestellt. Dabei wird die Geometrie durch eine Reihe von Scheiben vereinfacht, über die der Occlusion- Faktor berechnet werden kann ohne Strahlen ausschicken zu müssen. Das Verfahren ist in 2 Teile aufgeteilt. Im ersten Teil wird der Occlusion Faktor und die Bent-Normal berechnet. Der Wert, der hierbei herauskommt, enthält auch mehrfache Verschattungen durch Überlagerung der Scheiben. Um diesen Fehler wieder zu korrigieren wird im zweiten Teil der Anteil, den jede Scheibe am Occlusion-Faktor jeder anderen Scheiben hat, um den Occlusion-Faktor, der im ersten Teil berechnet wurde, vermindert. Screen-Space Ambient Occlusion (SSAO) ist für komplexere Szenen besser geeignet, da hierbei nur die Fragment-Daten, wie Normale und Tiefe benötigt werden. Eine der ersten Implementationen von SSAO befindet sich in der CryEngine 2 von Crytek [Mit07]. Hier werden eine Reihe von Samples innerhalb einer Kugel um den aktuellen Pixel mit dem Z-Test im Depth-Buffer verglichen. Die Anzahl an Samples, die nicht von der Geometrie verdeckt werden wird zur Berechnung des Occlusion Faktors verwendet. Da die Samples über die komplette Kugel verteilt sind, wird davon ausgegangen, dass nur die Hälfte der Samples innerhalb der Hemisphäre senkrecht zum Punkt liegen. Das bedeutet, wenn die Hälfte aller Samples nicht verdeckt wurden, ist der Occlusion Faktor 1, ansonsten wird die Zahl der nicht verdeckten Samples durch die Hälfte aller Samples geteilt und dieser Wert als Occlusion Faktor genommen. Gute Ergebnisse mit niedrigem Rauschen erzielt man mit diesem Vorgehen erst bei etwa 200 Samples. Das würde jedoch zu einer zu niedrigen Framerate führen. Deswegen werden nur bis zu 16 Samples verwendet, wobei für jeden Punkt die Samples anders zufällig verteilt sind. Die Ambient Occlusion Map, die dabei herauskommt wird dann noch mit einem Blur-Filter nachbearbeitet, so dass das Rauschen weitestgehend verschwindet. 22

23 Kapitel 3 Punktbasiertes Radiance Caching Im folgenden sollen die theoretischen Grundlagen des in dieser Arbeit implementierten Verfahrens näher erläutert werden. Eine Beobachtung die bei einigen der in Abschnitt behandelten globalen Beleuchtungsmodellen ausgenutzt wurde, ist, dass sich die indirekte Beleuchtung für diffuse Flächen nur relativ langsam ändert im Vergleich zur direkten Beleuchtung. Dies wird speziell beim Irradiance Caching ausgenutzt. Das ursprüngliche Verfahren [WRC88] eignet sich jedoch in der Form nicht für eine GPU-basierte Implementierung. Um das Verfahren GPU-tauglich zu machen, müssen die Positionen, für die die indirekte Beleuchtung berechnet werden soll, in einem Schritt bestimmt werden. Dies geschieht über ein Importance Sampling der Szene, das besonders an Übergängen zwischen unterschiedlichen Objekten viele, inmitten größerer Flächen aber nur einige wenige Punkte platziert. Für jeden dieser Punkte wird ein Cache Record, bestehend aus Position und Normale, angelegt. Irradiance-Werte zu speichern ist nur ausreichend, wenn eine konstante BRDF eingesetzt werden soll. Um jedoch auch andere BRDFs zu ermöglichen, wird stattdessen die einfallende Radiance über die komplette Hemisphäre gespeichert. Für jede der über Importance Sampling ermittelten Positionen muss jeweils ein solcher Radiance Cache berechnet werden. Da alle Caches innerhalb eines Frames berechnet werden sollen, ist hierfür ein möglichst effizientes Verfahren notwendig. Das gewählte Verfahren basiert auf den Imperfect Shadow 23

24 3 Punktbasiertes Radiance Caching Maps [RGK + 08]. Hierbei wird die Geometrie durch eine Anzahl an Punkten approximiert. Diese Punkte werden jeweils in jeden der Caches gerendert. Dabei wird für jeden Punkt die direkte Beleuchtung berechnet. Anschließend werden mithilfe des Pull-Push Verfahrens Löcher überdeckt. Das ganze wird mit zwei wesentlichen Einschränkungen durchgeführt. Zum einen wird nur das 1-fach indirekte Licht in den Radiance Caches gespeichert. Zum anderen wird in Kauf genommen, dass der Cache-Inhalt kleinere Fehler aufweist. Zur Berechnung des indirekten Lichts werden alle Radiance Caches ausgelesen. Für jeden Cache wird dabei die an der Position des Caches in Richtung der Kamera reflektierte Radiance berechnet. Für die Positionen, an denen keine Caches existieren, wird die indirekte Beleuchtung ermittelt durch Interpolation der bekannten Werte aus der Umgebung. Hierbei wird ein kantenerhaltender Gauss-Filter ähnlich wie in [SIMP06] eingesetzt. Der Gauss-Filter hat den Vorteil, das er in O(n) implementierbar ist, da er in einen spaltenweisen und einen zeilenweisen Filterschritt zerlegt werden kann. 3.1 G-Buffers In einigen Schritten des ganzen Verfahrens werden Informationen aus dem aktuellen Frame benötigt. Um diese Informationen zu erhalten, werden sogenannte Geometric Buffer (G- Buffer) erstellt. G-Buffer werden ursprünglich beim Deferred Shading ([DWS + 88] und [ST90]) eingesetzt und enthalten die für das Shading der Fragmente wichtigen Variablen. Die Idee hinter Deferred Shading ist, zunächst keine aufwendigen Berechnungen oder Texturzugriffe zu machen und nur die Variablen zu schreiben, die für das Shading wichtig sind. Die eigentlichen Shading-Operationen werden dann in einem Post-Processing Durchgang im Bildraum durchgeführt. Dadurch werden diese Operationen nur für Fragmente durchgeführt, die auch im Bild zu sehen sind und nicht mehr noch zusätzlich für Fragmente, die irgendwann verworfen werden. Die Informationen, die später benötigt werden sind die Normale, Position und diffusen und spekularen Materialeigenschaften. Der spekulare Anteil wird abhängig von der verwendeten BRDF nicht unbedingt benötigt. 3.2 Quasi-Monte Carlo Verteilung Für das Importance Sampling und für die Erstellung zufälliger Oberflächenpunkte wird eine Methode benötigt, die Punkte möglichst gleichmäßig und zufällig zu verteilen. Um zufällige Zahlen zu erhalten, können entweder Zufallsgeneratoren verwendet werden, oder man verwendet Quasi-Zufallszahlen, die zwar zufällig aussehen, aber immer dieselbe Sequenz an Zahlen enthalten. Der Vorteil solcher Quasi-Monte Carlo Methoden ist, dass die Verteilung der Punkte gleichmäßiger ist und man keine unerwünschten Verdichtungen oder Löcher erhält. 24

25 3.2 Quasi-Monte Carlo Verteilung Die hier verwendete Methode verwendet die Halton Sequenz ([Hal60] und [Kel97]) um eine möglichst gleichmäßige Verteilung von Punkten zu erhalten. Diese Methode hat den Vorteil, dass neue Punkte zu jedem Zeitpunkt hinzugefügt werden können ohne das man die alten Punkte neu berechnen müsste. Neue Punkte werden so platziert, dass sie gleichmäßig die Dichte erhöhen. Ein Beispiel für die Halton Sequenz zur Basis 2 sieht wie folgt aus: 1/2, 1/4, 3/4, 1/8, 3/8, 5/8, 7/8, 1/16,... Für die Basis 3 startet die Sequenz mit 1/3. Um Punkte auf einer Fläche zu erhalten, wird die Sequenz zur Basis 2 für die x-koordinaten und zur Basis 3 für die y-koordinate verwendet. Für Punkte im Raum wird zusätzlich die Sequenz zur Basis 5 für die z-koordinate verwendet. Ein Beispiel für eine 2D-Verteilung ist in Abbildungen 3.1 und 3.2 zu sehen. Der Pseudo-Code zur Berechnung lautet wie folgt: Algorithmus 3.1 Halton Sequenz function Φ(int b,int i) x 0.0 f 1.0/b while i > 0 do x x + f (i mod b) i i/b f f 1.0/b end while return x end functionx 1,00 1,00 0,90 0,90 0,80 0,80 0,70 0,70 0,60 0,60 0,50 0,50 0,40 0,40 0,30 0,30 0,20 0,20 0,10 0,10 0,00 0,00 0,10 0,20 0,30 0,40 0,50 0,60 0,70 0,80 0,90 1,00 0,00 0,00 0,10 0,20 0,30 0,40 0,50 0,60 0,70 0,80 0,90 1,00 Abbildung 3.1: 100 quasi-zufällige Punkte Abbildung 3.2: 500 quasi-zufällige Punkte 25

26 3 Punktbasiertes Radiance Caching 3.3 Importance Sampling Die indirekte Beleuchtung für jeden Punkt des Bildes auszuwerten wäre nur mit einem hohen Aufwand zu bewältigen. Für diffuse Flächen gilt jedoch, wie schon weiter oben erwähnt, dass sich das indirekte Licht eher langsam verändert im Vergleich zum direkten Licht. Um Festzustellen, wie schnell sich die indirekte Beleuchtung an einem Punkt ändern kann, wird ein Importance Sampling des Bildes durchgeführt. Starke Veränderungen im Bild der Hemisphäre über benachbarte Pixel hinweg können vor allem durch zwei Faktoren auftreten. Zum einen, wenn die im Bildraum benachbarten Punkte sehr weit voneinander entfernt liegende 3D-Koordinaten besitzen. Dies kann im Bildraum festgestellt werden durch Vergleich der Tiefenwerte. Starke Veränderungen können außerdem noch auftreten, wenn sich die Blickrichtung ändert. Dies kann durch Vergleich der Normalen festgestellt werden. Ein zusätzlicher dritter Faktor, der berücksichtigt werden muss, sind Übergänge zwischen unterschiedlichen Objekten mit unterschiedlichen Materialeigenschaften. Hierbei ändert sich zwar der Inhalt der Radiance Caches nicht unbedingt besonders stark, jedoch wird für die Interpolation später nicht über Objektgrenzen hinweg interpoliert. Das bedeutet, wenn man diese Stellen nicht beim Importance Sampling mit berücksichtigen würde, würden dort eventuell plötzliche Übergänge sichtbar werden. Abbildung 3.3: Alle drei Fälle die zu hohem Importance Wert führen, markiert durch die roten Punkte. Alle drei Faktoren sind in Abbilung 3.3 zu sehen. Zusammen ergeben sie einen Importance- Faktor, der schwächer wird, je weiter man von solchen Übergängen entfernt ist. Um den Importance-Wert zu berechnen werden eine Reihe von benachbarten Punkten entlang der Haupt- und Nebenachsen ausgehend vom Ursprungspunkt verwendet. Für diese benachbarten Punkte wird dann jeweils die Änderung in der Normalen, Tiefe und Objekt- oder Material-ID gemessen. Ist die Änderung höher als ein gewisser Schwellwert, 26

27 3.4 Punktbasierte Geometrie so wird der Importance-Wert erhöht, wobei die Erhöhung abnimmt, je weiter man vom Ursprungspunkt entfernt ist. Die Importance-Werte können entweder in einer Textur gespeichert werden, oder beim Importance Sampling direkt berechnet werden. Das Importance Sampling testet für eine Reihe von Samples, ob der Importance-Wert an der Position des Samples höher ist als ein Zufallswert, der für jeden Sample mit gespeichert wurde. Dadurch werden ein paar Punkten automatisch immer ausgewählt, solange der Importance Wert für unwichtige Stellen höher als 0 ist. Diese Punkte sind nötig, da bei der Interpolation von größeren Flächen sonst Löcher entstehen könnten. Sampling Punkte können entweder auf einem regulären Gitter angeordnet sein oder über die in Abschnitt 3.2 beschriebene Quasi-Monte Carlo Methode verteilt werden. Eine Verteilung über die Quasi-Monte Carlo Methode hat den Vorteil, dass man die Anzahl der Sampling Punkte beliebig erhöhen oder verringern kann. 3.4 Punktbasierte Geometrie Die Radiance Caches haben alle eine relativ kleine Auflösung, die im Bereich von 8 8 bis liegen kann. Die Geometrie direkt in die Caches zu rendern wäre daher ziemlich ineffizient. Ein Level of Detail Verfahren, dass die Geometrie sehr stark vereinfacht, sollte deshalb auf jeden Fall einen Vorteil bringen, ohne das Ergebnis zu sehr zu verfälschen. In dieser Arbeit wurde eine punktbasierte Repräsentation der Geometrie verwendet, wie sie auch in [RGK + 08] eingesetzt wurde. Um die Punkte zu erzeugen wird zuerst die Fläche A all aller Dreiecke berechnet. Diese Fläche wird dann als eindimensionale Größe interpretiert. Jeder der n Punkte belegt dadurch eine Fläche von A all /n. Punkte werden dann innerhalb einer Schleife über alle Dreiecke verteilt, wobei so lange Punkte zufällig auf dem Dreieck platziert werden, solange die aufsummierte Fläche, die von allen Punkten bisher belegt wird, kleiner ist als die aufsummierte Fläche aller bisher betrachteten Dreiecke, inklusive des aktuellen Dreiecks. Die Auswahl der Koordinaten innerhalb eines Dreiecks erfolgt indem seine baryzentrischen Koordinaten berechnet werden. Die Berechnung erfolgt durch ein in Graphics Gems I [Gla90] beschriebenes Verfahren. Dazu werden zuerst zwei der drei Koordinaten zufällig zwischen 0 und 1 gewählt. Hierbei kommt die zuvor beschriebene Quasi-Monte Carlo Methode zum Einsatz. Aus diesen zwei Werten werden dann die drei baryzentrischen Koordinaten eines Punktes im Dreieck berechnet über: u 1 t v (1 s) t w s t Mithilfe der baryzentrischen Koordinaten können dann die Punktkoordinaten und die Normale interpoliert werden. Für die Beleuchtung später werden außerdem noch diffuse und spekulare Materialeigenschaften gespeichert. Für den Fall, dass die Geometrie sich 27

28 3 Punktbasiertes Radiance Caching ändern sollte kann außerdem noch zusätzlich ein Index zurück auf das Dreieck gespeichert werden. Da die Punkte für jeden Cache wiederverwendet werden, wird noch zusätzlich gespeichert, welche der Lichtquellen den Punkt beleuchten. Dadurch erspart man sich die Texturzugriffe auf die Shadow-Map beim rendern der Punkte. Dieser Sichtbarkeits-Flag wird binär als Float-Wert kodiert über f lag = i=sichtbar 0.5 i mit i = 0..MAX_LIGHTS. Das heißt ein Wert von 0, 5 würde zum Beispiel bedeuten, dass nur die 2. Lichtquelle (i=1) den Punkt beleuchtet. Der Wert muss bei jeder Änderung der Geometrie und der Position der Lichtquellen neu berechnet werden. 3.5 Radiance Cache Berechnung Radiance Caches werden erzeugt, indem alle Oberflächenpunkte in jeden Cache gerendert werden. Zur Beleuchtung der Punkte werden einfache Punktlichtquellen verwendet. Jede andere Art von Lichtquelle wäre aber auch möglich. Da bei der Erzeugung der Punkte schon gespeichert wurde, welche der Lichtquellen ihn direkt beleuchten, wird keine weitere Schattentextur benötigt. Die modifizierte Rendering-Gleichung zur Beleuchtung der Oberflächenpunkte durch n Lichtquellen lautet: L(x) = n v i f (ω i, ω o )L i cos (θ) (3.1) i=0 Die verwendeten Größen sind: v i : Sichtbarkeits-Flag, ist entweder 0 oder 1, je nachdem ob die Lichtquelle i den Punkt x beleuchtet oder nicht. f (ω i, ω o ): BRDF, in der Implementierung wird hier eine diffuse BRDF verwendet, deren Größe nur vom Material abhängig ist, aber nicht von den Ein- und Ausfallwinkeln ω i und ω o. θ i : Winkel zwischen Lichtquelle und Normale. L i : Radiance der Lichtquelle Bevor ein Punkt gezeichnet wird, wird aus den Cache Records, also aus der Position und Normalen, eine Matrix berechnet mit der die Punkte in den Tangentialraum transformiert werden. Für die Beleuchtung ist es nicht wichtig, ob diese im Tangentialraum oder im Modellraum geschieht, für die im nächsten Abschnitt beschriebene Abbildung der Punkte in den Framebuffer müssen sie jedoch im Tangentialraum sein. 28

29 3.6 Pyramidal Mapping 3.6 Pyramidal Mapping Um die Radiance Werte der kompletten Hemisphäre in eine 2D Textur abzubilden gibt es diverse Mapping-Verfahren, die eingesetzt werden können. Die meisten davon haben jedoch einige Nachteile. Sphere Mapping ([MH84] und [Wil83]) würde zu Verzerrungen an den Rändern führen. Parabolic Mapping [HS98] ist zwar weniger stark von Verzerrungen betroffen, allerdings wird wie bei Sphere Mapping durch die Abbildung der Hemisphäre auf eine Kreisfläche ein Teil des Texturspeichers verschwendet. Zwei Methoden, mit denen der Texturspeicher komplett ausgenutzt wird, sind Cube-Maps bzw. Hemi-Cubes [CG85] sowie Octahedral Mapping ([PH03] und [ED08]) bzw. Pyramidal Mapping. Für die Implementierung wurde Pyramidal Mapping verwendet. Eine auf den 2D-Raum reduzierte Ansicht des Pyramidal Mappings ist in Abbildung 3.4 zu sehen. Die roten und grünen Punkte repräsentieren Punkte aus der Szene. Abbildung 3.4: Pyramidal Mapping im 2D-Raum Beim Pyramidal Mapping wird zunächst jeder Punkt auf die Oberfläche einer Pyramide abgebildet. Für eine Pyramide mit dem Innenkreis-Radius 1 (halbe Seitenlänge) gilt, dass für alle Punkte ihrer Oberfläche p x + p y + p z = 1 ist. Ein Punkt p im Raum kann also auf einen Punkt p auf einer Pyramiden-Oberfläche abgebildet werden durch folgende Gleichung: p = p p x + py + p z Punkte, die auf der negativen Hemisphäre liegen, also deren p z -Wert negativ ist, werden verworfen. Ein Punkt p im Texturraum ergibt sich aus p indem die z-komponente weg- 29

30 3 Punktbasiertes Radiance Caching gelassen wird. Hierdurch erhält man jedoch nur Punkte, die auf einem um 45 gedrehten Quadrat liegen. Um den Texturspeicher optimal auszunutzen gibt es zwei Möglichkeiten. Die erste Möglichkeit ist, das man zwei der vier Seiten der auf 2D abgebildeten Pyramide so verschiebt, dass sie eine rechteckige Fläche bilden. Die zweite Möglichkeit ist, das Quadrat um 45 zu drehen. Die erste Methode hat den Nachteil, dass benachbarte Pixel nicht mehr unbedingt räumlich zusammen hängen, was den nachfolgenden Pull-Push Algorithmus etwas komplizierter macht. Deshalb wird hier die zweite Möglichkeit verwendet und jeder Punkt um 45 gedreht bevor er in die Textur geschrieben wird. Dadurch erhält man quadratische Radiance Caches. Dieser muss noch um den Faktor 1 skaliert werden um Koordinaten 2 zwischen -1 und 1 zu erhalten. Um von einer 2D-Texturkoordinate wieder zurück auf die Anfangsposition p des Punktes zu kommen, muss zuerst der Z-Wert berechnet werden. Für Punkte auf der Pyramiden- Oberfläche gilt wie schon erwähnt, dass p x + p y + p z = 1 sein muss, also ist p z = 1 p x p y. Für p muss man jedoch noch zusätzlich die Distanz d zum Punkt p gespeichert haben. p erhält man dann über p = normalize(p ) d. Wenn nur der Winkel zum Punkt p benötigt wird, so erhält man diesen aus dem z-wert des normalisierten Punktes p, also über ω = normalize(p ).z. 3.7 Pull-Push Beim punktbasierten Rendern entsteht das Problem, dass das Ergebnisbild viele Lücken aufweist. Durch diese Lücken können zum Beispiel Punkte von Flächen sichtbar sein, die eigentlich verdeckt sein sollten. Um diese Lücken zu füllen wird das Pull-Push Verfahren ([GG96] und [GD98]) verwendet. Das Verfahren gliedert sich in zwei Phasen. In der ersten Phase, Pull genannt, wird aus dem Ausgangsbild in mehreren Schritten immer kleinere Bilder berechnet, in denen die Lücken langsam verschwinden. In der zweiten Phase, Push genannt, wird aus den gröber aufgelösten Bildern wieder schrittweise durch Kombination mit den feiner aufgelösteren Bildern ein weitestgehend lückenloses Bild erzeugt. Pull-Phase In der Pull-Phase wird in jedem Schritt eine neue Textur berechnet, die jeweils die halbe Auflösung der vorhergehenden Textur hat. Das bedeuten, für jeden neuen Pixel in der gröberen Textur existieren vier Pixel in der feineren Textur. Dies kann man jedoch nur solange problemlos wiederholen, solange die Texturauflösungen ein Vielfaches von zwei sind. Den Farbwert, Tiefenwert und andere Attribute des neuen Pixels erhält man aus den vier alten Pixeln, indem man den Durchschnitt aus allen gültigen Pixeln ermittelt. Für jeden Pixel muss daher festgestellt werden, ob dieser gültig ist oder nicht. Gültig ist ein Pixel 30

31 3.7 Pull-Push nur, wenn er einen Alpha-Wert von größer 0 besitzt. Sein Tiefenwert darf außerdem nur geringfügig vom niedrigsten Tiefenwert aller vier Pixel abweicht. Dadurch erreicht man, dass Pixel, die weiter weg sind von näheren Pixeln verdeckt werden, da sie nicht gültig sind und somit in der Pull-Phase nicht übernommen werden. neue Textur ¼ ¼ alte Textur ¼ ¼ Abbildung 3.5: Interpolation in der Pull-Phase mit 4 gültigen Pixeln Push-Phase In der Push-Phase geht man genau in entgegengesetzter Richtung der Pull-Phase vor. Das heißt man fängt mit der am gröbsten aufgelösten Textur an und endet zum Schluss mit der am höchsten aufgelösten Textur. Die Texturgröße wird dabei mit jedem Schritt verdoppelt, wobei der erste Schritt schon mit einer doppelt so hohen Auflösung anfängt, wie die Auflösung aus dem letzten Schritt der Pull-Phase. Für die Push-Phase werden sowohl die Textur mit der nächst niedrigeren Auflösung sowie die Textur mit derselben Auflösung aus der Pull-Phase benötigt. Für jeden Pixel der neuen Textur wird zunächst der Farbwert und Tiefenwert aus der alten Textur mit derselben Auflösung geholt. Ein neuer Farbwert muss nur berechnet werden, wenn der Pixel entweder verdeckt wird oder sein Alpha-Wert 0 ist. Die Verdeckung wird überprüft, indem der Tiefenwert aus der gröberen Textur geholt wird. Sollte dieser kleiner sein, so wird der Pixel verdeckt. Beim Test der Tiefenwerte sollte ähnlich wie in der Pull-Phase ein kleiner Spielraum eingeräumt werden. Wenn keine neuen Farbwerte berechnet werden müssen, wird der Farbwert und Tiefenwert aus der alten Textur mit derselben Auflösung in die neue Textur übernommen. Wenn jedoch 31

32 3 Punktbasiertes Radiance Caching neue Textur alte Textur Abbildung 3.6: Interpolation in der Push-Phase mit 4 gültigen Pixeln der Farbwert neu berechnet werden muss, so wird dieser wieder aus den vier gültigen Pixeln der gröberen Textur ermittelt. Nur einer dieser vier Pixel liegt direkt unter dem aktuellen Pixel. Die anderen drei Pixel sind die direkt benachbarten Pixel. Die Pixel werden daher auch nicht gleich gewichtet. Das Pixel unter dem aktuellen Pixel erhält die Gewichtung 9, die in eine Achse direkt benachbarten die Gewichtung 3 und das schräg benachbarte Pixel die Gewichtung 1. Zum Schluss müssen die gewichteten Werte noch mit dem Gesamtgewicht aller gültigen Pixel normalisiert werden. Ein Beispiel für vier gültige Pixel ist in Abbildung 3.6 zu sehen. Gültige Pixel sind hier wieder alle Pixel, deren Tiefenwerte nicht zu weit vom minimalen Tiefenwert aller 4 Pixel entfernt liegen und deren Alpha-Werte größer als 0 sind. Im Gegensatz zur Pull-Phase kann es hierbei vorkommen, dass die Texturkoordinaten auf benachbarte Pixel über den Rand der Textur ode des Caches hinausgehen. Daher muss ein zusätzlicher Gültigkeitstest gemacht werden, der die Texturkoordinaten testet. 3.8 Final Gathering Beim Final Gathering werden die Radiance Werte L i aus den Caches gelesen und für jeden Cache wird das in die Kamera fallende indirekte Licht berechnet. Die Gleichung ähnelt im wesentlichen der Gleichung 3.1, jedoch ohne den Visibility-Flag. Außerdem kommt das Licht nicht von Lichtquellen, sondern von den n Punkten aus dem Radiance Cache. Die Gleichung lautet damit wie folgt: 32

33 3.9 Radiance Interpolation L o = n f (ω i, ω o )L i (ω i ) cos θ i i=0 Es wird wieder eine einfache diffuse BRDF f (ω i, ω o ) verwendet, deren Größe nur abhängig ist von den Materialeigenschaften und nicht von den Winkeln ω i und ω o. 3.9 Radiance Interpolation Die resultierenden Radiance Werte L o aus dem Final Gathering Schritt werden zunächst in eine ansonsten leere Textur an die Position des jeweiligen Caches im Raum geschrieben. Hierdurch erhält man eine Textur mit spärlich verteilten Punkten. Die Zwischenräume zwischen den Punkten soll gefüllt werden durch einen Gauss-Filter, wie er zum Beispiel auch in [SIMP06] verwendet wurde. Hierbei ist es wichtig, dass die Textur einen Alpha-Kanal besitzt, der für leere Stellen 0 enthält damit diese Flächen nicht als schwarze Punkte gewertet werden. Zunächst braucht man jedoch noch zusätzliche Informationen um zu verhindern, dass die Interpolation über Objektgrenzen hinweg verläuft. Dazu wird eine Discontinuity-Map erzeugt. In dieser Map wird gespeichert, ob in positiver x-richtung oder in positiver y- Richtung eine Objektgrenze liegt. Zum Test werden Tiefe, Normale und Objekt-ID aus den G-Buffers verwendet. Getestet wird für beide Richtungen seperat, so dass man später feststellen kann, in welcher Richtung die Grenze liegt. Der Gauss-Filter wird in zwei Schritten durchgeführt, einmal zeilenweise und anschließend spaltenweise. Die folgende Form der Gauss-Gleichung wird hierfür verwendet: g(x) = 1 2 π σ e x2 2 σ 2 Der Filter ist abhängig von der Standardabweichung σ. Diese sollte in etwa den 1,5-fachen Wert des Abstands zwischen den Cache Punkten haben für gute Ergebnisse. Da dieser Abstand jedoch nicht bekannt ist und die Punkte außerdem sehr unterschiedlich dicht verteilt sind, wird ein ziemlich hoher Wert für σ gewählt, in der Regel zwischen 16 und 22. Alternativ könnte der Wert jedoch auch abhängig vom Inhalt der Importance-Map gewählt werden. Die Variable x enthält den Abstand zum Ausgangspunkt in Pixeln. Der Filter berechnet neue Farbwerte indem für n benachbarte Punkte entlang einer Achse in sowohl positiver wie auch negativer Richtung die Farbwerte c(x) aufsummiert werden. c new = n g(x) c(x) x= n/2 33

34 3 Punktbasiertes Radiance Caching Um Objektgrenzen zu erkennen, muss für jeden Farbwert c(x) vorher der Wert aus der Discontinuity-Map für die aktuelle Achse gelesen werden. Wird eine 1 gelesen, dann ist eine Grenze erreicht worden. Das bedeutet für Punkte in positiver Richtung, dass keine weiteren Punkte mehr gelesen werden. Wird die 1 für einen Punkt in negativer Richtung gelesen, so ist die Grenze für diesen Punkt schon überschritten worden und sein Farbwert sowie alle weiter entfernten Punkte werden ignoriert. Da bei der Filterung für einen Pixel relativ viele Werte benötigt werden, kann eine kleine Optimierung eingebaut werden. Dazu wird nur jeder zweite Texel gelesen, und zwar so, dass die Texturkoordinaten immer auf der Kante zwischen zwei Texeln liegen. Bei aktivierter linearer Interpolation werden dann beide Texturwerte interpoliert. Das erspart zwar keine Texturzugriffe, jedoch kann die Interpolation von der Hardware schneller durchgeführt werden als vom Shader. Nachdem man den Filter zuerst für die x-achse und dann für die y-achse angewendet hat, müssen die Farbwerte nur noch normalisiert werden. Dafür wird jeder RGBA-Wert durch seine Alpha-Komponente geteilt. 34

35 Kapitel 4 Implementationsdetails 4.1 Überblick Das komplette Verfahren ist in ein bestehendes OpenGL-Framework integriert worden. Um die neuen Teile von den bestehenden Teilen des Frameworks zu trennen, wurden die meisten Sachen in eine neue Klasse namens GPUIllumination mit gleichnamigen Dateien ausgelagert. Hinzu kamen etliche Shader-Dateien, die im Verzeichnis shader zu finden sind. Das Framework erzeugt ein Fenster in dem die Kamera mit der Maus gesteuert werden kann. Außerdem ist eine einfache GUI basierend auf AntTweakBar [Ant] eingebaut, über die Parameter zur Laufzeit des Programms verändert werden können. Zum Laden der Szene ist ein OBJ Loader im Framework enthalten, der die Szene beim Programmstart lädt. Für Framebuffer, Shader und Texturen sind außerdem Klassen enthalten, die die OpenGL- Funktionen kapseln. Der Großteil der nötigen Änderungen am bestehenden Code befindet sich in der Datei main.cpp. Hier wird die AntTweakBar erzeugt und hier ist auch die Hauptmethode zum Rendern der Szene enthalten. Die folgenden Abschnitte enthalten eine kurze Übersicht über alle Shader, Methoden, Attribute und OpenGL-Objekte, die in der Klasse GPUIllumination verwendet werden Attribute Die folgende Liste enthält die wichtigsten Attribute. Ausgenommen sind Attribute die für eine der OpenGL-Objekte verwendet werden. Für einen Teil der Attribute existieren Getter/Setter-Methoden, dies ist mit (g/s) markiert. model OBJ Modell, kann nur über den Konstruktor gesetzt werden pointcount Anzahl der zufälligen Oberflächenpunkte, wird über createpoints gesetzt 35

36 4 Implementationsdetails cacheblocksize Höhe/Breite für einen quadratischen Radiance Cache (g/s) cacheblockcount Anzahl der Radiance Caches in x/y-richtung (g/s) pullpushlevels Anzahl der Pull- und Push-Level (g/s) directlightcontrib Faktor mit dem die direkte Beleuchtung zum finalen Bild beiträgt (g/s) indirectlightcontrib Faktor mit dem die indirekte Beleuchtung zum finalen Bild beiträgt (g/s) gaussdeviation Standard-Abweichung für den Gauss-Filter bei der Radiance Interpolation (g/s) scenewidth Breite des Frames sceneheight Höhe des Frames newrecordscount Anzahl der beim letzten Importance Sampling erzeugten Cache Records currentrecordscount Anzahl der Cache Records vom letzten komplett durchlaufenen Update-Zyklus recordstoupdate Anzahl der Caches, die noch nicht berechnet wurden maxrecordstoprocess Maximale Zahl der Caches, die in einem Frame berechnet werden (g/s) tempcachesize Anzahl der Radiance Caches in x/y-richtung in den temporären Cache Texturen Texturen und Buffer Die folgende Tabelle enthält alle verwendete Texturen inklusive des verwendeten Formats und falls möglich die Standard-Auflösung der Textur. Variablenname Format Auflösung Beschreibung tcachefbcolor RGBA16F variabel Texturarray mit pullpushlevels Texturen. Enthält die temporären Radiance Caches sowie den finalen Radiance Cache. Fortsetzung auf der folgenden Seite... 36

37 4.1 Überblick Variablenname Format Auflösung Beschreibung tcachefbdepth DEPTH_COMPONENT24 variabel Texturarray mit pullpushlevels 2 Texturen. Enthält die Tiefenwerte für die temporären Radiance Caches. tindirectlitpoints RGBA16F Enthält die Ergebnisse des Final Gatherings als Punkte. tindirectlightinterpolated1 RGBA16F Enthält die Ergebnisse des horizontalen Gauss-Filters. tindirectlightinterpolated2 RGBA16F Enthält die Ergebnisse des vertikalen Gauss-Filters und damit die fertige indirekte Beleuchtung. tscenepositions RGBA16F Enthält die Raumkoordinaten aller Fragmente und die Objekt- ID. tscenenormals RGBA16F Enthält die Normale aller Fragmente und den Tiefenwert. tscenediffusemat RGBA16F Enthält die diffuse Materialfarbe. tscenespecularmat RGBA16F Enthält die spekulare Materialfarbe sowie den spekularen Exponent. tscenediscontinuity RGB Enthält Informationen über Objektgrenzen. tnewrecords[2] RGBA32F Enthält in der ersten Textur die Position und in der zweiten Textur die Normale der Cache Records. tshadowmap[8] LUMINANCE32F Shadow Cube Maps für bis zu 8 Lichtquellen. Normalerweise sind jedoch nur 2 belegt. timportancemap LUMINANCE Die Importance Map, besitzt nur die halbe Bildschirmauflösung. Tabelle 4.1: Tabelle aller Texturen Die nachfolgende Tabelle enthält alle verwendeten OpenGL-Buffer Objekte. Der Datentyp ist jeweils float. Die Länge bezieht sich auf die Anzahl der Werte, die gespeichert werden können. Die erste Zahl ist jeweils die Anzahl der Komponenten, die anderen beiden Zahlen geben die Höhe und Breite des Buffers an. Diese Aufteilung kommt daher, dass die 37

38 4 Implementationsdetails meisten Buffer entweder Textur- oder Bildschirmkoordinaten enthalten oder zusätzlich als 2D-Texturen verwendet werden. Variablenname Länge Beschreibung pointvbos[4] variabel Position, Normale und Materialeigenschaften der Oberflächenpunkte. Position inklusive Sichtbarkeitsinformationen. temppointvbo variabel Position der Oberflächenpunkte ohne Sichtbarkeitsinformationen. tempcachecoordsbuffer Enthält Texturkoodinaten, die auf die Mittelpunkte aller temporären Radiance Caches zeigen. texcoordbuffer Texturkoordinaten für den Radiance Cache. newrecordsbuffer[2] je Buffer, der beim Importance Sampling über Transform-Feedback gefüllt wird. Enthält Position und Normale der Cache Records. currentrecordsbuffer[2] je Cache Records Buffer aus dem vorhergehenden Update-Zyklus. samplingrasterbuffer Enthält 2D-Bildschirmkoordinaten und einen Zufallswert für das Importance Sampling. Tabelle 4.2: Tabelle aller Buffer Shader Die folgende Liste enthält eine kurze Beschreibung zu allen Shader-Dateien. Die meisten dieser Dateien besitzen gleichnamige Shader-Objekte in GPUIllumination.cpp mit dem Präfix shader. discontinuity Berechnet die Discontinuity Map im Fragment Shader aus den G-Buffers. (siehe Abschnitt 3.9) fillnewcaches Beleuchtet die Oberflächenpunkte und bildet sie in die Radiance Caches ab unter Verwendung des Pyramidal Mappings. (siehe Abschnitt 3.5) finalgathering Ließt die Radiance Caches aus und erzeugt daraus die indirekt beleuchteten Punkte. (siehe Abschnitt 3.8) globalillumination Kombiniert die indirekte Beleuchtung mit einer direkten Beleuchtung. Die indirekte Beleuchtung ist Ergebnis des Gauss-Filters und kommt aus einer Textur, die direkte Beleuchtung wird direkt im Shader berechnet. importancemap Berechnet und schreibt die Importance-Werte in eine Textur. 38

39 4.1 Überblick importancesampling Filtert über einen Geometrie-Shader eingehende Punkte mithilfe der Importance Map. Ergebnisse werden über Transform-Feedback wieder zurück in einen Buffer geschrieben. interpolatehorizontal Führt einen horizontalen Gauss-Filter durch. interpolatevertical Führt einen vertikalen Gauss-Filter durch und normalisiert die resultierenden Farbwerte über den Alpha-Wert. pointshadowing Fügt dem VBO für die Oberflächenpunkt-Positionen einen 4. Wert hinzu, der die Sichtbarkeit aller Lichtquellen zu diesem Punkt enthält. pointtoquad Erzeugt aus einem Eingangspunkt und (optionalen) Texturkoordinaten zwei Dreiecke, die ein Quadrat bilden. Der Shader wird nur in Zusammenhang mit anderen Fragment-Shadern verwendet. postprocess Finaler Rendering-Schritt, kopiert das fertige Bild in den Back-Buffer und führt dabei eine Gamma-Korrektur durch. pull Fragment-Shader für die Pull-Phase. push Fragment-Shader für die Push-Phase. Hierfür existieren in GPUIllumination zwei unterschiedliche Shader-Programme, da der letzte Schritt in die große Radiance Cache Textur schreibt und hierfür unterschiedliche Vertex- und Texturkoordinaten notwendig sind. scenetotexture Schreibt die Position, Normale, Tiefe, Objekt-ID und die Materialeigenschaften in G-Buffers. shadowmap Erstellt eine Seite einer Shadow Cube Map Methoden Die folgende Liste enthält eine Kurzbeschreibung zu den meisten der Methoden aus GPUIllumination. Private-Methoden sind mit markiert, alle anderen sind public. Setterund Getter-Methoden wurden weggelassen, genauso wie Debugging-Methoden. Debug- Ausgaben werden im Abschnitt 4.10 beschrieben. Die public Methoden werden alle von der Datei main.cpp aus aufgerufen. void createpoints(unsigned int num) Diese Methode wird von main.cpp aus aufgerufen um die Oberflächenpunkte zu erzeugen. Ein erneuter Aufruf löscht alle alten Punkte und erzeugt neue. Nach dem Aufruf dieser Methode existieren noch keine Daten für den Positions-Buffer, da die Positionen zuerst nur in temppointvbo gespeichert werden. Erst ein Aufruf von updateshadows kopiert diese Positionen und füllt sie gleichzeitig mit den Sichtbarkeits-Flags. 39

40 4 Implementationsdetails void createtextures() Die Methode createtextures erzeugt alle Texturen und die meisten der benötigten Buffer. Die Erstellung erfolgt dabei in einzelnen privaten Methoden. Ein erneuter Aufruf von createtextures löscht alle alten Texturen und Buffer und erstellt sie neu. Dies ist zum Beispiel nötig, wenn sich bestimmte Parameter, wie die Größe und Anzahl der Caches, geändert haben. void loadshaders(bool firsttime) Lädt alle benötigten Shader. Nach Änderung eines Shader kann diese Methode durch drücken der Taste r erneut aufgerufen werden. Dadurch werden dann alle Shader neu geladen. void renderscenetotexture() Rendert die Szene in G-Buffers. Diese Methode muss vor updateimportancemap und updatecaches aufgerufen werden, da die G-Buffers für beide benötigt werden. Die Methode erstellt außerdem die Discontinuity Map. void renderindirectlight() Diese Methode ist für das Final Gathering und die Interpolation des indirekten Lichts zuständig. void rendergeometry() Rendert die Geometrie mit direkter und indirekter Beleuchtung. Beim Zeichnen wird der Shader globalillumination verwendet, der die direkte Beleuchtung pro Pixel selbst berechnet und die indirekte Beleuchtung aus der Textur tindirectlightinterpolated2 liest. void updatecaches() Führt ein Importance Sampling durch und aktualisiert die Radiance Caches. void updateimportancemap() Aktualisiert die Importance Map. Diese Methode wird vor updatecaches aufgerufen. void updateshadows() Aktualisiert die Shadow Map für alle aktiven Lichtquellen. Die Methode aktualisiert außerdem den Sichtbarkeits-Flag der Oberflächenpunkte. double gettrianglearea(glmgroup* group, int idx) Berechnet die Fläche eines Dreiecks. Das Dreieck wird über die OBJ-Gruppe group und den Index idx adressiert. void createcachetextures() Erstellt die Texturen tcachefbcolor und tcachefbdepth sowie die FBOs cachemapsfbo für die Radiance Caches. Dazu werden zuerst 2 pullpushlevels Farb- und Tiefentexturen erstellt in denen die temporären Radiance Caches gespeichert werden. Zusätzlich kommt noch eine weitere Farb-Textur hinzu für den finalen Radiance Cache. Eine weitere Tiefentextur wird nicht benötigt. void createscenetextures() Erstellt die Texturen tscene* und fügt sie an die FBOs scenefbo und discontinuityfbo an um später in die Texturen schreiben zu können. Außerdem wird die Textur timportancemap erzeugt und zum FBO importancemapfbo angefügt. void createcacherecordtextures() Erstellt die zwei Texturen tnewrecords, in denen später die Cache Positionen und Normalen gespeichert werden. 40

41 4.2 Szenen-Informationen void createshadowtextures() Erstellt die Shadow Cube Map Texturen tshadowmap. Texturen werden nur für aktive Lichtquellen erstellt, was jedoch auch bedeutet, dass die Methode neu aufgerufen werden muss, falls sich die aktiven Lichtquellen ändern sollten. void createtexcoordbuffer() Erstellt den Buffer texcoordbuffer. Dieser enthält die Texturkoordinaten für den Radiance Cache. Es wird außerdem ein weiterer Buffer namens temptexcoordbuffer erstellt, der Texturkoordinaten für die temporären Radiance Caches enthält. void createdebugtextures() Diese Methode wird immer am Ende von createtextures aufgerufen und erstellt ein zweites Paar an Texturen, die aber nur für Debugging- Zwecke eingesetzt werden. Um zwischen beiden Versionen hin und her zu schalten wird die Methode switchdebug verwendet. void createsamplingrasterbuffer(bool random) Erstellt den Buffer samplingrasterbuffer. Sollten die Samples zufällig verteilt sein, so wird die in Abschnitt 3.2 beschriebene Quasi-Monte Carlo Methode verwendet. Sollen sie nicht zufällig sein, so werden sie auf einem regulären Gitter mit einem Abstand von sampledistance über das komplette Bild verteilt. void switchdebug() Schaltet zwischen zwei unterschiedlichen Sets an Texturen, Buffern und Parametern hin und her. Dies wird nur zu Debugging-Zwecken verwendet. void createindirectlightfbos() Erstellt die Texturen tindirectlight* und fügt sie an die FBOs indirectlight*fbo an mit jeweils einer Textur pro FBO. void findnewrecords() Führt ein Importance Sampling der Szene durch. Hierfür wird die schon berechnete Importance Map timportancemap verwendet um über einen Geometrie-Shader die Punkte in samplingrasterbuffer zu Filtern. Das Ergebnis wird über Transform Feedback in die Buffer newrecordsbuffer[0..1] gespeichert. Zusätzlich werden beide Buffer in die Texturen tnewrecords[0..1] umgewandelt. void rendernewcaches() Erstellt eine gewisse Anzahl an Radiance Caches. void deletepoints() Löscht alle Oberflächenpunkte. void printtimerqueryresults() Gibt bei aktivierter Zeitmessung die Ergebnisse für einen Frame aus. Die Timer Queries können aktiviert werden über TIMER_QUERY_ENABLED. Detailliertere Zeiten für den Cache Update können über setzen von TIMER_QUERY_DETAILED ausgegeben werden. Die Ausgabe dieser Ergebnisse erfolgt dann jedoch direkt in rendernewcaches. 4.2 Szenen-Informationen In einigen Abschnitten des Verfahrens werden Informationen der Szene benötigt. Diese werden deshalb in jedem Frame als erstes erstellt. 41

42 4 Implementationsdetails shadowmapfbo shadowmap cornell.obj scenetotexture scenefbo importancemap discontinuity importancemapfbo discontinuityfbo Abbildung 4.1: Diagramm zur Speicherung der Szenen-Informationen Hierzu wird zuerst über die Methode updateshadows für jede Lichtquelle eine Cube Shadow Map erzeugt. Diese Textur enthält den Abstand aller gerenderten Fragmente zur Lichtquelle. In einigen Shadern, die mit den Lichtquellen arbeiten, ist die Anzahl der Lichtquellen statisch auf 2 beschränkt um eine höhere Geschwindigkeit zu erreichen. Um die Anzahl zu erhöhen kann die Konstante NUM_LIGHTS modifiziert werden. 42

43 4.3 Oberflächenpunkte Aus der aktuellen Ansicht der Szene werden außerdem Informationen aus dem Bildraum benötigt. Diese werden in der Methode renderscenetotexture in die G-Buffers tscenepositions, tscenenormals, tscenediffusemat und tscenespecularmat gespeichert. tscenepositions enthält zusätzlich noch eine Objekt-ID und tscenenormals enthält zusätzlich noch die Fragment-Tiefe. Aus den Informationen in den G-Buffers kann dann die Discontinuity Map tscenediscontinuity erstellt werden. Außerdem wird mit diesen Informationen noch die Importance Map in der Methode updateimportancemap erstellt. Über das Attribut startimportance kann ein Importance-Wert für die ansonsten leeren Stellen festgelegt werden. Dieser wird in die Importance-Map geschrieben und verursacht, das abhängig vom Wert einige wenige Punkte beim Importance Sampling immer verwendet werden. Der genaue Verlauf ist auch in Abbildung 4.1 zu sehen. 4.3 Oberflächenpunkte Die Oberflächenpunkte müssen nur erstellt werden, wenn sich ihre Anzahl ändert. Die Erstellung erfolgt über die Methode createpoints, die von main.cpp aus aufgerufen wird. Die Methode erstellt fünf Buffer Objekte, pointvbos[0..3] und temppointvbo. pointvbos[0] ist für die Vertex-Positionen gedacht, wird jedoch zuerst leer gelassen. Die Vertex-Positionen landen stattdessen in temppointvbo. Die anderen drei Buffer enthalten die Normalen und die diffuse und spekulare Materialeigenschaften. Für jeden Frame, in dem sich entweder die Lichtquellen oder die Geometrie geändert hat, werden dann in der Methode updateshadows die Vertex-Positionen aus temppointvbo durch den Vertex-Shader pointshadowing verarbeitet. Dabei wird als 4. Komponente ein Sichtbarkeits- Flag hinzugefügt. Alle so veränderten Vertices werden über Transform-Feedback zurück in den Buffer pointvbos[0] gespeichert. 4.4 Cache Update Zyklus Die Aktualisierung des Radiance Caches kann in zwei unterschiedliche Formen geschehen. Zum einen können nur eine gewisse Anzahl an Caches aktualisiert werden, oder aber es werden alle Caches auf einmal aktualisiert. Die Anzahl der zu aktualisierenden Caches pro Frame kann über die GUI eingestellt werden. Alle Caches werden auf einmal aktualisiert, wenn die Anzahl der zu aktualisierenden Caches niedriger ist, als die Zahl der Caches, die pro Frame maximal aktualisiert werden sollen. Im Fall, dass die Caches über mehrere Frames hinweg berechnet werden, wird das Importance Sampling erst dann wieder durchgeführt, wenn alle Caches berechnet wurden. Beide Fälle sind in Abbildung 4.3 enthalten. Vor der Aktualisierung werden alle über die GUI einstellbaren Parameter an GPUIllumination übergeben. Falls einer der Parameter eine 43

44 4 Implementationsdetails pointvbos[4] createpoints() cornell.obj pointshadowing Abbildung 4.2: Diagramm zur Erstellung und Aktualisierung der Oberflächenpunkten Aufruf aus main.cpp Noch Caches zu berechnen? Nein Ja findnewrecords Wurden Caches erstellt? Nein Ja rendernewcaches zurück zu main.cpp Abbildung 4.3: Update-Zyklus innerhalb von updatecaches 44

45 4.5 Cache Records Textur verändern sollte, werden außerdem die Texturen neu erstellt. Die Aktualisierung der Radiance Caches findet durch Aufruf der Methode updatecaches von main.cpp aus statt. Falls der Update-Zyklus mehr als einen Frame zur Berechnung aller neuer Caches braucht, werden beim Final Gathering sowohl neue als auch alte Caches verwendet. Hierzu werden die Cache Records beider Versionen benötigt. Hierfür existieren je zwei Buffers, currentrecordsbuffer[0..1] und newrecordsbuffer[0..1]. Die Attribute currentrecordscount und newrecordscount speichern außerdem jeweils die Anzahl der Cache Records. Am Anfang eines Update-Zyklus werden die Buffer getauscht, der Wert von currentrecordscount auf den alten Wert von newrecordscount gesetzt und newrecordscount auf 0 gesetzt. 4.5 Cache Records samplingrasterbuffer newrecordsbuffer[0..1] importancesampling Abbildung 4.4: Diagramm zur Erstellung der Cache Records durch Importance Sampling. Cache Records werden über die Methode findnewrecords, die von updatecaches aufgerufen wird, erzeugt. Sie enthalten die Ausgangspositionen und Normalen der Radiance Caches. Um diese zu erzeugen wird die Importance Map sowie eine Reihe von Sampling Positionen, die gleichmäßig über das Frame verteilt sind, benötigt. 45

46 4 Implementationsdetails Anhand dieser beiden Informationen kann der Geometrie-Shader importancesampling dann bestimmte Punkte verwerfen oder übernehmen. Dazu testet der Shader, ob ein Zufallswert, der mit jedem Sampling Punkt übergeben wurde, kleiner ist als der Importance-Wert. Für Punkte, die übernommen werden, wird die Position und Normale aus tscenepositions und tscenenormals gelesen und per Transform-Feedback in die Buffer newrecordsbuffer[0..1] gespeichert. Beide Buffer werden außerdem noch in Texturen umgewandelt, die dieselben Informationen enthalten. Dies wird gemacht, weil innerhalb von Shadern kein direkter Zugriff auf die Buffer erfolgen kann. 4.6 Cache Rendering pointvbos[0..3] tnewrecords[0..1] cachemapsfbo[2] fillnewcaches cachemapsfbo[0] cachemapsfbo[1] pull push Abbildung 4.5: Diagramm zur Erstellung der Radiance Caches und zum Füllen der Löcher über Pull-Push. Die Methode rendernewcaches ist zuständig für die komplette Erstellung der Radiance Caches. Sie ist aufgeteilt in insgesamt drei Abschnitte. Im ersten Abschnitt werden die Oberflächen-Punkte in eine Anzahl an temporäre Radiance Caches gerendert. Der zweite und dritte Abschnitt enthält jeweils die Pull- bzw. Push-Phase zum Füllen der Löcher in den Caches. Alle drei Abschnitte sind in Abbildung 4.5 zu sehen. Zur besseren Übersicht sind 46

47 4.6 Cache Rendering nur 4 Radiance Caches zu sehen, in der Praxis sind es aber eher zwischen und Caches. Um Speicherplatz zu sparen werden beim Erstellen der Caches kleinere, temporäre Texturen verwendet. In diese passen per Default nur Caches. Nur die Textur, in die die finalen Caches geschrieben werden besitzt die volle Auflösung, welche per Default Platz für Caches hat. Das bedeutet, man kann nur 1024 Caches in einem Durchgang erstellen. Um trotzdem mehr Caches durch einen Aufruf von rendernewcaches erstellen zu können, sind alle drei Abschnitte, also Zeichnen der Punkte und die Pull-Push Abschnitte, in eine große While-Schleife eingeschlossen. Im ersten Abschnitt müssen für jeden Cache die Oberflächen-Punkte gezeichnet werden. Die Attribute dieser Punkte, also Position, Normale und Materialeigenschaften, befinden sich in den Buffern pointvbos[0..3]. Hierbei ergibt sich das Problem, dass sich für jeden Cache die Position und Blickrichtung ändert, das bedeutet man müsste ständig die Modelview- Matrix verändert. Dazu wäre es aber nötig die Cache Records aus dem Grafikspeicher in den Hauptspeicher zu holen. Um das zu vermeiden wurde eine andere Möglichkeit implementiert. Hierfür werden die Cache-Position und die Normale für jeden Zeichenvorgang vom Shader aus den zuvor erstellten Texturen tnewrecords[0..1] gelesen. Daraus wird dann eine Matrix erstellt mit der alle Oberflächenpunkte in den Tangentialraum transformiert werden können. Ein Vorteil dieses Vorgehens ist, das man hierdurch mithilfe eines Geometrie-Shaders mehrere Caches gleichzeitig erstellen kann. Dazu muss der Shader für jeden eingehenden Oberflächenpunkt mehrere Punkte erstellt, die dann auf die unterschiedlichen Caches verteilt werden. Die Anzahl der Caches, die vom Geometrie-Shader in einem Aufruf beschrieben werden, wird über die Konstante RECORDS_PER_DRAW gesteuert. Diese kann nur im Source-Code verändert werden. Eine Veränderung dieser Konstanten muss sowohl in der Datei GPUIllumination.cpp als auch im Shader fillnewrecords.gp.glsl gemacht werden. Mögliche Werte sollten hier immer Potenzen von zwei sein. Eine weitere Konstante, die das Zeichnen der Punkte beeinflusst, ist INSTANCED_CALL. Diese Konstante muss in GPUIllumination.cpp, fillnewcaches.vp.glsl und fillnewcaches.gp.glsl gleich sein. Sie beeinflusst, ob die Oberflächenpunkte über Aufruf von gldrawarrays einzeln in die jeweiligen Caches geschrieben werden, oder ob alle Caches auf einmal über einen Aufruf von gldrawarraysinstancedext erstellt werden. Diese Konstante wurde genau wie RECORDS_PER_DRAW zu Testzwecken eingebaut um die beste Methode zu finden, die Caches zu erstellen. Nachdem die Oberflächenpunkte in die maximal 1024 Caches gerendert wurden, kommt die Pull-Phase. Hierbei wird abhängig von der Anzahl an Level in pullpushlevels wiederholt ein Quadrat über die komplette neue Textur gerendert. Das Ergebnis wird im Fragment- Shader pull.fp.glsl berechnet und in jeweils eine neue Textur geschrieben. Ähnlich verhält es sich mit der Push-Phase. Hierbei gibt es jedoch eine Besonderheit. Da der letzte Durchlauf der Push-Phase das Ergebnis in die große Cache Textur schreibt, 47

48 4 Implementationsdetails verändern sich die Koordinaten, in die die Caches geschrieben werden. Es ist also nicht mehr möglich mit dem Zeichnen eines einzelnen Quadrats alle Caches zu bearbeiten. Stattdessen wird jeweils ein kleines Quadrat für jeden Cache gerendert. Hierzu werden die Vertexund Geometrie-Shader pointtoquad zusammen mit dem normalen Fragment-Shader der Push-Phase verwendet. Die Vertex-Koordinaten, die hierbei verwendet werden, stammen aus texcoordbuffer und enthalten die Mittelpunkte zu den Caches der großen Cache- Textur. Als Texturkoordinaten werden die Mittelpunkte für die Caches in den temporären Texturen aus tempcachecoordsbuffer verwendet. Der Geometrie-Shader erstellt aus den Vertex-Positionen und Texturkoordinaten der Eingangspunkte zwei Dreiecke, die ein Quadrat bilden, inklusive passender Texturkoordinaten. Die Pull-Push Phasen können nicht direkt abgestellt werden, zu Testzwecken existiert jedoch die Konstante PASS_THROUGH im Push-Shader, der den Shader auf reines kopieren der alten Werte umstellt, wodurch das ganze effektiv deaktiviert wird. 4.7 Final Gathering und Radiance Interpolation Beim Auslesen der Caches wird jeder Punkt des Caches als Lichtquelle betrachtet. Das bedeutet man benötigt für das Shading sowohl die Radiance Caches als auch die Material- Eigenschaften an der Position des jeweiligen Caches, wofür die G-Buffers verwendet werden. Die Ergebnisse werden als Punkte in eine Textur geschrieben. Hierbei kommt es zu einem Problem, wenn sich die Szene oder die Kameraposition ändern und nicht alle Caches auf einmal berechnet wurden. Da die alten Caches weiterverwendet werden, kommt es vor, dass einige Caches eigentlich nicht mehr sichtbar wären, da sie verdeckt sind oder außerhalb des View-Frustums liegen. Hierfür wurde im Shader finalgathering.vp.glsl ein zusätzlicher Test eingebaut, der den Tiefenwert der im G-Buffer tscenenormals gespeichert wurde mit dem Tiefenwert den der Cache haben sollte, vergleicht. Weichen die Werte zu stark voneinander ab, so wird die Vertex-Position auf einen Wert hinter der Kamera gesetzt, so das er nicht gezeichnet wird. 4.8 Darstellung mit direkter Beleuchtung Zum Schluss muss noch die direkte Beleuchtung der Szene berechnet werden. Hierfür wird die Geometrie ein letztes mal gerendert. Der Shader globalillumination berechnet dabei die direkte Beleuchtung mit einfachem Blinn-Phong Shading [Bli77]. Die indirekte Beleuchtung wird gleichzeitig aus der Textur tindirectlightinterpolated2 gelesen. Zur Gewichtung der direkten und indirekten Beleuchtung werden die Attribute directlightcontrib und indirectlightcontrib verwendet. Bevor das fertige Bild angezeigt wird, findet ein letzter Post-Processing Schritt durch den Shader postprocess statt. Dieser Shader stammt noch aus dem unveränderten Framework und wurde nur um eine Gamma-Korrektur erweitert. 48

49 4.9 User Interface newrecordsbuffer[0..1] indirectlitpointsfbo finalgathering interpolatehorizontal indirectlightinterpolatedfbo2 indirectlightinterpolatedfbo1 interpolatevertical Abbildung 4.6: Diagramm zum Final Gathering und zur Radiance Interpolation. 4.9 User Interface Die GUI wird über AntTweakBar [Ant] erstellt. Sie teilt sich auf in zwei Bereiche. Der obere Bereich kontrolliert die Lichtquellen. Die erste Lichtquelle lässt sich frei im Raum rotieren, ihr Abstand zum Zentrum ist jedoch auf 3 festgelegt. Die zweite Lichtquelle ist per Default nicht an, kann aber zusätzlich aktiviert werden. Diese Lichtquelle befindet sich immer genau an der Position der Kamera. Der zweite Bereich enthält Optionen, die für die indirekte Beleuchtung relevant sind. Die Optionen und ihre Auswirkungen im einzelnen sind: render Besitzt zwei Optionen, zwischen denen gewechselt werden kann. Die erste Option schaltet auf das vom Framework mitgelieferte Rendering um, die zweite Option auf Radiance Caching Methode. debug Enthält eine Liste von Debugging-Optionen. Siehe Abschnitt

50 4 Implementationsdetails Abbildung 4.7: GUI points Die Anzahl der Oberflächenpunkte. Eine Änderung wird alle Punkte neu erstellen. caches Die Anzahl der Caches pro Achse, d.h. die maximale Anzahl ergibt sich aus caches caches. Der Wert kann maximal 256 und minimal 32 sein. cache size Die Größe eines Caches in Pixeln. Da das Texturlimit bei OpenGL bei 8192 (NVIDIA) liegt, darf cachesize caches diese Zahl nicht überschreiten. Kann maximal 32 und minimal 8 sein. Werte sollten 2er-Potenzen sein. direct contrib Faktor mit dem das direkte Licht multipliziert wird. indirect contrib Faktor mit dem das indirekte Licht multipliziert wird. caches per frame Anzahl der Caches, die in einem Frame berechnet werden soll. Die Zahl bedeutet, das immer alle Caches berechnet werden, da es nie mehr als Caches geben kann. gauss deviation Die Standardabweichung für den Gauss-Filter. pull push Anzahl der Pull-Push Level. debug cache size Größe des Caches, das für Debugging-Zwecke verwendet wird. Dieser Cache kann auch größer sein als Des weiteren existieren einige Tastenkürzel, mit denen bestimmte Aktionen ausgeführt werden können. Die Taste r lädt alle Shader neu. p pausiert die Aktualisierung der Caches, zeigt aber weiterhin die indirekte Beleuchtung an. s kann zum Speichern von Texturen verwendet werden, das ist jedoch nur zum Debugging wichtig. Näheres hierzu ist in der Methode debugsavetextures zu finden. Mit d kann man zwischen den unterschiedlichen Debug-Optionen umschalten. a lässt die erste Lichtquelle um den Mittelpunkt kreisen, oder 50

51 4.10 Debug-Optionen stoppt die Animation wieder. Die Taste g schaltet das Grid an oder ab. q oder Escape beenden das Programm Debug-Optionen Zu Debugging-Zwecken besitzt das Programm einige Methoden, die jeweils mit debug beginnen. Über diese können einige der Zwischenergebnisse ausgegeben werden oder Berechnungen durchgeführt werden, die für die normalen Ergebnisse nicht wichtig sind. Die Ausgabe erfolgt entweder indem die aktuelle Ansicht von der Debug-Ansicht komplett überschrieben wird, oder indem die Debug-Ansicht die normale Ansicht der Szene überlagert. Debug-Methoden werden fast immer von main.cpp aus aufgerufen. Die Debug-Methoden im einzelnen sind: debugrenderpoints Zeigt die Oberflächenpunkte an. debugrendercachetexture Zeigt alle Radiance Cache Texturen an, inklusive der temporären. debugsavetextures Kann verwendet werden um Texturen als BMP-Dateien zu speichern. Welche Texturen gespeichert werden sollen muss extra in der Methode angegeben werden. debugrenderscenetextures Blendet die G-Buffers für Position, Normale und diffuse und spekulare Materialfarbe ein. debugrendernewcacherecords Zeigt die zwei Texturen mit den Cache Records an. Zeigt außerdem eine der Shadow-Maps an. debugrenderimportance Zeigt die Importance Map an. debugrendersamplingraster Zeigt das Ergebnis des Importance Samplings an. Falls der Shader in dieser Methode deaktiviert wird, werden alle Sampling-Punkte angezeigt. debugrenderdiscontinuity Zeigt die Discontinuity Map an. debugrenderfinalgathering Zeigt die Textur mit den indirekt beleuchteten Punkte, die als Ergebnis des Final Gatherings entstehen, an. debugrendergauss1 Zeigt die Textur mit dem Ergebnis nach einer zeilenweisen Gauss- Interpolation an. debugrendergauss2 Zeigt die Textur mit dem Ergebnis nach der spaltenweisen Gauss- Interpolation und Normalisierung an. Die Textur enthält die fertige indirekte Beleuchtung der Szene. 51

52 4 Implementationsdetails debugrendersinglecache Wird verwendet, um einen zweiten Radiance Cache für von den aktuellen Einstellungen abweichende Parametern zu erstellen. Die Methode arbeitet dabei ähnlich wie updatecaches. Die Cache-Größe kann über die GUI eingestellt werden und kann höher als sein. Die Anzahl der Caches liegt per Default bei 1, für mehr Caches muss der Wert im Konstruktor modifiziert werden. debugrenderdebugcachetexture Diese Methode wird verwendet um die Debug-Caches anzuzeigen. Dies geschieht genau wie in debugrendercachetexture, aber mit dem Unterschied, dass die Positionen der Caches zusätzlich als rote Punkte angezeigt werden. debugrenderfullscreentexture Hilfsmethode um eine Textur über den kompletten Bildschirm anzuzeigen. 52

53 Kapitel 5 Ergebnisse 5.1 Performance Zur Zeitmessung wurden zwei unterschiedliche Methoden verwendet. Zum einen wurde die Framerate gemessen durch Bestimmung der Zeit zwischen aufeinander folgenden Frames und Mittelung über eine Sekunde oder mindestens ein Frame. Zum anderen wurde mithilfe der OpenGL-Extension EXT_timer_query [Etq] für die wichtigsten Schritte die Zeit einzeln gemessen. Zusammenhängende Messungen wurden jeweils mit derselben Kameraeinstellung gemacht. Alle Messungen wurden auf einem AMD Athlon 64 X mit 2048MB RAM und einer NVIDIA GeForce GTX 260 (Treiber-Version ) unter Windows XP64 durchgeführt. Für die ersten Messungen wurde die Office-Szene verwendet. Diese besteht aus Dreiecken. Für alle Messungen wurde nur ein Pull-Push Level verwendet. Falls nicht anders angegeben wurden immer Sampling Punkte beim Importance Sampling verwendet. Für die FPS-Messung ergeben sich damit die in Tabelle 5.1 notierten Ergebnisse. Die Bilder aus den Messungen sind in Abbildung 5.1 zu sehen. Als nächstes wurden die einzelnen Abschnitte genauer untersucht, um festzustellen, wofür die meiste Zeit benötigt wird. Auch hierbei wurde wieder die Office-Szene verwendet. Die Tabelle 5.2 enthält alle Messergebnisse für unterschiedliche Einstellungen. Die verwendeten Parameter können der Tabelle 5.3 entnommen werden. Aus der Tabelle ergibt sich, dass die meiste Zeit für das Erstellen der Caches benötigt wird. Dieses Ergebnis ist nicht weiter verwunderlich, wenn man bedenkt, dass bei Oberflächenpunkten und Caches schon 36 Millionen Vertices bearbeitet werden müssen. Eine genauere Untersuchung der Methode rendernewcaches ergab, das 84% der Zeit für das Zeichnen der Punkte benötigt wird. 4% werden für die Pull-Phase und 12% für die Push-Phase benötigt. Die normalen Cache-Texturen sind alle im Format GL_RGBA16F. Eine Reduktion auf GL_RGBA ergab eine Verbesserung der Zeit von unter 1%. Das bedeutet für die Geschwindigkeit ist das Texturformat eher unbedeutend. Anders sieht es aus, wenn man zum Shading der Punkte 53

54 5 Ergebnisse Oberflächenpunkte Cache-Anzahl Cache-Größe FPS , , , , , , , , , , , , 68 Tabelle 5.1: FPS Messung mit der Office-Szene nur eine einzige Lichtquelle anstatt zwei verwendet. Dabei ergab sich eine Verbesserung von ca. 14%. Das bedeutet, die Rechenleistung der GPU ist hier sehr wahrscheinlich der beschränkende Faktor. Eine weitere Beobachtung, die anhand der Messungen gemacht werden kann, ist, dass die Zeit beim Final Gathering proportional zur Cache-Größe und der Anzahl an Caches ist. Die Messergebnisse für (b) zeigen hier eine deutliche Abweichung, jedoch ist hierfür kein eindeutiger Grund ersichtlich. Die für die Erstellung der Shadow Maps relevanten Parameter sind vor allem die Szenenkomplexität, die Position der Kamera und die Anzahl der Lichtquellen. Die Position der Kamera ist auch wichtig bei der Berechnung der Importance Map. Eine Verringerung der Zeit hängt hierbei jedoch nicht mit der Komplexität der Szene zusammen, da die Berechnung im Bildraum arbeitet, sondern damit wieviel der Bildfläche mit relevanten Informationen gefüllt ist, da leere Stellen direkt übersprungen werden. Alle anderen Messwerte sind relativ unabhängig von den Parametern. Die Radiance Interpolation hängt nur von der Anzahl an Pixeln ab, über die interpoliert wird. In diesem Fall sind das jeweils 16 Schritte in jede Richtung. Das bedeutet, für jeden Pixel des finalen Bildes werden maximal 66 linear interpolierte Texel gelesen. Die Gesamtzeit ist die Zeit zwischen zwei aufeinander folgenden Frames. Die restliche Zeit ergibt sich aus der Differenz der Gesamtzeit und aller gemessener Einzelzeiten. In dieser Zeit passiert alles, was nicht gemessen wurde. Dies teilt sich zum einen auf in die restlichen Rendering-Schritte, wie Anzeige der AntTweakBar, des Grids, der Statistik und dem Post-Processing Schritt, und zum anderen in die Abschnitte, in denen die GPU nichts zu tun hat und nur die CPU arbeitet. 54

55 5.1 Performance Einstellungen: (a) (b) (c) (d) (e) (f) (g) G-Buffers 3, 03 3, 15 3, 57 2, 97 3, 06 2, 94 3, 49 Importance Map 3, 14 1, 55 1, 96 3, 14 3, 16 3, 15 3, 15 Shadow Map 11, 73 14, 43 15, 95 13, 31 11, 51 13, 46 11, 89 Punkt-Sichtbarkeit 0, 03 0, 03 0, 03 0, 03 0, 03 0, 05 0, 03 Importance Sampling 1, 38 1, 26 0, 67 0, 61 0, 55 0, 44 0, 39 Radiance Caches 126, 45 34, 02 32, , , , 78 65, 01 Final Gathering 26, 85 4, 86 1, 83 5, 74 27, 02 26, 73 14, 27 Radiance Interpolation 6, 34 6, 86 7, 08 6, 45 6, 45 6, 45 6, 62 Geometrie Rendern 0, 86 0, 97 0, 93 0, 89 0, 89 0, 89 0, 97 Rest 9, 02 12, 42 13, 74 12, 86 8, 83 13, 66 13, 46 Gesamtzeit 188, 83 79, 55 78, , , , , 27 Tabelle 5.2: Messungen der einzelnen Methoden über EXT_timer_query Einstellung Cache-Größe Oberflächenpunkte Samples Caches (a) (b) (c) (d) (e) (f) (g) Tabelle 5.3: Einstellungen für die EXT_timer_query Messungen Alternatives Rendering der Oberflächenpunkte OpenGL bietet eine Erweiterung namens EXT_draw_instanced an, mit der viele Instanzen eines Objekts durch einen einzelnen Funktionsaufruf gezeichnet werden können. Diese Erweiterung wurde zum Zeichnen der Oberflächenpunkte in die Radiance-Caches getestet, in der Hoffnung dadurch die CPU etwas zu entlasten. In der Praxis führte dieses Vorgehen jedoch zu keinen Verbesserungen. Für 200 Oberflächenpunkte und weniger war die Performance mit gldrawarraysinstancedext besser oder gleich gut wie mit gldrawarrays. Für mehr als 200 Punkte wurde gldrawarraysinstancedext jedoch immer schlechter. Bei 2000 Punkten wurden mit gldrawarrays noch ca. 10 FPS erreicht, während gldrawarraysinstancedext auf ca. 8, 2 FPS kam. Eine Aufteilung der 2000 Punkte auf kleinere Mengen und mehrfachen Aufruf von gldrawarraysinstancedext erbrachte eine kleine Verbesserung, jedoch nicht genug um schneller als die Implementierung mit gldrawarrays zu sein. Ein weiterer Test, der zur möglichen Verbesserung der Performance durchgeführt wurde, war, die Oberflächenpunkte über einen Geometrie-Shader ( fillnewcaches.gp.glsl ) zu vervielfachen. So können über einen gldrawarrays Aufruf mehrere Radiance Caches berechnet 55

56 5 Ergebnisse werden. Eine höhere Geschwindigkeit konnte damit jedoch auch nicht erreicht werden. Bei 2000 Oberflächenpunkten und 2 Caches pro gldrawarrays Aufruf verringerten sich die FPS von 10 auf 8, 5 9. Weitere Erhöhung verringerte die Performance noch mehr. 5.2 Speicherbedarf Eines der größten Probleme des Verfahrens ist der für die Radiance Caches benötigte Speicherbedarf. Mit den Standard-Einstellungen von Caches, einer Cache-Größe von und einer 16 Bit RGBA Textur werden 392 MB Grafikspeicher alleine für die Cache Textur benötigt. Bei Caches wären es schon 512 MB. Für den letzten Pull-Push Vorgang, der seine Ergebnisse in diese Textur schreibt, werden außerdem unter anderem zwei der temporären Texturen im Grafikspeicher benötigt. Dadurch kommen nochmal , 75 MB hinzu, was nicht besonders viel ist. Bei einer Erhöhung der Anzahl an temporären Caches sollte dies jedoch berücksichtigt werden. Der komplette Speicherbedarf aller Texturen und Buffer ist in Tabelle 5.4 zu sehen. Nicht aufgeführt dort sind die Renderbuffer-Objekte und alles was außerhalb der Klasse GPUIllumination vom Framework erzeugt wird sowie alle verwendeten Display Listen und Shader. Es kann außerdem vorkommen, dass OpenGL für einige der Objekte mehr Speicher reserviert als notwendig wäre. Textur Größe (in KB) Buffer Größe (in KB) tcachefbcolor[0] pointvbos[0] 31, 25 tcachefbdepth[0] pointvbos[1] 23, 4 tcachefbcolor[1] pointvbos[2] 23, 4 tcachefbdepth[1] 768 pointvbos[3] 31, 25 tcachefbcolor[2] temppointvbo 23, 4 tindirectlitpoints tempcachecoordsbuffer 8 tindirectlightinterpolated texcoordbuffer 392 tindirectlightinterpolated newrecordsbuffer[0..1] tscenepositions currentrecordsbuffer[0..1] tscenenormals samplingrasterbuffer 588 tscenediffusemat tscenespecularmat tscenediscontinuity Fortsetzung auf der folgenden Seite... 56

57 5.3 Bilder Textur Größe (in KB) Buffer Größe (in KB) tnewrecords[0..1] tshadowmap[0..1] timportancemap 192 Gesamt: KB Tabelle 5.4: Speicherverbrauch aller Texturen und Buffer 5.3 Bilder In der ersten Abbildung 5.1 sind die Auswirkungen unterschiedlicher Parameter für die Cache-Größe (Zeilen) und die Anzahl der Oberflächenpunkte (Spalten) zu sehen. Hier sieht man, das eine Cache-Größe von 8 8 noch zu viele Artefakte erzeugt. Erst bei werden die Ergebnisse einigermaßen akzeptabel. Die Artefakte werden dadurch verursacht, das kleine Objekte bei einer niedrigen Cache-Größe zwar vielleicht nur mit einem Pixel vertreten sind, dieser Pixel aber schon einen viel größeren Bereich der Hemisphäre abdeckt als das Objekt eigentlich belegen würde. Außerdem kommt hinzu, dass das Pull-Push Verfahren vor allem für kleine Auflösungen deutlich stärkere Verfälschungen des Bildes erzeugen kann als bei höheren Auflösungen. Die weiteren Bilder enthalten weitere Szenen mit unterschiedlicher Beleuchtung. In Abbildung 5.4 sieht man, das hier die Radiance Interpolation an kleinen Flächen im Bild versagt, wodurch schwarze Stellen entstehen können. Für solche Stellen wäre entweder eine höhere Sample-Dichte beim Importance-Sampling notwendig, oder eine Modifikation des Gauss-Filters. 57

58 5 Ergebnisse x8 16x16 24x24 32x32 Referenz-Bild mit 32x32 und Punkten Abbildung 5.1: Vergleich mit unterschiedlichen Einstellungen. 58

59 5.3 Bilder Abbildung 5.2: Cornell Box mit unterschiedlich positioniertem Licht. Oben mit direkte Beleuchtung, unten ohne direkter Beleuchtung. Abbildung 5.3: Cornell Box mit Kugel Abbildung 5.4: Japanraum-Szene 59