Visuelle Effekte mit volumetrischen Shadern. Studienarbeit

Transkript

1 Fachbereich 4: Informatik Visuelle Effekte mit volumetrischen Shadern Studienarbeit im Studiengang Computervisualistik vorgelegt von Dennis Willkomm Betreuer: Dipl. Inf. Matthias Biedermann AG Computergrafik Koblenz, im Mai 2006

2

3 Erklärung Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. Der Veröffentlichung dieser Arbeit im Internet stimme ich zu (Ort, Datum) (Unterschrift) 1

4 Inhaltsverzeichnis 1 Einleitung 3 2 Shader Die OpenGL Pipeline Vertex Shader Fragment Shader Cg Volume Rendering Das Volumenrendering Integral Ray Casting Texturbasiertes Volumenrendering Softwaretechnische Konzeption 12 5 Implementation Textur Slices Noise Die Shader Ergebnisse 24 7 Ausblick 24 Abbildungsverzeichnis 1 OpenGL Rendering Pipeline Die programmierbare Grafik-Pipeline Core Cg Runtime Das Emissions- und Absorptionsmodell Ray Casting Object-aligned Slices als Proxy-Geometrie Umschaltung zwischen den Slice-Stapeln View-aligned Slices als Proxy-Geometrie Eine grobe Übersicht über den softwaretechnischen Entwurf Die 64x128 Pixel große Flammentextur Skizze zur Rotation des original Bildes zur Füllung der 3D-Textur Die durch Rotation eines 2D-Bildes entstandene 3D-Textur Die Boundingbox wird gefüllt mit einem Stack von Slices Aufsummierung zur Perlin Noise Die Noise 3D-Textur Die Ein- und Ausgaben des Vertex Shaders Die Ein- und Ausgabewerte des Fragment Shader Die fertige Flamme in der Bounding Box Fragmente in der Flamme

5 1 Einleitung Die schnellen Fortschritte in der Computergrafik und das Ziel, die Welt in Echtzeit so realistisch wie möglich darzustellen, führten zu der Entwicklung von programmierbaren Grafikprozessoren, so genannten GPUs. Mit Hilfe kleiner Programme (Shader), die direkt auf der Grafikhardware ausgeführt werden, ist es möglich, sehr realistische Effekte in Echtzeit zu erzielen. Dabei sind die Berechnungen auf der Grafikhardware sehr optimiert implementiert, so dass eine deutlich höhere Geschwindigkeit beim Rendering erreicht werden kann, als wenn die Rechenschritte auf der CPU durchgeführt würden. Neben den in der Computergrafik weit verbreiteten polygonalen Modellen ist es aufgrund der stark gestiegenen Verarbeitungsleistung moderner Grafikkarten nun auch möglich, mit Hilfe so genannter volumetrischer Shader visuelle Effekte wie z.b. Glühen, Nebel oder Feuer sehr realistisch darzustellen. Diese Shader können dabei rein prozedural, d.h. nur auf Basis mathematischer Beschreibungen, den gewünschten Effekt erzielen, als auch durch übliche Texturen in ihrem Aussehen gesteuert werden. In der vorliegenden Arbeit wurde versucht einen visuellen Effekt, hier im speziellen Fall eine Flamme, mit Hilfe von volumetrischen Shadern umzusetzen. Unter Verwendung von OpenGL und der Shader-Hochsprache Cg wurde mit Hilfe einer texturbasierten Technik eine Flamme implementiert. 2 Shader Der Einsatz von Shadern auf moderner Grafikhardware ermöglicht eine realistische Darstellung visueller Effekte in Echtzeit. Shader sind kleine Programme, die direkt auf der GPU ausgeführt werden. Dabei gibt es zwei verschiedene Arten von Shadern: den Vertex-Shader und den Fragment-Shader, worauf noch genauer eingegangen wird. Vorteil dieser Shader ist, dass die Funktionen die man benötigt um Grafik zu berechnen auf der Hardware sehr optimiert implementiert wurden. Dadurch können die Berechnungen sehr schnell ausgeführt werden. Ausserdem ist es so möglich, in die festgelegte Pipeline einzugreifen und die Szene kann noch realistischer gerendert werden, worauf im Folgenden noch genauer eingegangen wird. Wie auch die Programme die auf der CPU laufen, können Shader direkt in Assembler programmiert werden. Die Assemblerbefehle sind jedoch nicht leicht zu lesen und nicht einfach nachzuvollziehen. Zur Vereinfachung gibt es, wieder eine Parallele zu den CPU-Programmen, Shader Hochsprachen, die eine intuitivere Programmierung ermöglichen und die Programme entweder vorab oder zur Laufzeit der Applikation in Assemblerbefehle die die GPU versteht kompilieren. Beispiele für solche Shader Hochsprachen sind zum Beispiel GLSL (GL Shading Language), die auf OpenGL aufsetzt, oder nvidias Cg (C for graphics), die sich sehr stark an die Programmiersprache C anlehnt. Letztere Programmiersprache wurde zur Umsetzung dieser Studienarbeit verwendet. Um den Einsatz von Shadern zu verstehen und zu eklären, was ein Shader genau macht, muss man sich die OpenGL Rendering Pipeline vor Augen führen. 3

6 Abbildung 1: OpenGL Rendering Pipeline 2.1 Die OpenGL Pipeline Die OpenGL Rendering Pipeline ist eine Folge von Operationen, die in einer festen Reihenfolge angeordnet sind. Dabei werden sequentiell die Daten durch die Pipeline geschickt und an verschiedenen Stationen verändert. Eine Station innerhalb der Pipeline bekommt ihre Eingabedaten von der ihr vorangestellten Station und reicht ihre Ergebnisse an die ihr nachfolgende Station innerhalb der Pipeline weiter. Abbildung 1 zeigt schematisch die Verarbeitungsschritte der Daten durch die OpenGL Rendering Pipeline. Der erste Schritt bei der Verarbeitung durch die Pipeline besteht in Operationen auf den Vertices. Dies können Transformationen sein, aber auch die Generierung von Texturkoordinaten oder Berechnung der Beleuchtung fällt unter diesen Punkt. Darauf folgt die Umwandlung der einzelnen Vertices in geometrische Primitive, ausgehend von der Verbindung der Vertices untereinander (zum Beispiel in OpenGL die POINTS, LINES, LINELOOP,... ). In diesem Arbeitsschritt findet neben dem Clipping am view frustum auch das Culling statt. Die Polygone die die Clipping- und Cullingschritte überstanden haben müssen nun im nächsten Schritt rasterisiert werden. Unter Rasterisierung versteht man die Bestimmung, welche Pixel durch ein geometrisches Primitiv abgedeckt werden. Hierbei werden also nun die Polygone in Fragments zerlegt. Unter einem Fragment verstehet man pixelgroße Fragmente die ein Primitiv bedeckt. Ein Fragment besitzt eine Pixellocation, einen Tiefenwert, und eine Menge von interpolierten Parametern wie zum Beispiel Farbe oder mehrere Texturkoordinaten. Sozusagen ist ein Fragment ein potenzieller Pixel. Wenn ein Fragment die zahlreichen Rasterisierungstests übersteht, werden seine Informationen zum Update 4

