Shader - Versionsgeschichte

Glawesome: /* Beispiel: Meshanimation */

2014-02-20T17:07:59Z

‎Beispiel: Meshanimation

Glawesome: /* Beispiel: Meshanimation */

2014-02-20T14:44:20Z

‎Beispiel: Meshanimation

Igel457: /* Beispiel: General-Purpose Computation */

2010-01-16T19:50:49Z

‎Beispiel: General-Purpose Computation

Coolcat: /* Transform-Feedback */

2010-01-10T13:23:08Z

‎Transform-Feedback

Coolcat: /* Fragmentshader */

2010-01-10T13:21:58Z

‎Fragmentshader

Coolcat: /* Konzept */

2010-01-04T13:32:31Z

‎Konzept

Coolcat: /* Transform-Feedback (auch Stream-Out) */ zwei neue Beispiele + Bildchen

2009-04-02T15:25:08Z

‎Transform-Feedback (auch Stream-Out): zwei neue Beispiele + Bildchen

Coolcat: /* Beispiel: Per-Pixel-Lighting */ Typo

2009-02-22T17:31:12Z

‎Beispiel: Per-Pixel-Lighting: Typo

Flash: /* Beispiel: Per-Pixel-Lighting */

2009-02-22T17:02:24Z

‎Beispiel: Per-Pixel-Lighting

Coolcat: /* Wie geht es nun weiter? */ Shadersammlung

2009-02-22T14:03:55Z

‎Wie geht es nun weiter?: Shadersammlung

@@ Zeile 34: / Zeile 34: @@
 ====Beispiel: Meshanimation====
-Will man ein Mesh animieren, um z.B. einen menschlichen Charakter darzustellen, reicht es nicht aus, alle Vertices des Meshes mit der selben Matrix zu transformieren. In der Regel beschreibt man dazu das Skelett des Charakters mithilfe vieler Matrizen. Zudem werden viele Vertices nicht nur von einer dieser Matrizen beeinflusst. Die gewichtete Transformation mit mehreren Matrizen für viele Vertices auszuführen fordert die CPU sehr - zumal die berechneten Vertices zum Rendern erst noch an die Grafikkarte übertragen werden müssten. Das alles kann man sich sparen, wenn man die Berechnungen direkt im Vertexshader durchführt. Eine Implementierung, die genau die tut, findet sich im [[Tutorial Charakteranimation]].
+Will man ein Mesh animieren, um z.B. einen menschlichen Charakter darzustellen, reicht es nicht aus, alle Vertices des Meshes mit der selben Matrix zu transformieren. In der Regel beschreibt man dazu das Skelett des Charakters mithilfe vieler Matrizen. Zudem werden die Vertices meist nicht nur von einer dieser Matrizen beeinflusst. Die gewichtete Transformation mit mehreren Matrizen für viele Vertices auszuführen fordert die CPU sehr - zumal die berechneten Vertices zum Rendern erst noch an die Grafikkarte übertragen werden müssten. Das alles kann man sich sparen, wenn man die Berechnungen direkt im Vertexshader durchführt. Eine Implementierung, die genau dies tut, befindet sich im [[Tutorial Charakteranimation]].
 == Fragmentshader ==

@@ Zeile 34: / Zeile 34: @@
 ====Beispiel: Meshanimation====
-Will man ein Meshanimieren muss man normalerweise jeden Teil des Meshes einzelnen rendern. Im Vertexshader kann man jeden Teil des Meshes einzeln transformieren oder auch zwischen den Teilen interpolieren. Diese Methode erfordert natürlich eine Markierung der einzelnen Meshteile. Hier eignet sich beispielsweise ein Farbkanal der Vertexfarbe.
+Will man ein Mesh animieren, um z.B. einen menschlichen Charakter darzustellen, reicht es nicht aus, alle Vertices des Meshes mit der selben Matrix zu transformieren. In der Regel beschreibt man dazu das Skelett des Charakters mithilfe vieler Matrizen. Zudem werden viele Vertices nicht nur von einer dieser Matrizen beeinflusst. Die gewichtete Transformation mit mehreren Matrizen für viele Vertices auszuführen fordert die CPU sehr - zumal die berechneten Vertices zum Rendern erst noch an die Grafikkarte übertragen werden müssten. Das alles kann man sich sparen, wenn man die Berechnungen direkt im Vertexshader durchführt. Eine Implementierung, die genau die tut, findet sich im [[Tutorial Charakteranimation]].
 == Fragmentshader ==

