Benutzer:Coolcat: Unterschied zwischen den Versionen

Aus DGL Wiki
Wechseln zu: Navigation, Suche
 
(36 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
= Komplettüberarbeitung des [[Shader]]-Artikels =
+
* Realname: Martin Weusten
 
+
* Studium (abgeschlossen):
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. Einzelne Komponenten der Pipeline können durch kleine Programme, sog. ''Shader'' ersetzt werden. Bevor man sich mit Shadern beschäftigt hat sollte man die Grundlagen von OpenGL und den Aufbau der Renderingspipeline vollständig verstanden haben.
+
** Diplom Informatiker
 
+
** Vertiefungsrichtung: Computergrafik
Es gibt verschiedene Shader-Versionen, das sogenannte ''ShaderModel'', kurz SM. Man sollte immer darauf achten welches SM die eigene Grafikkarte unterstützt. Hier ein paar grobe Richtwerte:
+
** RWTH Aachen University
 
+
* Platform: Linux, C++
{|{{Prettytable_B1}}
+
* Web: [http://martin-weusten.de martin-weusten.de]
!   Hersteller  !! Chip !! ShaderModel
+
* Jabber: http://jabber.rwth-aachen.de/w/images/c/ca/Jid-martin.weusten.jpg http://jabber.rwth-aachen.de/w/images/b/ba/Modrewrite-martin.weusten.gif
|-
+
::(das ist '''keine''' EMailadresse, sondern eine [http://jabber.rwth-aachen.de/wiki/Jabber_-_Einfach_erkl%C3%A4rt! Jabberadresse!])
| ATI || Radeon 9800 Pro || 2.0
 
|-
 
| Nvidia
 
| GeForce 9800 GT
 
| 4.0
 
|}
 
 
 
Folgendes Bild zeigt den Aufbau der festen Renderingpipeline. Mit roten Kästen sind die Teile markiert die sich durch eigene kleine Programme, also Shader, ersetzen lassen. Weiter unten im Artikel werden diese Teile dann im einzelnen erklärt. Die im Bild als optional markierten Teile sind standardmäßig abgeschaltet und nur auf neuester Grafikhardware verfügbar.
 
 
 
[[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 ==
 
Der Vertexshader erlaubt uns jeden Vertex einzeln zu modifizieren. Wir müssen die Modelview-Transformation sowie die Perspective-Transformation selbst übernehmen. Wollen wir klassisches [[Gouraud Shading]] müssen wir dies auch selbst übernehmen.
 
 
 
====Beispiel: Heightmap-Terrain====
 
Angenommen wir benötigen für jeden Vertex eine Position, eine Normale und zwei Sets von Texturkoordinaten, also insgesamt 10 Floats bzw. 40 Bytes. Bei einer Heightmapgröße von 4096x4096 benötigen wir also 640 Mb Speicher. Dies ist also nicht wirklich sinnvoll, insbesondere da viele Grafikkarten nur 512 oder gar 256 Mb Speicher haben. Dies ist also mit der festen Funktionspipeline nicht praktikabel zu lösen.
 
 
 
Gewöhnlich rendert man das Terrain nicht am Stück sondern in Blöcken von z.B. 64x64 Quads. Wir verwenden nun ''einen'' kleinen Vertexbuffer der 65x65 minimale Vertices enthält: Jeweils nur eine 2D-Position. Die Höhe des jeweiligen Vertex wird im Vertexshader aus der Heightmap-Textur ausgelesen und an die entsprechende Koordinate geschrieben. Auch die Vertexnormalen und Texturkoordinaten berechnet man direkt im Shader. Letzlich benötigen wir nur den vernachlässigbar kleinen Vertex-, den ebenfalls sehr kleinen Indexbuffer und natürlich die Heightmaptextur. Angenommen wir verwenden 16bit Graustufen dann hat diese Textur eine Größe von 32 Mb. Dies sollte auch auf älteren Grafikkarten im Rahmen des machbaren sein.
 
 
 
====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.
 
 
 
== Fragmentshader (auch Pixelshader) ==
 
 
 
== Geometryshader ==
 
Der Geometryshader ist Teil von Shader Model 4.0 und somit nur auf neueren Grafikkarten verfügbar. Zudem gehört er wirklich zu den fortgeschrittenen Dingen in der Computergrafik. Als Anfänger sollte man sich also vielleicht erstmal mit dem Vertexshader zufriedengeben.
 
 
 
Der Geometryshader kann vom Prinzip die gleichen Dinge tun wie der Vertexshader, hat aber diverse Vorteile:
 
* verarbeitet man z.B. Dreiecke, kann man ein Dreieck als ganzes Verarbeiten. Man kann also gleichzeitig auf alle 3 Vertices des Dreiecks zu greifen.
 
* es gibt neben den bekannten GL_POINTS, GL_LINES und GL_TRIANGLES neue Input-Geometrietypen, z.B.: GL_TRIANGLES_ADJACENCY_EXT und GL_TRIANGLE_STRIP_ADJACENCY_EXT. Diese erlauben es nicht nur auf das aktuelle Dreieck zuzugreifen, sondern auch auf die benachbarten Dreiecke. Bei GL_TRIANGLES_ADJACENCY_EXT bekommt man dann zum Beispiel ein Array der Größe 6 für jedes Attribut des Vertex. Diese Adjazenz-Informationen müssen natürlich auch bereits so im Vertexbuffer gegeben sein.
 
* der Geometryshader stellt neue Funktionen bereit mit denen man neue Primitive zusammenbauen kann. Es gibt drei mögliche Output-Geometrietypen: GL_POINTS, GL_LINE_STRIP und GL_TRIANGLE_STRIP
 
* alle Primitive die den Geometryshader verlassen muss man selbst erzeugen. Man kann also insbesondere auch einfach keine Primitive erzeugen.
 
 
 
Kommen wir zu den Nachteilen der aktuellen Implementierung:
 
* Anzahl der Output-Vertices und der Geometrietyp müssen im voraus festgelegt werden. Egal ob die Vertices erzeugt werden oder nicht wird der dafür nötige Speicher reserviert. Aus diesem Grund ist die Performance eines Geometryshaders sehr stark von dieser einmal vom Programmierer konstant festgelegten Anzahl Output-Vertices abhängig. [[#Quellen|[1]]]
 
* Der Geometryshader eignet sich nur für kleine Modifikationen, nicht für Heavy-Output Algorithmen.
 
 
 
==== Beispiel: Shadow-Volumes ====
 
Shadow-Volumes haben den Nachteil das man zusätzliche Geometrie für die Seiten des Volumes erzeugen muss. Dafür gibt es verschiedene Wege.
 
* Man kann die zusätzliche Geometrie auf der CPU erzeugen und in drei Passes (1. Frontfaces, 2. Backfaces extrudiert, 3. Seiten) rendern. Dies ist offensichtlich ineffizient.
 
* jede Kante im Mesh durch zwei degenerierte Dreiecke ersetzen. Im Vertexshader kann man dann Backfacing-Polygone extrudieren. Dies erhöht die Vertexanzahl um den Faktor 2. Die Anzahl der Dreiecke wird um den Faktor 4 erhöht.
 
* der Geometryshader erlaubt es nun die zwei benötigten Dreiecke einfach dann zu erzeugen wenn man sie benötigt. Da man zusätzlich Adjazenz-Informationen benötigt, vergrößert sich auch hier der Vertexbuffer um den Faktor 2. Allerdings bleibt die Anzahl der Dreiecke konstant und es ist nicht notwendig degenerierte Dreiecke zu rendern.
 
 
 
==== Beispiel: Cube-Maps / Environment-Mapping ====
 
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. Für jeden Framebuffer muss die Geometrie mit einer eigenen Transformationsmatrix transformiert. Man muss natürlich beachten, dass das Viewing-Frustum-Culling so ebenfalls 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) ==
 
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.
 
 
 
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.
 
 
 
Transform-Feedback stellt eine flexiblere Alternative zu [[Tutorial_Framebufferobject|Framebuffer-Objekten]] dar.
 
 
 
==== Beispiel: Meshanimation ====
 
Für diverse Algorithmen muss man die Szene mehrfach, zum Teil auch aus verschiedenen Perspektiven rendern. Natürlich kann man ein 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.
 
 
 
== Quellen ==
 
[1] [http://developer.nvidia.com/object/gpu_programming_guide.html NVIDIA GeForce 8 and 9 Series GPU Programming Guide], insbesondere Abschnitt 4.6
 

Aktuelle Version vom 30. Januar 2011, 17:38 Uhr

  • Realname: Martin Weusten
  • Studium (abgeschlossen):
    • Diplom Informatiker
    • Vertiefungsrichtung: Computergrafik
    • RWTH Aachen University
  • Platform: Linux, C++
  • Web: martin-weusten.de
  • Jabber: Jid-martin.weusten.jpg Modrewrite-martin.weusten.gif
(das ist keine EMailadresse, sondern eine Jabberadresse!)