7 Abbildung 2: Die programmierbare Grafik-Pipeline eines Pixels gebraucht. Anschliessend werden verschiedene Operationen durchgeführt, wie zum Beispiel verschiedene Werte interpoliert, texturiert und coloriert. Diese Daten werden dann an den Framebuffer gesendet, und alles nimmt den Lauf von vorne. Neue Vertex- Informationen werden verarbeitet und vorhandene Pixel werden aktualisiert. Die OpenGL Rendering Pipeline ist festgelegt und wird in dieser Reihenfolge immer ausgeführt, wenn man etwas auf Grundlage einer OpenGL-Applikation rendert. Neuere GPU s bieten nun aber die Möglichkeit einer programmierbaren Grafik-Pipeline (siehe Abbildung 2). Dabei besteht die Möglichkeit an bestimmten Stellen der Pipeline die festgelegten Stationen durch eigene Anweisungen zu ersetzen. Shader können somit die Funktionalität der Pipeline erweitern. Dabei unterscheidet man zwischen zwei Arten von Shadern: den Vertex-Shadern und den Fragment-Shadern. 2.2 Vertex Shader In der üblichen OpenGL-Pipeline durchläuft jeder Vertex die Pipeline und wird durch die verschiedenen Stationen der Pipeline verarbeitet. Die Vertex-Shader auf neueren GPU s erlauben es nun, diesen vorderen Teil der Standardpipeline durch eigene Funktionen zu ersetzen. Das heisst die Verarbeitung der Vertices bis hin zum Clipping kann nun vom Benutzer selbst im Vertex-Shader vorgenommen werden. Also würde ein minimaler Shader darin bestehen, die Umwandlung der Koordinaten vom Weltkoordinatensystem ins Kamerakoordinatensystem vorzunehmen, die Beleuchtung zu berechnen, sowie die Transformation ins kanonische Volumen durchzuführen. Das Ergebnis würde dann dem entsprechen, was man bei einem normalen Pipeline-Durchlauf erhalten würde. Der Vorteil eines Vertex-Shaders 5

8 liegt aber nun darin, dass man zusätzlich zu diesen Aufgaben noch weitere Funktionen ausführen kann. Zum Beispiel kann man Texturkoordinaten im Shader generieren, verbesserte Beleuchtungsmodelle implementieren oder Vertex-Animationen generieren. Zu beachten ist dabei, dass ein Vertex-Shader immer nur die Kenntnis von genau einem Vertex hat. 2.3 Fragment Shader Am Ende der Pipeline steht der Fragment-Shader. Dieser Shader wird in jedem Renderingdurchlauf für jeden Pixel einmal auferufen. Der Shader bekommt die zuvor berechneten Informationen aus der Pipeline als Eingabe, gibt als Ausgabe aber nur die Farbe des Pixels zurück. Im Fragmentprogramm findet dann auch der Texturzugriff statt. Sind alle Befehle des Shaders abgearbeitet worden terminiert das Programm und gibt die aktuelle Pixelfarbe zurück. 2.4 Cg Shader in der Computergrafik sind schon länger bekannt. In den späten 80er Jahren entwickelte Pixar die RenderMan-Shadinglanguage. Diese war jedoch noch nicht interaktiv und konnte also zur Programmierung von Echtzeiteffekten nicht verwendet werden. Heute ist es kein Problem mehr interaktive Shader zu entwickeln. Wie Programme, die auf der CPU ausgeführt werden, in unterschiedlichen Programmiersprachen geschrieben werden können, so können auch Shader mit unterschiedlichen Mitteln implementiert werden. Die ursprünglichste Form ist, wie auch auf der CPU, die Assemblerprogrammierung. Jedoch sind Assemblerprogramme nicht intuitiv zu verstehen und so wurde auch für GPU s Hochsprachen entwickelt, die Befehle in für die GPU verständliche Anweisungen kompiliert. Als Beispiele seien hier die OpenGL eigene Shader Hochsprache GLSL, Microsofts HLSL oder nvidias Cg erwähnt. Auf letztere setzt die Implementation von viseffect auf. Cg bedeutet soviel wie C for graphics und ist eine C ähnliche Sprache, die plattformunabhängig ist. Ein Cg Programm kann nur in Verbindung mit einer Applikation genutzt werden. Dafür muss es für die verwendete 3D-API (DirectX, OpenGL) entsprechend kompiliert werden und in die Applikation eingebunden werden um Daten zwischen Shader und Hauptprogramm austauschen zu können. Die Cg Laufzeitumgebung erlaubt es, Cg Programme zur Laufzeit einer Applikation zu kompilieren und einzubinden. Die Funktionalität der Laufzeitumgebung (Cg Runtime) ist in Abbildung 3 dargestellt. Es gibt eine Menge von Funktionen, die den Kern der Laufzeitumgebung bilden (Cg Core Runtime) und spezielle Funktionen für die jeweilige API, die auf den Kernfunktionen aufbauen. Die API-spezifischen Funktionen adaptieren die Philosophie und Datenstrukturen der jeweils verwendeten Grafikbiliotheken. Ein weiterer Vorteil von Cg ist die Verwendung von verschiedenen Profilen. So kann man seinen Shader für bestimmte Profile kompilieren, die unterschiedliche Anforderungen an die verwendete Hardware stellen. Je fortgeschrittener ein Profil ist, desto mehr Möglichkeiten bietet es, komplizierte Berechungen direkt auf der GPU auszuführen und desto höher ist auch die Geschwindigkeit. 6

