Andy Reimann
Shadow Volumes und Shadow Mapping mit OpenGL/GLSL
ISBN: 978-3-8428-1866-8
Herstellung: Diplomica® Verlag GmbH, Hamburg, 2011
Zugl. Bauhaus-Universität Weimar, Weimar, Deutschland, Bachelorarbeit, 2011
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden und der Verlag, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica Verlag GmbH
http://www.diplomica.de, Hamburg 2011
Inhaltsverzeichnis
Abbildungsverzeichnis
VII
Tabellenverzeichnis
XI
1
Einleitung
1
2
Motivation und Zielstellung
3
2.1
Aufbau der Arbeit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3
Grundlagen
5
3.1
Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1.1
OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1.2
Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1.3
Softshadows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.2
Schatten gebende Verfahren . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2.1
Zeitgeschichtliche Entwicklung . . . . . . . . . . . . . . . . . . .
17
4
Shadow Mapping
23
4.1
Die Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
Die Schatten-Transformation Pipeline . . . . . . . . . . . . . . . . . . .
25
4.3
Probleme
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3.1
Z-Fighting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.3.2
Peter-Pan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.3.3
Perspektivisches Aliasing . . . . . . . . . . . . . . . . . . . . . .
29
4.3.4
Dueling Frusta . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4
Weiterentwicklungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.4.1
Light Space Perspective Shadow Maps . . . . . . . . . . . . . .
31
4.4.2
Dual Paraboloid Shadow Maps . . . . . . . . . . . . . . . . . .
31
4.4.3
Queried Virtual Shadow Maps . . . . . . . . . . . . . . . . . . .
33
- V -
Inhaltsverzeichnis
4.4.4
Cascaded Shadow Maps . . . . . . . . . . . . . . . . . . . . . .
35
4.5
Softshadows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.6
Variable Near- und Far-Clip Plane . . . . . . . . . . . . . . . . . . . . .
44
4.7
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5
Shadow Volumes
47
5.1
Die Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.2
Z-Pass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.3
Z-Fail
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
5.4
Konstruktion der Shadow Volumes . . . . . . . . . . . . . . . . . . . .
52
5.5
Rendern der Shadow Volumes . . . . . . . . . . . . . . . . . . . . . . .
60
5.6
Probleme mit Animation . . . . . . . . . . . . . . . . . . . . . . . . . .
62
5.7
Vor- und Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
5.8
2-Pass-Rendering zu 1-Pass-Rendering . . . . . . . . . . . . . . . . . .
63
5.9
Optimierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
5.9.1
Persistente Datenspeicherung . . . . . . . . . . . . . . . . . . .
66
5.9.2
Dynamic Z-Fail . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.9.3
Silhouettentracking . . . . . . . . . . . . . . . . . . . . . . . . .
66
5.10 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6
Die Demoapplikation
69
6.1
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
6.2
Parametrisierung von Cascaded Shadow Mapping . . . . . . . . . . . .
70
6.3
Parametrisierung von Shadow Volumes . . . . . . . . . . . . . . . . . .
71
6.4
Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
6.5
Performance Tests
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
6.5.1
Cascaded Shadow Mapping . . . . . . . . . . . . . . . . . . . .
73
6.5.2
Shadow Volumes . . . . . . . . . . . . . . . . . . . . . . . . . .
78
7
Zusammenfassung
85
8
Ausblick
87
Literaturverzeichnis
89
- VI -
Abbildungsverzeichnis
3.1
Ein Einheitswürfel, die Normalisierten Gerätekoordinaten . . . . . . . .
6
3.2
Modell einer perspektivischen Kameraprojektion . . . . . . . . . . . . .
7
3.3
Perspektivische Projektion der Kamerakoordinaten auf die Near-Clip-Plane
8
3.4
Modell einer orthogonalen Kameraprojektion . . . . . . . . . . . . . . .
9
3.5
Die Transformationspipeline von OpenGL . . . . . . . . . . . . . . . .
10
3.6
Modellhafte Darstellung einer realen Lichtquelle (links) und einer virtuelle
Lichtquelle (rechts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.7
Timeline von 1991 bis heute über die Entwicklung verschiedener Shado-
wing Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.1
Test auf die Entfernung von den Pixeln aus Sicht der Kamera und aus
Sicht der Lichtquelle . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.2
Die Biasmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3
Die Transformationspipeline eines Vertex im Kamerakoordinatensystem
und im Lichtkoordinatensystem . . . . . . . . . . . . . . . . . . . . . .
26
4.4
Der Effekt Z-Fighting beim Shadow Mapping
. . . . . . . . . . . . . .
28
4.5
Der Effekt Peter-Pan beim Shadow Mapping . . . . . . . . . . . . . . .
29
4.6
Das Verhältnis von Shadowmap-Fläche zu Render-Fläche . . . . . . . .
30
4.7
2-Dimensionale Darstellung der Problematik Dueling Frusta . . . . . .
30
4.8
Vergleich von normalem Shadow Mapping (links) und Light Space Per-
spective Shadow Mapping (rechts) . . . . . . . . . . . . . . . . . . . . .
32
4.9
Plot eines Paraboloid konstruiert nach der Bildungsvorschrift aus Formel
4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.10 Bereichsabdeckung der einzelnen Shadow Maps bei Cascaded Shadow
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.11 Qualitätsstufen der Shadow Maps bei Cascaded Shadow Mapping . . .
36
4.12 Szenen abhängige Möglichkeiten das Kamerafrustum zu splitten . . . .
37
- VII -
Abbildungsverzeichnis
4.13 Cascadengenerierung ohne (links) und mit Transformationskorrekturen
(rechts)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
4.14 Renderpipeline für Geometry Shader Cloning . . . . . . . . . . . . . . .
41
4.15 Renderpipeline für Geometry Instancing . . . . . . . . . . . . . . . . .
42
4.16 Komplexer Schattenwurf aus der Demoapplikation . . . . . . . . . . . .
43
5.1
Darstellung eines visualisierten Shadow Volumes . . . . . . . . . . . . .
48
5.2
Umgekehrte Schattierung bei Z-Fail mit der Kamera innerhalb eines
Shadow Volumes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
5.3
Stencil Wert Berechnung unter Verwendung von Z-Pass . . . . . . . . .
51
5.4
Stencil Wert Berechnung unter Verwendung von Z-Fail . . . . . . . . .
53
5.5
Visualisierung eines Shadow Volumes von der Z-Fail-Methode gefüllt und
als Wireframe-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.6
Beispiel eines Meshes bestehend aus Dreiecken . . . . . . . . . . . . . .
55
5.7
Verlauf der Konnektivitätsberechnung . . . . . . . . . . . . . . . . . . .
57
5.8
Beispiel - Schattenvolumenfehler bei unterschiedlicher Geometrieauflösung 59
6.1
Ein sehr komplexes schattenwerfendes Objekt der Demoapplikation . .
70
6.2
Vergleich von Shadow Mapping und Shadow Volumes . . . . . . . . . .
72
6.3
Performance von Cascaded Shadow Maps mit einer Kugel mit Tesselie-
rungsgrad 5 (20480 Dreiecke)
. . . . . . . . . . . . . . . . . . . . . . .
74
6.4
Vergleich der Schattenqualität verschiedener Cascaded Shadow Mapping
Einstellungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
6.5
Performance von Z-Pass Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 1 (80 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.6
Performance von Z-Fail Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 1 (80 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.7
Performance von Z-Pass Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 2 (320 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . . .
79
6.8
Performance von Z-Fail Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 2 (320 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . . .
80
6.9
Performance von Z-Pass Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 3 (1280 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . .
80
6.10 Performance von Z-Fail Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 3 (1280 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . .
80
- VIII -
Abbildungsverzeichnis
6.11 Performance von Z-Pass Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 4 (5120 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . .
81
6.12 Performance von Z-Fail Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 4 (5120 Dreiecke) . . . . . . . . . . . . . . . . . . . . . . . .
81
6.13 Performance von Z-Pass Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 5 (20480 Dreiecke)
. . . . . . . . . . . . . . . . . . . . . . .
81
6.14 Performance von Z-Fail Shadow Volumes und einer Kugel mit Tesselie-
rungsgrad 5 (20480 Dreiecke)
. . . . . . . . . . . . . . . . . . . . . . .
82
7.1
Beispielhafter Screenshot einer schwer zu schattierenden Szene der De-
moapplikation mit Shadow Volumes . . . . . . . . . . . . . . . . . . . .
86
- IX -
Tabellenverzeichnis
6.1
Übersicht über alle erhaltenen Messwerte des Performance Tests von
Cascaded Shadow Maps . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
6.2
Übersicht über alle erhaltenen Messwerte des Performance Tests von
Shadow Volumes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
- XI -
1 Einleitung
Um die Realität in der Computergrafik so gut wie möglich nach zustellen, sind realistisch
anmutende Schatten unerlässlich. Je realistischer die Szenen werden, desto weniger
Fehldarstellungen kann man sich erlauben. Schatten geben dem Betrachter in einer
virtuellen Umgebung eine genauere Vorstellung von der Objekt-Objekt Beziehung und
unterstützen den räumlichen Eindruck. Im Rahmen dieser Bachelorarbeit werden die
zwei bekanntesten Herangehensweisen Shadow Mapping und Shadow Volumes diskutiert
und implementiert. Die Vor- und Nachteile dieser werden intensiv erläutert. Des weiteren
werden Möglichkeiten aufgezeigt, welche die genannten Techniken visuell verbessern und
beschleunigen können. Von der Vielzahl an Erweiterungen von Shadow Mapping werden
die Techniken Perspective Shadow Mapping, Light Space Perspective Shadow Mapping,
Cascaded Shadow Mapping und Dual Paraboloid Shadow Mapping genauer erläutert.
Zu den Shadow Volumes werden die beiden Verfahren Z-Pass und Z-Fail genau erklärt
und implementiert. Des weiteren wird der Algorithmus anhand eines Minimalbeispiels
erläutert und auf Probleme eingegangen.
- 1 -
2 Motivation und Zielstellung
Die Entwicklung von Spielen ist die Königsdisziplin der Computergrafik und gliedert
sich in viele Teilbereiche wie physikalisches Verständnis, künstliche Intelligenz, Benut-
zerinterface und viele mehr. Die realistische Abbildung von Schatten ist hierbei eine
Grundvoraussetzung für eine glaubhafte Abbildung der Realität. Das faszinierende an
Spielen für mich sind die Vielzahl an Spezialeffekten, mit denen man konfrontiert wird.
Jede Art der Interaktion kann zu einem visuellen Erlebnis führen. Besonders diese sind
es, die mich interessieren. Jedoch ist nicht immer alles Gold, was glänzt. Wenn man
sich nicht nur von den wunderschönen Landschaften mitreißen lässt, sondern wirklich
genauer hinsieht, so fallen einem sehr schnell Fehler auf. Vieles was man meint zu sehen,
existiert so gar nicht. Wieder anderes sieht auf dem zweiten Blick plötzlich gar nicht
mehr so schön aus. Schatten gehören zu genau dieser Kategorie. Viele Spieltitel müssen
einen teils merkbaren Kompromiss zwischen Geschwindigkeit und Qualität zugunsten
der Geschwindigkeit in Kauf nehmen.
Das Hauptziel dieser Bachelorarbeit ist die Implementierung einer robusten Tech-
nik zur Darstellung von Schatten. Hierzu werden bestehende Techniken vorgestellt,
implementiert und verglichen. Dabei wird sehr viel Wert auf die Skalierbarkeit und Er-
weiterbarkeit gelegt. Die entstandene Technik soll ein fester Bestandteil meiner eigenen
Game-Engine[Reimann, 2011] werden, welche ein universelles Shadow Mapping System
mitbringen soll, das in möglichst vielen Umgebungen gute Ergebnisse erzielt. Es soll also
ein Schattenframework entstehen, welches dem Nutzer mit wenig Hintergrundwissen
ermöglicht auf denkbar einfache Weise Schatteneffekte zu einer selbst gebauten Szene
hinzuzufügen.
Im Rahmen dieser Bachelorarbeit soll anschließend unter Verwendung des Schatten-
Frameworks eine Demoapplikation entworfen werden, in der komplexe Objekte zu sehen
sind und die Art der Schattierung interaktiv gewechselt werden kann, sowie bestimmte
Parameter eingestellt werden können. Diese Applikation soll sowohl die Grenzen als
auch das Potential der einzelnen Schattentechniken verdeutlichen. Dabei wird besonders
- 3 -
2 Motivation und Zielstellung
darauf geachtet, dass die Objekte der Szene sehr komplexe Schatten werfen, sodass die
einzelnen Techniken an ihre Grenzen gebracht werden.
2.1 Aufbau der Arbeit
Die vorliegende Bachelorarbeit gliedert sich in 3 Hauptkapitel. Nachdem die Grundlagen
der Arbeit in Kapitel 3 erläutert werden schildert das Kapitel 4 die Schatten gebende
Technik Shadow Mapping und einige damit verwandten Verfahren. Angefangen bei der
Beschreibung des Algorithmus über auftretende Probleme bis hin zu Optimierungen
werden viele Themen behandelt. Das nächste Kapitel 5 widmet sich den Shadow Volu-
mes und ist grundlegend genauso aufgebaut, wie das vorherige Kapitel. Den Abschluss
bildet Kapitel 6, welches sowohl die im Rahmen der Bachelorarbeit entwickelte De-
moapplikation, als auch das Schattenframework beschreibt und die Ergebnisse diskutiert.
Abgerundet wird die Arbeit mit einer Zusammenfassung und einem Ausblick auf weitere
Verbesserungsmöglichkeiten.
- 4 -
3 Grundlagen
In diesem Kapitel werden die Themen diskutiert, die dieser Bachelorarbeit als Grundlagen
dienen. Dazu gehören erweiterte Techniken, mit denen Schatten erzeugt werden können,
aber auch die verwendete Grafikbibliothek. Es wird ein Überblick über die bestehenden
Techniken und deren Eigenheiten geschaffen. Abgerundet wird dieses Kapitel durch eine
Zeitgeschichtliche Aufstellung der bis heute entstandenen Schatten Techniken.
3.1 Terminologie
Bevor wir in die einzelnen Techniken der Schattenerstellung einsteigen können, müssen
hier noch ein paar Begrifflichkeiten geklärt werden.
3.1.1 OpenGL
Zur Darstellung einer grafischen Szene wird OpenGL[Group, 2010] verwendet. Ein
Grund für die Verwendung von OpenGL ist, dass es ein plattformübergreifendes Open
Source Framework ist. Es bietet eine Low-Level API um mit der Grafikkarte zu kom-
munizieren. Die Version 1.0 wurde am 1. Juli 1992 veröffentlicht. OpenGL ist ein
weit verbreitetes 2D bzw. 3D Framework. Es stellt eine Spezifikation von etwa 250
Befehlen bereit, die die Darstellung von komplexen 3D-Szenen in Echtzeit ermöglichen.
Des weiteren ist es unabhängig von dem Fenstersystem welches verwendet wird. Dies
macht es zu einem sehr flexiblen Framework, was auch komplexen Aufgaben gewachsen
ist. Momentan befindet sich OpenGL in der Version 4. Die folgenden Unterpunkte
beschreiben im Rahmen dieser Arbeit verwendete Techniken und Begriffe, welche mit
OpenGL in Verbindung stehen. Für eine vollständige Referenz zu OpenGL kann man
die Einzelheiten in dem Red Book [Dave Shreiner, 2007a] und in dem Blue Book
[Dave Shreiner, 2007b] online nachschlagen.
- 5 -
3 Grundlagen
Das Kameramodell
Das Kameramodell in der Computergrafik unterscheidet sich von dem gewohnten realen
Modell. Genau genommen gibt es in OpenGL eigentlich gar keine Kamera. Man sieht
die Szene vielmehr immer vom Koordinatenursprung aus. Dabei wird die gesamte Szene
immer so transformiert, dass ihr der Koordinatenursprung da liegt, wo sich die Kamera
befinden soll. Sie wird während dieser Transformation auch genau so rotiert, dass die
negative Z-Achse in die gewünschte Blickrichtung zeigt.
Ein Monitor ist ein 2-Dimensionales Anzeigegerät. 3-Dimensionale Szenen müssen in
dem 2-Dimnesionalen Raum transformiert werden, um dargestellt werden zu können.
Grundlegend gibt es 2 unterschiedliche Arten der Transformationen, die perspektivische
und die orthogonale Transformation. Beide Transformationen werden in OpenGL mithilfe
der Projection Matrix durchgeführt, deren Aufgabe darin besteht, den darzustellenden
Bereich der Szene in den korrespondierenden Bereich des Einheitswürfels (Abbildung
3.1) zu transformieren.
Abbildung 3.1: Ein Einheitswürfel, die Normalisierten Gerätekoordinaten
Um solch eine Matrix für die perspektivische Projektion konstruieren zu können,
benötigt man einen horizontalen Kameraöffnungswinkel (Field of View), eine Near-
Clip-Plane und eine Far-Clip-Plane. Aus diesen Informationen können die in Abbildung
- 6 -
3 Grundlagen
3.2 zu sehenden Frustum-Punkte, bestehend aus den Komponenten n,f,l,r,t und b,
berechnet werden.
.DPHUD
1HDU &OLS 3ODQH
Q
)DU OLS 3ODQH
I
OWQ
UWQ
UEQ
OEQ
Abbildung 3.2: Modell einer perspektivischen Kameraprojektion
In OpenGL wird ein Punkt (
x
e
, y
e
, z
e
) im Kamerakoordinatensystem zuerst auf die
Near-Clip-Plane auf den Punkt (
x
p
, y
p
, z
p
) projiziert. Dies geschieht über die Verhältnisse
gleicher Dreiecke für die X und Z Koordinate wie in den Gleichung 3.1 und 3.3 zu
sehen. Werden diese umgestellt nach
x
p
respektive
y
p
, so erhält man die vollständigen
Berechnungsvorschriften zu sehen in den Gleichungen 3.2 und 3.4. In der Abbildung
3.3 ist diese Projektion noch einmal visualisiert. Zu beachten ist zudem, dass sowohl
x
p
als auch
y
p
invers proportional von
-z
e
abhängen. Das ist sehr wichtig, da durch diese
Abhängigkeit, anders als bei einer orthogonalen Projektion, der perspektivische Effekt
zustande kommt.
x
p
x
e
=
-
n
z
e
(3.1)
x
p
=
-
n
z
e
· x
e
(3.2)
y
p
y
e
=
-
n
z
e
(3.3)
- 7 -
3 Grundlagen
y
p
=
-
n
z
e
· y
e
(3.4)
(a) Sicht von oben auf die Projektion
(b) Sicht von der Seite auf die Projektion
Abbildung 3.3: Perspektivische Projektion der Kamerakoordinaten auf die
Near-Clip-Plane
Nach dieser Projektion sind die Koordinaten immer noch homogene Koordinaten. Sie
werden anschließend durch die Perspective Division in Normalisierte Gerätekoordinaten
(NDC) umgewandelt, indem sie durch ihre W Koordinate dividiert werden.
Möchte man eine orthogonale Projektion wie in Abbildung 3.4 berechnen, so sind
die Berechnungen und Abhängigkeiten deutlich einfacher, da ein Punkt (
x
e
, y
e
, z
e
) im
Kamerakoordinatensystem linear auf einen Punkt (
x
p
, y
p
, z
p
) projiziert werden kann.
Auch wird bei der orthogonalen Projektion keine Perspective Division benötigt.
- 8 -
3 Grundlagen
1HDU OLS 3ODQH
Q
)DU OLS 3ODQH
I
.DPHUD
OWQ
UWQ
UEQ
OEQ
Abbildung 3.4: Modell einer orthogonalen Kameraprojektion
Die Transformationspipeline
Um die Objekte einer Szene in ein Ausgabebild zu überführen, stellt OpenGL eine
Transformationspipeline bereit, die von jedem zu zeichnenden Objekt durchlaufen
wird. Diese transformiert ein Objekt von seinem Objektkoordinatensystem auf die
Fensterkoordinaten. Abbildung 3.5 zeigt die einzelnen Schritte, die dabei durchlaufen
werden.
- 9 -
3 Grundlagen
2EMHNWNRRUGLQDWHQ
:HOWNRRUGLQDWHQ
.DPHUDNRRUGLQDWHQ
OLSNRRUGLQDWHQ
0RGHO 0DWUL[
9LHZ 0DWUL[
3URMHNWLRQV 0DWUL[
0RGHOYLHZ 0DWUL[
1RUPDOLVLHUWH
*HUlWHNRRUGLQDWHQ
3HUVSHNWLYLVFKH 'LYLVLRQ
)HQVWHUNRRUGLQDWHQ
9LHZSRUW 0DWUL[
Abbildung 3.5: Die Transformationspipeline von OpenGL
Jedes Objekt ist gegeben im Objektkoordinatensystem und wird durch die Modelma-
trix in das Weltkoordinatensystem überführt. Anschließend wird das Objekt mithilfe
der Viewmatrix in das Kamerakoordinatensystem transformiert. Diese beiden Trans-
formationen sind in OpenGL zu der Modelview Transformation zusammengefasst. In
der Formel 3.5 ist diese Transformation zu sehen, wobei
M
V iew
die Viewmatrix und
M
M odel
die Modelmatrix ist und
M
M odelview
die aus der Zusammenfassung entstehende
Modelviewmatrix ist. Um das Objekt nun auf das Frustum abzubilden, wird die Projek-
tionsmatrix verwendet. Dabei werden die Clipkoordinaten nach Formel 3.6 berechnet,
wobei
M
P rojection
die Projektionsmatrix ist. Liegt nun ein Vertex außerhalb des Frustum
der Kamera, so wird dieses geclipt da es außerhalb des darstellbaren Bereichs liegt.
In dem nächsten Schritt wird aus den Clipkoordinaten so Normalisierten Gerätekoor-
dinaten (NDC) erstellt. Dies geschieht durch die Perspektivische Division durch die
- 10 -
3 Grundlagen
W-Komponente der Clipkoordinaten, zu sehen in Formel 3.7. Um diese NDC nun in
Fensterkoordinaten umzurechnen wird in einem letzten Schritt die Viewport Transfor-
mation angewendet. Dabei wird auf die NDC eine Skalierung und eine Translation
angewendet, sodass diese in das Renderfenster eingepasst werden. Die Berechnung der
Fensterkoordinaten wird wie in Formel 3.8 zu sehen berechnet. Dabei steht
w
viewport
für die Breite und
h
viewport
für die Höhe des Fensters in Pixeln und
x
viewport
für den
horizontalen und
y
viewport
für den vertikalen Offset des Viewports im Fenster. Diese 4
Werte sind die, die man auch in der Funktion glViewport als Parameter angibt.
far
und
near sind die Far-Clip-Plane und die Near-Clip-Plane der Kamera.
x
eye
y
eye
z
eye
w
eye
=
M
M odelview
·
x
obj
y
obj
z
obj
w
obj
=
M
V iew
· M
M odel
·
x
obj
y
obj
z
obj
w
obj
(3.5)
x
clip
y
clip
z
clip
w
clip
=
M
P rojection
·
x
eye
y
eye
z
eye
w
eye
(3.6)
x
ndc
y
ndc
z
ndc
=
x
clip
w
clip
y
clip
w
clip
z
clip
w
clip
(3.7)
x
win
y
win
z
win
=
w
viewport
2
· x
ndc
+ (
x
viewport
+
w
2
)
h
viewport
2
· y
ndc
+ (
y
viewport
+
h
2
)
f ar
-near
2
· z
ndc
+
f ar
+near
2
(3.8)
- 11 -
3 Grundlagen
Framebuffer
Ein Framebuffer ist ein Buffer, der die Informationen über einen Frame hält. Dies sind
unter anderem Farbinformationen und Tiefeninformationen der einzelnen Pixel. Es
können aber auch noch andere Informationen Teil des Framebuffers sein. Jedes geöffnete
Fenster besitzt solch einen Framebuffer, der die darzustellende Szene beinhaltet. Jedoch
können Framebuffer auch dazu verwendet werden, um die Farbinformationen einer
gerenderten Szene direkt in eine Textur umzuleiten. Diese Technik wird in OpenGL in
das sog. Framebufferobject abstrahiert [Barris und Koch, 2008].
Depthbuffer
Der Depthbuffer (Tiefenbuffer) ist ein Buffer, der Tiefeninformationen einer Szene
pro Pixel speichern kann. Das besondere an dem Depthbuffer ist seine Genauigkeit in
Abhängigkeit der Entfernung zur Kamera. Diese verläuft nicht linear, sondern logarith-
misch, was zur Folge hat, dass die Genauigkeit in der Nähe der Kamera deutlich höher
liegt, als in größeren Entfernungen. Natürlich kann man diesen logarithmischen Verlauf
auch bedingt beeinflussen, sodass eine akzeptable Abweichung in der Entfernung zu
beobachten ist. Maßgeblich beeinflusst wird dieser Verlauf durch die bedachte Wahl
der Near-Clip-Plane und Far-Clip-Plane der Kamera. Allgemein gesagt treten große
Schwierigkeiten auf, sobald die Far-Clip-Plane zu weit entfernt gewählt wurde, oder die
Near-Clip-Plane zu nah bei 0.0 liegt. Der maßgebliche Parameter ist das Verhältnis
von Near-Clip-Plane zu Far-Clip-Plane.
Stencilbuffer
Der Stencilbuffer ist ein zusätzlicher Buffer des Framebuffers. Jedem Pixel wird ein Wert
im Stencilbuffer zugeordnet. Die Hauptaufgabe des Stencilbuffers ist es, die Übernahme
von einem Pixel in den Framebuffer während des Renderns an eine Operation/Bedingung
zu knüpfen, bzw. eine Schablone bereitzustellen. Diese Schablone bestimmt dann, welche
Pixel in den Framebuffer übernommen werden und welche nicht. Die zu erfüllende
Eigenschaft kann mithilfe der Stencil-Funktion angegeben werden. Die Modifikation
des Stencilwerts bei Erfüllung der Eigenschaft wird mithilfe einer Stencil-Operation
festgelegt. Der Stencilbuffer hat pro Pixel 8 Bit zur Speicherung von Informationen
zur Verfügung. Dies ist technisch damit zu begründen, dass sich der Depthbuffer und
der Stencilbuffer bis heute den selben Speicherbereich auf der GPU teilen. Sie haben
- 12 -
3 Grundlagen
zusammen genau 32 Bit pro Pixel zur Verfügung, was der gleichen Genauigkeit entspricht,
wie die des Farbbuffers zur Speicherung von Farbinformationen pro Pixel.
Culling
Eine Polygonfläche hat in der Computergrafik immer zwei Seiten, eine der Kamera
abgewandte und eine der Kamera zugewandte Seite. Erstere nennt man Front-Face
und letztere Back-Face. Als Culling wird nun eine Technik bezeichnet, bei der keine,
eine oder beide dieser Seiten/Faces ignoriert, also nicht gezeichnet werden. Wenn die
Front-Faces nicht gezeichnet werden, so nennt man dies Front-Face-Culling und wenn
die Back-Faces nicht gezeichnet werden nennt man dies Back-Face-Culling.
Shader
Ein Shader ist ein Programm, das vollständig auf der Grafikkarte läuft. Es wird vom
Autor mit einer High-Level Programmiersprache wie GLSL[OpenGL.org, 2011] oder
Cg[NVIDIA, 2011] geschrieben und zur Laufzeit in für die Grafikkarte verständlichen
Maschinencode übersetzt. Es gibt mehrere verschiedene programmierbare Arten von
Shadern, die alle einen unterschiedlichen Arbeitsbereich haben und unterschiedliche
Daten verarbeiten. Solche Daten sind beispielsweise die Vertices der zu rendernden
Geometrie samt deren Informationen wie Farben, Normalen und Texturkoordinaten.
Für die Umsetzung der Aufgabenstellung wurde GLSL verwendet, da es einen herstel-
lerübergreifenden Standard bietet und sich zudem perfekt in den OpenGL-Standard
eingliedert.
Lichtquellen
Grundlegend gibt es drei zu unterscheidende Arten von Lichtquellen, die von OpenGL
bereitgestellt werden. Dies sind das Omnidirectional Light (Punktlichtquelle), das Spot-
light (Strahler) und das Directional Light (direktionales Licht). All diese Typen von
Lichtquellen sind Annäherungen/Vereinfachungen zu den korrespondierenden realen
Lichtquellen. In der Realität hat eine Lichtquelle immer eine Ausdehnung, was bei einem
Omnidirectional Light nicht der Fall ist. Diese ist durch einen Punkt definiert ,von
dem aus alle Lichtstrahlen versendet werden. Ebenso verhält es sich bei dem Spotlight.
Das Directional Light wird ausschließlich durch eine Richtung definiert und besitzt
keine feste Position. Alle Lichtstrahlen werden überall in diese Richtung versendet. Das
korrespondierende reale Licht ist in diesem Fall das Sonnenlicht. Das Licht besteht
- 13 -
Ende der Leseprobe aus 103 Seiten
- nach oben
Details
- Arbeit zitieren
- , 2011, Shadow Volumes und Shadow Mapping mit OpenGL/GLSL, Hamburg, Bedey Media GmbH, https://www.diplom.de/document/228550
Ähnliche Arbeiten
Deutschlands größter Sharing Community
Jetzt Zusammenfassungen, Skripte und Klausuren kostenlos downloaden!
Uniturm.de
Ihre Vorteile als Autor
Geld verdienen Für jedes verkaufte Exemplar erhalten Sie Autorenhonorar - bis zu 40%.Kostenlose Buchveröffentlichung
Als eBook-Studie im Original und / oder auf Wunsch zusätzlich als hochwertiges Fachbuch in unserem renommierten Buchverlag.
Renommee als Fachbuchautor
Präsentieren Sie sich als Fachfrau oder Fachmann in Ihrem Fachgebiet und machen Sie sich bekannt.
Persönliche Betreuung
Unser Lektorat wird Sie persönlich betreuen und ist auch telefonisch unter 040-655992-14 erreichbar.
Weltweit im Buchhandel
Ihr Buch ist weltweit im Buchhandel und Online-Buchhandel wie z.B. amazon erhältlich.
Jetzt Autor werden!
Kommentare