@@ Zeile 111: / Zeile 111: @@
 ==== Beispiel: General-Purpose Computation ====
-Transform-Feedback ist ein wichtiges Feature, wenn man auf der Grafikkarte beliebige Berechnungen durchführen will. Zwar kann man nicht alles effizient auf der GPU implementieren, aber die Anwendung muss auch nicht unbedingt mit 3D-Grafik zusammenhängen. Der Vorteil einer Grafikkarte ist das sie hoch parallel arbeitet, dies kann viele Algorithmen extrem beschleunigen. Diverse Beispiele gibt es auf [http://www.gpgpu.org/ gpgpu.org].
+Transform-Feedback ist ein wichtiges Feature, wenn man auf der Grafikkarte beliebige Berechnungen durchführen will. Zwar kann man nicht alles effizient auf der GPU implementieren, aber die Anwendung muss auch nicht unbedingt mit 3D-Grafik zusammenhängen. Der Vorteil einer Grafikkarte ist, dass sie hoch parallel arbeitet, dies kann viele Algorithmen extrem beschleunigen. Diverse Beispiele gibt es auf [http://www.gpgpu.org/ gpgpu.org].
 == Wie geht es nun weiter? ==

@@ Zeile 94: / Zeile 94: @@
 Der Geometryshader stellt ein neues Vertexattribut ''gl_Layer'' zur Verfügung. Dieses erlaubt es zu bestimmen in welchen Framebuffer ein Dreieck gerendert werden soll. Dies kann man nun benutzen um in 6 Framebuffer gleichzeitig zu rendern. Der Geometryshader arbeitet dabei als Geometrie-Duplizierer. Da wir volle Kontrolle über die erzeugte Geometrie haben, können wir für jeden Framebuffer eine andere ModelViewProjection-Matrix zur Transformation verwenden. Man muss natürlich beachten, dass in diesem Fall das [[Frustum_Culling|Frustum-Culling]] zu einem großen Teil im Shader stattfinden muss. Aber, letztendlich kann man so in einem einzigen Durchgang alle 6 Seiten einer [[Environment_Mapping|Environment-Cubemap]] rendern!
-== Transform-Feedback (auch Stream-Out) ==
+== Transform-Feedback ==
-Auch Transform-Feedback ist ein Feature von Shader Model 4.0 und somit nur auf neueren Grafikkarten verfügbar. Transform-Feedback gehört ebenfalls zu den fortgeschrittenen Dingen in der Computergrafik und sei daher für Anfänger zunächst nicht zu empfehlen.
+Auch [[Transform-Feedback]] ist ein Feature von Shader Model 4.0 und somit nur auf neueren Grafikkarten verfügbar. Transform-Feedback gehört ebenfalls zu den fortgeschrittenen Dingen in der Computergrafik und sei daher für Anfänger zunächst nicht zu empfehlen. In der [http://de.wikipedia.org/wiki/DirectX DirectX]-Welt ist Transform-Feedback unter der Bezeichnung ''Stream-Out'' bekannt.
 Bei diesem Feature handelt es sich ''nicht'' um einen Shader im eigentlichen Sinne. Jedoch arbeitet Transform-Feedback eng mit dem Vertexshader bzw. dem Geometryshader zusammen. Diese Funktion ermöglicht es einzelne oder alle Output-Variablen aus dem Shader abzugreifen und in ein (oder mehrere) Buffer-Objekte zu schreiben. Buffer-Objekte sind einfach nur Speicherbereiche die sich flexibel als Textur, als Vertexbuffer oder auch Indexbuffer interpretieren lassen. Immer so wie man es gerade braucht.

@@ Zeile 36: / Zeile 36: @@
 Will man ein Meshanimieren muss man normalerweise jeden Teil des Meshes einzelnen rendern. Im Vertexshader kann man jeden Teil des Meshes einzeln transformieren oder auch zwischen den Teilen interpolieren. Diese Methode erfordert natürlich eine Markierung der einzelnen Meshteile. Hier eignet sich beispielsweise ein Farbkanal der Vertexfarbe.
-== Fragmentshader (auch Pixelshader) ==
+== Fragmentshader ==
-Im Fragmentshader dürfen wir die Berechnung des Farbwertes eines Fragments (Pixel) selbst übernehmen. Angenommen wir verarbeiten Dreiecke, dann erhalten wir die interpolierten Vertexattribute als Shader-Input. Als Output schreiben wir in der Regel in gl_FragColor, der Farbe, die in den Framebuffer geschrieben werden soll.
+Im Fragmentshader dürfen wir die Berechnung des Farbwertes eines Fragments (Pixel) selbst übernehmen. Angenommen wir verarbeiten Dreiecke, dann erhalten wir die interpolierten Vertexattribute als Shader-Input. Als Output schreiben wir in der Regel in gl_FragColor, der Farbe, die in den Framebuffer geschrieben werden soll. In der [http://de.wikipedia.org/wiki/DirectX DirectX]-Welt ist der Fragmentshader unter der Bezeichnung ''Pixelshader'' bekannt.
 Ich denke alleine die Anzahl der folgenden Beispiele zeigt das hier so einiges möglich ist.

@@ Zeile 1: / Zeile 1: @@
 == Konzept ==
-Die traditionelle [[Feste Funktionspipeline|Funktionspipeline]] der [[OpenGL]] ist eine feste Pipeline, auf die man nur beschränkt durch Statechanges Einfluß nehmen kann. Man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrer Attribute können variiert werden. Neuere Algorithmen erfordern aber eine viel höhere Flexibiltät.
+Die traditionelle [[Feste Funktionspipeline|Funktionspipeline]] der [[OpenGL]] ist eine feste Pipeline, auf die man nur beschränkt durch Statechanges Einfluss nehmen kann. Man hat also an sehr vielen Stellen starre Vorgaben die nur minimal anpassbar sind. So sind z.B. Farbberechnungen oder die Beleuchtung fest definiert und nur wenige ihrer Attribute können variiert werden. Neuere Algorithmen erfordern aber eine viel höhere Flexibilität.
 Einzelne Komponenten der Pipeline können nun aber durch kleine Programme, sog. ''Shader'' ersetzt werden. Diese Shader werden in der C ähnlichen Hochsprache GLSL geschrieben. Es gibt Variablen, if-Bedingungen, Schleifen, beliebige Texturzugriffe, ... vom Prinzip ist auf aktuellen Grafikchips fast alles möglich was auch auf auf einer CPU geht. Der wesentliche Unterschied beim Programmieren der GPU ist jedoch, dass die Programme parallel laufen. Die aktuelle CPUs haben bis zu 4 parallel arbeitende Kerne. Demnächst wird es wohl auch CPUs mit 8 Kernen geben. Im Vergleich dazu hat beispielsweise die GeForce GTX 295 zwei GPUs mit jeweils 240 Kernen [[#Quellen|[1]]]. Diese Kerne können jedoch, anderes wie bei der CPU, untereinander nicht kommunizieren. Daher holen Grafikkarten ihre enorme Geschwindigkeit. Es ist also schwierig bis unmöglich einen sequenziellen Algorithmus effizient auf der GPU zu implementieren.
@@ Zeile 22: / Zeile 22: @@
 [[Bild:Pipeline.png]]
 Der Scissor- und Stencil-Test ist im Bild nach dem Pixelshader angeordnet. Auf den meisten Diagrammen im Internet ist dies ebenfalls so, daher haben wir uns entschieden diese hier genauso zu machen. Höchstwahrscheinlich ist der Scissor-Test aber direkt im Rasterizer implementiert und auch der Stencil-Test kommt vermutlich aus Performancegründen vor dem Pixelshader. Möglicherweise ist dies auch auf verschiedenen Chips unterschiedlich implementiert. Für das Verständnis der Shader sind diese Implementierungsdetails jedoch unerheblich.
 == Vertexshader ==

@@ Zeile 102: / Zeile 102: @@
 Ein weiterer Vorteil ist, dass man die Renderpipeline direkt nach dem Transform-Feedback-Schritt (also noch vor dem Cliping) auf Wunsch auch komplett abschalten kann. Insbesondere der Pixelshader wird dann gar nicht erst ausgeführt und auch nichts in den Framebuffer geschrieben.
 ==== Beispiel: Meshanimation ====
 Für diverse Algorithmen muss man die Szene mehrfach, zum Teil auch aus verschiedenen Perspektiven rendern. Natürlich kann man ein komplex animiertes Mesh jedes mal komplett neu berechnen. Man könnte aber auch beim ersten Durchgang die Vertexdaten abgreifen und in einen temporären Buffer schreiben. Beim nächsten Pass kann man einfach diesen Buffer als Vertexbuffer interpretieren und rendern.
 == Wie geht es nun weiter? ==

@@ Zeile 43: / Zeile 43: @@
 ==== Beispiel: Per-Pixel-Lighting ====
 [[Bild:perpixellighting.jpg|thumb|256px|Per-Vertex-Lighting vs. Per-Pixel-Lighting]]
-Die klassische Anwendung des Fragmentshader ist sicherlich das [[Tutorial_glsl2#Per-Pixel-Lighting|Per-Pixel-Lighting]]. Die feste Funktionspipeline erlaubt nur pro Vertex eine Beleuchtungsfarbe zu berechnen. Über die Fläche des Dreiecks wird diese Farbe dann interpoliert. Bei sehr hoch aufgelößten (viele kleine Dreiecke) [[Mesh]]es mag das funktionieren. Jedoch bei niedriger Auflösung sieht dies ziemlich grauenhaft aus, insbesondere da Specular-Highlights komplett verloren gehen oder verstärkt werden können. Im Bild rechts sieht man eine niedrig aufgelößte Kugel und wie die per-Vertex-Beleuchtung hier unnatürlich wirkt.
+Die klassische Anwendung des Fragmentshader ist sicherlich das [[Tutorial_glsl2#Per-Pixel-Lighting|Per-Pixel-Lighting]]. Die feste Funktionspipeline erlaubt nur pro Vertex eine Beleuchtungsfarbe zu berechnen. Über die Fläche des Dreiecks wird diese Farbe dann interpoliert. Bei sehr hoch aufgelösten (viele kleine Dreiecke) [[Mesh]]es mag das funktionieren. Jedoch bei niedriger Auflösung sieht dies ziemlich grauenhaft aus, insbesondere da Specular-Highlights komplett verloren gehen oder verstärkt werden können. Im Bild rechts sieht man eine niedrig aufgelöste Kugel und wie die per-Vertex-Beleuchtung hier unnatürlich wirkt.
 Beim Per-Pixel-Lighting übergibt man vom Vertexshader zusätzliche die Normale des Vertex. Im Fragmentshader erhält man dann also die interpolierte Normale aller drei Vertices. Nun führt man das Phong-Modell das sonst im Vertexshader (bzw. in der festen Pipeline) ausgewertet würde einfach im Fragmentshader auf Grundlage dieser Normale durch. Man erhält also für jeden Pixel die korrekte Beleuchtung. Der hier beschriebene Shader ist in der [[Shadersammlung]] verfügbar.

@@ Zeile 110: / Zeile 110: @@
 * [[Tutorial_glsl|Tutorial GLSL]]: Einstieg in die Shader-Programmierung mit GLSL
 * [[Tutorial_glsl2|Tutorial GLSL, Anhang]]
 * [[Shader_(historisch)|Nutzung von Shadern auf alter Grafikhardware]]
 * OpenGL-Extensions