9 Abbildung 3: Core Cg Runtime Man kann auf viele erweiterte Datentypen zurückgreifen. Da die Vektor- und Matrizenrechnung in der Computergrafik sehr wichtig ist, besitzt Cg für diese Datentypen optimierte Funktionen. So sind zum Beispiel float3 und float4 als dreibeziehungsweise vierdimensionale Vektoren fest in Cg verwurzelt, ebenso zum Beispiel eine matrix4x4. Auf die aktuelle Position, Texturkoordinaten, Normalen und manche andere States kann man über die Register im Shader zugreifen. Zudem besteht die Möglichkeit Uniform-Parameter zu verwenden. Das sind Parameter, die in der Applikation gesetzt werden und sowohl bei Vertex- als auch bei Fragmentshadern verwendbar sind. Dafür werden sie auf die Grafikhardware hochgeladen und stehen dort zur Verfügung zur weiteren Verarbeitung. Diese Werte sind für jeden Vertex, beziehungsweise für jedes Fragment gleich. 3 Volume Rendering In der Computergrafik werden 3D-Modelle traditionell durch die Beschreibung ihrer Oberflächen modelliert, zum Beispiel durch Netze von Polygonen, NURBS oder ähnlichem. Die visuellen Eigenschaften dieser Modelle sind durch diese Art der Modellierung jedoch leicht eingeschränkt. Die Beleuchtung, zum Beispiel durch ein einfaches Phong-Modell, kann nur die Punkte auf der Oberfläche des Objektes beeinflussen. Selbst kompliziertere Beleuchtungsalgorithmen, wie beispielsweise eine BRDF, ist nicht in der Lage Lichtineraktionen darzustellen, die innerhalb eines Objektes auftreten, wenn man die Modelle mit dem traditionellen Modell über die Oberflächen beschreibt. Im Gegensatz zu dieser traditionellen Methode bietet das Volumenrendering die Möglichkeit auch Eigenschaften im Inneren eines Objektes darzustellen. Applika- 7

10 tionen können zum Beispiel die Eigenschaften der Oberfläche steuern, somit kann man Effekte erzielen, wie zum Beispiel die Durchleuchtung eines Rucksackes und Darstellung des Inhalts. Motiviert wurde die Entwicklung des Volumenrenderings durch die medizinische Bildverarbeitung. Die Bilddaten, die zum Beispiel beim MRI (Magnet Resonance Imaging) vom menschlichen Körper erfasst wurden, können mit Hilfe von Volumenrendering-Algorithmen dreidimensional dargestellt werden. Somit kann man einen Blick in den menschlichen Körper werfen und mit verschiedenen Einstellungen bestimmte Körperteile oder Gewebearten hervorheben beziehungsweise durchsichtig machen. Mit dieser Entwicklung ist das Volumenrendering auch immer mehr in den Bereich der Kunst eingedrungen. Viele visuelle Effekte wie beispielsweise Rauch, Nebel oder Feuer, lassen sich auf diese Art besonders realistisch darstellen. Hat man Volumendaten, stellt sich die Frage, wie man sie darstellt. Volumenrendering ist nicht so einfach wie das traditionelle Surface-Rendering. Es gibt zwei Möglichkeiten des Renderns: der texturbasierte Ansatz und Ray-Casting, die im Folgenden noch genauer vorgestellt werden. 3.1 Das Volumenrendering Integral Jeder Algorithmus zum Volumenrendering versucht auf die ein oder andere Methode, möglichst genau das Volumenrendering Integral abzuschätzen. Das Volumenrendering Integral ist die theoretische Grundlage für das Modell der Absorption, auf die das Volumenrendering aufsetzt. Die Methode, die das Integral am numerisch korrektesten annähert, ist das Ray Casting, auf das im nächsten Abschnitt genauer eingegangen wird. Dabei werden optische Eigenschaften entlang eines Sehstrahls integriert. Dies verlangt nach kontinuierlichen Werten, sowohl für die Daten des Volumens als auch für die Abbildung der optischen Eigenschaften. In der Praxis hat man jedoch nur diskrete Werte zur Verfügung und muss versuchen, das Integral möglichst genau numerisch abzuschätzen. Durch Anwendung einiger zusätzlichen Vereinfachungen kann man schließlich das Integral, genauer die optische Tiefe, durch eine Riemann Summe ersetzen. Mathematisch lässt sich das Volumenrendering Integral über folgende Parameter beschreiben. Man geht von einem Ray Cast in ein Volumen aus, der mit x(t) beschrieben wird. Dabei ist t der Abstand vom Augpunkt. Der dazu gehörende skalare Wert entlang des Sehstrahls wird mit s( x(t)) beschrieben. Ausgehend vom Modell der Emission und Absorption muss man Absorptionskoeffizienten κ(s) und emissive Farben c(s) entlang des Strahls hinzufügen. Zur Vereinfachung werden diese Werte auch in Abhängigkeit der Distanz t entlang des Sehstrahls angegeben anstatt anhand vom skalaren Wert s: c(t) := c(s( x(t))) κ(t) := κ(s( x(t))) Das Modell zur Emission und Absorption (siehe Abbildung 4) geht davon aus, dass eine Strahlungsenergie, die in einer Distanz t vom Augpunkt emittiert wird, 8

11 Abbildung 4: Das Emissions- und Absorptionsmodell fortlaufend entlang des Strahls in Richtung Auge absorbiert wird. Das bedeutet dann, dass nur ein Bruchteil der in der Distanz t emittierten Energie das Auge tatsächlich erreicht. Die tatsächlich emittierte Energie c wird also durch Absorptionskoeffizienten zu c abgeschwächt. Ist die Absorption konstant, so berechnet sich c aus: c = c e κd Geht man davon aus, dass die Absorption nicht konstant ist, sondern von der Position auf dem Strahl abhängt, dann berechnet sich c durch Integration der Koeffizienten entlang der Distanz d c = c e R d 0 κ(ˆt)dˆt Das Integral über die Absorptionskoeffizienten im Exponenten wird auch als optische Tiefe τ(d 1, d 2 ) bezeichnet. In dem bisherigen Beispiel wurde davon ausgegangen, dass c nur von einem bestimmten Punkt aus emittiert wurde und auf dem Weg zum Augpunkt abgeschwächt wurde. Beim Volumenrendering muss man jedoch davon ausgehen, dass entlang eines Sehstrahls viele Punkte Energie emittieren, die auf die resultierende Energie am Augpunkt aufgerechnet werden muss. Daher ergibt sich folgendes Integral: 3.2 Ray Casting C = 0 c(t) e τ(0,t) dt Das Samplen der volumetrischen Daten spielt eine zentrale Rolle beim Volumenrendering. Da man die Daten in digitaler Form besitzt, hat man es von Anfang an mit diskreten Werten zu tun. Somit besteht also die Aufgabe darin, diese Daten zu resamplen. Das Ausgangssignal muss also aufgrund der zur Verfügung stehenden diskreten Daten so gut wie möglich rekonstruiert werden, um gute Ergebnisse zu erzielen. Dies wird durch Interpolation und Compositing erreicht. Diese Operationen können auf moderner Grafikhardware sehr schnell ausgeführt werden, da dort optimierte Algorithmen implementiert sind. Eine Möglichkeit diese Aufgabe zu erfüllen ist das sogenannte Ray Casting. Ray Casting ist ein image-order Algorithmus, das heisst ein bestehendes Bild wird in Pixel unterteilt und der Einfluss des gesamten Volumens auf jedes einzelne Pixel wird berechnet. Dabei spielt das numerische Abschätzen des Volumenrendering Integrals eine zentrale Rolle. 9

