DGL Wiki - Benutzerbeiträge [de]

Scanlinerenderer

2004-10-21T09:49:32Z

Mars:

Unter "Scanline rendern" versteht man im Allgemeinen die Methode, Polygone in horizontale Linien aufzuteilen, die dann besonders effektiv (sprich schnell) gezeichnet werden können.
Scanlines ergeben sich ganz automatisch aus der Organisation des Videospeichers, den man sich als zweidimensionales Feld vorstellen kann, bei dem horizontale Pixel genau hintereinander liegen - wenn man also horizontal benachbarte Pixel zeichnet, so ist keine weitere Offsetberechnung nötig, und man kann direkt mit wiederholten Maschinenbefehlen (auf Intel Architektur z.B. mit rep Präfix) darauf zugreifen.
Dass der Videospeicher so aufgebaut ist, ergibt sich übrigens wiederum daraus, dass es früher nur Kathodenstrahlröhren als Bildschirme gab, bei denen der Elektronenstrahl durch Magnetfelder zeilenweise horizontal über die Lochmaske (oder ganz früher die Lumineszenzschicht) gesteuert wurde, d.h. es war wichtiger schnell auf horizontal benachbarte Bilddaten zugreifen zu können.

Auch wenn inzwischen Softwarelösungen zum Rendern ziemlich in den Hintergrund getreten sind, gelten für 3D-Hardware doch die selben Prinzipien, die ansonsten programmgesteuert umgesetzt wurden - d.h. eigentlich alle modernen Grafikkarten können ebenfalls als Scanlinerenderer betrachtet werden, da Polygone immer noch in Zeilen aufgeteilt und von oben nach unten in den Videospeicher gezeichnet werden.

Alternativen zum Scanlinerendern sind beispielsweise: echtes Vektorrendern (wird nicht mehr eingesetzt: mit dieser Methode steuerten manche Computer direkt einen Elektronenstrahl, der dann irgendwas auf der Kathodenstrahlröhre darstellte, es gab also überhaupt keine Pixel) und Raytracing, bei dem es völlig egal ist, wie die Bildpunkte durchlaufen werden, da jeder Bildpunkt für sich berechnet wird - und Raytracing meist ohnehin nicht in Echtzeit abläuft.

--[[Benutzer:Mars|Mars]] 07:49, 21. Okt 2004 (UTC)

Volumetrische Stencilschatten

2004-10-21T08:41:49Z

Mars: /* zFail */

== Konzept ==

Bei dieser Technik nutzt man den (seit ~2000 von fast allen Grafikkarten angebotenen) [[Schablonenpuffer|Stencilpuffer]] um dort die im Schatten liegenden Bereiche der Szene abzulegen. Später werden dann mit einem passenden Stencilvergleich die Schatten dargestellt.

Dazu wird für jedes Objekt ausgehend von seiner [[Silhouette]] (es entsteht immer dort eine Silhouetten-Kante, wo ein dem Licht abgewandtes und ein dem Licht zugewandtes Dreieck sich treffen) durch extrudieren ihrer Eckpunkte (im Idealfall in die Unendlichkeit, am Einfachsten lösbar über die W-Koordinate) ein Volumen erstellt das den Bereich des Objektes darstellt den es schattiert.

== Geschichte ==

1977 - Erfunden von Crow : Software-Renderer<br>
1984 - Brotman und Badler : Software-Tiefenpuffer und viele Punktlichter für weiche Schatten<br>
1985 - Fuchs und Co. : Erste Hardwareimplementation und Volumentechnik statt Raytracing<br>
1986 - Bergeron : Behandlung offener Modelle, Nicht-Planare Polygone<br>
1988 - Forunier & Fussell : Theorie zum Zählen der Schattenvolumen in einem Puffer<br>
1991 - Heidmann : Implementation in IRIS GL über Stencilpuffer<br>
1992 - Akeley & Foren : Der für IRIS GL entwickelte Stencilpuffer wird patentiert und in OpenGL 1.0 implementiert<br>
1996 - Deifenbach : Multi-Pass Shattenvolumen<br>
1999 - Dietrich : ZFail-Methode vorgestellt<br>
1999 - Kilgard : Invertierter Algorithmus für planare Ausschnitte<br>
2000 - Carmack : Erste detaillierte Diskussion zur Gleichheit von ZPass und ZFail<br>
2001 - Kilgard : ZPass mit Capping vorgestellt<br>
2002 - Everitt & Kilgard : Mehrere Techniken für eine robuste Lösung<br>