12 Abbildung 5: Ray Casting Für jedes Pixel der Bildebene wird ein Strahl in die Szene gesendet. Dabei wird geprüft, ob der Strahl die Bounding Box um das Volumen schneidet. Wenn dies der Fall ist, dann wird nun entlang dieses Strahls in gleichmäßigen Abständen das Volumen mit Hilfe von trilinearer Interpolation resampled. Das bedeutet, dass an jeder dieser Positionen am Strahl die Werte von acht benachbarten Voxeln entsprechend ihrer Distanz gewichtet werden um den Wert an der zu berechnenden Stelle zu liefern. Anhand einer Lookup-Tabelle wird der so errechnete skalare Wert optischen Eigenschaften in Form von RGBA-Werten zugeordnet. Im anschliessenden Schritt werden die so errechneten Werte durch Alpha-Blending in back-to-front oder front-to-back Reihenfolge dargestellt. 3.3 Texturbasiertes Volumenrendering Im Gegensatz zum vorgestellten Ansatz des Ray Casting, der von einem imageorder Ansatz ausgeht, gibt es auch noch die Möglichkeit eines, der Grafikhardware eher entsprechendem, object-order Ansatz. Das Prinzip des object-order Ansatzes besteht darin, dass man erst ein Objekt in Primitive unterteilt und dann errechnet, welche Pixel durch ein Primitiv beeinflusst werden. Die geschieht zum Beispiel durch Texture Mapping, wo ein Texturbild interpoliert wird um die Farbe an gewissen Punkten zu errechnen. Dieses Vorgehen lässt sich auch zum Zweck des Volumenrenderings einsetzen. Dazu benötigt man eine Proxy-Geometrie. Die Proxy-Geometrie ist sozusagen eine Menge von geometrischen Primitiven, die mit Texturkoordinaten versehen werden und dann gerendert werden. Durch das Texture Mapping und mit Hilfe von Alpha Blending wird so ein Volumeneffekt erzielt. Diese Proxy-Geometrie wird in den meisten Fällen durch Slices realisiert. Einfache Slices bestehen aus einem Quad, also einem Rechteck, das mit Texturkoordinaten an den vier Eckpunkten versehen worden ist. Es gibt jedoch auch kompliziertere Slices, wie im Beispiel 10

13 Abbildung 6: Object-aligned Slices als Proxy-Geometrie Abbildung 7: Umschaltung zwischen den Slice-Stapeln der View-Aligned Slices zu sehen ist. Von diesen Slices erstellt man nun einen ganzen Stapel und summiert diese durch Alpha-Blending auf. Die Volumendaten sind in diesem Fall entweder in 2D- oder in 3D-Texturen enthalten. Für den Fall, dass die 3D-Texturen den Speicherplatz auf der Hardware übersteigen, ist es auch möglich, einen Stapel von 2D-Texturen zu verwenden. Beim Texturbasierten Ansatz hat man zwei Möglichkeiten die Proxy-Geometrie zu erstellen. Zum einen kann man Object-aligned Slices benutzen, wie in Abbildung 6 dargestellt. Das heisst, man benutzt einen Stapel von Quads, die entlang der Achsen des Koordinatensystems, beziehungsweise der Bounding-Box, ausgerichtet sind. Dies führt jedoch dazu, dass man, wenn man den Augpunkt verschiebt, Artefakte erhalten kann, wenn man einen ungünstigen Blickwinkel auf die Slices erhält oder gar zwischen diesen hindurch sehen kann. Daher muss man drei verschiedene Slice-Stapel generieren, die je nach Augpunkt umgeschaltet werden können, so dass man möglichst wenig Artefakte erhält. Dabei wird dann immer der Stapel ausgewählt, dessen Normale am ehesten Parallel zu der Blickrichtung ist. In Abbildung 7 sieht man das Prinzip angewendet. Die Positin des Augpunktes oder der Kamera wird durch Rotation um das Objekt verändert. Irgendwann würde man in einem Winkel auf die Slices sehen, der so ungünstig ist, dass man zwischen den einzelnen Slices hindurchschauen würde. Zwischen Schritt C und Schritt D wird 11

14 Abbildung 8: View-aligned Slices als Proxy-Geometrie aber der Slice-Stapel ausgetauscht, und somit verhindert, dass dieser ungünstige Fall eintreten kann. Dadurch wird die Anzeige des Volumens optimiert. Ein optisch besserer, dafür aber auch komplizierter Ansatz für die zu rendernde Proxy-Geometrie, stellen die View-aligned Slices dar. Wie der Name schon vermuten lässt, handelt es sich dabei um Slices, die den Sehstrahlen entsprechend ausgerichtet werden. Das heisst die Normale der Slices entspricht dem negativen Sehstrahl. Rendert man ein Volumen mit dieser Methode so erhält man kaum noch Artefakte, da man immer genau frontal auf die Slices sieht (siehe Abbildung 8). Dafür ist die Berechnung dieser Slices nicht ganz so trivial. Die Annäherung an das Volumenrenderingintegral findet bei diesem Ansatz durch das Alpha-Blending statt. 4 Softwaretechnische Konzeption Die Umsetzung einer Flamme durch Volumenrendering benötigt nicht viele Klassen, daher ist der softwaretechnische Aufbau sehr übersichtlich. In einer erweiterten Version, in der mehrere Effekte dargestellt werden können, nicht nur eine Flamme, ist eine Klasse für die Effekte vorgesehen, die die zu rendernden Effekte aufruft. Dabei hat auch jeder Effekt eine einzelne Klasse. In der Implementation ist jedoch bisher nur ein Effekt vorgesehen, daher ist eine Auslagerung in diese Klassen nicht zwingend notwendig. Notwendig ist jedoch eine Vektor-Klasse, die Rechenoperationen für dreidimensionale Vektoren zur Verfügung stellt. Darunter fallen sowohl Standardfunktionen wie Kreuzprodukt oder Skalarprodukt, als auch spezielle Funktionen die für die Implementation der Flamme von Bedeutung sind (zum Beispiel eine Funktion, die die maximale Komponente in einem Vektor liefert). Zudem benötigt man eine Klasse für die BoundingBox. In dieser Klasse werden verschiedene Berechnungen und Funktionen für die Verwendung von Bounding- Boxen implementiert, aber auch eine Funktion, die eine BoundingBox zeichnet. Zuletzt wird noch eine Ray-Klasse benötigt. In dieser Klasse werden Strahlen erzeugt. Diese sind zum Beispiel für die Berechnung von Schnittpunkten mit der BoundingBox nötig. Eine Skizze der Klassenstruktur zeigt Abbildung 9. 12