(Teilweise entnommen aus dem Dokument ''"Optimized Stencil
Shadow Volumes"'' von Cass Everitt & Mark J. Kilgard)

== Zukunft ==

Zumindest für die in der Spieleindustrie treibenden ''"Kraft"'' in Sachen OpenGL, John Carmack ([http://www.idsoftware.com/ id Software]), gehört die Zukunft klar den Schatten Volumen. Zumal die zwei frappierendsten aktuellen Nachteile (Ermitteln der [[Silhouette]] und Extrudieren eben dieser für das Volumen, sowie die hohe Anforderung an die Füllrate) dank schneller werdender Grafikkarten und CPUs immer weiter in den Hintergrund rücken. So kann man inzwischen dank [[Vertex Programm|Vertex Programmen]] alle Eckpunkte der Silhouette einfach auf der GPU extruhieren.
Auch die Tatsache dass diese Technik nur sehr scharfkantige Schatten wirf lässt sich via [[Jittering]] (mehrfachem, versetzem Rendern der Schattenvolumen mit unterschiedlicher Helligkeit) spätestens dann realisieren wenn Grafikkarten genug Füllrate anbieten, und eben genau diese steigt von Generation zu Generation recht stetig an.

== Grundlegende Funktionsweise ==

Um eine Szene mit volumetrischen Stencilschatten zu rendern sieht der Renderablauf im Normalfall wie folgt aus :
# Szene nur mit ambientem Lichtanteil in den Farbpuffer rendern
# [[Silhouette]] zwischen Objekten und Lichtquellen errechnen
# Silhouetten extrudieren (und je nach Technik noch Deckel für das Volumen erstellen)
# Stenciltest aktivieren und erstellte Schattenvolumen dort hinein rendern (mit unterschiedlichen Stenciloperationen für Vorder- und Rückseite)
# Szene mit diffusem Lichtanteil rendern (da Schatten im Stencilpuffer liegen wird die Szene jetzt schattiert)

== Methoden ==

=== zPass ===
Bei dieser (zuerst entwickelten) Methode inkrementieren nach vorne zeigende Dreiecke den Wert im Stencilpuffer, wenn diese den Test passieren; und nach hinten zeigende Dreiecke dekrementieren diesen Wert.
Nachteil dieser Methode ist jedoch die Tatsache das es zu Fehlern beim Zählen der Schattenwerte im Stencilpuffer kommt, sobald der Betrachter in ein Schattenvolumen eintritt. Um dies zu lösen gibt es jedoch die zFail-Methode.

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_KEEP, GL_INCR_WRAP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_KEEP, GL_DECR_WRAP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

=== zFail ===
Die von John Carmack im Jahre 2000 "erfundene" Methode zählt die Schattenfragmente etwas anders : Für nach vorne zeigende Dreiecke wird der Wert im Stencilpuffer inkrementiert, wenn diese den Test '''nicht''' bestehen (daher der Name); und dekrementiert für nach hinten zeigende Dreiecke. Weiterhin muss man bei dieser Methode (damit die Fragmente korrekt gezählt werden) ein geschlossenes Schattenvolumen erstellen, das neben der extrudierten (meist in die Unendlichkeit) Silhouette des schattenwerfenden Objektes sowohl einen vorderen Deckel (''Front-Cap'') als auch einen abschliessenden (''Back-Cap'') hat.
Der große Vorteil (auf den man in den seltensten Fällen verzichten) kann ist hier die Tatsache das zFail auch dann korrekte Schatten darstellt wenn der Betrachter in das Volumen eindringt. Nachteilig ist aber das man bedingt durch Deckel und Boden für die Schattenvolumen mehr Berechnungen und Pixeltests durchführen muss. Im Normalfall findet man deshalb eine Kombination aus beiden Techniken in einer Anwendung (zPass generell, wenn Betrachter in einem Volumen ist, dann zFail).

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_INCR_WRAP, GL_KEEP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_DECR_WRAP, GL_KEEP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

== Vor- und Nachteile ==

'''Positiv :'''
* Sehr hohe Details (kein [[Aliasing]])
* Selbstschattierung für schattenwerfende Objekte

'''Negativ :'''
* Benötigt Kenntnis über die zugrundeliegende Geometrie (für die Schattensilhouette)
* [[Silhouette]] muss auf der CPU errechnet werden (->CPU-Lastig)
* Verbraucht sehr viel Füllrate

== Beispiel ==
[[Bild:shadowvolume_scene.jpg]]<br>
Zu sehen ist hier eine Szene die mittels volumetrischer Stencilschatten schattiert wurde. Die roten Umrandungen stellen die Silhouette der Szene ggü. der Lichtquelle dar, während die blauen Linien die Schattenvolumen darstellen (extruhiert in die Unendlichkeit).

== Ressourcen ==
*[http://www.gamasutra.com/features/20021011/lengyel_01.htm "The Mechanics of Robust Stencil Shadows - Eric Lengyel"]
*[http://www.gamedev.net/reference/articles/article1873.asp "The Theory of Stencil Shadow Volumes - Hun Yen Kwoon"]
*[http://developer.nvidia.com/attach/6832 "John Carmack zum Thema Shadow Volumes"]
*[http://developer.nvidia.com/object/fast_shadow_volumes.html Fast, Practical, and Robust Shadow Volumes (NVidia)]
*[http://developer.nvidia.com/object/robust_shadow_volumes.html Practical and Robust Shadow Volumes (NVidia)]

Volumetrische Stencilschatten

2004-10-21T08:40:20Z

Mars: /* Grundlegende Funktionsweise */

== Konzept ==

Bei dieser Technik nutzt man den (seit ~2000 von fast allen Grafikkarten angebotenen) [[Schablonenpuffer|Stencilpuffer]] um dort die im Schatten liegenden Bereiche der Szene abzulegen. Später werden dann mit einem passenden Stencilvergleich die Schatten dargestellt.

Dazu wird für jedes Objekt ausgehend von seiner [[Silhouette]] (es entsteht immer dort eine Silhouetten-Kante, wo ein dem Licht abgewandtes und ein dem Licht zugewandtes Dreieck sich treffen) durch extrudieren ihrer Eckpunkte (im Idealfall in die Unendlichkeit, am Einfachsten lösbar über die W-Koordinate) ein Volumen erstellt das den Bereich des Objektes darstellt den es schattiert.

== Geschichte ==

1977 - Erfunden von Crow : Software-Renderer<br>
1984 - Brotman und Badler : Software-Tiefenpuffer und viele Punktlichter für weiche Schatten<br>
1985 - Fuchs und Co. : Erste Hardwareimplementation und Volumentechnik statt Raytracing<br>
1986 - Bergeron : Behandlung offener Modelle, Nicht-Planare Polygone<br>
1988 - Forunier & Fussell : Theorie zum Zählen der Schattenvolumen in einem Puffer<br>
1991 - Heidmann : Implementation in IRIS GL über Stencilpuffer<br>
1992 - Akeley & Foren : Der für IRIS GL entwickelte Stencilpuffer wird patentiert und in OpenGL 1.0 implementiert<br>
1996 - Deifenbach : Multi-Pass Shattenvolumen<br>
1999 - Dietrich : ZFail-Methode vorgestellt<br>
1999 - Kilgard : Invertierter Algorithmus für planare Ausschnitte<br>
2000 - Carmack : Erste detaillierte Diskussion zur Gleichheit von ZPass und ZFail<br>
2001 - Kilgard : ZPass mit Capping vorgestellt<br>
2002 - Everitt & Kilgard : Mehrere Techniken für eine robuste Lösung<br>

(Teilweise entnommen aus dem Dokument ''"Optimized Stencil
Shadow Volumes"'' von Cass Everitt & Mark J. Kilgard)

== Zukunft ==

Zumindest für die in der Spieleindustrie treibenden ''"Kraft"'' in Sachen OpenGL, John Carmack ([http://www.idsoftware.com/ id Software]), gehört die Zukunft klar den Schatten Volumen. Zumal die zwei frappierendsten aktuellen Nachteile (Ermitteln der [[Silhouette]] und Extrudieren eben dieser für das Volumen, sowie die hohe Anforderung an die Füllrate) dank schneller werdender Grafikkarten und CPUs immer weiter in den Hintergrund rücken. So kann man inzwischen dank [[Vertex Programm|Vertex Programmen]] alle Eckpunkte der Silhouette einfach auf der GPU extruhieren.
Auch die Tatsache dass diese Technik nur sehr scharfkantige Schatten wirf lässt sich via [[Jittering]] (mehrfachem, versetzem Rendern der Schattenvolumen mit unterschiedlicher Helligkeit) spätestens dann realisieren wenn Grafikkarten genug Füllrate anbieten, und eben genau diese steigt von Generation zu Generation recht stetig an.

== Grundlegende Funktionsweise ==

Um eine Szene mit volumetrischen Stencilschatten zu rendern sieht der Renderablauf im Normalfall wie folgt aus :
# Szene nur mit ambientem Lichtanteil in den Farbpuffer rendern
# [[Silhouette]] zwischen Objekten und Lichtquellen errechnen
# Silhouetten extrudieren (und je nach Technik noch Deckel für das Volumen erstellen)
# Stenciltest aktivieren und erstellte Schattenvolumen dort hinein rendern (mit unterschiedlichen Stenciloperationen für Vorder- und Rückseite)
# Szene mit diffusem Lichtanteil rendern (da Schatten im Stencilpuffer liegen wird die Szene jetzt schattiert)

== Methoden ==

=== zPass ===
Bei dieser (zuerst entwickelten) Methode inkrementieren nach vorne zeigende Dreiecke den Wert im Stencilpuffer, wenn diese den Test passieren; und nach hinten zeigende Dreiecke dekrementieren diesen Wert.
Nachteil dieser Methode ist jedoch die Tatsache das es zu Fehlern beim Zählen der Schattenwerte im Stencilpuffer kommt, sobald der Betrachter in ein Schattenvolumen eintritt. Um dies zu lösen gibt es jedoch die zFail-Methode.

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_KEEP, GL_INCR_WRAP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_KEEP, GL_DECR_WRAP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

=== zFail ===
Die von John Carmack im Jahre 2000 "erfundene" Methode zählt die Schattenfragmente etwas anders : Für nach vorne zeigende Dreiecke wird der Wert im Stencilpuffer inkrementiert, wenn diese den Test '''nicht''' bestehen (daher der Name); und dekrementiert für nach hinten zeigende Dreiecke. Weiterhin muss man bei dieser Methode (damit die Fragmente korrekt gezählt werden) ein geschlossenes Schattenvolumen erstellen, das neben der extruhierten (meist in die Unendlichkeit) Silhouette des schattenwerfenden Objektes sowohl einen vorderen Deckel (''Front-Cap'') als auch einen abschliessenden (''Back-Cap'') hat.
Der große Vorteil (auf den man in den seltensten Fällen verzichten) kann ist hier die Tatsache das zFail auch dann korrekte Schatten darstellt wenn der Betrachter in das Volumen eindringt. Nachteilig ist aber das man bedingt durch Deckel und Boden für die Schattenvolumen mehr Berechnungen und Pixeltests durchführen muss. Im Normalfall findet man deshalb eine Kombination aus beiden Techniken in einer Anwendung (zPass generell, wenn Betrachter in einem Volumen ist, dann zFail).

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_INCR_WRAP, GL_KEEP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_DECR_WRAP, GL_KEEP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

== Vor- und Nachteile ==

'''Positiv :'''
* Sehr hohe Details (kein [[Aliasing]])
* Selbstschattierung für schattenwerfende Objekte

'''Negativ :'''
* Benötigt Kenntnis über die zugrundeliegende Geometrie (für die Schattensilhouette)
* [[Silhouette]] muss auf der CPU errechnet werden (->CPU-Lastig)
* Verbraucht sehr viel Füllrate

== Beispiel ==
[[Bild:shadowvolume_scene.jpg]]<br>
Zu sehen ist hier eine Szene die mittels volumetrischer Stencilschatten schattiert wurde. Die roten Umrandungen stellen die Silhouette der Szene ggü. der Lichtquelle dar, während die blauen Linien die Schattenvolumen darstellen (extruhiert in die Unendlichkeit).

== Ressourcen ==
*[http://www.gamasutra.com/features/20021011/lengyel_01.htm "The Mechanics of Robust Stencil Shadows - Eric Lengyel"]
*[http://www.gamedev.net/reference/articles/article1873.asp "The Theory of Stencil Shadow Volumes - Hun Yen Kwoon"]
*[http://developer.nvidia.com/attach/6832 "John Carmack zum Thema Shadow Volumes"]
*[http://developer.nvidia.com/object/fast_shadow_volumes.html Fast, Practical, and Robust Shadow Volumes (NVidia)]
*[http://developer.nvidia.com/object/robust_shadow_volumes.html Practical and Robust Shadow Volumes (NVidia)]

Volumetrische Stencilschatten

2004-10-21T08:39:58Z

Mars: /* Zukunft */

== Konzept ==

Bei dieser Technik nutzt man den (seit ~2000 von fast allen Grafikkarten angebotenen) [[Schablonenpuffer|Stencilpuffer]] um dort die im Schatten liegenden Bereiche der Szene abzulegen. Später werden dann mit einem passenden Stencilvergleich die Schatten dargestellt.

Dazu wird für jedes Objekt ausgehend von seiner [[Silhouette]] (es entsteht immer dort eine Silhouetten-Kante, wo ein dem Licht abgewandtes und ein dem Licht zugewandtes Dreieck sich treffen) durch extrudieren ihrer Eckpunkte (im Idealfall in die Unendlichkeit, am Einfachsten lösbar über die W-Koordinate) ein Volumen erstellt das den Bereich des Objektes darstellt den es schattiert.

== Geschichte ==

1977 - Erfunden von Crow : Software-Renderer<br>
1984 - Brotman und Badler : Software-Tiefenpuffer und viele Punktlichter für weiche Schatten<br>
1985 - Fuchs und Co. : Erste Hardwareimplementation und Volumentechnik statt Raytracing<br>
1986 - Bergeron : Behandlung offener Modelle, Nicht-Planare Polygone<br>
1988 - Forunier & Fussell : Theorie zum Zählen der Schattenvolumen in einem Puffer<br>
1991 - Heidmann : Implementation in IRIS GL über Stencilpuffer<br>
1992 - Akeley & Foren : Der für IRIS GL entwickelte Stencilpuffer wird patentiert und in OpenGL 1.0 implementiert<br>
1996 - Deifenbach : Multi-Pass Shattenvolumen<br>
1999 - Dietrich : ZFail-Methode vorgestellt<br>
1999 - Kilgard : Invertierter Algorithmus für planare Ausschnitte<br>
2000 - Carmack : Erste detaillierte Diskussion zur Gleichheit von ZPass und ZFail<br>
2001 - Kilgard : ZPass mit Capping vorgestellt<br>
2002 - Everitt & Kilgard : Mehrere Techniken für eine robuste Lösung<br>

(Teilweise entnommen aus dem Dokument ''"Optimized Stencil
Shadow Volumes"'' von Cass Everitt & Mark J. Kilgard)

== Zukunft ==

Zumindest für die in der Spieleindustrie treibenden ''"Kraft"'' in Sachen OpenGL, John Carmack ([http://www.idsoftware.com/ id Software]), gehört die Zukunft klar den Schatten Volumen. Zumal die zwei frappierendsten aktuellen Nachteile (Ermitteln der [[Silhouette]] und Extrudieren eben dieser für das Volumen, sowie die hohe Anforderung an die Füllrate) dank schneller werdender Grafikkarten und CPUs immer weiter in den Hintergrund rücken. So kann man inzwischen dank [[Vertex Programm|Vertex Programmen]] alle Eckpunkte der Silhouette einfach auf der GPU extruhieren.
Auch die Tatsache dass diese Technik nur sehr scharfkantige Schatten wirf lässt sich via [[Jittering]] (mehrfachem, versetzem Rendern der Schattenvolumen mit unterschiedlicher Helligkeit) spätestens dann realisieren wenn Grafikkarten genug Füllrate anbieten, und eben genau diese steigt von Generation zu Generation recht stetig an.

== Grundlegende Funktionsweise ==

Um eine Szene mit volumetrischen Stencilschatten zu rendern sieht der Renderablauf im Normalfall wie folgt aus :
# Szene nur mit ambientem Lichtanteil in den Farbpuffer rendern
# [[Silhouette]] zwischen Objekten und Lichtquellen errechnen
# Silhouetten extruhieren (und je nach Technik noch Deckel für das Volumen erstellen)
# Stenciltest aktivieren und erstellte Schattenvolumen dort hinein rendern (mit unterschiedlichen Stenciloperationen für Vorder- und Rückseite)
# Szene mit diffusem Lichtanteil rendern (da Schatten im Stencilpuffer liegen wird die Szene jetzt schattiert)

== Methoden ==

=== zPass ===
Bei dieser (zuerst entwickelten) Methode inkrementieren nach vorne zeigende Dreiecke den Wert im Stencilpuffer, wenn diese den Test passieren; und nach hinten zeigende Dreiecke dekrementieren diesen Wert.
Nachteil dieser Methode ist jedoch die Tatsache das es zu Fehlern beim Zählen der Schattenwerte im Stencilpuffer kommt, sobald der Betrachter in ein Schattenvolumen eintritt. Um dies zu lösen gibt es jedoch die zFail-Methode.

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_KEEP, GL_INCR_WRAP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_KEEP, GL_DECR_WRAP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

=== zFail ===
Die von John Carmack im Jahre 2000 "erfundene" Methode zählt die Schattenfragmente etwas anders : Für nach vorne zeigende Dreiecke wird der Wert im Stencilpuffer inkrementiert, wenn diese den Test '''nicht''' bestehen (daher der Name); und dekrementiert für nach hinten zeigende Dreiecke. Weiterhin muss man bei dieser Methode (damit die Fragmente korrekt gezählt werden) ein geschlossenes Schattenvolumen erstellen, das neben der extruhierten (meist in die Unendlichkeit) Silhouette des schattenwerfenden Objektes sowohl einen vorderen Deckel (''Front-Cap'') als auch einen abschliessenden (''Back-Cap'') hat.
Der große Vorteil (auf den man in den seltensten Fällen verzichten) kann ist hier die Tatsache das zFail auch dann korrekte Schatten darstellt wenn der Betrachter in das Volumen eindringt. Nachteilig ist aber das man bedingt durch Deckel und Boden für die Schattenvolumen mehr Berechnungen und Pixeltests durchführen muss. Im Normalfall findet man deshalb eine Kombination aus beiden Techniken in einer Anwendung (zPass generell, wenn Betrachter in einem Volumen ist, dann zFail).

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_INCR_WRAP, GL_KEEP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_DECR_WRAP, GL_KEEP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

== Vor- und Nachteile ==

'''Positiv :'''
* Sehr hohe Details (kein [[Aliasing]])
* Selbstschattierung für schattenwerfende Objekte

'''Negativ :'''
* Benötigt Kenntnis über die zugrundeliegende Geometrie (für die Schattensilhouette)
* [[Silhouette]] muss auf der CPU errechnet werden (->CPU-Lastig)
* Verbraucht sehr viel Füllrate

== Beispiel ==
[[Bild:shadowvolume_scene.jpg]]<br>
Zu sehen ist hier eine Szene die mittels volumetrischer Stencilschatten schattiert wurde. Die roten Umrandungen stellen die Silhouette der Szene ggü. der Lichtquelle dar, während die blauen Linien die Schattenvolumen darstellen (extruhiert in die Unendlichkeit).

== Ressourcen ==
*[http://www.gamasutra.com/features/20021011/lengyel_01.htm "The Mechanics of Robust Stencil Shadows - Eric Lengyel"]
*[http://www.gamedev.net/reference/articles/article1873.asp "The Theory of Stencil Shadow Volumes - Hun Yen Kwoon"]
*[http://developer.nvidia.com/attach/6832 "John Carmack zum Thema Shadow Volumes"]
*[http://developer.nvidia.com/object/fast_shadow_volumes.html Fast, Practical, and Robust Shadow Volumes (NVidia)]
*[http://developer.nvidia.com/object/robust_shadow_volumes.html Practical and Robust Shadow Volumes (NVidia)]

Volumetrische Stencilschatten

2004-10-21T08:39:23Z

Mars: /* Konzept */

== Konzept ==

Bei dieser Technik nutzt man den (seit ~2000 von fast allen Grafikkarten angebotenen) [[Schablonenpuffer|Stencilpuffer]] um dort die im Schatten liegenden Bereiche der Szene abzulegen. Später werden dann mit einem passenden Stencilvergleich die Schatten dargestellt.

Dazu wird für jedes Objekt ausgehend von seiner [[Silhouette]] (es entsteht immer dort eine Silhouetten-Kante, wo ein dem Licht abgewandtes und ein dem Licht zugewandtes Dreieck sich treffen) durch extrudieren ihrer Eckpunkte (im Idealfall in die Unendlichkeit, am Einfachsten lösbar über die W-Koordinate) ein Volumen erstellt das den Bereich des Objektes darstellt den es schattiert.

== Geschichte ==

1977 - Erfunden von Crow : Software-Renderer<br>
1984 - Brotman und Badler : Software-Tiefenpuffer und viele Punktlichter für weiche Schatten<br>
1985 - Fuchs und Co. : Erste Hardwareimplementation und Volumentechnik statt Raytracing<br>
1986 - Bergeron : Behandlung offener Modelle, Nicht-Planare Polygone<br>
1988 - Forunier & Fussell : Theorie zum Zählen der Schattenvolumen in einem Puffer<br>
1991 - Heidmann : Implementation in IRIS GL über Stencilpuffer<br>
1992 - Akeley & Foren : Der für IRIS GL entwickelte Stencilpuffer wird patentiert und in OpenGL 1.0 implementiert<br>
1996 - Deifenbach : Multi-Pass Shattenvolumen<br>
1999 - Dietrich : ZFail-Methode vorgestellt<br>
1999 - Kilgard : Invertierter Algorithmus für planare Ausschnitte<br>
2000 - Carmack : Erste detaillierte Diskussion zur Gleichheit von ZPass und ZFail<br>
2001 - Kilgard : ZPass mit Capping vorgestellt<br>
2002 - Everitt & Kilgard : Mehrere Techniken für eine robuste Lösung<br>

(Teilweise entnommen aus dem Dokument ''"Optimized Stencil
Shadow Volumes"'' von Cass Everitt & Mark J. Kilgard)

== Zukunft ==

Zumindest für die in der Spieleindustrie treibenden ''"Kraft"'' in Sachen OpenGL, John Carmack ([http://www.idsoftware.com/ id Software]), gehört die Zukunft klar den Schatten Volumen. Zumal die zwei frapierendsten aktuellen Nachteile (Ermitteln der [[Silhouette]] und Extruhieren eben dieser für das Volumen, sowie die hohe Anforderung an die Füllrate) dank schneller werdender Grafikkarten und CPUs immer weiter in den Hintergrund rücken. So kann man inzwischen dank [[Vertex Programm|Vertex Programmen]] alle Eckpunkte der Silhouette einfach auf der GPU extruhieren.
Auch die Tatsache dass diese Technik nur sehr scharfkantige Schatten wirf lässt sich via [[Jittering]] (mehrfachem, versetzem Rendern der Schattenvolumen mit unterschiedlicher Helligkeit) spätestens dann realisieren wenn Grafikkarten genug Füllrate anbieten, und eben genau diese steigt von Generation zu Generation recht stetig an.

== Grundlegende Funktionsweise ==

Um eine Szene mit volumetrischen Stencilschatten zu rendern sieht der Renderablauf im Normalfall wie folgt aus :
# Szene nur mit ambientem Lichtanteil in den Farbpuffer rendern
# [[Silhouette]] zwischen Objekten und Lichtquellen errechnen
# Silhouetten extruhieren (und je nach Technik noch Deckel für das Volumen erstellen)
# Stenciltest aktivieren und erstellte Schattenvolumen dort hinein rendern (mit unterschiedlichen Stenciloperationen für Vorder- und Rückseite)
# Szene mit diffusem Lichtanteil rendern (da Schatten im Stencilpuffer liegen wird die Szene jetzt schattiert)

== Methoden ==

=== zPass ===
Bei dieser (zuerst entwickelten) Methode inkrementieren nach vorne zeigende Dreiecke den Wert im Stencilpuffer, wenn diese den Test passieren; und nach hinten zeigende Dreiecke dekrementieren diesen Wert.
Nachteil dieser Methode ist jedoch die Tatsache das es zu Fehlern beim Zählen der Schattenwerte im Stencilpuffer kommt, sobald der Betrachter in ein Schattenvolumen eintritt. Um dies zu lösen gibt es jedoch die zFail-Methode.

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_KEEP, GL_INCR_WRAP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_KEEP, GL_DECR_WRAP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

=== zFail ===
Die von John Carmack im Jahre 2000 "erfundene" Methode zählt die Schattenfragmente etwas anders : Für nach vorne zeigende Dreiecke wird der Wert im Stencilpuffer inkrementiert, wenn diese den Test '''nicht''' bestehen (daher der Name); und dekrementiert für nach hinten zeigende Dreiecke. Weiterhin muss man bei dieser Methode (damit die Fragmente korrekt gezählt werden) ein geschlossenes Schattenvolumen erstellen, das neben der extruhierten (meist in die Unendlichkeit) Silhouette des schattenwerfenden Objektes sowohl einen vorderen Deckel (''Front-Cap'') als auch einen abschliessenden (''Back-Cap'') hat.
Der große Vorteil (auf den man in den seltensten Fällen verzichten) kann ist hier die Tatsache das zFail auch dann korrekte Schatten darstellt wenn der Betrachter in das Volumen eindringt. Nachteilig ist aber das man bedingt durch Deckel und Boden für die Schattenvolumen mehr Berechnungen und Pixeltests durchführen muss. Im Normalfall findet man deshalb eine Kombination aus beiden Techniken in einer Anwendung (zPass generell, wenn Betrachter in einem Volumen ist, dann zFail).

<table border="0">
<tr>
<td><code><pre>
glCullFace(GL_FRONT);
glStencilOp(GL_KEEP, GL_INCR_WRAP, GL_KEEP);
RenderShadowVolumes;

glCullFace(GL_BACK);
glStencilOp(GL_KEEP, GL_DECR_WRAP, GL_KEEP);
RenderShadowVolumes;</pre></code>
</td>
</tr>
</table>

== Vor- und Nachteile ==

'''Positiv :'''
* Sehr hohe Details (kein [[Aliasing]])
* Selbstschattierung für schattenwerfende Objekte

'''Negativ :'''
* Benötigt Kenntnis über die zugrundeliegende Geometrie (für die Schattensilhouette)
* [[Silhouette]] muss auf der CPU errechnet werden (->CPU-Lastig)
* Verbraucht sehr viel Füllrate

== Beispiel ==
[[Bild:shadowvolume_scene.jpg]]<br>
Zu sehen ist hier eine Szene die mittels volumetrischer Stencilschatten schattiert wurde. Die roten Umrandungen stellen die Silhouette der Szene ggü. der Lichtquelle dar, während die blauen Linien die Schattenvolumen darstellen (extruhiert in die Unendlichkeit).

== Ressourcen ==
*[http://www.gamasutra.com/features/20021011/lengyel_01.htm "The Mechanics of Robust Stencil Shadows - Eric Lengyel"]
*[http://www.gamedev.net/reference/articles/article1873.asp "The Theory of Stencil Shadow Volumes - Hun Yen Kwoon"]
*[http://developer.nvidia.com/attach/6832 "John Carmack zum Thema Shadow Volumes"]
*[http://developer.nvidia.com/object/fast_shadow_volumes.html Fast, Practical, and Robust Shadow Volumes (NVidia)]
*[http://developer.nvidia.com/object/robust_shadow_volumes.html Practical and Robust Shadow Volumes (NVidia)]

Polygon

2004-10-04T19:33:17Z

Mars:

Polygon ist das griechische Wort für "Vieleck", gemeint ist damit ein Anzahl von Punkten, die durch einen Linienzug geschlossen miteinander verbunden sind. In der Computergrafik sind hauptsächlich gefüllte Polygonzüge von Bedeutung, das heißt, dass nicht nur die Eckpunkte mit Linien verbunden werden, sondern auch der Raum zwischen den Kanten ausgefüllt wird - entweder mit einer Farbe, Farben, die zwischen den Eckpunkten interpoliert werden, Texturen, deren Koordinaten zwischen den Eckpunkten interpoliert werden, oder seit Neuestem mittels Shaderprogrammen, bei denen der Programmierer ganz genau sagen kann, was nun mit jedem Fragment eines Polygons geschehen soll.

Beim aktuellen Stand der Computergrafik werden Polygone mit mehr als drei Eckpunkten typischerweise vor dem Rendern automatisch in Dreiecke zerlegt, weswegen es auch in OpenGL zumeist am günstigsten ist, direkt mit Dreiecken zu arbeiten.

Die Beschränkung auf Dreiecke ergibt sich übrigens aus der Rasterisierung, da drei Punkte im dreidimensionalen Raum immer in einer Ebene liegen, und ein Dreieck auch immer konvex sein muss: bei konkaven Vielecken könnte es geschehen, dass Scanlinerenderer, wie es eigentlich alle Grafikkarten zur Zeit sind, für eine vertikale Position mehr als eine horizontale Linie rendern müssen, was einen erheblichen Mehraufwand an Rechenzeit benötigt.

Polygon

2004-10-04T19:32:55Z

Mars:

Polygon ist das griechische Wort für "Vieleck", gemeint ist damit ein Anzahl von Punkten, die durch einen Linienzug geschlossen miteinander verbunden sind. In der Computergrafik sind hauptsächlich gefüllte Polygonzüge von Bedeutung, das heißt, dass nicht nur die Eckpunkte mit Linien verbunden werden, sondern auch der Raum zwischen Kanten den Kanten ausgefüllt wird - entweder mit einer Farbe, Farben, die zwischen den Eckpunkten interpoliert werden, Texturen, deren Koordinaten zwischen den Eckpunkten interpoliert werden, oder seit Neuestem mittels Shaderprogrammen, bei denen der Programmierer ganz genau sagen kann, was nun mit jedem Fragment eines Polygons geschehen soll.

Beim aktuellen Stand der Computergrafik werden Polygone mit mehr als drei Eckpunkten typischerweise vor dem Rendern automatisch in Dreiecke zerlegt, weswegen es auch in OpenGL zumeist am günstigsten ist, direkt mit Dreiecken zu arbeiten.

Die Beschränkung auf Dreiecke ergibt sich übrigens aus der Rasterisierung, da drei Punkte im dreidimensionalen Raum immer in einer Ebene liegen, und ein Dreieck auch immer konvex sein muss: bei konkaven Vielecken könnte es geschehen, dass Scanlinerenderer, wie es eigentlich alle Grafikkarten zur Zeit sind, für eine vertikale Position mehr als eine horizontale Linie rendern müssen, was einen erheblichen Mehraufwand an Rechenzeit benötigt.

Polygon

2004-10-04T19:25:59Z

Mars:

Polygon ist das griechische Wort für "Vieleck", gemeint ist damit ein Anzahl von Punkten, die durch einen Linienzug geschlossen miteinander verbunden sind. Beim aktuellen Stand der Computergrafik werden Polygone mit mehr als drei Eckpunkten typischerweise vor dem Rendern automatisch in Dreiecke zerlegt, weswegen es auch in OpenGL zumeist am günstigsten ist, direkt mit Dreiecken zu arbeiten.

Die Beschränkung auf Dreiecke ergibt sich übrigens aus der Rasterisierung, da drei Punkte im dreidimensionalen Raum immer in einer Ebene liegen, und ein Dreieck auch immer konvex sein muss: bei konkaven Vielecken könnte es geschehen, dass Scanlinerenderer, wie es eigentlich alle Grafikkarten zur Zeit sind, für eine vertikale Position mehr als eine horizontale Linie rendern müssen, was einen erheblichen Mehraufwand an Rechenzeit benötigt.

glLineStipple

2004-09-08T13:10:55Z

Mars: /* Delphi-Spezifikation */

{{Unvollständig}}
= glLineStipple =

<br>
== Name ==
'''glLineStipple''' - Definiert mit welchem Muster eine Linie getüpfelt wird.

<br>
== Delphi-Spezifikation ==

procedure '''glLineStipple'''(''factor'' : GLint; ''pattern'' : GLushort);

<br>

== Parameter ==

{| border="1" rules="all"
! ''factor''
| Spezifiziert einen Multiplikator für jedes Bit im Tüpfelmuster einer Linie. Wenn der Faktor beispielsweise 3 ist, wird jedes Bit im Muster drei Mal genutzt, bevor das nächste Bit im Muster verwendet wird. Der factor ist festgesetzt zwischen dem Bereich von 1 bis 256 und der Standardwert ist 1'''. If factor is 3, for example, each bit in the pattern is used three times before the next bit in the pattern is used. factor is clamped to the range[1,256] and defaults to 1.'''
|-
! ''pattern''
| '''Specifies a 16-bit integer whose bit pattern determines which fragments of a line will be drawn when the line is rasterized. Bit zero is used first; the default pattern is all 1's.'''
|}

<br>

== Beschreibung ==
'''Line stippling masks out certain fragments produced by rasterization; those fragments will not be drawn. The masking is achieved by using three parameters: the 16-bit line stipple pattern pattern, the repeat count factor, and an integer stipple counter s.

Counter s is reset to zero whenever glBegin is called, and before each line segment of a glBegin(GL_LINES)/glEnd() sequence is generated. It is incremented after each fragment of a unit width aliased line segment is generated, or after each i fragments of an i width line segment are generated. The i fragments associated with count s are masked out if

pattern bit (s / factor) mod 16

is zero, otherwise these fragments are sent to the frame buffer. Bit zero of pattern is the least significant bit.

Antialiased lines are treated as a sequence of 1xwidth rectangles for purposes of stippling. Whether rectangle s is rasterized or not depends on the fragment rule described for aliased lines, counting rectangles rather than groups of fragments.'''

Um Linien tüpfeln zu lassen, benutzt [[glEnable]] und [[glDisable]] mit dem Token GL_LINE_STIPPLE. Wenn dies aktiviert ist, werden die Linien mit dem Muster getüpfelt, dass oben beschrieben wurde. Wenn es deaktiviert ist, werden alle Muster so behandelt als seien sie auf 1 gesetzt. Standardgemäß ist das Tüpfeln von Linien deaktiviert.

<br>

== Fehlermeldungen ==
GL_INVALID_OPERATION wird generiert wenn glRect innerhalb eines glBegin-glEnd Blocks aufgerufen wird.

<br>
== Zugehörige Wertrückgaben ==
[[glGet]] mit Token [[glGet#GL_MEIN_TOKEN|GL_MEIN_TOKEN]]
[[glGet]] mit Token [[glGet#GL_LINE_STIPPLE_PATTERN]]
[[glGet]] mit Token [[glGet#GL_LINE_STIPPLE_REPEAT]]
[[glIsEnabled]] mit Token [[glIsEnabled#GL_LINE_STIPPLE]]
<br>

== Siehe auch ==
[[glLineWidth]], [[glPolygonStipple]]