15 Abbildung 9: Eine grobe Übersicht über den softwaretechnischen Entwurf 5 Implementation Bei der Implementation wurde exemplarisch als visueller Effekt eine Flamme ausgewählt. Diese Flamme wird mit Hilfe des texturbasierten Verfahrens volumetrisch gerendert und mit einer Noise Funktion animiert. Da nur dieser eine Effekt dargestellt wird, benötigt man, wie bereits oben erwähnt, keine Vielzahl an Klassen. Die meisten Funktionen finden sich in der main-methode. Das Programm ist daher sehr prozedural aufgebaut und programmiert. Im Folgenden wird genauer auf die Erstellung und das Mappen der Textur, die Implementation der Slices, die Noise Funktion sowie den Vertex- und Fragmentshader eingegangen. 5.1 Textur Als Methode des Volumenrenderings wurde in dieser Arbeit der texturbasierte Ansatz ausgewählt. Die Implementation einer Flamme orientierte sich an der in [Green 2005] vorgestellten Methode. Dabei wird erst eine Proxy-Geometrie erzeugt, auf die dann eine Flammentextur gemappt wird. So erhält man ein Volumen. Im Fragmentshader wird eine Noise-Funktion aufgerufen, die die für eine Flamme typischen Bewegungen erzeugt. Als Textur wurde die in Abbildung 10 abgebildete Textur benutzt. Es ist eine einfache 2D-Textur im PNG Format, damit auch ein Alpha Kanal zur Verfügung steht. Um ein Volumen zu erzeugen, wurde eine dreidimensionale Textur aus der Vorlage der 2D-Textur erstellt. Dafür wurde das 2D-Bild durch Rotation um die Y- Achse in eine 3D-Textur überführt. Dabei handelt es sich um eine Textur der Größe 128x128x128 im RGBA Modus. Mit Hilfe der DevIL-Bibliothek lassen sich so gut wie alle bekannten Bildformate als Textur in OpenGL laden. Somit stellt das Laden der PNG-Datei kein großes Problem dar. Mit einer eigenen getpixel()-methode 13

16 Abbildung 10: Die 64x128 Pixel große Flammentextur kann man nun die Bilddaten auslesen und zuerst einmal in einem Array speichern. Dieses Array ist noch keine 3D-Textur sondern trägt nur die 2D Bildinformationen. Dafür benötigt man ein dreidimensionales Array, da man 64 Felder für die Breite braucht, 128 für die Höhe und vier für RGBA. Dementsprechend benötigt man für die zu erstellende 3D-Textur ein 4D-Array der Größe 128x128x128x4. Die Füllung dieser 3D-Textur mit den Werten aus der 2D-Textur sieht so aus: 1 void loadtexture() 2 { 3 ladeilbild(); 4 5 for (int bmpx=0;bmpx<h2;bmpx++) 6 { 7 for(int bmpy=0;bmpy<v2;bmpy++) 8 { 9 getpixel(bmpx,bmpy,texdata2,myrgb); 10 myarray[bmpy][bmpx][0]=myrgb[0]; 11 myarray[bmpy][bmpx][1]=myrgb[1]; 12 myarray[bmpy][bmpx][2]=myrgb[2]; 13 myarray[bmpy][bmpx][3]=myrgb[3]; 14 } 15 } printf("textur wird berechnet\n"); 18 for(int x1=0; x1<128; x1++) 19 { 20 for(int y1=0; y1<128; y1++) 21 { 22 for(int z1=0; z1<128; z1++) 23 { 24 for(int i1=0; i1<4; i1++) 25 { 26 mytex3d[x1][y1][z1][i1]=0; 27 } 28 } 14

17 29 } 30 } 31 int r=0;//hoehe 32 int s=0;//breite 33 float theta = 0.00; 34 float myx,myz; for (int th=0; th<360; th++) 37 { 38 for(int x=0; x<h; x++) 39 { 40 for(int y=0; y<v; y++) 41 { 42 myx=x*cos(theta); 43 myz=x*sin(theta); 44 mytex3d[(int)myz+64][y][(int)myx+64][0]=myarray[y][x][0]; 45 mytex3d[(int)myz+64][y][(int)myx+64][1]=myarray[y][x][1]; 46 mytex3d[(int)myz+64][y][(int)myx+64][2]=myarray[y][x][2]; 47 mytex3d[(int)myz+64][y][(int)myx+64][3]=myarray[y][x][3]; 48 } 49 } 50 theta+=0.1; 51 } Die Funktion ladeilbild() in Zeile 3 läd das Texturbild mit Funktionen aus der DevIL-Bibliothek in den Speicher. Die in Zeile 5 beginnende for-schleife liest mit Hilfe einer getpixel()-methode die Daten aus dem Speicher aus und schreibt sie in geeigneter Form in ein Array myarray. Dieser Schritt könnte auch übersprungen werden und man könnte gleich die Werte aus dem Speicher auslesen und in die 3D-Textur an die richtige Stelle schreiben. Durch diesen Umweg wird jedoch die Funktion zum Füllen der 3D-Textur übersichtlicher und leserlicher. In Zeile 18 wird nun das Array mytex3d mit 0 vorbelegt, das die Daten der 3D-Textur empfangen soll. Die Füllung dieses Arrays beginnt in Zeile 36. Dabei durchläuft man eine dreifache Schleife, über theta, über x und über y. Dabei muss der jeweilige x- und z-wert im 3D-Volumen durch trigonometrische Funktionen berechnet werden, während der y-wert dem 2D-Abbild entspricht (siehe auch Abbildung??). Die X und Z Werte in der dreidimensionalen Textur lassen sich folgendermaßen berechnen: X(3D) = x(2d) cos(θ) Z(3D) = z(2d) sin(θ) Hat man das Array auf diese Weise gefüllt, so muss man es noch als 3D-Textur binden. Dies geschieht durch folgenden Code: 1 glgentextures(1,&textures[0]);glbindtexture(gl_texture_3d,textures [0]); 2 3 gltexparameteri(gl_texture_3d,gl_texture_mag_filter,gl_nearest); 4 gltexparameteri(gl_texture_3d,gl_texture_min_filter,gl_nearest); 5 6 gltexparameteri(gl_texture_3d,gl_texture_wrap_s, GL_CLAMP); 7 gltexparameteri(gl_texture_3d,gl_texture_wrap_t, GL_CLAMP); 15

18 Abbildung 11: Skizze zur Rotation des original Bildes zur Füllung der 3D- Textur 8 gltexparameteri(gl_texture_3d,gl_texture_wrap_r, GL_CLAMP); 9 10 PFNGLTEXIMAGE3DPROC pglteximage3d= (PFNGLTEXIMAGE3DPROC) wglgetprocaddress("glteximage3d"); 11 pglteximage3d(gl_texture_3d, 0, GL_RGBA, 128, 128, 128,0, GL_RGBA, GL_UNSIGNED_BYTE, mytex3d); Dafür muss die glextension glteximage3d geladen werden. Als Ergebnis erhält man nun eine 3D-Textur, die eine Flammenform darstellt. Abbildung 12 zeigt die fertige 3D-Textur die aus dem 2D-Bild erstellt wurde. 5.2 Slices Die Implementation der Slices bildet die Grundlage zur Darstellung eines dreidimensionalen Volumens. Ein Volumen wird dargestellt durch Scheiben die einen Querschnitt durch die Volumendaten darstellen. Mit Hilfe des Volumenrenderingintegrals, das in der Implementation durch das Alpha-Blending angenähert wird, werden dann diese Scheiben zu einem Volumen kombiniert. In dieser Arbeit wurde die schon vorgestellte Methode der Object-aligned-Slices verwendet. Dafür wurden drei Stapel von Quads erstellt, je für die drei Hauptachsen des Objekts. Ausserdem muss man unterscheiden in welcher Reihenfolge man den Stapel rendert, damit das Alpha-Blending ordentlich funktioniert. Beispielhaft sei hier der Aufbau des Slice-Stacks für die Z-Achse gezeigt. 16

19 Abbildung 12: Die durch Rotation eines 2D-Bildes entstandene 3D-Textur 17

20 1 for (int i=1; i<anzahl_der_slices+1; i++) 2 { 3 //SliceStack Z 4 5 glbegin(gl_quads); 6 gltexcoord3f(0.0, 0.0,march); 7 glvertex3f(lup[0],lup[1],lup[2]); 8 //lup: linker, vorderer, unterer Punkt der BoundingBox 9 gltexcoord3f(1.0,0.0,march); 10 glvertex3f(rup[0],rup[1],rup[2]); 11 //rup: rechter, vorderer, unterer Punkt der BoundingBox 12 gltexcoord3f(1.0, 1.0,march); 13 glvertex3f(rop[0],rop[1],rop[2]); 14 //rop: rechter, vorderer, oberer Punkt der BoundingBox 15 gltexcoord3f(0.0, 1.0, march); 16 glvertex3f(lop[0],lop[1],lop[2]); 17 //lop: linkter, vorderer, oberer Punkt der BoundingBox 18 glend(); lup[2] += abstand_zwischen_den_slices; 22 rup[2] += abstand_zwischen_den_slices; 23 rop[2] += abstand_zwischen_den_slices; 24 lop[2] += abstand_zwischen_den_slices; march += (float)1/anzahl_der_slices; }; Ein Slice in dieser Applikation wird aus der primitiven Form des GL QUADS gebildet. Ein GL QUAD besteht aus vier Eckpunkten. Diese Eckpunkte lassen sich bestimmen aus den Informationen aus der Bounding Box. Jedem der Eckpunkte werden 3D-Texturkoordinaten zugewiesen. Dabei sind die r und s Werte der Textur für jeden Slice im Stack gleich an den Vertices, während sich die t-koordinate der Textur mit der Tiefe im Stack ändert. Dies wird durch eine Variable march gewährleistet, die Abhängig von der Anzahl der Slices die t-koordinate erhöht. Ebenso wird für das nächste Slice die Z-Koordinate erhöht. Nun muss man dafür sorgen, dass zwischen den Slice-Stacks umgeschaltet wird, so dass man nicht plötlich zwischen den einzelnen Scheiben hindurchschauen kann. Dafür berechnet man zuerst den Sehstrahl, der vom Augpunkt in die Szene hinein zeigt. Da man die Position des Augpunktes durch die Maussteuerung dynamisch verändern kann, berechnet sich der Sehstrahl so: viewray = lookat x lookat y lookat z eye x eye y eye z Um zu entscheiden, welcher Stack gezeichnet werden muss, sucht man die maximale, absolute Komponente im viewray heraus. Ist die maximale Komponente beispielsweise der X-Wert, so wird der X-Achsen-Stapel gerendert. Dann spielt das Vorzeichen des Wertes eine Rolle. Es entscheidet, in welcher Reihenfolge der Stapel gerendert wird. Wie ein solcher Slice-Stapel in der Applikation aussieht, zeigt Abbildung 13. Hier wurde die Anzahl der Slices auf 10 begrenzt, 18

21 Abbildung 13: Die Boundingbox wird gefüllt mit einem Stack von Slices während im eigentlichen Programm die Anzahl wesentlich höher ist, damit weniger Artefakte entstehen. 5.3 Noise Zur Animation der Flamme benötigt man nun eine Funktion, die zufällig pro Frame die Texturkoordinaten verschiebt, damit eine möglichst natürliche Bewegung in die Flamme kommt. Für diesen Zweck braucht man Zufallswerte. Jedoch wirkt die Verwendung einfacher Zufallszahlen nicht sehr natürlich, deshalb benutzt man eine Noise-Funktion, die natürlichere Ergebnisse liefert. Dazu bietet sich die Perlin-Noise Funktion an, die nach ihrem Erfinder Ken Perlin benannt wurde. Da in der Natur alles aus sehr unterschiedlichen Detailstufen besteht, versucht die Perlin Noise diese fraktale Eigenschaft der Natur nachzubilden. Dies geschieht, indem verschiedene Noise Funktionen in unterschiedlichen Skalierungen aufeinander addiert werden. Um die Perlin Noise zu implementieren benötigt man eine Noise Funktion und eine Funktion zur Interpolation. Eine Noise Funktion ist nichts weiter als ein Zufallszahlengenerator. Man übergibt einen Wert und erhält einen zufälligen Wert zurück, der auf dem Eingabewert basiert. Es muss für die Perlin Noise jedoch sichergestellt sein, dass man, wenn man einen Wert zweimal übergibt, auch für Beide Eingaben den gleichen Zufallswert 19

22 Abbildung 14: Aufsummierung zur Perlin Noise erhält. Somit erhält man für eine Reihe von Eingabwerten zufällige Ausgabewerte. Diese Werte sind noch diskret. Deshalb interpoliert man nun zwischen diesen errechneten Zufallswerten und erhält eine einfache Noise Funktion. Abbildung 14 zeigt das Prinzip, das hinter der Perlin Noise steckt. Man hat eine gewisse Anzahl an Noise Funktionen mit unterschiedlichen Frequenzen und Amplituden. Addiert man diese zusammen, so erhält man eine Funktion mit großen, mittleren und kleinen Variationen. Diese Summe der Noise Funktionen ist die Perlin Noise. Das Ergebnis in der Abbildung zeigt auch, wofür man die Perlin Noise sehr gut Einsetzen kann: zur Generierung von Terrains. Denn die Funktion sieht aus wie das Höhenprofil eines Gebirges. Bei der Aufsummierung der Noise kann man nun wählen, welche Amplitude und welche Frequenz man pro Noise benutzen möchte. Dabei ist das weit verbreitete Modell die doppelte Frequenz und die halbe Amplitude für jede neue Noise- Funktion. Diese Werte können jedoch frei variiert werden, je nachdem welchen Effekt man mit der Perlin-Noise erzielen möchte. Um das ganze zu vereinfachen gibt es einen bestimmten Wert, die Persistenz, der das Verhältnis von Frequenz und Amplitude ausdrückt. [Elias 2006] definiert die Persistenz so: frequenz = 2 i amplitude = persistenz i Dabei ist i die i-te Funktion die hinzuaddiert wird. Die Noise-Funktionen die man addiert bezeichnet man als Oktaven. Oktaben deshalb, weil jede Noise-Funktion die doppelte Frequenz der vorherigen besitzt. Diese Eigenschaft besitzen auch die Oktaven in der Musik. Dabei ist es für die Perlin Noise egal, wie viele Oktaven man aufeinander addiert. Dies hängt ganz alleine vom Zweck und dem Detail der Darstellung ab. Denn irgendwann, wenn die 20

23 Abbildung 15: Die Noise 3D-Textur Frequenz zu hoch ist, ist es unmöglich diese an einem Computerbildschirm noch darzustellen, beziehungsweise ihre Auswirkung auf die Summe ist zu gering, als dass sich das Ergebnis dadurch beeinflussen ließe. Hat man nun eine Noise Funktion, dann ist es sinnvoll die Werte auch zu glätten. Dies kann erreicht werden durch einfache lineare Interpolation, aber auch fortgeschrittene Methoden wie zum Beispiel eine Kosinus Interpolation oder eine kubische Interpolation sind dabei möglich. Kriterium sollte sein, ob man mehr Wert auf das Aussehen oder auf die Geschwindigkeit legt. Denn während eine lineare Interpolation sehr schnell ausgeführt wird, benötigt die Hardware für die Berechnungen einer kubischen Interpolation doch etwas länger. Dafür sehen die Ergebnisse bei fortgeschrittenen Interpolationsmodellen auch wesentlich glatter aus. Die Umsetzung der Theorie in die Praxis gestaltete sich nicht ganz so einfach. Daher wurde eine leicht veränderte Berechnung der Noise vorgenommen. Ein Hauptproblem stellt sich bei der Arbeit mit Shadern dadurch, dass man im Shader keine Zufallswerte für die Noise Funktion erstellen kann. Ausserdem ist ja immer nur ein Vertex beziehungsweise ein Fragment bekannt. Daher wird in der Applikation bereits für die Streuung der Zufallswerte gesorgt. Diese werden dann in einer 3D-Textur gespeichert, die als uniform Parameter auf die GPU geladen wird. Dabei handelt es sich um eine Textur der Größe 32 3, die in Abbildung 15 gezeigt wird. Erstellt wird die NoiseMap bei jedem Aufruf der display()-funktion, 21

24 also für jeden Frame einmal. Das heisst auch, dass für jeden Frame die Zufallswerte neu berechnet werden. Die Hauptarbeit für die Noise Funktion findet dann im Fragment Shader statt. Hier werden, nachdem im Vertex Shader schon einige Vorberechnungen durchgeführt wurden, auf die im nächsten Kapitel noch genauer eingegangen wird, Texturkoordinaten mit Hilfe von der Noise Funktion verändert. Dies geschieht durch folgende zwei Funktionen: 1 half4 noise3d(sampler3d NoiseMap, float3 P) 2 { 3 return tex3d(noisemap, P); 4 } 5 6 half4 turbulence4(sampler3d NoiseMap, float3 P) 7 { 8 half4 sum = noise3d(noisemap, P)* noise3d(noisemap, P*2)* noise3d(noisemap, P*4)* noise3d(noisemap, P*8)*0.0625; 12 return sum; 13 } Dabei macht die Funktion noise3d nichts anderes als einen einfach Lookup in der erstellten NoiseMap, der dann einen vierdimensionalen Zufallsvektor zurückliefert. Die Funktion turbulence4 addiert die verschiedenen Oktaven der Perlin Noise, wie oben beschrieben. Zurückgegeben wird dann die aufsummierte Perlin Noise für einen bestimmten Wert. Wie durch den Aufruf der Funktion die Texturkoordinaten verändert werden, wird im nächsten Abschnitt erklärt. 5.4 Die Shader Die OpenGL Applikation berechnet eine dreidimensionale Textur, die die Volumendaten der Flamme enthält. Ausserdem wird noch eine weitere dreidimensionale Textur berechnet, die Zufallswerte zur Berechnung der Perlin Noise enthält. Ausserdem werden Slices mit Texturkoordinaten versehen und gerendert, die das Volumen darstellen sollen. Doch die Hauptarbeit findet in den Shadern statt. Hier wird texturiert und animiert. Ohne den Einsatz der Shader würde man nur eine leere Bounding Box zu sehen bekommen. Der Vertex Shader ist dabei noch recht simpel gehalten. Seine Hauptaufgabe besteht darin, die für die Darstellung notwendigen Berechnungen durchzuführen und Vorberechnungen für den Fragment Shader zu leisten. Abbildung 16 zeigt die Ein- und Ausgaben des Vertex Shaders. Die für die Darstellung der Flamme wichtigsten Berechnungen werden in den Variablen NoisePos und FlamePos gespeichert. Die Variable HPosition enthält die, durch die Multiplikation mit der ModelviewProjection-Matrix berechnete, Position des aktuellen Vertex. 1 NoisePos = UV * tick * 0.001; 2 FlamePos = UV * flamescale; NoisePos berechnet sich dabei, wie in Zeile 1 zu sehen, durch die Multiplikation der aktuellen Texturkoordinaten mit einem Skalierungsfaktor für die Noi- 22

25 Abbildung 16: Die Ein- und Ausgaben des Vertex Shaders Abbildung 17: Die Ein- und Ausgabewerte des Fragment Shader se, auf den ein durch die Zeit variierender Werte addiert wird, der auch mit einem Skalierungsfaktor versehen ist. Die Variable tick wird in der Applikation durch tick += glutget(glut_elapsed_time); erstellt und pro Frame an den Shader übergeben. Die Hauptarbeit findet im Fragment Shader statt. Hier muss die Texturierung durchgeführt werden, sowie die Noise Funktion angewendet werden. Eine Übersicht über die Ein- und Ausgabewerte des Fragmen Shader gibt die Abbildung 17. Als Eingabe erhält der Shader die Werte, die durch das Vertex Programm berechnet wurden, also HPosition, NoisePos und FlamePos. Ausserdem werden von der Applikation die erstellten dreidimensionalen Texturen als uniform Parameter übergeben. NoiseMap ist die erstellte Textur mit den Zufallswerten und decal ist das erstellte Flammenvolumen. Als Ausgabewert hat der Shader einen vierdimensionalen Vektor, der einen RGBA-Wert darstellt. Neben den bereits vorgestellten Funktionen zur Berechnung der Perlin Noise noise3d und turbulence4 befinden sich in der Hauptfunktion die Berechnungen und Texturierungsschritte. 23

26 1 half3 uv; 2 uv.x = IN.FlamePos.x; 3 uv.y = IN.FlamePos.y; 4 uv.z = IN.FlamePos.z; 5 6 uv.y += (turbulence4(noisemap, IN.NoisePos)).y - 0.3;// / uv.x; 7 8 float4 flamecolor = { 0.2, 0.2, 0.2, 0.2 }; 9 float4 rgbcol = tex3d(decal, uv).rgbr; 10 return half4 (rgbcol* flamecolor); In diesem Teil des Fragment Shaders wird erst ein dreidimensionaler Vektor angelegt, dessen Komponenten aus den Werten der übergebenen FlamePos bestehen. Auf den y-wert dieses Vektors wird nun die Perlin Noise angewendet. Der resultierende RGBA-Wert, den der Fragment Shader als Ergebnis zurückliefert errechnet sich aus einer Texturierung mit den durch die Noise Funktion veränderten Texturkoordinaten und dem anschliessenden Multiplizieren mit einem fixen Wert für die Flammenfarbe, der für eine realistischere Färbung sorgt. Der Alpha-Wert wird dabei mit dem Rotwert belegt. 6 Ergebnisse Kombiniert mit dem Shader entsteht nun eine Flamme, die sich anhand einer Zeitvariablen ändert. Abbildung 18 zeigt das fertige Bild der Flamme in der Bounding Box. Ganz optimal ist das Bild noch nicht, da in der Flamme noch kleinere Fragmente auftreten. Dies zeigt auch Abbildung 19, wo man deutlich die vertikalen Lücken in der Flamme erkennen kann. 7 Ausblick Es gibt noch einige Möglichkeiten die Darstellung der Flamme zu optimieren und zu verbessern. Eine Möglichkeit Fragmente zu beseitigen besteht darin, die View- Aligned Slices zu implementieren. Dadurch würden, wie bereits oben erwähnt, die Slices immer parallel zur Bildebene stehen und dadurch hätte man nie das Problem, dass man die Lücken zwischen den einzelnen Slices erkennen würde. Ein weiterer Punkt zur Verbesserung wäre eine verbesserte Perlin Noise Funktion. Verbesserungen wären vor allen Dingen bei der Interpolation zwischen den Oktaven denkbar. Zu guter Letzt wäre natürlich der Ausbau der Applikation um weitere Effekte zu bedenken. Man könnte leicht andere Effekte wie Feuerbälle oder Nebel mit dem vorhandenen Framework erstellen. Dafür wäre eine Nutzung der effect-klasse sinnvoll. 24

27 Abbildung 18: Die fertige Flamme in der Bounding Box 25

28 Abbildung 19: Fragmente in der Flamme Literatur [Elias 2006] ELIAS, Hugo. Perlin Noise [Fernando und Kilgard 2003] FERNANDO, Randima ; KILGARD, Mark J.: The Cg Tutorial. Addison-Wesley, April 2003 [Green 2005] GREEN, Simon: Conference 2005, 2005 Volume Rendering for Games, Game Developers [Hadwiger 2004] HADWIGER, Markus: Real Time Volume Graphics - Introduction, Course Notes 28, Siggraph 2004, 2004 [Müller und Grosch 2003] MÜLLER, Stefan ; GROSCH, Thorsten. Vorlesung Computergrafik [nvidia 2004] NVIDIA: Cg Toolkit User s Manual - A developer s guide to programmable graphics. nvidia Corporation, January 2004 [Shreiner u. a. 2006] SHREINER, Dave ; WOO, Mason ; NEIDER, Jackie: OpenGL Programming Guide - The Official Guide to Learning OpenGL, Version rd Edition. Addison-Wesley,