DGL Wiki - Benutzerbeiträge [de]

Tutorial Matrix2

2011-12-18T10:08:40Z

Phlegmatiker: /* GL_MODELVIEW */ www.seitseid.de :) Kommasetzung, Richtige Fälle...

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem zweiten Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt drei Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzige, was man von der "Kamera" mitbekommt, ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wisst, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seid ihr in der Lage beim "Bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<source lang="pascal">glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</source>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem einen oder anderen ist vielleicht aufgefallen, dass wir zweimal das selbe Objekt zeichnen sollen. Der einzige Unterschied besteht in der Position, Ausrichtung und Größe/Skalierung. Um Arbeit zu sparen, erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert und ruft vor dem Zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<source lang="pascal">procedure ZeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
ZeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
ZeichneWuerfel;
glPopMatrix;
end;
</source>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<source lang="pascal">procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</source>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glRotate richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/shared/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Tutorial Matrix2

2011-12-18T10:02:49Z

Phlegmatiker: /* GL_PROJECTION */ einzigste -> einzige, wißt -> wisst, Kommasetzung

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem zweiten Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt drei Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzige, was man von der "Kamera" mitbekommt, ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wisst, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seit ihr in der Lage beim "bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<source lang="pascal">glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</source>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem ein oder anderen ist vielleicht aufgefallen, dass wir 2x das selbe Objekt zeichnen sollen. Der einzigste Unterschied besteht in der Position, Ausrichtung und Größe/Scalierung. Um Arbeit zu sparen erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert, und ruft vor dem zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<source lang="pascal">procedure zeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
zeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
zeichneWuerfel;
glPopMatrix;
end;
</source>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<source lang="pascal">procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</source>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glRotate richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/shared/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Tutorial Matrix2

2011-12-18T10:00:25Z

Phlegmatiker: /* Matrizen in OpenGL */ Zahlen bis 12 schreibt man aus.

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem zweiten Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt drei Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzigste was man von der "Kamera" mitbekommt ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wißt, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seit ihr in der Lage beim "bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<source lang="pascal">glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</source>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem ein oder anderen ist vielleicht aufgefallen, dass wir 2x das selbe Objekt zeichnen sollen. Der einzigste Unterschied besteht in der Position, Ausrichtung und Größe/Scalierung. Um Arbeit zu sparen erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert, und ruft vor dem zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<source lang="pascal">procedure zeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
zeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
zeichneWuerfel;
glPopMatrix;
end;
</source>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<source lang="pascal">procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</source>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glRotate richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/shared/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Tutorial Matrix2

2011-12-18T09:59:17Z

Phlegmatiker: /* Vorwort */ Zahlen bis 12 schreibt man aus.

=Matrizen und Matrixmanipulationen=

== Vorwort ==
Willkommen bei meinem zweiten Tutorial.<br>
In letzter Zeit traten im Forum verstärkt fragen wie ''"Wie positioniere ich Objekte richtig?"'' und ''"Ich komm mit den Matrizen net klar. Könnt ihr helfen?"'' auf. Dies war Anlass für mich ein weiteres Tutorial zum Thema Matrizen zu schreiben. Ich werde versuchen viel mit Bildern und Gleichnissen zu arbeiten. Wer aber das ganze Angebot zum Thema "Matrix" nutzen will sollte ruhig auch einen Blick auf Phobeus Matrixtutorial ([[Tutorial_lektion3]]) und auf den Wikiartikel zum Thema [[Matrix]] werfen.

== Matrizen in OpenGL ==

OpenGL kennt 3 Matrizen. Wer OpenGL programmieren will sollte diese auch kennen:
* '''GL_MODELVIEW''' - Die Modelviewmatrix
: Die Modelviewmatrix sollte immer dann aktiviert sein, wenn ihr an die Grafikkarte [[Vertex]]daten senden wollt. Diese Matrix wird auf die Position der Vertices, die mit [[glVertex]] gesendet werden angewandt. Ebenso beeinflusst sie die Ausrichtung der [[Normalen]], die mit Hilfe von [[glNormal]] gesetzt werden. Kurz, alles was mit den Objekten eurer Welt zu tun hat, erfordert die Aktivierung dieser Matrix.
* '''GL_PROJECTION''' - Die Projektionsmatrix
: Diese Matrix wird selten gebraucht. Sie bestimmt, wie am Ende alles angezeigt wird. Sie bestimmt quasi die Eigenschaften der "Kamera".
* '''GL_TEXTURE''' - Die Texturmatrix
: Diese Matrix wird auf die Texturkoordinaten angewandt, mit der Folge, dass sich die Texturen auf den Oberflächen bewegen.

Diese 3 Matrizen können per [[glMatrixMode]] aktiviert werden. Dabei kann immer nur eine Matrix aktiv sein. Wenn ihr z.B. {{INLINE_CODE|glMatrixMode(GL_MODELVIEW)}} aufgerufen habt, dann sagt man "Die Modelviewmatrix ist die '''''aktuelle Matrix'''''". Alle Matrixmanipulationen (wir kommen gleich dazu was das ist) wirken sich ''nur'' auf die ''aktuelle Matrix'' aus.

== Kurze Matrixtheorie ==
''Was sind Matrizen?'' <br>
Matrizen sind aufgebaut wie Tabellen. Das tolle daran ist - man kann damit rechnen. <br>
''"Gaaaaanz toll! Jetzt rechnen die schon mit Tabellen..."''<br>
So schlimm ist das gar nicht. Denn das Rechnen übernimmt OpenGL für uns. Ihr müsst nur wissen, dass wann immer ihr einen Befehl wie [[glTranslate]], [[glRotate]] oder [[glScale]] verwendet, ihr eine Matrix mit der ''aktuellen Matrix'' multipliziert.
{{Hinweis|Wenn ihr wissen wollt, wie man Matrizen miteinander multipliziert, dann lest euch einmal den Artikel "[[Matrix]]" durch und auch das dort verlinkte PDF "CompGeoScript".}}

== Wie sehen Matrizen aus? ==
In "echt" sehen Matrizen wie Tabellen voller Zahlen aus. <br>
Will man sich eine Matrix grafisch vorstellen, sollte man sich ein 3 dimensionales Gitter vorstellen. Dieses Gitter ist das Koordinatensystem der Matrix. Wenn ihr mit [[glTranslate]], [[glRotate]] oder [[glScale]] die Matrix manipuliert, dann verändert ihr die Position des Koordinatenursprungs (glTranslate), die Ausrichtung der Achsen (glRotate) oder die Maße (glScale). Im dritten Teil des Tutorials gehe ich auf die Auswirkungen dieser Befehle noch einmal genauer ein.

= Die drei OpenGL Matrizen =

== GL_PROJECTION ==
Ich möchte zuerst einmal die Projektionsmatrix vorstellen. Diese Matrix wird meist nur am Rande erwähnt, macht aber einen verdammt wichtigen Job: Sie projeziert den Inhalt der Welt auf den Bildschirm.

Wenn ihr der Projektionsmatrix per [[glLoadMatrix]] eine Matrix zuweist, die nur Nullen enthält, werdet ihr feststellen, dass ihr nichts seht. Ihr habt damit nämlich die Projektionsmatrix ausgeschaltet und da wir ja was sehen wollen, unterlassen wir das in Zukunft lieber ;).

''Aber was kann man dann mit der Projektionsmatrix machen (,außer sie nicht auszuschalten ;-) )?'' <br>
Bei der Vorstellung der einzelnen Matrizen erwähnte ich bereits die "Kamera". Um gleich mal eins festzustellen: Ein Objekt "Kamera" existiert nicht. Das einzigste was man von der "Kamera" mitbekommt ist die Ausgabe. Und wie wir gerade gelernt haben ist welcher Teil für die Ausgabe zuständig? Richtig! Die Projektionsmatrix. Sie ist unsere "Kamera".

Kommt jetzt aber bitte nicht auf die Idee, eure Projektionsmatrix per '''glTranslate''' und '''glRotate''' irgendwohin zu bewegen... Das ist nämlich gar nicht die Aufgabe der Projektionsmatrix. Ihre Aufgabe ist "das Abbild für die Ausgabe zu manipulieren".

Im Ausgangszustand ([[glLoadIdentity]] wurde für die Projektionsmatrix aufgerufen), gibt die Projektionsmatrix das Bild der Welt unverändert aus. Wenn man '''glTranslate''' auf die Projektionsmatrix anwendet, dann verschiebt man nicht die Welt, sondern sagt der Projektionsmatrix, dass sie das gesehene Bild verschieben soll.

Befehle wie [[gluPerspective]] und [[glOrtho]] sind typische Befehle zum einstellen der Projektionsmatrix. Diese Befehle bestimmen nämlich in welcher Form die Ausgabe gemacht wird. Entweder perspektivisch verzerrt (gluPerspective) oder durch Parallelprojektion (glOrtho).

Wenn man die Projektionsmatrix manipuliert, ist das vergleichbar mit dem Austauschen des Objektivs bei einer Kamera. Man könnt sogar über die Projektionsmatrix einen "Fischauge" Effekt erzeugen... (Aber fragt mich bitte nicht, wie die Matrix dazu aussieht... ;-) Falls ihrs wißt, einfach im Forum posten. Ich wäre interessiert.)

== GL_MODELVIEW ==
Wie bereits erwähnt ist die Modelviewmatrix die wichtigste Matrix in der OpenGL Welt, denn sie wirkt sich auf Ausrichtung und Position aller Primitive und damit Objekte in der OpenGL Welt aus. Ohne Daten in der Modelviewmatrix, kann die Projektionsmatrix auch nichts ausgeben.

Wenn ihr [[Vertex]]daten an die Grafikkarte übermittelt solltet ihr die Modelviewmatrix aktiviert haben. Positionsangaben wie z.B. {{INLINE_CODE|glVertex3f(1,0,1);}} beziehen sich auf das aktuelle Koordinatensystem. Das Koordinatensystem ist quasi der Teil der Matrix mit dem ihr arbeitet, und den ihr euch vorstellen könnt (/müßt.).<br>
Wie ihr bereits wisst kann man mit den Befehlen [[glTranslate]], [[glRotate]] und [[glScale]] das Koordinatensystem manipulieren. Dadurch seit ihr in der Lage beim "bauen" von Objekten mit "lokalen Koordinaten" zu arbeiten.

=== lokale und globale Koordinaten ===
''Worin unterscheiden sich lokale und globale Koordinaten?'' <br>
Um diese Frage zu klären bedarf es eines kleinen Beispiels:

Stellt euch vor, ihr wollt zwei Würfel zeichnen. Der eine soll um den Punkt (3,4,5) mit einer Kantenlänge von 1 erstellt werden, der andere soll um den Punkt (1,2,3) mit Kantenlänge 2 und dazu 30° um die Y-Achse gedreht werden.

Wenn man mit '''globalen''' Koordinaten arbeitet lässt man die Matrix so wie sie ist (verzichtet also auf die 3 genannten Befehle) und schreibt die Koordinaten der Eckpunkte per Hand hin:
<source lang="pascal">glBegin(GL_QUADS);
//Vorderseite erster Würfel
glVertex3f(2,5,6);
glVertex3f(2,3,6);
glVertex3f(4,3,6);
glVertex3f(4,5,6);
//Nächste Seite
[...]

//Vorderseite zweiter Würfel
glVertex3f(0,3,4);
glVertex3f(0,1,4);
glVertex3f(2,1,4);
glVertex3f(2,3,4);
[...]

glEnd;
</source>

Bei '''lokalen''' Koordinaten bewegt man zuerst den Koordinatenursprung an die Stelle an die der Würfel entstehen soll, richtet dann wenn nötig die Achsen entsprechend aus, und kann dann '''lokale''' Koordinaten übergeben. Lokal bedeutet hier relativ zum aktuellen Koordinatensystem.

''Aber was soll das für einen Vorteil haben?'' <br>
Dem ein oder anderen ist vielleicht aufgefallen, dass wir 2x das selbe Objekt zeichnen sollen. Der einzigste Unterschied besteht in der Position, Ausrichtung und Größe/Scalierung. Um Arbeit zu sparen erstellt man deshalb ein Unterprogramm welches einen Einheitswürfel (Kantenlänge 1) rendert, und ruft vor dem zeichnen einfach die passende Kombination aus glTranslate, glRotate und glScale auf:

<source lang="pascal">procedure zeichneWuerfel;
begin
glBegin(GL_QUADS);
glVertex3f(-0.5, 0.5, 0.5);
glVertex3f(-0.5,-0.5, 0.5);
glVertex3f( 0.5,-0.5, 0.5);
glVertex3f( 0.5, 0.5, 0.5);
[...]
glEnd;
end;

begin
glPushMatrix;
glTranslatef(3,4,5);
zeichneWuerfel;
glPopMatrix;
glPushMatrix;
glTranslatef(1,2,3);
glRotatef(30,0,1,0);
glScalef(2,2,2);
zeichneWuerfel;
glPopMatrix;
end;
</source>

Wie ihr seht, haben lokale Koordinaten den Vorteil, dass man wiederverwendbaren Code schreiben kann. Bei globalen Koordinaten muss für jedes Objekt eigener Code geschrieben werden (und wenn sich das Objekt bewegt dann wieder...).

Dreimal dürft ihr raten, welche Methode häufiger verwendet wird. ;-)
{{Hinweis|Modeller wie 3D Studio Max benutzen globale Koordinaten beim exportieren der Modelle. Dies hat den Vorteil, dass beim importieren einer ganzen 3DS Szene, die Objekte gleich an der richtigen Position stehen, und nicht erst ausgerichtet werden müssen.}}

== GL_TEXTURE ==
Dieser Matrix sollte endlich mehr Aufmerksamkeit geschenkt werden. Sie kann nämlich mit den Texturen in der Szene einiges anfangen...

Aber der Reihe nach:

Wie ihr vielleicht schon im [[Tutorial_lektion4|Einsteigertutorial 4 - Texturen]] gelesen habt, sind Texturkoordinaten immer so, dass {{INLINE_CODE|[[glTexCoord2f]](0,0)}} die obere linke Ecke und {{INLINE_CODE|glTexCoord2f(1,1)}} die untere Rechte Ecke der Textur betrifft. Wie die Textur außerhalb dieses Bereichs aussieht bestimmt ihr mittels [[glTexParameter]] und dem Parametern '''GL_TEXTURE_WRAP_S''' und '''GL_TEXTURE_WRAP_T'''.

Nun stellt euch einmal vor, ihr habt 2 Quads die beide die selbe Textur bekommen sollen. Einziger Unterschied ist, dass bei dem einen Quad der Inhalt der Textur um 20° in Uhrzeigerrichtung gedreht ist. Blöd, oder? Das heißt ja jetzt, dass ihr in eurem Zeichenprogramm eine weitere Textur erstellen müßt, um das zweite Quad zu texturieren oder die Texturkoordinaten per Hand ändern müsst. <br>
'''STOP!''' Ihr hab es sicherlich schon mitbekommen: Dieses Szenario kann leicht mit der Texturmatrix gelößt werden. Und zwar so...

<source lang="pascal">procedure drawTexturedQuad;
begin
glBegin(GL_QUADS);
glTexCoord(0,0); glVertex3f(-1, 1,0);
glTexCoord(0,1); glVertex3f(-1,-1,0);
glTexCoord(1,1); glVertex3f( 1,-1,0);
glTexCoord(1,0); glVertex3f( 1, 1,0);
glEnd;
end;

begin
glMatrixMode(GL_MODELVIEW);
glBindTexture(GL_TEXTURE_2D, texID);
glTranslatef(-2,0,0);
drawTexturedQuad;

glMatrixMode(GL_TEXTURE);
glRotatef(20,0,0,1);

glMatrixMode(GL_MODELVIEW);
glTranslatef(4,0,0);
drawTexturedQuad;
end;</source>
''Was ist hier geschehn? ''<br>
Durch die vorherige Aktivierung der Texturmatrix wirkt sich das nachfolgende glRotate nicht auf die Modelle der Szene sondern auf die Texturkoordinaten aus. Auf gut deutsch: OpenGL dreht vor dem rendern des zweiten Quads die Textur um 20°.

Wenn ihr beim rotieren der Texturmatrix, bei jedem Renderdurchlauf den Winkel um ein Stück erhöht passiert was?... Richtig! Eure Textur dreht sich auf eurem Quad... Das is dann quasi eure erste Animation... Und das ohne ein Objekt zu bewegen... Cool, oder?

= Auswirkungen von Matrixmanipulationen - oder "Wie positioniere ich meine Objekte richtig?"=
In diesem Teil des Tutorials möchte ich euch zeigen wie die 3 Befehle '''glTranslate, glRotate''' und '''glScale''' eure aktuelle Matrix verändern. Ich bleibe hierbei im 2 dimensionalen Raum, da sonst die Skizzen zu unübersichtlich werden. (Die Befehle sind dabei natürlich die selben wie für 3D Manipulationen. Ich ignoriere nur einfach immer die Y-Angaben.)

Zuersteinmal zum warm werden: <br>
[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|So stelle ich mir eine 2D-Matrix vor.]]

==glTranslate==
{{INLINE_CODE|[[glTranslate]](a,b,c)}} verschiebt den Koordinatenursprung des aktuellen Koordinatensystems um ''a'' Einheiten in die Richtung der X-Achse, um ''b'' Einheiten in die Richtung der Y-Achse und um ''c'' Einheiten in die Richtung der Z-Achse.

[[Bild:Tutorial Matrix2 Translate.png|framed|center|Das passiert bei einer Translation um 3.5 Einheiten in X und -3 Einheiten in Z-Richtung.]]

==glRotate==
{{INLINE_CODE|[[glRotate]](w,x,y,z)}} rotiert das Koordinatensystem um ''w'' Grad um die Rotationsachse welche durch (0,0,0) und (''x,y,z'') verläuft. '''glRotate richtet also die Achsen neu aus.''' (Die Richtung der Achsen ist z.B. wichtig für glTranslate)

[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Das passiert bei einer Rotation um 45° mit der Y-Achse als Rotationsachse.]]

==glScale==
{{INLINE_CODE|[[glScale]](x,y,z)}} skaliert die Maße der Koordinatenachsen (Bestimmt also wie lange "eine Einheit" wirklich ist). Wenn ''x,y'' oder ''z'' größer als 1 ist, werden die Maßeinheiten der entsprechenden Achse gestreckt, wenn die Werte kleiner 1 sind gestaucht. (Wenn die Werte gleich 0 sind verschwindet die Szene auf nimmer wieder sehn(, da hilft dann nur noch glLoadIdentity um die Matrix wieder nutzbar zu machen), sind die Werte gleich 1 verändert sich nichts.)

''x,y'' und ''z'' muss man sich als Prozentangaben vorstellen. Will man die Szene in X-Richtung um das doppelte (also 200%) vergrößern/strecken muss ''x'' gleich 2 sein. Will man die Y-Richtung auf ein Zehntel (also 10%) verkürzen/stauchen muss ''y'' gleich 0.1 sein.

[[Bild:Tutorial Matrix2 Scale.png|framed|center|Das passiert bei einer Skalierung. Wie ihr seht, sind die Seiten unterschiedlich skaliert worden (X-Achse: 80%, Z-Achse: 60%).]]

==Kombination - Translate vor Rotate==
Wird Translate vor Rotate aufgerufen, bewegt sich der Koordinatenursprung zuerst an den Zielpunkt (über glTranslate angegeben). Anschließend werden die Achsen neu ausgerichtet (durch glRotate).

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glTranslatef(3.5,0,-3);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Translate.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die jeweils vorhergehende Veränderung bestehend bleibt, und die Basis für die nachfolgende Änderung bildet.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, dreht sich ein anschließend gezeichnetes Objekt um die durch glTranslate angegeben Position.

==Kombination - Rotate vor Translate==
Wird Rotate vor Translate aufgerufen, werden zuerst die Achsen neu ausgerichtet und dann der Koordinatenursprung bezüglich dieser neuen Achsen verschoben.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glRotatef(45, 0, 1, 0);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Rotate.png|framed|center|Nachdem glRotate aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde. Man sieht, dass die vorhergehende Rotation die Verschieberichtung beeinflusst.]]
|}</div>

Wird der Winkel von glRotate bei jedem Renderdurchlauf erhöht, bewegt sich ein nach glTranslate gezeichnetes Objekt auf einer Kreisbahn um den Koordinatenursprung wie er beim Aufruf von glRotate aktuell war. Der Radius der Kreisbahn wird durch glTranslate bestimmt.

Wenn man die beiden Ergebnisse direkt vergleicht sieht man, dass die Reihenfolge von Bedeutung für das Ergebniss ist. Das die Unterschiede so "klein" ausfallen liegt nur daran, dass bei rotate nicht mit größeren Winkeln rotiert wurde.

<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 RotateTrans.png|framed|center|Erst Rotiert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 TranslateRot.png|framed|center|Erst Verschoben]]
|}</div>

==Kombination - Scale vor Rotate==
Die Rotation wird nur von der Richung, nicht aber der Länge der Achsen beeinflusst. Der Winkel um den gedreht wird, bleibt von der Skalierung unberührt (45° bleiben 45°. Die Achsen zeigen anschließend jeweils in die gleiche Richtung)

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glRotatef(45, 0, 1, 0);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Nachdem glRotate aufgerufen wurde. Man sieht, dass die Skalierung den Winkel nicht beeinflusst. Das Koordinatensystem wurde korrekt um 45° gedreht.]]
|}</div>

Der direkte Vergleich zeigt, dass die Skalierung keinen Effekt auf den Winkel hatte. Beide Koordinatensysteme sind gleich ausgerichtet:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Rotate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleRot.png|framed|center|Skaliert]]
|}</div>

==Kombination - Scale vor Translate==
Die Verschiebung ist Abhängig von der Ausrichtung der Achsen (glRotate) und der Maße der Achsen (glScale). Aus diesem Grunde beeinflusst glScale die nachfolgenden Translationen.

<div align="center">
{|{{Prettytable}}
|Folgender Code wird demonstriert:
<source lang="pascal">
glScalef(0.8, 1, 0.6);
glTranslatef(3.5,0,-3);
ZeichneKoordinatensystem;
</source>
|-
|[[Bild:Tutorial Matrix2 Ausgangsbild.png|framed|center|Bevor glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 Scale.png|framed|center|Nachdem glScale aufgerufen wurde.]]
|-
|[[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Nachdem glTranslate aufgerufen wurde.]]
|}</div>

Der direkte Vergleich zeigt, dass sich die Skalierung auf die Verschiebung auswirkt. Denn obwohl der Verschiebung in die gleiche Richtung und um den selben Wert erfolgt, sind die Resultate nicht identisch. Dies liegt daran, dass glScale die Maße verändert hat. Die Verschiebung in X-Richtung erreicht dadurch nur 80% und in Z-Richtung sogar nur 60% der unskalierten Transformation:
<div align="center">
{|{{Prettytable}}
|width="50%" | [[Bild:Tutorial Matrix2 Translate.png|framed|center|Unskaliert]]
|-
|width="50%" | [[Bild:Tutorial Matrix2 ScaleTrans.png|framed|center|Skaliert]]
|}</div>

=Nachwort=
7 Stunden sind vorbei und das Tutorial ist auf eine ordentliche Länge angewachsen. Ich hoffe ich konnte euch die OpenGL Matrizen etwas näher bringen.

Wer jetzt denkt ''"Bilder sind mir zu statisch!"'', dem möchte ich noch diese Programme ans Herz legen:
<div align="center">
{|{{Prettytable}}
!Name
!Hersteller
!Beschreibung
|-
|[http://www.delphigl.com/forum/viewtopic.php?p=37378#37378 '''Matrix2 - Skizzenrenderer''']
|Flash
|Dieses Programm habe ich geschrieben um die Skizzen für dieses Tutorial zu erstellen. Es wurde so modifiziert, dass man beliebige Kombinationen von glTranslate, glRotate und glScale anzeigen kann.
|-
|[http://www.phobeus.de/hosting/shared/pixelpracht/main.php?s=opengl&t=1&p=2 '''Matrix Control''']
|Lithander
|Das Programm erlaubt euch zu beobachten, wie die Matrizen sich bei den einzelnen Befehlen verändern und wie die Ausgabe aussieht. Besonderheit an diesem Programm ist, dass ihr die Matrizen auch per Hand manipulieren könnt.
|}</div>

Sollten immer noch Unklarheiten bestehen bleibt das Forum natürlich auch weiterhin die Anlaufstelle Nummer1. Dies betrifft auch euer Feedback zum Tutorial.

MfG
: Flash ('''Kevin Fleischer''')

{{TUTORIAL_NAVIGATION|[[Tutorial_2D]]|-}}

[[Kategorie:Tutorial|Matrix2]]

Tool

2011-08-16T16:43:24Z

Phlegmatiker: totel Links entfernt

== Kostenlose Tools ==

Kostenlose für OpenGL/3D-Spieleprogrammierung/3D-Grafik relevante Tools und Programme.

=== OpenGL ===
{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
![http://www.realtech-vr.com/glview/ GLView]
|Tool welches Informationen über die auf einem Rechner vorhandene GL Implementation extrahiert und anzeigt. Unter anderem von welchem Hersteller die Implementation stammt und welche Extensions/GL-Version unterstützt wird.
|-
![http://delphi3d.net/hardware/index.php GLinfo]
|Tool welches Informationen über die auf einem Rechner vorhandene GL Implementation extrahiert und anzeigt. Es werden auch technische Informationen wie maximal zulässige Texturgröße angezeigt. Das Tool generiert ein Logfile was, wenn gewünscht, auch in die '''OpenGL Hardware Registry''' eingetragen werden kann.
|-
![http://www.gremedy.com/ gDEBugger]
| Mächtiger OpenGL/OpenCL Debugger, Profiler und Memory Analyzer.
|}

=== Mathematik/Physik ===
{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
![http://www.amd.com/acml/ ACML]
| Bibliothek mit hochoptimierten Befehlen für Mathematische Berechnungen (C++, gut dokumentiert, AMD-optimiert)
|-
! [http://math-atlas.sourceforge.net/ ATLAS]
| Bibliothek basierend auf BLAS und LAPACK (C++/Fortran)
|-
! [http://www.netlib.org/blas/ BLAS]
| Bibliothek mit optimierten Befehlen für lineare Algebra (Fortran 77)
|-
! [http://www.partow.net/projects/fastgeo/index.html FastGeo]
| Bibiothek mit optimierten mathematischen Funktionen die direkt für Delphi/FreePascal entwickelt wurde. Prozedural aufgebaut (nicht OOP)
|-
! [http://www.fftw.org/ FFTW]
| Bibliothek mit optimierten Befehlen für FFTs (als DLL mit C++/Pascal-Header erhältlich)
|-
! [http://www.netlib.org/lapack/ LAPACK]
| Bibliothek mit optimierten Befehlen für lineare Algebra (Fortran 77)
|-
! [http://www.nvidia.de/object/nvidia_physx_de.html PhysX Engine]
| Eine der größten Physik-Engines
|}

=== 2D/Texturen-Tools ===

{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
! [http://www.lmnopc.com/bitmapfontbuilder/ Bitmap Font Builder]
| Erstellt 2D-Fonttexturen, mit diversen Einstellungsmöglichkeiten. Exportiert zudem auch noch die Dimensionen der Buchstaben.
|-
! [http://www.saschawillems.de/?page_id=253 Explosion Texture Generator]
| Erstellt eine 2D-Textur mit einer animierten Explosion. Ideal für animierte Billboard-Explosionen.
|-
! [http://www.planetside.co.uk/terragen/ Terragen]
| Ein besseres Tool zum Erstellen realistischer Skybox-Texturen gibt es nicht.
|-
! [http://www.planetside.co.uk/terragen/tg2/tech_preview.shtml Terragen 2 Technology Preview]
| Obwohl noch die Technology Preview schon gut geeignet um sowohl Skyboxes als auch Terrain-Texturen mit Normalmaps zu rendern.
|-
! [http://www.saschawillems.de/?page_id=92 TerrTexGen]
| Tool zur Erstellung von Terraintexturen. Oft und gerne genutzt.
|-
! [http://www.bundysoft.com/L3DT/ L3DT]
| Der 'Large 3D Terrain Generator' (L3DT) erzeugt hochwertige 16bit Graustufen [[Heightmap|Heightmaps]] sowie Alphamaps und darf auch in der kostenlosen Version kommerziell genutzt werden.
|-
! [http://www.texturesynthesis.com/texture.htm MRFsynthesis]
| Automatische Generierung von hochwertigen, kachelbaren Texturen mit beliebiger Auflösung aus Fotos oder anderen Quelltexturen. Ausführliche Beschreibung im [[Texturesynthesis|Texturesynthesis-Artikel]].
|-
! [http://www.logarithmic.net/pfh/resynthesizer Resynthesizer]
| Ein Plugin für '''GIMP''' mit ähnlichen Funktionen wie '''MRFsynthesis''', jedoch mehr Features und höherer Geschwindigkeit. Ausführliche Beschreibung im [[Texturesynthesis|Texturesynthesis-Artikel]].
|-
! [http://www.gimp.org/ GIMP]
| GNU Image Manipulation Tool. Gutes kostenloses Bildbearbeitungsprogramm das sich nicht unbedingt vor Photoshop & Co. (mal abgesehen von der UI) verstecken muss.
|-
! [http://web.bethere.co.uk/terabit/ Tattoo]
| Ein sog. 3D-Paint Tool, mit dem man direkt auf ein Modell zeichnen kann und so Texturen erstellen kann. Besonders für Leute die Probleme haben 2D-Texturen für komplexe Modelle zu erstellen ein tolles Programm. Das Tool unterstützt viele Modell- und Texturformate und ist für die nicht-kommerzielle Nutzung umsonst.
|-
! [http://www.lysator.liu.se/~kand/caustics/ Caustics Generator]
| Ein sehr schönes Programm, dass Relief-Texturen aller Colleur erzeugen kann. Das Programm eignet sich auch zum automatischen Berechnen animierter Sequenzen, wie zum Beispiel einer Wasserbewegung in 30 Frames. Sowohl die Ränder als auch die Übergänge zeitlich werden so erstellt, dass alle Übergänge fließend wirken.
|-
! [http://neotextureedit.sourceforge.net/index.html NeoTextureEdit]
| NeoTextureEdit ist ein einfach zu benutzender, graphenbasierter OpenSource-Textureditor/-generator. Auf Basis von kontinuierlichen Funktionen und Filtern kann man Texturen beliebiger Größe und Auflösung erzeugen.
|}

=== 3D-Tools ===

{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
! [http://www.delgine.com/ DeleD]
| Mit Delphi entwickelter 3D-Editor, der speziell auf Spieleentwickler ausgerichtet ist. Zwar noch in Entwicklung, aber bereits mehr als brauchbar.
|-
! [http://www.anim8or.com/ Anim8or]
| Kostenloser 3D-Modeller, allerdings fehlen (noch) einige nützliche Features wie z.B. UVW-Mapping.
|-
! [http://sourceforge.net/projects/wings/ Wings 3D]
| Freeware Polygon Modeller. Obwohl ihm noch einige Features fehlen, ist er einen Blick wert.
|-
! [http://www.blender3d.org/ Blender3D]
| Sehr ausgereiftes und komplexes 3D Tool mit frei gestaltbarer Oberfläche.
* [http://blendpolis.serverpool.org/f/article.php blend.polis]- Deutsche Blender Seite mit Tutorials
* umfangreiches [http://www.trcoding.de/informatik/blender/index.html Einsteiger Tutorial]
* '''sehr gute''' [http://blenderunderground.com/category/video-tutorials/ Video-Tutorials] (englisch)
|-
! [http://www.fluidstudios.com/ FSRad]
|Auf Lightmaps spezialisierter Radiosity Prozessor.
|-
! [http://www.delphigl.com/forum/viewtopic.php?t=2421 gl3ds]
| '''3ds''' Model-Loader (DGL-Projekt)
|}

=== Shaderentwicklung ===

{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
! [http://www.ati.com/developer/rendermonkey/index.html RenderMonkey 1.5]
| ATI's HLSL-Shader IDE. Jetzt auch endlich mit Support für glSlang.
|-
! [http://www.opengl.org/sdk/tools/ShaderDesigner/ OpenGL Shader Designer]
| Gute Shader IDE für glSlang.
|}

=== Sound ===

{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
! [http://www.buzzmachines.com/ BUZZ]
| Komplettes Soundstudio für E-Sounds. Es existieren unmengen Plugins welche das verhalten von allen denkbaren Soundeffekten und Soundgeneratoren imitieren können.
|-
! [http://www.bluemoon.ee/history/scwin/index.html Sound Club]
| Eine Art "Tracker" mit recht vielen Features, der dass Erstellen von Musik einfach macht. War mal Shareware, ist inzwischen aber als Freeware erhältlich.
|-
! [http://www-personal.monash.edu.au/~myless/catnap/pamela/index.html PAMELA]
| Vergleicht in Waveform abgespeicherte Sprache mit einem eingegebenem Text und ermittelt an welchem Zeitpunkt welche Laute vorkommen, und erstellt daraus eine Liste. Mit Hilfe dieser Liste kann man seine Figuren lippensynchron animieren.
|-
! [http://www.madtracker.org/ MadTracker]
| Sehr ausgereifter, professioneller Tracker. Kann auch FastTracker-Module (*.xm) bearbeiten. Wer modulbasierte Musik in seinen Programmen nutzen will, sollte sich MadTracker auf jeden Fall ansehen.
|-
! [http://www.modplug.com/ ModPlugTracker]
| Sehr ausgereifter und vielseitiger Tracker. Kann alle gängigen Module (*.mod, *.nst, *.s3m, *.stm, *.xm, *.it, *.mtm, *.okt, *.mdl, *.669, *.far) bearbeiten, sowie Midis und Waves importieren und exportieren. Auch einen Download wert: ModPlugPlayer, der kleine Bruder vom Tracker, der die oben genannten Module abspielen kann und das mit einer Vielzahl von Funktionen. So kann z.B. der Resampling-Mode eingestellt werden, oder die Geschwindigkeit des abgespielten Mods, sowie die Tonhöhe über Schieberegler verändern. Die beiden Programme können auch komprimierte Mods (*.mdz, *.s3z, *.xmz, *.itz), sowie die Unreal-Module (*.utx) bearbeiten.
|}

=== Programmierung/IDE/Allgemein ===

{| {{Prettytable_B1}}
!width="25%"| Name, Link
!width="75%"| Beschreibung
|-
! [http://www.prestosoft.com/ps.asp?page=edp_examdiff ExamDiff]
| Beschreibung: Visuelles Vergleichsprogramm für Text/Quellcode Dateien um Veränderungen an solchen Dateien zu suchen. (Freeware nur Pro Version kostenpflichtig)
|-
! [http://www.gexperts.org/ GExperts]
| Geniale IDE-Erweiterung (inkl. diverser Tools) um die Produktivität bzw. Funktionalität von Delphi zu verbessern/erweitern.
|-
! [http://www.automatedqa.com/downloads/memproof.asp MemProof]
| Ein Tool für diverse Borland Entwicklungsumgebungen, welches nach Speicherlecks sucht.
|-
! [http://www.winmerge.org/ WinMerge]
| Externes Datei-Vergleichen zum visuellen Zusammenführen von Konflikten.
|}

Tutorial GLScene

2011-07-30T11:07:32Z

Phlegmatiker: /* Installation(das Grauen...) */

=GlScene Tutorial=
==Vorwort==

GLScene ist eine wirklich geniale Komponentensammlung, um schnell z.B. einen Editor für die eigene Engine zu proggen. Aber schon die Installation ist so komplex, dass einige daran scheitern. Ich habe auch eine Weile (ca. 3 Stunden nur für die Installation) gebraucht. Darum liefere ich hier eine kleine Einführung in GLScene (exklusiv für DelphiGL.com ;-)). Habe ein bisschen dafür gebraucht, weil wieder mal ein paar Lehrer eine „Schreibt-mal-schnell-eine-zweiseitige-Abhandlung-Phase“ hatten. Aber schließlich bin ich doch noch fertig geworden. Diese Anleitung ist für totale Einsteiger - Fortgeschrittene und Profis werden nix Neues erfahren. Da ich kein Freund großer Worte bin, fange ich einfach mal an.

==Installation (so wie bei jedem andern Package auch)==

* im $(BDS)\Lib oder $(DELPHI)\Lib Ordner einen GLScene Ordner anlegen und entweder GLScene da hinein auschecken oder die Archive die man von sf.net beziehen kann dort hin entpacken. Dann sollten Strukturen wie diese hier entstehen: ..\Lib\GLScene\Source, ..\Lib\GLScene\Source\Base, ..\Lib\GLScene\Demos, ... und so weiter

* Delphi starten

* Dann entscheidet man sich, möchte man GLScene generell immer verfügbar haben oder doch nur für bestimmte Projekte. Falls man es generell verfügbar haben möchte, schließt man alle offenen Projekte und geht in die Optionen, Verzeichnisse & Bedingungen (Directories & Conditionals) und fügt bei den Suchpfaden sämtliche Ordner und Unterordner des Source Verzeichnisses von GLScene hinzu.

* Man durchsucht das GLScene Verzeichnis nach dlls, es sollten ansich 4 Stück sein. FMod, Bass, ODE und öhm noch irgendeine andere :) - Diese kopiert man entweder in den %SYSTEMROOT%\System32 (aufnem 32Bit Windows) oder ins %SYSTEMROOT%\SysWOW64 (aufnem 64bit Windows), damit Delphi auch die Einstiegspunkte für externe Funktionen finden kann. Später reichts die dlls mit in das Verzeichnis zu packen wo die fertige .exe deines Programms liegt.

* Je nach Delphiversion öffnet man dann aus dem GLScene\ Verzeichnis das passende Package. Im Fall von Delphi 14 (D2010) zuerst das GLScene_RunTime.dproj, dann das jeweilige DesignTime Package zum installieren der eigentlich Komponenten.

* Das gleiche kann man dann auch mit den zusätzlichen Packages durchführen. Für die Cg Shader Komponenten ist das Nvidia Cg SDK von nöten, da dlls benötigt werden die diesem SDK beiliegen.

==Erste Schritte==

Als erstes fügen wir eine Komponente mit dem schönen Namen GLScene ([[Bild:Tutorial GLScene html m2fc1a926.png]]) ein. Das ist das wichtigste aller Objekte und wird in allen euren GLScene-Programmen vorkommen. Mit einem Doppelklick darauf seht ihr den Grundaufbau eurer Szene:

[[Bild:Tutorial GLScene html 74dd1768.png]]

Alle Bestandteile eurer Szene werden in GLScene nach Cameras und Scene objects eingeordnet. Um euch einen Überblick über die von GLScene bereitgestellten Objekte zu verschaffen, macht ihr einen Rechtsklick auf Scene objects und geht dann auf Add object. Die meisten von den Einträgen hier erklären sich von selbst und wenn sie es nicht gleich tun, dann nach einigem Ausprobieren.

Anschließend setzen wir noch einen GLSceneViewer ([[Bild:Tutorial GLScene html m27e37d40.png]]) ins Formular. Standardmäßig ist er nur 100x100 groß, also stellen wir in den Eigenschaften des GLSceneViewers Align auf alClient. Wie der Name schon sagt, ist der GLSceneviewer das Objekt, das die Szene (aus dem Objekt GLScene) auf den Bildschirm bringt.

Nun können wir das Programm einfach mal starten:

[[Bild:Tutorial GLScene html cffa458.png]]

Juhu! Es lässt sich [hoffentlich] compilieren (bei einem OpenGL-Init ohne GLScene käme das, bei mir jedenfalls, fast einem Wunder gleich ;-)). Aber was sehen unsere entzündeten Augen da? Das Formular ist ja ganz leer! Nun, anscheinend ist die Initialisierung doch nicht so einfach. Es fehlt noch eine Kamera, die, mit dem GLSceneviewer verknüpft, unsere Szene anzeigt. Wer gut aufgepasst hat, sieht wahrscheinlich gleich, was zu tun ist (Den anderen gibt`s was auf die Finger!). Mit einem Doppelklick auf [[Bild:Tutorial GLScene html m2fc1a926.png]] öffnen wir das „Inhaltsverzeichnis“ unserer Szene. Es folgt ein Rechtsklick auf Cameras und dann auf Add Camera. Schon ist die Kamera in unserer Szene implementiert. Jetzt muss unserem GLSceneviewer nur noch gesagt werden, über welche Kamera er die Szene darstellen soll, denn bei größeren Programmen gibt es oft mehrere Kameras. Dazu klicken wir auf den GlSceneviewer und stellen in den Eigenschaften Camera auf GLCamera1 ein. Nach einem weiteren Compilieren stellen wir fest, dass sich immer noch nichts tut. Das liegt daran, dass sich ja noch nichts in der Szene befindet, was darzustellen wäre. Deshalb fügen wir jetzt einfach per Scene objects -> Add object -> Basic geometry > Sphere im GlScene – Dialog eine Kugel ein. Dann fehlt nur noch, dass wir die Camera ein wenig verschieben, da sie sich standardmäßig mitten in der Kugel an dem Punkt 0|0|0 befindet. Also stellen wir die Eigenschaft Position von der Camera ein wenig anders ein. Zu guter letzt definieren wir unsere Kugel als Zielobjekt (TargetObject), auf das die Kamera gerichtet sein soll. Das Ergebnis:

[[Bild:Tutorial GLScene html m151172de.png]]

Demotivierend, nicht? Naja, wenigstens ist was Rundes da. Das kommt daher, dass wir noch keine Lichtquelle definiert haben. Inzwischen dürfte der Weg aber klar sein: GLScene1 -> Scene objects -> Rechtsklick -> Add object -> LightSource. Dann verschieben wir noch schnell die Lichtquelle, wie immer mit einer kleinen Veränderung der Positionseigenschaft. Und schon haben wir unsere erste Szene fertig:

[[Bild:Tutorial GLScene html 17961123.png]]

Immer noch sehr schlicht, aber man muss natürlich den Arbeitsaufwand mit dem eines normalen Inits vergleichen, um jetzt darüber zu urteilen.

Wer durch unsere bisherigen (optischen) Ergebnisse etwas demotiviert wurde, dem verordne ich dringend mal einen Besuch im GLScene - Ordner Demos/bench/... !

==Zusätzliches==

Natürlich gibt es noch weitere Features, von denen ich hier mal ein paar aufzählen möchte:

Alles, was die Szene indirekt kosmetisch beeinflusst, ist bei der Eigenschaft Buffer des GLSceneViewers zu finden:

[[Bild:Tutorial GLScene html m549c3f82.png]]

Die meisten dürften sich selbst erklären. Da dies aber ein Tutorial für Anfänger sein soll, mal eine kleine Aufzählung:

:AntiAliasing: Wird verwendet, um pixelige Stufen zu vermeiden. Man hat hier mehrere Stufen zur Auswahl, die jeweilige Unterstützung hängt von der Grafikkarte und ihren Treibern ab.

[[Bild:Tutorial GLScene html m3d75de8.png|center]]

::Das umrahmte Bild zeigt eine „antialiasierte“ (grausam, dieses Wort, nicht?) Kugel. AntiAliasing hat aber den Nachteil, dass es den PC zum Teil enorm verlangsamen kann, sofern man nicht eine Grafikkarte von ATI ab einer Radeon 9500 Pro besitzt.

:BackgroundColor: Legt, wie könnte es anders sein, die Hintergrundfarbe des GLSceneViewers fest.

:ColorDepth: Hier kann man, wie bei den Desktop-Eigenschaften die Farbtiefe der Darstellung anpassen. Standard sind, glaube ich, 32 Bit (cddefault)

:ContextOptions: Hier können Veränderungen am Rendering-Kontext vorgenommen werden, wie z.B. der StencilBuffer aktiviert werden etc...

:DepthPrecision: Hat mehr oder weniger die gleiche Funktion wie ColorDepth.

:FaceCulling: Zeichnet nur die Vorderseiten von Objekten und bringt so mehr Frames. (Dazu gibt’s ein DGL – Tutorial)

:FogEnable: Aktiviert Nebel.

:FogEnvironment: Die Optionen des Nebels:

:FogColor: Hmm.. *scharf nachdenk* ach ja, Farbe des Nebels ;-)

:FogDistance: Legt fest, ob sich der Nebel kreis- oder würfelförmig um den Betrachter ausbreiten soll.

:FogEnd: Bestimmt die Entfernung zum Betrachter, ab der nichts mehr zu sehen ist.

:FogLinear: Dazu gibt’s schon ein Tutorial (von Lithander).

:FogStart: Gegenpart zu FogEnd und legt den Abstand zum Betrachter fest, ab dem der Nebel beginnt.

:Lighting: Aktiviert/Deaktiviert alle Lichtquellen.

:ShadeModel: Wie schön rund sollen z.B. Kugeln werden?

Als nächstes möchte ich mit euch noch einige Optionen der Objekte selbst durchgehen:

:Bottom (bei Kugeln): Hier kann man bestimmen, ob und wie die Kugel „beschnitten“ werden soll (mir ist hier nix Besseres eingefallen), am besten einfach mal Werte wie -20 eingeben.

:Material: Mit einem Klick auf ... öffnet man den Material Editor:

[[Bild:Tutorial GLScene html m7dc9f971.png|center]]

::Das hier ist mal das Texturfenster. Hier kann man ein Bild als Textur laden. Anschließend hat man einige Optionen zur Verfügung, am besten probiert ihr einfach mal ein bisschen rum, um die verschiedenen Effekte zu genießen. Wichtig ist nur, dass das Häkchen bei Disabled entfernt ist, da sonst keine Textur dargestellt wird (wird immer wieder gern vergessen). Ansonsten gibt’s halt noch die Register Front und Back, deren Optionen sich auch selbst erklären dürften. Um einfach die Farbe des Objekts zu verändern, geht man meist auf Front -> Diffuse.

:PitchAngle, RollAngle, TurnAngle: die Drehung des Objekts in um die Z-(PitchAngle), die X-(RollAngle) und die Y-Achse (TurnAngle)

:Slices und Stacks (bei Kugeln): Gibt an, aus wie vielen Teilen die Kugeln gemacht werden soll, sprich die „Rundheit“ (wo wird uns dieses Deutsch noch hinführen?)

:Stop (auch bei Kugeln): Eigentlich wie Bottom, nur wird die Kugel durch eine Senkrechte Ebene „beschnitten“ (ich geb`s auf)

:ShowAxes: Zeigt die Achsen an (ist eine meiner Lieblingsoptionen!)

:Visible: Ist wohl selbsterklärend ;)

==Der „Cadencer“==

[[Bild:Tutorial GLScene html m1130af53.png]]

Wenn man mit GLScene arbeitet, wird man zwangsläufig irgendwann mal mit dem Cadencer zu tun haben. Er ist nämlich das Wichtigste für Animationen und entspricht dem OnIdle aus der VCL. Im einzigen Ereignis des Cadencers, OnProgress, kann man dann z.B. Bewegungen nach dem Prinzip

<source lang="pascal">
Objekt.Position = Objekt.Position + Objekt.Geschwindigkeit
</source>

durchführen.

Der Cadencer ermöglicht es aber auch, frameunabhägige Bewegungen durchzuführen:

<source lang="pascal">
Objekt.Position = Objekt.Position + Objekt.Geschwindigkeit * Deltatime
</source>

==Objekte erzeugen, während das Programm läuft==

Wenn man z.B. einen Editor programmiert, wird man Objekte während des Renderns komplett neu erzeugen müssen.

Alle Objekte der Szene sind sogenannte GLCustomSceneObjects. Also definieren wir in einer Variablen-Sektion eine Variable nach dem Schema:

<source lang="pascal">
Objekt: TGLCustomSceneObject;
</source>

Um dann also ein Objekt zu erzeugen, müssen wir entscheiden, ob es ein sogenanntes Rootobject oder Childobject werden soll. Rootobjekte befinden sich in der Objekthierarchie ganz oben, Childobjekte sind immer einem Rootobjekt untergeordnet. Das zeige ich am besten mal mit folgendem Bild:

[[Bild:Tutorial GLScene html m325f1590.png]]

Der praktische Unterschied der beiden Arten ist, dass Rootobjekte automatisch an die Position 0|0|0 gesetzt werden. Childobjekte werden im Gegensatz dazu zwar auch an der Position 0|0|0 erstellt, jedoch relativ zu ihrem Rootobjekt. Das heißt, wenn man z.B. ein Rootobjekt an die Position 1|2|4 stellt, dann wird ein Childobjekt, das dann erstellt wird, auch an die Position 1|2|4 gebracht. Das ist ein bisschen kompliziert, am besten probiert ihr das einfach mal aus.

Nun aber zum praktischen Teil:

*Ein Rootobjekt erstellen
RootObjekt := GLScene.Objects.AddNewChild(TGLCube);
| |
TGLCustomSceneObject Typ des neuen Objekts

*Ein Childobjekt erstellen

ChildObjekt := RootObjekt.AddNewChild(TGLFrustrum);
| | |
TGLCustomSceneObject Das Rootobjekt des Childobjekts Typ des neuen Objekts

==Nachwort==

Das war’s erstmal. Ich hoffe, dass ich euch einen kleinen Überblick über die Materie habe geben können. Wie immer könnt ihr eure Fragen, eventuelle Fehler oder Ideen für ein weiterführendes Tutorial im Forum posten. Über Feedback würde ich mich natürlich auch sehr freuen!

Euer

'''La_Boda'''

{{TUTORIAL_NAVIGATION|-|[[Tutorial_WebGL]]}}

[[Kategorie:Tutorial|GLScene]]

Checkliste Allgemein

2011-07-15T20:44:33Z

Phlegmatiker: /* Grundlagen */ Schreibfehler, Grammatik

Hier gibt es eine allgemeine Checkliste, wenn ihr nichts oder nicht das seht, was ihr sehen wollt.

==Grundlagen==
*'''Benutzen Sie eine funktionierende Programmgrundlage (Template)?'''
:Wurde ein [[Template]] von DelphiGL.com benutzt, oder wurde das Template bereits erfolgreich getestet, dann kann von einer funktionierenden Programmgrundlage ausgegangen werden.

*'''Läuft das Programm ohne OpenGL-Fehler zu produzieren?'''
:Mittels eines Error-Handlers, wie er im "[[Tutorial_quickstart]]" beschrieben ist, wird dies überprüft.

==Was machen wenn...?==
* '''"Ich sehe nur die Fensterfarbe/garnichts"'''
** [[SwapBuffers]] fehlt?

* '''"Ich sehe nur schwarz"'''
** Hintergrundfarbe mal auf etwas anderes als schwarz stellen um zu schauen, ob das Objekt eventuell schwarz gezeichnet wird. Wenn ja:
*** Ist versehentlich eine Textur gesetzt? → glDisable(GL_TEXTURE_2D)
*** Versehentlich die falsche Farbe eingestellt? → glColor4f(1.0, 1.0, 1.0, 1.0)
** Folgende Tests testweise deaktivieren:
*** Tiefentest (GL_DEPTH_TEST)
*** Backfaceculling (GL_CULL_FACE)
*** Alphatest (GL_ALPHA_TEST)

* '''"Ich sehe nur die Hintergrundfarbe"'''
** Wenn diese schwarz ist, bitte oben nachschauen
** Ist die Projektionsmatrix richtig gesetzt ([[glOrtho]], [[gluPerspective]])?
** Ist der Viewport richtig gesetzt ([[glViewport]])?
** Ist das Objekt zwischen Near- und Far-Cull-Plane (gesetzt in der Projektion)? → ggf. mit [[glTranslate|glTranslatef]](0, 0, -z) experimentieren.
** Ist Culling aktiviert? Werden die Vertices in der richtigen Reihenfolge übergeben? ([[Tutorial_Lektion_5]])

Tutorial glsl

2011-07-15T20:40:59Z

Phlegmatiker: /* Die Shadersprache */

=Einleitung=
Hallo und willkommen bei meiner "Einführung" in GLSL (kurz für "Open'''GL''' '''S'''hading '''L'''anguage"), der offiziellen Hochlevel-Shadersprache von OpenGL. In diesem umfangreichen Dokument werde ich versuchen, sowohl auf die Nutzung (sprich das Laden und Anhängen von Shadern im Quellcode), als auch auf die Programmierung von Shadern selbst einzugehen, inklusive aller Sprachelemente der OpenGL Shadersprache. Es wird also auch recht viele Informationen zu der C-ähnlichen Programmstruktur und den von GLSL angebotenen Variablen und Attributen gehen. Am Ende dieser Einführung sollten alle die, die sich für das Thema interessieren, in der Lage sein, zumindest einfach Shader zu schreiben und auch in ihren Programmen zu nutzen. Ausserdem soll dieses Dokument gleichzeitig als ein deutsches "Pendant" zu den von Khronoes veröffentlichten Shaderspezifikationen, und damit als alltägliches Nachschlagewerk, dienen.

==Vorkenntnisse==
Wie auch schon mein ARB_VP-Tutorial richtet sich auch diese Einführung aufgrund ihrer Thematik eher an die fortgeschritteneren GL-Programmierer und neben sehr guten GL-Kenntnissen sollten sich alle, die sich daran versuchen wollen, mit den technischen Hintergründen der GL, wie z.B. dem Aufbau der Renderpipeline auskennen. Weiterhin sind C-Kenntnisse absolut erforderlich, da die Shader ja in einer an ANSI-C angelehnten Syntax geschrieben werden. Auch Begriffsdefinitionen zu Vertex oder Fragment werden zum Verständis dieser Einführung benötigt. Wer also noch am Anfang seiner GL-Karriere steht, dem wird dieses Dokument nicht viel nützen. Ganz nebenbei solltet ihr auch noch eine gehörige Portion Zeit (am besten nen kompletten Nachmittag) mitbringen, denn die folgende Kost ist nicht nur umfangreich, sondern auch manchmal recht schwer verdaulich.

=Was ist GLSL?=
Wie Eingangs kurz angesprochen handelt es sich bei GLSL um eine Shadersprache, also um eine Hochsprache, in der man die programmierbaren Teile aktueller Grafikbeschleuniger nach eigenem Belieben programmieren kann. Sie stellt quasi den Nachfolger zu den in Assembler geschriebenen Vertex- und Fragmentprogrammen ([[GL_ARB_Vertex_Program]]/[[GL_ARB_Fragment_Program]]) dar und basiert auf ANSI C, erweitert um Vektor- und Matrixtypen sowie einige C++-Mechanismen.

Die in GLSL geschriebenen Programme nennen sich, angepasst an die Terminologie von RenderMan und DirectX, [[Shader]] (im Gegensatz zu "Programme" bei ARB_VP/FP) und werden entweder auf Eckpunkte (VertexShader), Fragmente (FragmentShader) angewendet, oder (neuerdings, ab Shadermodell 4.0) auch genutzt um Geometrie zu erstellen (Geometryshader). Andere Teile der Renderpipeline (z.B. die Rasterisierung) können momentan noch nicht durch Shader beeinflusst werden, was allerdings in Zukunft noch kommen kann.

==Voraussetzungen==

GLSL wurde 2005 mit OpenGL 1.5 eingeführt. Während es in Sachen Treiber- und Hardwareunterstützung anfänglich noch dürftig aussah, wird man inzwischen keine Grafikkarte mehr kaufen können die nicht zumindest Vertex- und Fragmentshader beherscht. Geometrieshader hingegen sind relativ neu und wurden erst mit Shadermodell 4.0 eingeführt, hier ist es also unter Umständen noch möglich dass selbst aktuelle Treiber/Karten keine Geometrieshader beherrschen.

Natürlich benötigt man auch einen passenden OpenGL-Header der die für GLSL nötigen Funktionen exportiert. Ich verweise dazu auf unseren eigenen OpenGL-Header [[DGLOpenGL.pas]], der peermanent auf dem aktuellsten Stand gehalten wird und auch Support für Geometrieshader mitbringt.

==Extensions==

Die GL-Shadersprache "besteht" in ihrer aktuellen Version aus folgenden Extensions, fürs Verständnis wäre es nicht schlecht, wenn ihr euch zumindest die Einleitungen dazu durchlest :
* [[GL_ARB_Shader_Objects]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shader_objects.txt Orginal Spezifikation])
: Definiert die API-Aufrufe die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.
* [[GL_ARB_Vertex_Shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt Orginal Spezifikation])
: Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.
* [[GL_ARB_Fragment_Shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt Orginal Spezifikation])
: Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.
* [[GL_ARB_Shading_Language_100]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shading_language_100.txt Orginal Spezifikation])
: Gibt die unterstützte Version von glSlang an, momentan 1.00.

'''Hinweis''' : Seit OpenGL 2.0 ist GLSL Teil des Kerns. Wenn die Karte als OpenGL 2.0 unterstützt, dann unterstützt sie auch (zumindest in Software) Vertex- und Fragmentshader.

==Sprachversionen==

Neben der OpenGL-Version und dem vorhandenen Shadermodell (das eher an DirectX ausgerichtet ist), bietet auch GLSL verschiedene Versionen, die entsprechend erweiterte Funktionalität bieten.

Auslesen kann man die verfürgbare GLSL-Version wie folgt :

glGetString(GL_SHADING_LANGUAGE_VERSION)

Erst ab Version 1.4. kann man davon ausgehen dass GLSL alle Features des Shadermodells 4.0 liefert, ab 1.3 grob gesagt Shadermodell 3.0 (bei GLSL lässt sich das leider nicht so leicht unterteilen).

Ausserdem kann man seinem Shader eine Versionsnummer verpassen. Sollte der Shadercompiler (also Treiber bzw. Hardware) diese Version nicht unterstützen, gibt dieser eine Fehlermeldung heraus :

#version 1.50

''(Hinweis : Muss am Anfang des Shaders stehen)''

==Objekte==

Im Zuge der Vereinheitlichung der GL wird immer häufiger in Objekte gekapselt, deren API dann auch aneinander angelehnt ist. Ziel ist, dabei die Programmierung der GL uniform zu machen, so dass z.B. zwischen dem Erstellen und Verwalten eines Vertex-Buffer-Objektes oder eines Shader-Objektes kaum ein Unterschied besteht (demnächst kommen dann auch Pixel-Buffer-Objekte dazu). Mit glSlang wurden dann im Zuge dieser Aktion zwei neue Objekte eingeführt, deren Definition ihr euch unbedingt einprägen solltet :

* '''Programmobjekt'''
:Ein Objekt, an das die Shader später angebunden werden. Bietet Funktionalität zum Linken der Shader und prüft dabei die Kompatibilität zwischen Vertex- und Fragmentshader.

* '''Shaderobjekt'''
:Dieses Objekt verwaltet den Quellcodestring eines Shaders und ist entweder vom Typ '''GL_VERTEX_SHADER''', '''GL_FRAGMENT_SHADER_ARB''' oder '''GL_GEOMETRY_SHADER'''.

==Ressourcen==

Die Shadersprache ist keinesfalls final und es wurden bereits diverse Ausdrücke für zukünftige Verwendung reserviert, denn ein Ziel bei ihrer Entwicklung war es, sie so zukunftsorientiert zu gestalten, dass auch Grafikkarten der nächsten und übernächsten Generation voll ausgenutzt werden können. Damit einher geht die Tatsache, dass sich die Spezifikationen in Zukunft ändern/erweitern werden, weshalb man da immer einen Blick hineinwerfen sollte. Die Anlaufstelle dafür ist die [http://www.opengl.org/documentation/specs/ Spezifikationenliste auf OpenGL.org].

=GLSL im Programm=
Bevor wir uns mit der Syntax von glSlang beschäftigen, zeige ich euch erstmal, wie ihr Shader in euer Programm einbindet und nutzt. Warum das zuerst? Ganz einfach deshalb, weil ihr dann das, was ihr im glSlang-Syntaxteil lernt, direkt in eurer Testanwendung verwenden könnt. Hoffe diese Entscheidung klingt logisch und findet Anklang.

Zuerst benötigen wir natürlich unsere Objekte. Zum einen ein ''Programmobjekt'', an das unsere Shader gebunden werden, und zwei ''Shaderobjekte'', die den Quellcode unseres Vertex bzw. Fragment Shaders aufnehmen. Dazu wurde eigens der neue "Datentyp" {{INLINE_CODE|glHandle}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandle;
VertexShaderObject : GLhandle;
FragmentShaderObject : GLhandle;

Nach dieser Deklaration können wir dann damit beginnen unsere Objekte zu erstellen. Den Anfang macht das Programmobjekt :

ProgramObject := glCreateProgram;

Die Funktion [[glCreateProgram]] erstellt uns oben ein leeres Programmobjekt und gibt ein gültiges Handle darauf zurück.

Weiter gehts mit der Erstellung unseres Vertex bzw. Fragment Shaders :

VertexShaderObject := glCreateShader(GL_VERTEX_SHADER);
FragmentShaderObject := glCreateShader(GL_FRAGMENT_SHADER);

[[glCreateShader]] dient zur Generierung eines leeren Shaderobjektes. Momentan unterstützt diese Funktion VertexShader und FragmentShader.

Nachdem wir nun also zwei gültige Shaderobjekte haben, wollen wir diese auch mit entsprechendem Quellcode versorgen :

glShaderSource(VertexShaderObject, 1, @ShaderText, @ShaderLength);
glShaderSource(FragmentShaderObject, 1, @ShaderText, @ShaderLength);

Via [[glShaderSource]] setzen wir den Quellcode eines Shaderobjektes ''komplett'' neu. Zum Laden des Quellcodes bietet sich unter Delphi übrigens eine TStringList geradezu an. Es sollte beachtet werden, dass der Quellcode zu diesem Zeitpunkt ''nicht geparst'' wird, also keine Fehleruntersuchung stattfindet.

Der Quellcode wurde jetzt also an unsere Shaderobjekte gebunden und sollte dann natürlich auch noch kompiliert werden :

glCompileShader(VertexShaderObject);
glCompileShader(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShader]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der Shadercompiler (je nach Treiber) recht detaillierte Infos aus. Wie man an diese Infos kommt könnt ihr gleich nachlesen.

Wenn unsere Shader dann kompiliert werden konnten, ist es Zeit, diese an unser anfangs erstelltes Programmobjekt anzuhängen :

glAttachShader(ProgramObject, VertexShaderObject);
glAttachShader(ProgramObject, FragmentShaderObject);

Nachdem die Shaderobjekte nun an das Programmobjekt angehängt wurden, werden diese nicht mehr benötigt und ihre Resourcen können freigegeben werden :

glDeleteShader(VertexShaderObject);
glDeleteShader(FragmentShaderObject);

Am Schluß müssen wir dann noch unsere ans Programmobjekt gebundenen Shader linken :

glLinkProgram(ProgramObject);

Während [[glCompileShader]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgram]] die angehangenen Shader zu einem ausführbaren Shader gelinkt. Folgende Bedingungen führen zu einem '''Linkerfehler''':

* Die Zahl der von der Implementation unterstützten Attributvariablen wurde überschritten
* Der Speicherplatz für Uniformvariablen wurde überschritten
* Die Zahl der von der Implementation angebotenen Sampler wurde überschritten
* Die main-Funktion fehlt
* Die Liste der Varying-Variablen des Vertexshaders stimmt nicht mit der des Fragmentshaders überein
* Funktions- oder Variablenname nicht gefunden
* Eine gemeinsame Globale ist mit unterschiedlichen Werten oder Typen initialisiert worden
* Zwei Sampler unterschiedlichen Typs zeigen auf die selbe Textureneinheit
* Ein oder mehrere angehangene(r) Shader wurden nicht erfolgreich kompiliert

Die Nutzung von glSlang im eigenen Programm ist wie oben erkennbar also nicht wirklich schwer und innerhalb kurzer Zeit realisiert. Natürlich ist es auch möglich z.B. nur einen VertexShader oder nur einen FragmentShader an ein Programmobjekt zu binden.

Noch eine kleine Notiz zum Löschen der Shader mittel [[glDeleteShader]] : Da Shader(objekte) einen Referenzzähler besitzen und erst gelöscht werden wenn diese nirgendwo mehr benötigt werden, ist es nicht falsch diese vor dem Linkvorgang zu löschen. Allerdings spielt es letztendlich keine Rolle ob die Löschanweisung vorher der nachher ausgeführt wird.

==Fehlererkennung==
Natürlich wird es ohne Fehlerausgabe recht schwer, etwaige Probleme in einem Vertex- oder Fragmentshader zu finden. Doch auch in diesem Bereich wurde glSlang recht gut durchdacht und es wurden zwei Funktionen eingeführt, welche im Zusammenspiel die Fehlersuche recht einfach machen, nämlich [[glGetShaderInfoLog]] und [[glGetShader]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH}}. Erstere Funktion liefert uns einen Logstring, während uns letztere Funktion dessen Länge angibt. Der Logstring wird verändert, sobald ein Shader kompiliert oder ein Programm gelinkt wird.

Um die Ausgabe dieses Logs so einfach wie möglich zu machen, bietet es sich an beide in einer einfach Funktion unterzubringen :

<source lang="pascal">function glSlang_GetInfoLog(pShader: GLHandleARB): String;
var
blen, slen: GLInt;
InfoLog: PGLCharARB;

begin
glGetShaderiv(glObject, GL_INFO_LOG_LENGTH , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen * SizeOf(GLCharARB));
glGetShaderInfoLog(pShader, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</source>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetShaderiv}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetShaderInfoLog}} in {{INLINE_CODE|InfoLog}} ausgeben und liefern diesen als Ergebnis zurück.

Wie bereits gesagt wird nur nach dem Kompilieren eines Shaders bzw. dem Linken eines Programmobjektes ein Infolog erstellt. Es bietet sich dadurch an, direkt danach einen solchen Aufruf zu machen :

glCompileShader(VertexShaderObject);
ShowMessage(glSlang_GetInfoLog(VertexShaderObject));

Wenn unser Vertex Shader komplett fehlerfrei kompiliert werden konnte, dann sehen wir als Ergebnis nur einen leeren Dialog. Ist dies nicht der Fall, so werden wir vom Treiber mit recht detaillierten Fehlerinformationen "belohnt", z.B. so :

[[Bild:GLSL_error_vshader.jpg]]

Auch das Infolog nach dem Linken des Programmobjektes dürfte, selbst wenn keine Fehler vorkommen, recht interessant sein, das sieht dann nämlich so aus :

[[Bild:GLSL info programobject.jpg]]

Wie zu sehen, wird uns nach dem erfolgreichen Linken auch gesagt, ob und welcher Shader in Hardware bzw. Software läuft. Für Debuggingzwecke sicherlich eine mehr als brauchbare Information.

==Shader benutzen==
Um den Shader auch für die nächsten Polygone zu benutzen oder Uniformparameter übergeben zu können, ruft man die Funktion
glUseProgramt(ProgramObject);
um alle Shader zu deaktivieren, ruft man dieselbe Funktion mit dem Parameter 0.

==Parameterübergabe==
Uniformparameter (mehr dazu später) stellen die Schnittstelle zwischen eurem Programm und dem Shader dar, werden also genutzt um Daten aus dem Programm heraus an einen Shader zu übergeben. Zur Übergabe dieser Parameter bietet OpenGL diverse Funktionen, die alle Abkömmlinge von [[glUniform]] sind. Während mit {{INLINE_CODE|glUniform4f}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fv}} ganze Matrizen schnell und einfach übergeben. Ausserdem gibt es nun die Möglichkeit Uniformparameter direkt über ihren Namen, statt wie unter ARB_FP/VP über einen festen Index zu adressieren. Die Funktion [[glGetUniformLocationARB]] gibt anhand des übergebenen Parameternamens dessen Position zurück. Man kann also ganz einfach über den Namen drauf zugreifen :

glUniform3f(glGetUniformLocation(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1i(glGetUniformLocation(ProgramObject, PGLCharARB('texSamplerTMU3')), 3);

Wichtig ist hier, das man je nach Parametertyp auch die passende Anzahl von Argumenten übergibt. Also für einen 4-Komponenten Floatvektor {{INLINE_CODE|glUniform4fARB}} und für einen einfachen Integerwert (z.B. Textureinheit für einen Sampler) glUnifrom1iARB. Auch nicht vergessen dürft ihr, das die Namen der Parameter genauso wie im Shader geschrieben werden müssen, also Groß- und Kleinschreibung beachtet werden muß.

=Die Shadersprache=

Nachdem wir uns mit der Einbindung der glSlang-Shader in unser Programm beschäftigt haben, wollen wir uns in den folgenden Kapiteln um die Sprachelemente von glSlang kümmern. Wie schon gesagt basiert glSlang auf ANSI-C, wurde allerdings um speziell auf den Zielbereich angepasste Vektor- und Matrixtypen und einige C++-Features wie das freie deklarieren von Variablen an jeder Stelle und das Funktionsüberladen auf Basis des Argumenttyps erweitert. Wer sich ein wenig mit C/C++ auskennt sollte also in der nun folgenden Materie keine Probleme bekommen.

'''Obligatorische Hinweise für verwöhnte Delphi-Nutzer : '''
*Wie von C/C++ her gewohnt, spielt auch in glSlang die Groß- und Kleinschreibung eine wichtige Rolle, also bitte achtet darauf. gl_Position ist eine komplett andere Variable als z.B. gl_position.
*Es findet keine automatische Typenkonvertierung statt. Das bedeutet also das float MyFloat = 1 ungültig ist und es in dem Falle float MyFloat = 1.0 heissen muss. Typecasts müssen also immer manuell stattfinden, z.B. MyFloat = float(MyInt).

'''Kleine Programmstrukturkunde für C-Unkundige :'''<br>
Da sicherlich einige Delpher nie richtig was mit C gemacht haben, zeige ich mal anhand eines kleinen Beispieles (das auf keinen Fall nen brauchbaren Shader darstellt) den grundlegenden Aufbau eines glSlang-Shaders, der natürlich dem Aufbau eines C-Programmes stark ähnelt :
<source lang="glsl">
uniform vec4 VariableA;
float VariableB;
vec3 VariableC;
const float KonstanteA = 256.0;

float MyFunction(vec4 ArgumentA)
{
float FunktionsVariableA = float(5.0);

return float(ArgumentA * (FunktionsVariableA + KonstanteA));
}

// Ich bin ein Kommentar
/* Und ich auch */
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Sieht doch recht bekannt aus, unser Programmaufbau. Delphi und C haben ja so einige Grundlagen gleich, darunter auch der ungefähre Programmaufbau. Ausserhalb jeglicher Funktionen legen wir am Programmanfang unsere Variablen, Konstanten und Attribute fest, die dann ''global'' nutzbar sind, also in jeder Funktion.

Darunter deklarieren wir dann eine kleine Funktion. Wie auch bei den Variablendeklarationen wird hier der Rückgabetyp nicht wie bei Pascal nach dem Funktionsnamen untergebracht, sondern davor. Innerhalb der Funktion können dann wieder Variablen deklariert werden, die dann allerdings ''lokal'', also nur in dieser Funktion nutzbar sind. Vorteil dieser Deklaration ist die Tatsache, dass je nach Grafikkarte nur bestimmt viele globale Variablen deklariert werden können. Wenn möglich sollte man also mit lokalen Vorlieb nehmen. Unsere Funktion gibt dann natürlich noch via return einen Wert zurück, ''was gemacht werden muss'', sofern man diese nicht als void deklariert hat (entspräche dann einer Prozedur in Pascal). Wird dies nicht getan, so spuckt der Compiler einen Fehler aus.

Auch wichtig sind natürlich Kommentare. Erste Variante (Doppelslash) ist auch in der Pascalwelt verfügbar und kommentiert eine einzelne Zeile aus. Die Variante darunter kann man für Kommentarblöcke nutzen (/* .. */) und entspricht den Kommentaren in geschweiften Klammern in Delphi.

Danach kommt dann die '''wichtigste Funktion''' des Shaders, nämlich '''main''', die in keinem Shader fehlen darf. Sie stellt quasi den Programmkörper dar und ist oft auch die einzige Funktion in einem Shader. Sie erhält weder ein Argument, noch gibt sie einen Wert zurück.

Soviel also zum grundlegenden Aufbau eines Shader. Hoffe das jetzt alle die in C nicht so bewandert sind damit klar kommen, und dann bald ihre ersten glSlang-Shader schreiben können.

==Datentypen==

Obwohl einige Datentypen aus C übernommen wurden, sieht man der Typenliste an, das diese speziell auf den 3D-Bereich zugeschnitten wurde. Variablen müssen vor ihrer Nutzung eindeutig deklariert sein, Typecasting erfolgt über Konstruktoren (dazu später mehr). Folgende Datentypen stehen sowohl im Vertex- als auch Fragmentshader zur Verfügung :

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|void
|Für Funktionen die keinen Wert zurückgeben
|-
|bool
|Konditionaler Typ, entweder true (wahr) oder false (falsch)
|-
|int
|Vorzeichenbehafteter Integerwert
|-
|float
|Fließkommaskalar mit Singlegenauigkeit (32 Bit)
|-
|vec2
|2-Komponenten Fließkommavektor
|-
|vec3
|3-Komponenten Fließkommavektor
|-
|vec4
|4-Komponenten Fließkommavektor
|-
|bvec2
|2-Komponenten Booleanvektor
|-
|bvec3
|3-Komponenten Booleanvektor
|-
|bvec4
|4-Komponenten Booleanvektor
|-
|ivec2
|2-Komponenten Integervektor
|-
|ivec3
|3-Komponenten Integervektor
|-
|ivec4
|4-Komponenten Integervektor
|-
|mat2
|2x2 Fließkommamatrix
|-
|mat3
|3x3 Fließkommamatrix
|-
|mat4
|4x4 Fließkommamatrix
|}

Die sampler-Typen stellen eine besondere Klasse zum Zugriff auf Texturen dar, und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler2DRect
|Zugriff auf Texturen die nicht 2^n * 2^n entsprechen ("non power-of-two", NPOT)
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|samplerCubeShadow
|Zugriff auf Tiefentextur in einer Cubemap (z.b. für omni-diretionale Lichtquellen)
|-
|sampler2DRectShadow
|Zugriff auf 2D-NPOT-Tiefentextur
|-

|sampler1DArray
|Zugriff auf ein array aus 1D-Texturen
|-
|sampler2DArray
|Zugriff auf ein array aus 2D-Texturen
|-
|sampler1DArrayShadow
|Zugriff auf ein array aus 1D-Tiefentexturen
|-
|sampler2DArrayShadow
|Zugriff auf ein array aus 2D-Tiefentexturen
|-
|samplerBuffer
|Zugriff auf eine Puffertextur (1D-Texutr zum Speichern von Pufferobjekten)
|-
|sampler2DMS
|Zugriff auf eine 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|sampler2DMSArray
|Zugriff auf einarray aus 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|}

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<source lang="glsl">
float temp[3];
</source>
beginnt also bei Index 0 und endet bei Index 2. Im Gegensatz zu C lassen sich Arrays in glSlang allerdings ''nicht bei der Initialisierung vorbelegen''. Wenn ein Array als Parameter einer Funktion deklariert wird, so darf dieses keine Dimensionierung erhalten.

===Strukturen===

Neu ggü. ARB_FP/VP ist nun auch die Möglichkeit, Strukturen in einem Shader zu deklarieren. Vor allem die Übersicht komplexerer Shader kann dadurch stark verbessert werden. Strukturen werden wie gewohnt mit dem Schlüsselwort {{INLINE_CODE|struct}} eingeleitet und können dann zur Typisierung von Variablen genutzt werden. Folgendes Beispiel dürfte die Nutzung verdeutlichen :
<source lang="glsl">
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</source>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<source lang="glsl">
light LightSource[3];
</source>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<source lang="glsl">
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</source>

==Typenqualifzierer==

Zusätzlich zur Typendeklaration kann eine Variable noch einen Typenqualifizerer vorangestellt bekommen, der an den Anfang der Deklaration gehört.

* '''const'''
: Festgelegte (nur lesen) Konstante bzw. nur lesbarer Funktionsparameter.

* '''uniform'''
: Ein den ganzen Shader über gleichbleibender Wert, der eine Schnittstelle zwischen dem Shader und der OpenGL-Anwendung darstellt. Ein Uniformwert wird in der Hauptanwendung an den entsprechenden Shader übergeben und kann dort dann genutzt werden.

* '''attribute'''
: Nur lesbare Werte die eine Verbindung zwischen dem Shader und der OpenGL-VertexAPI darstellen (z.B. VertexParameter eines VertexArrays). Natürlich nur in einem Vertex Shader nutzbar.

* '''varying'''
: Stellt die Verbindung zwischen einem Vertex- und einem FragmentShader dar. Werden im VertexShader geschrieben und dann perspektivisch korrekt über die Primitive interpoliert, um dann im Fragment Shader gelesen werden zu können. Nutzbar sind hier nur die Typen float, vec2, vec3, vec4, mat2, mat3 und mat4, Strukturen und andere Datentypen können nicht varying sein. Die Namen einer varying-Variable müssen sowohl im VertexShader als auch im FragmentShader gleich sein.

* '''in'''
: Für Variablen die an eine Funktion übergeben und dort ausgelesen werden.

* '''out'''
: Für Variablen die von einer Funktion nach aussen zurückgegeben werden.

* '''inout'''
: Für Variablen die sowohl an eine Funktion übergeben als auch von dieser zurückgegeben werden.

Um obige Auflistung nicht leer im Raum stehen zu lassen zeige ich ein paar Beispiele die hoffentlich zum Verständnis beitragen :

===Beispiel A===
Vertexnormale soll an einen FragmenShader (interpoliert) übergeben werden :

:Im VertexShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</source>
:Im FragmentShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</source>

===Beispiel B===
Uniformparameter zur nachträglichen Farbänderung der Szene wird im Programm übergeben :

:Im VertexShader :
<source lang="glsl">
uniform vec4 GlobalColor;
...
gl_FrontColor = GlobalColor * gl_Color;
</source>
:Im Programm :

glUniform4fARB(glSlang_GetUniLoc(ProgramObject, 'GlobalColor'), Col[0], Col[1], Col[2], Col[3]);

===Beispiel C===
Konstante zur festen Farbänderung :

:Im VertexShader :
<source lang="glsl">
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</source>
==Konstruktoren==

Um in einem Shader ''Vektoren'' oder ''Matrizen'' mit Werten zu belegen, gibt es sogenannte Konstruktoren (nicht zu verwechseln mit z.B. Klassenkonstruktoren unter Delphi), die im Endeffekt nichts anderes als Funktionen zur Vorbelegung von Vektoren oder Matrizen darstellen. Dabei trägt der Konstruktor den selben Namen wie die Typendeklaration, also lässt sich eine Variable vom Typ {{INLINE_CODE|vec4}} mit dem Konstruktor {{INLINE_CODE|vec4(float, float, float, float)}} initialisieren.

Allerdings hat man sich recht viel Mühe bei dieser Konstruktorgeschichte gemacht, so dass man einen vec4 nicht unbedingt mit einem {{INLINE_CODE|vec4}}-Konstruktor vorbelegen muss, sondern es vielseitige Möglichkeiten gibt. Um dies zu verdeutlichen gibts ein paar Beispiele :
<source lang="glsl">
vec4 Color = vec4(1.0, 0.0, 0.0, 0.0);
vec4 Color = vec4(MyVec3, 1.0);
vec4 Color = vec4(MyVec2_A, MyVec2_B);

vec3 LVec = vec3(MyVec4);
vec2 Tmp = vec2(MyVec3);
</source>

Trotz der recht wenigen Beispiele sollte schnell erkennbar sein, das man hier wirklich sehr viele Kombinationsmöglichkeiten hat, die dann gültig sind ''wenn man mindestens auf die benötigte Anzahl der Argumente kommt''. Im vorletzten Beispiel wird z.B. ein 3-Komponentenvektor aus einem 4-Komponentenvektor initialisiert. Das erzeugt keinen Fehler, sondern führt dazu das {{INLINE_CODE|vec3.x, vec3.y, vec3.z}} aus MyVec4 übernommen werden und MyVec4.w einfach ignoriert wird.

Das Umkehrbeispiel, also
<source lang="glsl">
vec4 Color = vec4(MyVec3)
</source>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<source lang="glsl">
vec4 Color = vec4(MyVec3, 0.0)
</source>
heissen.

Obiges gilt natürlich auch für ''Matrixkonstruktoren'', hier sind z.B. folgende Konstuktoren denkbar, obwohl eigentlich alle Möglichkeiten nutzbar sind, ''solange die benötigte Zahl an Argumenten erreicht wird'' :
<source lang="glsl">
mat4 MyMatrix = mat4(MyVec4, MyVec4, MyVec4, MyVec4);
mat2 MyMatrix = mat4(1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
0.0, 0.0, 0.0, 1.0);
</source>

==Vektor- und Matrixkomponenten==

Was natürlich in keiner Shadersprache fehlen darf, ist der leichte Zugriff auf die einzelnen Komponenten eines Vektors. glSlang bietet, je nach Anwendungsgebiet gleich drei Namensets für den Zugriff auf die Komponenten eines solchen Vektors, welches Set man nutzen will bleibt natürlich frei und ist unabhängig von der Deklaration eines Vektors. Man sollte nur darauf achten, beim gleichzeitigen Zugriff auf mehrere Komponenten im gleichen Namenset zu verbleiben :

* {x, y, z, w}
:Für den Zugriff auf Vektoren die Punkte, Normale oder sonstige Vertexdaten repräsentieren.

* {r, g, b, a}
:Für den Zugriff auf Vektoren die Farbwerte repräsentieren.

* {s, t, p, q}
:Für den Zugriff auf Vektoren die Texturkoordinaten repräsentieren.

Ein paar Beispiele zur Unterstreichung des oben gesagten :
<source lang="glsl">
v4.rgba = vec4(1.0, 0.0, 0.0, 0.0); // gültig
v4.rgzw = vec4(1.0, 1.0, 1.0, 2.0); // Ungültig, da verschiedenen Namensets
v2.rgb = vec3(1.0, 2.0, 1.0); // Ungültig, da vec2 nur r+g besitzt
v2.xx = vec2(5.0, 3.0); // Ungültig, da 2 mal gleiche Komponente
</source>

Auch der Zugriff auf die Komponenten einer Matrix geht leicht von der Hand. Namensets wie bei den Vektoren gibt es hier natürlich keine, aber folgende Beispiele sollen den Zugriff aufzeigen :
<source lang="glsl">
MyMat4[2] = vec4(1.0); // Setzt die 3.Zeile der Matrix komplett auf 1.0
MyMat4[3][3] = 3.5; // Setzt das Element unren rechts auf 3.5
</source>

Ein Zugriff auf Matrixelemente ausserhalb ihrer Dimension (also z.B. MyMat4[4][4]) liefert unvorhersehabre Ergebnise, also sollte man auf diese Fälle prüfen.

==Vektor- und Matrixoperationen==

Wie von C gewohnt sind in glSlang so ziemlich alle Operatoren die man auf Matrizen oder Vektoren anwenden kann überladen, so das man nicht umständlich über selbstgeschriebene Funktionen kombinieren muss. Darüber hinaus ist es in den meisten Fällen auch möglich ohne Konvertierung Fließkommawerte mit kompletten Matrizen oder Vektoren zu kombinieren. Folgende Beispiele zeigen einige der vielfältigen Kombinationsmöglichkeiten auf :
<source lang="glsl">
vec3 dest;
vec3 source;
float factor;

vec3 dest = source + factor;

// Ist gleich
dest.x = source.x + factor;
dest.y = source.y + factor;
dest.z = source.z + factor;
</source>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<source lang="glsl">
vec3 dest;
vec3 source;
mat3 MyMat;

dest = source * MyMat;

// Ist gleich
dest.x = dot(source, MyMat[0]);
dest.y = dot(source, MyMat[1]);
dest.z = dot(source, MyMat[2]);
</source>

Auch hier sind die Möglichkeiten fast unbeschränkt und zeigen wieder wie flexibel glSlang ausgelegt ist.

==Operatoren==

glSlang bietet (momentan) folgende Operatoren, die Liste ist nach ihrer Gewichtung sortiert (Anfang = höchste). Alle ''reservierten'' Operatoren werden erst in kommender Hardware/glSlang-Versionen nutzbar sein :

<div align="center">
{|{{Prettytable_B1}}
!Operatorklasse
!Operatoren
!Assoziation
|-
|Gruppering
|()
| -
|-
|Arrayindizierung<br>Funktionsaufrufe und Konstruktoren<br>Strukturfeldwahl und Swizzle<br>Postinkrement und -dekrement<br>
|[]<br>()<br>.<br>++ --
|Links n. Rechts
|-
|Prefixinkrement- und dekrement<br>Einheitlich (~ reserviert)
| ++ --<br> + - ~ !
|Rechts n. Links
|-
|Mulitplikation (% reserviert)
|* / %
|Links n. Rechts
|-
|Additiv
| + -
|Links n. Rechts
|-
|Bitweises Verschieben (reserviert)
|<< >>
|Links n. Rechts
|-
|Relation
|< > <= >=
|Links n. Rechts
|-
|Vergleich
|== !=
|Links n. Rechts
|-
|Bitweises AND (reserviert)
|&
|Links n. Rechts
|-
|Bitweises XOR (reserviert)
|^
|Links n. Rechts
|-
|Bitweises OR (reserviert)
| <nowiki>|</nowiki>
|Links n. Rechts
|-
|Logisches AND
|&&
|Links n. Rechts
|-
|Logisches XOR
|^^
|Links n. Rechts
|-
|Logisches OR
| <nowiki>||</nowiki>
|Links n. Rechts
|-
|Auswahl
|?:
|Rechts n. Links
|-
|Zuweisung<br>Arithmetrische Zuweisung<br>(Modulis, Shift und bitweise Op. reserviert)
|<nowiki>=</nowiki><br> <nowiki>+= -= *= /= %=</nowiki> <br> <nowiki><<= >>= &= ^= |=</nowiki>
|Rechts n. Links
|-
|Aufzählung
|,
|Links n. Rechts
|-
|}
</div>

==Funktionen==

Ein großer Vorteil von Hochsprachen ist u.A. die Möglichkeit oft genutzte Codeteile in Funktionen (bzw. auch Prozeduren unter Pascal) zu verpacken um so Flexibilität als auch Übersichtlichkeit zu steigern. Wer schonmal was in C geschrieben hat, der wird sich jetzt sicherlich kein Kopfzerbrechen machen müssen. Funktionen werden in glSlang genauso nach folgendem Prinzip deklariert :
<source lang="glsl">
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</source>

Funktionen die ''nichts zurückgeben'' müssen mit dem RückgabeTyp {{INLINE_CODE|void}} deklariert werden, ausserdem entfällt dann logischerweise das {{INLINE_CODE|return}}. Falls die Funktion eines ihrere Argumente nach aussen übergeben soll, muss dieses Argument mit dem Typenqualifizierer out (Siehe Kapitel 4.2) versehen werden. ''Arrays'' können nur als Eingabeargumente übergeben werden und dürfen nich dimensioniert als Argument verwendet werden, sondern müssen mit leeren Klammern argumentiert werden.
Ein paar Beispiele :
<source lang="glsl">
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</source>

Diese Funktion gibt ''nichts'' zurück, aber gibt EingabeWert*MyConstValue im Ausgabeargument AusgabeWert nach aussen.
<source lang="glsl">
float MeineFunktion(float EingabeWert)
{
return EingabeWert*MyConstValue;
}
</source>

Bietet genau die selbe Funktionalität wie das Beispiel darüber. Allerdings wird hier der berechnete Wert als Ergebnis der Funktion zurückgeliefert.
<source lang="glsl">
float VektorSumme(float v[])
{
return v[0]+v[1]+v[2]+v[3];
}
</source>

Wie bereits gesagt darf ein Array als Argument keine Dimensionierung enthalten. Wenn man der Funktion also ein Array übergibt, sollte man vorher drauf achten das es entsprechend der in der Funktion genutzten Indizes dimensioniert wurde.

==if-Anweisung==

Selektion über eine if-Anweisung darf auch in keiner Hochsprache fehlen. Genauso wie in C oder Delphi erwartet auch hier die If-Anweisung einen boolschen Ausdruck (Wahr oder Falsch) und wird dann ausgeführt (wahr) bzw. verzweigt auf ein (wenn vorhanden) else (falsch). Verschachtelung ist wie erwartet auch möglich.

'''Hinweis : '''
Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten im Fragmentshader kein Early-Out, was zur Folge hat das bei einer If-Anweisung immer alle Zweige ausgeführt werden. Am Ende wird dann aber nur ein Ergebnis geschrieben, die anderen verworfen. Auf solchen Karten bringen If-Anweisungen also im Normalfall keine Geschwindigkeitssteigerung, sondern oft eher das Gegenteil.
Neuere SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall, da hier dynamische Verzweigungen und auch Early-Out von der Hardware implementiert werden.

==Schleifen==

Auch Schleifen, ein wichtiges Konzept jeder Hochsprache haben ihren Weg in glSlang gefunden. Unterstützt werden folgende Schleifentypen :

* '''for'''-Schleife
<source lang="glsl">
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck)
{
statement
}
</source>

* '''while'''-Schleife
<source lang="glsl">
while (Durchlaufbedingung)
{
statement
}
</source>

* '''do'''-while-Schleife
<source lang="glsl">
do
{
statement
}
while (Durchlaufbedingung)
</source>

'''Hinweis :''' Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten Schleifen nicht in Hardware. Schleifen werden dann beim Kompilieren vom Treiber entrollt, wodurch natürlich Shader mit weitaus mehr Instruktionen als erwartet generiert werden. Von daher sollte man auf solchen Karten möglichst auf Schleifen verzichten, oder diese nur recht kurz halten. Bei SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall.

=Eingebaute Variablen, Attribute und Konstanten=
Nachdem wir uns nun lange genug mit den minderinterssanten Elementen der glSlang-Syntax beschäftigt haben, gehts jetzt endlich an die wirklich interessanten Dinge. Wie schon ARB_VP/ARB_FP bringt auch glSlang jede Menge eingabauter Variablen, Attribute und Konstanten mit, deren Aliase sie recht leicht identifizierbar machen (ganz im Gegensatz zum Indexgewusel bei den DX-Shadern).

==Variablen im Vertex Shader==
Exklusiv im Vertex Shader stehen die folgenden Variablen zur Verfügung :

* vec4 gl_Position muss geschrieben werden
:Dieser Variable '''muss''' im Vertexshader ein Wert zugewiesen werden, wird dies nicht getan ist das Ergebnis (sprich die Position des Vertex) undefiniert. Vorgesehen ist diese Variable für die ''homogene Position des Vertex'' und wird u.a. zum Clipping und Culling verwendet. Sie darf natürlich auch (mehrfach) geschrieben und ausgelesen werden.

* float gl_PointSize kann geschrieben werden
:Diese Variable wurde dazu vorgesehen um dort im VertexShader die Punktgröße in Pixeln hineinzuschreiben.

* vec4 gl_ClipVertex kann geschrieben werden
:Falls genutzt, sollten hier die Vertexkoordinaten die im Zusammenhang mit benutzerdefinierten Clippingplanes genutzt werden abgelegt werden. Wichtig ist, das gl_ClipVertex im selben Koordinatenraum wie die Clippingplane definiert ist.

==Attribute im Vertex Shader==

Folgende Attribute stehen nur im Vertex Shader zur Verfügung und '''können nur gelesen werden''' :

* vec4 gl_Color
: Farbwert des Vertex.
* vec4 gl_SecondaryColor
:Sekundärer Farbwert des Vertex.
* vec4 gl_Normal
:Normale des Vertex.
* vec4 gl_Vertex
:Koordinaten des Vertex;
* vec4 gl_MultiTexCoord0..7
:Texturkoordinaten auf Textureinheit 0..7.
* float gl_FogCoord
:Nebelkoordinate des Vertex.

==Variablen im Fragment Shader==

Im Fragment Shader sind folgende Variablen exklusiv nutzbar :

* vec4 gl_FragColor
: Speichert den Farbwert des Fragmentes, der von folgenden Funktionen der festen Pipeline genutzt wird. Wird dieser Variable nichts zugewiesen, so ist ihr Inhalt undefiniert und darauf aufbauende Ergebnisse ebenfalls.

* vec4 gl_FragData[0..15]
: Ersetzt gl_FragColor bei der Verwendung von multiplen Rendertargets.

* float gl_FragDepth
: Durch schreiben dieser Variable kann man den von der festen Funktionspipeline ermittelten Tiefenwert überspringen, der mit {{INLINE_CODE|gl_FragCoord.z}} ausgelesen werden kann. Wird dieser Wert nicht geschrieben, nutzen folgende Funktionen der Pipeline den vorher fest berechneten Wert.

* vec4 gl_FragCoord nur lesen
: In dieser Variable ist die Position des Fragmentes relativ zur Fensterposition im Format x,y,z,1/w abgelegt, wobei z den von der festen Funktionspipeline berechneten Tiefenwert enthält.

* bool gl_FrontFacing nur lesen
: Gibt an ob das Fragment zu einer nach vorne zeigenden Primitive gehört (=true).

Im Bezug auf {{INLINE_CODE|gl_FragColor}} und {{INLINE_CODE|gl_FragDepth}} sei noch anzumerken das diese ''nicht'' in den Wertebereich 0..1 gebracht werden müssen, da dies später durch die feste Funktionspipeline automatisch gemacht wird.

==Eingebaute Varyings==

Wie bereits in Kapitel 4.2 erwähnt, stellen Varyings eine Schnittstelle zwischen dem Vertex und dem Fragment Shader dar. Sie werden im Vertex Shader geschrieben und können dann im Fragment Shader ausgelesen werden, ohne das die folgenden Varyings dafür explizit deklariert werden müssen :

* vec4 gl_FrontColor
: Farbe der Vorderseite des Vertex.

* vec4 gl_BackColor
: Farbe der Rückseite des Vertex.

* vec4 gl_FrontSecondaryColor
: Sekundäre Farbe der Vorderseite des Vertex.

* vec4 gl_BackSecondaryColor
: Sekundäre Farbe der Rückseite des Vertex.

* vec4 gl_TexCoord[x]
: Texturkoordinaten des Vertex auf Textureinheit x, wobei x die von der Hardware zur Verfügung gestellte Zahl der Textureinheiten-1 nicht überschreiten darf.

* float gl_FogFragCoord
: Nebelkoordinate des Fragmentes.

Die Varyings {{INLINE_CODE|gl_FrontColor, gl_FrontSecondaryColor, gl_BackColor}} und {{INLINE_CODE|gl_BackSecondaryColor}} können im FragmentShader nur unter den Aliases gl_Color bzw. gl_SecondaryColor gelesen werden. Welcher Wert des Vertex Shaders im Fragment Shader dort eingesetzt wird ist abhängig davon ob das Fragment zu einer nach vorne oder nach hinten zeigenden Primitive gehört.

==Eingebaute Konstanten==
Auch diverse Konstanten wurden definiert um darauf schnell im Shader zugreifen zu können. In den Klammern stehen die von einer GL-Implementation als Mindestanforderung anzubietenden Werte. Alle Konstanten sind sowohl im Vertex als auch im Fragment Shader abrufbar :

: OpenGL 1.0/1.2 :
* int gl_MaxLights (8)
* int gl_MaxClipPlanes (6)
* int gl_MaxTextureUnits (2)

: ARB_Fragment_Program :
* int gl_MaxTextureCoordsARB (2)

: Vertex_Shader :
* int gl_MaxVertexAttributesGL2 (16)
* int gl_MaxVertexUniformFloatsGL2 (512)
* int gl_MaxVaryingFloatsGL2 (32)
* int gl_MaxVertexTextureUnitsGL2 (1)

: Fragment_Shader :
* int gl_MaxFragmentTextureUnitsGL2 (2)
* int gl_MaxFragmentUniformFloatsGL2 (64)

==Eingebaute Uniformvariablen==

Um den Zugriff auf OpenGL-Staten zu vereinfachen wurden in glSlang diverse Uniformvariablen zur direkten Verwendung im Shader eingebaut. Wie gewohnt wurden auch hier sinnvolle Namen verwendet, so dass eine tiefere Erklärung unnötig sein dürfte :

* mat4 gl_ModelViewMatrix
* mat4 gl_ProjectionMatrix
* mat4 gl_ModelViewProjectionMatrix
* mat3 gl_NormalMatrix
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die invertierten und anschließend transponierten oberen 3x3 Werte der {{INLINE_CODE|gl_ModelViewMatrix}}.
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]

* float gl_NormalScale
: Gibt den unter OpenGL festgelegten Faktor zur Skalierung der Normalen zurück.

* struct gl_DepthRangeParameters
<source lang="glsl">
struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;
</source>
: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
<source lang="glsl">
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</source>
*struct gl_MaterialParameters
<source lang="glsl">
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</source>
*struct gl_LightSourceParameters
<source lang="glsl">
struct gl_LightSourceParameters
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
vec4 position;
vec4 halfVector;
vec3 spotDirection;
float spotExponent;
float spotCutoff;
float spotCosCutoff;
float constantAttenuation;
float linearAttenuation;
float quadraticAttenuation;
};
gl_LightSourceParameters gl_LightSource[gl_MaxLights];
</source>
*struct gl_LightModelParameters
<source lang="glsl">
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</source>
*struct gl_LightModelProducts
<source lang="glsl">
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</source>
*struct gl_LightProducts
<source lang="glsl">
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</source>
* vec4 gl_TextureEnvColor[gl_MaxFragmentTextureUnitsGL2]
* vec4 gl_EyePlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneQ[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneQ[gl_MaxTextureCoordsARB]

*struct gl_FogParameters
<source lang="glsl">
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</source>
Diese recht umfangreiche GL-Stateliste sollte eigentlich jeden Bedarf decken und momentan gibts kaum einen OpenGL-Status den man so nicht in einem Shader abfragen bzw. nutzen kann.

=Eingebaute Funktionen=
glSlang ist mit diversen Skalar- und Vektorfunktionen ausgestattet, die teilweise (idealerweise) sogar direkt in der Hardware ausgeführt werden, weshalb einer fertigen Funktion ggü. gleichwertigen eigenen Berechnungen immer der Vorzug zu geben ist.
{{Hinweis| ''genType'' kann vom Type float, vec2, vec3 oder vec4 sein, ''mat'' vom Typ mat2, mat3 oder mat4.}}

==Trigonometrie und Winkel==
Alle übergebenen Winkel sollten, soweit nicht anders vermerkt, in Radien angegeben werden.

* genType radians (genType degrees)
: Wandelt von Grad nach Radien.
* genType degrees (genType radians)
: Wandelt von Radien nach Grad.
* genType sin (genType angle)
: Gibt den Sinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType cos (genType angle)
: Gibt den Cosinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType tan (genType angle)
: Gibt den Tangens von Angle zurück, wobei Angle in Radien angegeben wird.
* genType asin (genType x)
: Liefert den Arcsinus von x zurück, also den Winkel dessen Sinus x ergeben würde.
* genType acos (genType x)
: Liefert den Arccosinus von x zurück, also den Winkel dessen Cosinus x ergeben würde.
* genType atan (genType y, genType x)
: Liefert den Winkel zurück, dessen Tangens x/y ergeben würde.
* genType atan (genType y_over_x)
: Liefert den Winkel zurück, dessen Tangens x über y ergeben würde.

==Exponentiell==
* genType pow (genType x, genType y)
: Gibt x hoch y zurück.
* genType exp2 (genType x)
: Gibt 2 hoch x zurück.
* genType log2 (genType x)
: Gibt den Logarithmus zur Basis 2 von x zurück.
* genType sqrt (genType x)
: Gibt die Wurzel von x zurück.
* genType inversesqrt (genType x)
: Gibt die umgekehrte Wurzel von x zurück.

==Standardfunktionen==
* genType abs (genType x)
: Liefert den absoluten Wert von x zurück.
* genType sign (genType x)
: Gibt -1.0 zurück, wenn x < 0.0, 0.0 wenn x = 0.0 und 1.0 wenn x > 0.0.
* genType floor (genType x)
: Gibt denn nächsten Integerwert zurück, der kleiner oder gleich x ist.
* genType ceil (genType x)
: Gibt den nächsten Integerwert zurück, der größer oder gleich x ist.
* genType fract (genType x)
: Gibt den Nachkommateil von x zurück.
* genType mod (genType x, float y)
* genType mod (genType x, genType y)
: Gibt den Modulus zurück. (=x-y * floor(x/y))
* genType min (genType x, genType y)
* genType min (genType x, float y)
: Liefert y zurück wenn y < x, ansonsten x.
* genType max (genType x, genType y)
* genType max (genType x, float y)
: Liefert y zurück wenn x < y, ansonsten x.
* genType clamp (genType x, genType minVal, genType maxVal)
* genType clamp (genType x, float minVal, float maxVal)
: Zwängt x in den Bereich minVal..maxVal.
* genType mix (genType x, genType y, genType a)
* genType mix (genType x, genType y, float a)
: Liefert den linearen Blend zwischen x und y zurück. (= x * (1-a) + y * a)
* genType step (genType edge, genType x)
* genType step (float edge, genType x)
: Liefert 0.0 zurück, wenn x <= edge, ansonsten 1.0.
* genType smoothstep (genType edge0, genType edge1, genType x)
* genType smoothstep (float edge0, float edge1, genType x)
: Liefert 0.0 zurück, wenn x <= edge und 1.0 wenn x >= edge. Dabei wird eine weiche Hermite Interpolation zwischen 0 und 1 durchgeführt.

==Geometrie==
* float length (genType x)
: Gibt die Länge des Vektors x (= sqrt(x[0]² + x[1]² + ... + x[n]²) zurück.
* float distance (genType p0, genType p1)
: Gibt die Distanz zwischen den zwei Vektoren p0 un p1 (= length(p0-p1)) zurück.
* float dot (genType x, genType y)
: Gibt das Punktprodukt von x und y zurück (=x[0]*y[0] + x[1]*y[1] + ... + x[n]*y[n]).
* vec3 cross (vec3 x, vec3 y)
: Gibt das Kreuzprodukt von x und y zurück.
* genType normalize (genType x)
: Normalisiert den Vektor x auf die Länge 1.
* vec4 ftransform()
: Nur im Vertex Shader. Die Funktion stellt sicher, das das eingehende Vertex haargenau so transformiert wird wie in der festen Funktionspipeline. gl_Position = ftransform() wird dann also gebraucht, wenn in mehreren Durchgängen sowohl im Shader als auch in der festen Pipeline gerendert wird, um sicherzustellen das in beiden Fällen die gleiche Vertexposition herauskommt.
* genType faceforward (genType N, genType I, genType Nref)
: Gibt einen nach vorne zeigenden Vektor N zurück. (If dot(NRef, I) < 0 return N else return -N)
* genType reflect (genType I, genType N)
: Gibt den an der Flächenausrichtung N reflektierten Vektor I zurück. (=I-2 * dot(N,I) * N)

==Matrixfunktionen==
* mat matrixCompMult (mat x, mat y)
: Multipliziert Matrix X mit Matrix Y komponentenweise. Um eine normale lineare Matrixmultiplikation durchzuführen, sollte der "*"-Operator genutzt werden.

==Vektorvergleiche==
Die meisten Vektorvergleichsfunktionen liefern als Ergebnis einen boolvektor zurück, da die Vergleiche per Komponente stattfinden. Wenn man also x = vec4(1.0, 3.0, 0.0, 0.0) mit y = vec4(2.0, 1.5, 1.5, 0.0) via lessThan(x, y) vergleicht, erhält man als Ergebnis bvec(true, false, true, false).

* bvec lessThan (vec x, vec y)
* bvec lessThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x < y zurück.
* bvec lessThanEqual (vec x, vec y)
* bvec lessThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x <= y zurück.
* bvec greaterThan (vec x, vec y)
* bvec greaterThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x > y zurück.
* bvec greaterThanEqual (vec x, vec y)
* bvec greaterThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x >= y zurück.
* bvec equal (vec x, vec y)
* bvec equal (ivec x, ivec y)
* bvec equal (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x == y zurück.
* bvec notEqual (vec x, vec y)
* bvec notEqual (ivec x, ivec y)
* bvec notEqual (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x != y zurück.
* bool any (bvec x)
: Liefert true zurück, wenn mindestens eine der Komponenten von x true ist.
* bool all (bvec x)
: Liefert true zurück, wenn alle Komponenten von x true sind.
* bvec not (bvec x)
: Liefert die logische Negation von x zurück.

==Texturenzugriffe==

Diese wichtige Funktionskategorie dient dazu, Werte aus einer an eine Textureinheit gebundenen Textur zu ermitteln. Die Texturenzugriffe können sowohl im Vertex (!) als auch im Fragment Shader ausgeführt werden, wobei der optionale Parameter bias im Vertex Shader ignoriert wird. Allerdings gibt es zusätzlich Funktionen die auf "Lod" enden und nur im Vertex Shader genutzt werden dürfen um eben dieses Manko zu umgehen. Funktionen mit dem Suffix "Proj" geben einen projizierten Texturenwert zurück.

: '''1D-Texturen :'''
* vec4 texture1D (sampler1D sampler, float coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec2 coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture1DLod (sampler1D sampler, float coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec2 coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec4 coord, float lod)

: '''2D-Texturen :'''
* vec4 texture2D (sampler2D sampler, vec2 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

: '''3D-Texturen :'''
* vec4 texture3D (sampler3D sampler, vec3 coord [, float bias])
* vec4 texture3DProj (sampler3D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture3DLod (sampler3D sampler, vec3 coord, float lod)
* vec4 texture3DProjLod (sampler3D sampler, vec4 coord, float lod)

: '''Cubemap :'''
* vec4 textureCube (samplerCube sampler, vec3 coord [, float bias])
: Nur im Vertex Shader :
*vec4 textureCubeLod (samplerCube sampler, vec3 coord, float lod)

: '''Tiefentextur (Shadowmap) :'''
* vec4 shadow1D (sampler1DShadow sampler, vec3 coord [, float bias])
* vec4 shadow2D (sampler2DShadow sampler, vec3 coord [, float bias])
* vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord [, float bias])
* vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 shadow1DLod (sampler1DShadow sampler, vec3 coord, float lod)
* vec4 shadow2DLod (sampler2DShadow sampler, vec3 coord, float lod)
* vec4 shadow1DProjLod (sampler1DShadow sampler, vec4 coord, float lod)
* vec4 shadow2DProjLod (sampler2DShadow sampler, vec4 coord, float lod)

Wie bereits eingangs gesagt ist dieses Kapitel ein sehr wichtiges, denn eine 3D-Szene ohne Texturen ist heute kaum denkbar. Darüber hinaus lassen sich durch Texturenzugriffe recht viele interessante Sachen machen, z.B. ein einfacher Blurfilter oder das freie überblenden bestimmter Texturenteile. Deshalb führe ich hier kurz ein paar Beispiele an, welche die Nutzung dieser Funktionen verdeutlichen sollen :

===Beispiel A===
Eine Textur gebunden die einfach ausgegeben werden soll

''Im Vertex Shader'' :
<source lang="glsl">
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>
Der Vertex Shader ist recht minimal. Neben der homogenen Vertexposition leiten wir hier nur die im OpenGL-Programm angegebenen Texturkoordinaten weiter. ''Dies ist aber unbedingt nötig!'' Ohne die letzte Zeile hätten wir im Fragment Shader keine gültigen Texturkoordinaten auf TMU0, was in einer Fehldarstellung enden würde.

''im Fragment Shader'' :
<source lang="glsl">
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</source>
Zuerst deklarieren wir hier einen 2D-Texturensampler, wichtig : '''Texturensampler müssen IMMER als uniform deklariert werden!''' In der Hauptfunktion weisen wir dann einfach den über die Funktion texture2D aus unserer gebundenen Textur ausgelesenen Farbwert, anhand der vom Vertex Shader übergebenen Texturkoordinaten, zu.

===Beispiel B===
Zwei Texturen, jeweils auf TMU0 und TMU1. Fragmentfarbe soll eine Multiplikation der beiden Texturen darstellen.

In diesem Beispielfall (der recht häufig vorkommt) müssen wir im Programm festlegen, ''welcher Sampler welche Textureinheit adressiert'', genau deshalb müssen die Texturensampler auch als uniform deklariert werden. Die Standardtextureneinheit eines Samplers ist TMU0, was in unserem Falle natürlich nicht brauchbar ist. Also müssen wir unserem zweiten Textursampler im Programm mitteilen das er seine Daten aus TMU1 beziehen soll :

glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);

Dies ist also unbedingt zu machen, sobald ein Texturensampler eine Textureinheit > GL_TEXTURE_0 adressieren will. Die Textureneinheit des Samplers lässt sich also nicht im Shader selbst festlegen. Der Fragment Shader ist nun allerdings schnell hergeleitet (Vertex Shader verändert sich nicht, da TMU1 die Texturkoordinaten auch von TMU0 bezieht) :

im Fragment Shader :
<source lang="glsl">
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

void main(void)
{
gl_FragColor = texture2D(texSamplerTMU0, vec2(gl_TexCoord[0])) *
texture2D(texSamplerTMU1, vec2(gl_TexCoord[0]));
}
</source>

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich [[GLSL noise|Noisefunktionen]] nutzen, mit deren Hilfe sich eine gewisse "Zufälligkeit" simulieren lässt (wirklich zufällige Werte sind es natürlich nicht). Ein zurückgegebener Wert liegt dabei immer im Bereich [-1..1] und ist immer bei gleichem Eigabewert auch immer gleich. Die Verwendung empfiehlt sich derzeit allerdings eher nicht, da nicht alle aktuellen Treiber die Funktionen unterstützen und eine Noisetextur wahrscheinlich performanter ist.

* float noise1 (genType x)
* vec2 noise2 (genType x)
* vec3 noise3 (genType x)
* vec4 noise4 (genType x)

==Discard==
Eigentlich keine Funktion, sondern eine Abbruchbedingung '''nur im Fragment Shader'''. Das Schlüsselwort {{INLINE_CODE|discard}} verwirft das aktuell bearbeitete Fragment und beendet gleichzeitig den Shader. Es kann z.B. genutzt werden um Alphamasking manuell durchzuführen.
Man sollte dabei jedoch beachten dass ein Großteil der aktuellen Hardware kein "early-out" (frühes Beenden) im Fragmentshader unterstützt. Wenn dort also ein {{INLINE_CODE|discard}} auftaucht, wird trotzdem auch der Code danach ausgeführt und einfach verworfen. Einen Geschwindigkeitsvorteil durch diesen Befehl wird man also erst auf neueren Karten feststellen, die dieses Faeature auch so unterstützen wie es angedacht war.

=Beispielshader=
Wen bis hierhin nicht der Mut verlassen hat, und wer aufmerksam gelesen hat, dürfte jetzt also zumindest in der Lage sein kleinere Shader in glSlang zu schreiben und diese auch im Programm zu nutzen. Ich habe im Themenbereich "glSlang" versucht alle Bereiche der Shadersprache selbst anzusprechen und hoffe das auch brauchbar rübergebracht zu haben. Um oben erlerntes (hoffe ich doch mal) nochmal zu vertiefen werde ich jetzt (wie ich das bereits bei meinem ARB_VP-Tutorial getan habe) einen simplen Beispielshader (Vertex und Fragment Shader) auseinanderpflücken um so u.a. auch die Programmstruktur für alle die in C nicht so bewandert sind zu erörtern.

==Der Vertex Shader==
<source lang="glsl">
uniform vec4 GlobalColor;

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color * GlobalColor;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Wie gesagt recht simpel. Angefangen wird mit der Deklaration einer globalen Uniformvariable namens {{INLINE_CODE|GlobalColor}}. Wie wir uns erinnern gibt der Typenqualifizierer uniform an, das wir den Wert dieser Variable (ein 4-Komponentenvektor, da Farbwerte aus R,G,B und A bestehen) in unserem Programm an den Shader übermitteln.

Danach gehts ohne Umwege direkt in unsere Hauptfunktion, da wir im Vertex Shader keine anderen Funktionen benötigen. Dort berechnen wir zuerst die homogene Position unseres Vertex, die sich aus der eingehenden Vertexposition multipliziert mit der Modelansichtsmatrix ergibt. Wie schonmal gesagt '''muss diesem Wert etwas zugewiesen werden''', da sonst alle darauf aufbauenden Funktionen unvorhersehbare Ergebnisse liefern.
Ausserdem wollen wir die Frontfarbe unseres Vertex jedesmal mit der im Programm übergebenen GlobalColor multiplizieren, so dass wir den Farbwert der gesamten Szene aus unserem Programm heraus manipulieren können. Zu guterletzt geben wir dann noch unsere aus der festen Funktionspipeline erhaltenen Texturkoordinaten auf Textureinheit 0 weiter. Wenn im Fragmentshader Texturkoordinaten verwendet werden, '''muss das getan werden'''.

==Der Fragment Shader==
<source lang="glsl">
uniform sampler2D Texture0;
uniform sampler2D Texture1;
uniform sampler2D Texture2;
uniform sampler2D Texture3;

void main(void)
{
vec2 TexCoord = vec2( gl_TexCoord[0] );
vec4 RGB = texture2D( Texture0, TexCoord );

gl_FragColor = texture2D(Texture1, TexCoord) * RGB.r +
texture2D(Texture2, TexCoord) * RGB.g +
texture2D(Texture3, TexCoord) * RGB.b;
}
</source>

Auch hier passiert nicht wirklich viel Großartiges. Wir deklarieren beim Shaderanfang zuerst vier Texturensampler, da wir insgesamt vier verschiedene Texturen im Shader auslesen wollen, eine Verlaufstextur und drei Oberflächentexturen. Auch hier sei wieder gesagt das man Sampler '''immer als uniform deklarieren muss'''. In der Hauptfunktion deklarieren wir dann einen Farbvektor, der auch direkt einen Farbwert aus Textureinheit 0 zugewiesen bekommt. Auf Textureinheit 0 haben wir ihm Hauptprogramm eine Verlaufstextur gebunden, die angibt wie die drei folgenden Texturen ineinander geblendet werden.
Danach schreiben wir dann den Farbwert des Fragmentes, der '''im Fragment Shader ausgegeben werden muss'''. Der besteht wie einfach zu erkennen aus Farbwert von Textureinheit 1 * Rotwert von Textureinheit 0 + Farbwert von Textureinheit 2 * Grünwert von Textureinheit 0 + Farbwert von Textureinheit 3 * Blauwert von Textureinheit 0. So ist z.B. an Stellen an denen in der Verlaufstextur reines blau liegt nur die dritte Textur sichtbar.

So viel also zu unserem kleinen Beispielshader. Er ist weder besonders toll noch besonders sinnvoll, sollte aber auch eher dazu dienen euch glSlang ein wenig zu veranschaulichen, was mir hoffentlich gelungen ist.

Wenn ihr in den vorangegangenen Kapiteln zumindest ein wenig aufgepasst habt, dann könnt ihr euch vor eurem inneren Auge hoffentlich vortstellen was der Shader macht : Er blendet drei Texturen weich anhand der Verlaufstextur ineinander über. Sowas kann man z.B. für ein Terrain nutzen, um dieses anhand einer Farbtextur zu texturieren. Für alle, die damit Probleme haben hier zwei Bilder die den Shader veranschaulichen. Links die Verlaufstextur, die angibt wo welche Textur wie stark gewichtet wird und rechts dann das Ergebnis :

<div align="center"> [[BILD:GLSL_sample_shader_a.jpg]] [[BILD:GLSL_sample_shader_b.jpg]]</div>

=Post Mortem=
Das wars also, meine "Einführung" in die OpenGL Shader Sprache. Ich hoffe es hat euch nicht gelangweilt und auch die von mir zur Verfügung gestellten Informationen haben euch hoffentlich ausgereicht. Mit der Veröffentlichung dieser Einführung geht übrigens auch die Eröffnung eines Shaderforums hier auf der DGL einher, in der ihr dann also fleissig Fragen zum Thema stellen oder eure Shader präsentieren könnt. In diesem Post Mortem gehe ich jetzt noch kurz auf die Zukunft von glSlang ein und zeige ein paar Screenshots (damit die Augen entspannen können), bevor ihr euch dann selbst in die Shaderwelt stürzen könnt.

=Beispiele=

Anbei ein paar exemplarische Screenshots. Da man mit GLSL aber alle möglichen Effekte berechnen kann (u.a. auch 1:1 die feste Funktionspipeline) ist es hier unmöglich einen Überblick aller möglichen Techniken zu geben.

[[Datei:tut_glsl_eigenershader_01.png]] [[Datei:tut_glsl_eigenershader_02.png]] [[Datei:tut_glsl_eigenershader_03.png]]

Wie im ersten (und dritten) Screenshot zu sehen ist es natürlich auch möglich mehrere Techniken innerhalb einer Szene zu nutzen. Hier sind letztendlich bis auf Hardwarelimitationen keine Grenzen gesetzt.

=Die Zukunft=
Als dieses Tutorial geschrieben wurde, war noch nicht ganz abzusehen dass bzw. ob sich GLSL auch durchsetzen würde. ARB-Shadr und NVidias cG waren damals die Platzhirsche, aber inzwischen werden ARB-Shader nicht mehr genutzt (und auch schon länger nicht mehr weiterentwickelt) und auch NVidia setzt primär auf GLSL. GLSL wird permanent weiterenwtickelt und Hersteller können dank des flexiblen Extensionsystems auch in GLSL eigene Extensions offenlegen um die aktuellsten Features (wie z.b. den Tesselator auf aktuellen ATI-Karten) nutzen zu können. GLSL it als inzwischen auch offizielle die Shadersprache frü OpenGL und wird permanent an die neusten technischen Entwicklungen im Grafikkartenbereich angepasst.

Wer also unter OpenGL etwas mit Shadern machen möchte, kommt an GLSL nicht vorbei!

Also viel Spaß beim Experimentieren und Shaderschreiben! Und nicht vergessen : Wir wollen sehen was ihr so treibt,

Euer
:Sascha Willems

{{TUTORIAL_NAVIGATION|-|[[Tutorial_glsl2]]}}
[[Kategorie:Tutorial|GLSL]]

Tutorial glsl

2011-07-15T20:39:12Z

Phlegmatiker: /* Fehlererkennung */ Code gescheit eingerückt, auch wenn die Namenskonvention zu wünschen übrig lässt.

Tutorial glsl

2011-07-15T20:36:17Z

Phlegmatiker: /* Ressourcen */ OpenGL.org richtig geschrieben :)

=Einleitung=
Hallo und willkommen bei meiner "Einführung" in GLSL (kurz für "Open'''GL''' '''S'''hading '''L'''anguage"), der offiziellen Hochlevel-Shadersprache von OpenGL. In diesem umfangreichen Dokument werde ich versuchen, sowohl auf die Nutzung (sprich das Laden und Anhängen von Shadern im Quellcode), als auch auf die Programmierung von Shadern selbst einzugehen, inklusive aller Sprachelemente der OpenGL Shadersprache. Es wird also auch recht viele Informationen zu der C-ähnlichen Programmstruktur und den von GLSL angebotenen Variablen und Attributen gehen. Am Ende dieser Einführung sollten alle die, die sich für das Thema interessieren, in der Lage sein, zumindest einfach Shader zu schreiben und auch in ihren Programmen zu nutzen. Ausserdem soll dieses Dokument gleichzeitig als ein deutsches "Pendant" zu den von Khronoes veröffentlichten Shaderspezifikationen, und damit als alltägliches Nachschlagewerk, dienen.

==Vorkenntnisse==
Wie auch schon mein ARB_VP-Tutorial richtet sich auch diese Einführung aufgrund ihrer Thematik eher an die fortgeschritteneren GL-Programmierer und neben sehr guten GL-Kenntnissen sollten sich alle, die sich daran versuchen wollen, mit den technischen Hintergründen der GL, wie z.B. dem Aufbau der Renderpipeline auskennen. Weiterhin sind C-Kenntnisse absolut erforderlich, da die Shader ja in einer an ANSI-C angelehnten Syntax geschrieben werden. Auch Begriffsdefinitionen zu Vertex oder Fragment werden zum Verständis dieser Einführung benötigt. Wer also noch am Anfang seiner GL-Karriere steht, dem wird dieses Dokument nicht viel nützen. Ganz nebenbei solltet ihr auch noch eine gehörige Portion Zeit (am besten nen kompletten Nachmittag) mitbringen, denn die folgende Kost ist nicht nur umfangreich, sondern auch manchmal recht schwer verdaulich.

=Was ist GLSL?=
Wie Eingangs kurz angesprochen handelt es sich bei GLSL um eine Shadersprache, also um eine Hochsprache, in der man die programmierbaren Teile aktueller Grafikbeschleuniger nach eigenem Belieben programmieren kann. Sie stellt quasi den Nachfolger zu den in Assembler geschriebenen Vertex- und Fragmentprogrammen ([[GL_ARB_Vertex_Program]]/[[GL_ARB_Fragment_Program]]) dar und basiert auf ANSI C, erweitert um Vektor- und Matrixtypen sowie einige C++-Mechanismen.

Die in GLSL geschriebenen Programme nennen sich, angepasst an die Terminologie von RenderMan und DirectX, [[Shader]] (im Gegensatz zu "Programme" bei ARB_VP/FP) und werden entweder auf Eckpunkte (VertexShader), Fragmente (FragmentShader) angewendet, oder (neuerdings, ab Shadermodell 4.0) auch genutzt um Geometrie zu erstellen (Geometryshader). Andere Teile der Renderpipeline (z.B. die Rasterisierung) können momentan noch nicht durch Shader beeinflusst werden, was allerdings in Zukunft noch kommen kann.

==Voraussetzungen==

GLSL wurde 2005 mit OpenGL 1.5 eingeführt. Während es in Sachen Treiber- und Hardwareunterstützung anfänglich noch dürftig aussah, wird man inzwischen keine Grafikkarte mehr kaufen können die nicht zumindest Vertex- und Fragmentshader beherscht. Geometrieshader hingegen sind relativ neu und wurden erst mit Shadermodell 4.0 eingeführt, hier ist es also unter Umständen noch möglich dass selbst aktuelle Treiber/Karten keine Geometrieshader beherrschen.

Natürlich benötigt man auch einen passenden OpenGL-Header der die für GLSL nötigen Funktionen exportiert. Ich verweise dazu auf unseren eigenen OpenGL-Header [[DGLOpenGL.pas]], der peermanent auf dem aktuellsten Stand gehalten wird und auch Support für Geometrieshader mitbringt.

==Extensions==

Die GL-Shadersprache "besteht" in ihrer aktuellen Version aus folgenden Extensions, fürs Verständnis wäre es nicht schlecht, wenn ihr euch zumindest die Einleitungen dazu durchlest :
* [[GL_ARB_Shader_Objects]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shader_objects.txt Orginal Spezifikation])
: Definiert die API-Aufrufe die zum Erstellen, Kompilieren, Linken, Anhängen und Aktivieren von Shader- und Programmobjekten nötig sind.
* [[GL_ARB_Vertex_Shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_shader.txt Orginal Spezifikation])
: Fügt der OpenGL Programmierbarkeit auf Vertexebene hinzu.
* [[GL_ARB_Fragment_Shader]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/fragment_shader.txt Orginal Spezifikation])
: Fügt der OpenGL Programmierbarkeit auf Fragmentebene hinzu.
* [[GL_ARB_Shading_Language_100]] ([http://oss.sgi.com/projects/ogl-sample/registry/ARB/shading_language_100.txt Orginal Spezifikation])
: Gibt die unterstützte Version von glSlang an, momentan 1.00.

'''Hinweis''' : Seit OpenGL 2.0 ist GLSL Teil des Kerns. Wenn die Karte als OpenGL 2.0 unterstützt, dann unterstützt sie auch (zumindest in Software) Vertex- und Fragmentshader.

==Sprachversionen==

Neben der OpenGL-Version und dem vorhandenen Shadermodell (das eher an DirectX ausgerichtet ist), bietet auch GLSL verschiedene Versionen, die entsprechend erweiterte Funktionalität bieten.

Auslesen kann man die verfürgbare GLSL-Version wie folgt :

glGetString(GL_SHADING_LANGUAGE_VERSION)

Erst ab Version 1.4. kann man davon ausgehen dass GLSL alle Features des Shadermodells 4.0 liefert, ab 1.3 grob gesagt Shadermodell 3.0 (bei GLSL lässt sich das leider nicht so leicht unterteilen).

Ausserdem kann man seinem Shader eine Versionsnummer verpassen. Sollte der Shadercompiler (also Treiber bzw. Hardware) diese Version nicht unterstützen, gibt dieser eine Fehlermeldung heraus :

#version 1.50

''(Hinweis : Muss am Anfang des Shaders stehen)''

==Objekte==

Im Zuge der Vereinheitlichung der GL wird immer häufiger in Objekte gekapselt, deren API dann auch aneinander angelehnt ist. Ziel ist, dabei die Programmierung der GL uniform zu machen, so dass z.B. zwischen dem Erstellen und Verwalten eines Vertex-Buffer-Objektes oder eines Shader-Objektes kaum ein Unterschied besteht (demnächst kommen dann auch Pixel-Buffer-Objekte dazu). Mit glSlang wurden dann im Zuge dieser Aktion zwei neue Objekte eingeführt, deren Definition ihr euch unbedingt einprägen solltet :

* '''Programmobjekt'''
:Ein Objekt, an das die Shader später angebunden werden. Bietet Funktionalität zum Linken der Shader und prüft dabei die Kompatibilität zwischen Vertex- und Fragmentshader.

* '''Shaderobjekt'''
:Dieses Objekt verwaltet den Quellcodestring eines Shaders und ist entweder vom Typ '''GL_VERTEX_SHADER''', '''GL_FRAGMENT_SHADER_ARB''' oder '''GL_GEOMETRY_SHADER'''.

==Ressourcen==

Die Shadersprache ist keinesfalls final und es wurden bereits diverse Ausdrücke für zukünftige Verwendung reserviert, denn ein Ziel bei ihrer Entwicklung war es, sie so zukunftsorientiert zu gestalten, dass auch Grafikkarten der nächsten und übernächsten Generation voll ausgenutzt werden können. Damit einher geht die Tatsache, dass sich die Spezifikationen in Zukunft ändern/erweitern werden, weshalb man da immer einen Blick hineinwerfen sollte. Die Anlaufstelle dafür ist die [http://www.opengl.org/documentation/specs/ Spezifikationenliste auf OpenGL.org].

=GLSL im Programm=
Bevor wir uns mit der Syntax von glSlang beschäftigen, zeige ich euch erstmal, wie ihr Shader in euer Programm einbindet und nutzt. Warum das zuerst? Ganz einfach deshalb, weil ihr dann das, was ihr im glSlang-Syntaxteil lernt, direkt in eurer Testanwendung verwenden könnt. Hoffe diese Entscheidung klingt logisch und findet Anklang.

Zuerst benötigen wir natürlich unsere Objekte. Zum einen ein ''Programmobjekt'', an das unsere Shader gebunden werden, und zwei ''Shaderobjekte'', die den Quellcode unseres Vertex bzw. Fragment Shaders aufnehmen. Dazu wurde eigens der neue "Datentyp" {{INLINE_CODE|glHandle}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandle;
VertexShaderObject : GLhandle;
FragmentShaderObject : GLhandle;

Nach dieser Deklaration können wir dann damit beginnen unsere Objekte zu erstellen. Den Anfang macht das Programmobjekt :

ProgramObject := glCreateProgram;

Die Funktion [[glCreateProgram]] erstellt uns oben ein leeres Programmobjekt und gibt ein gültiges Handle darauf zurück.

Weiter gehts mit der Erstellung unseres Vertex bzw. Fragment Shaders :

VertexShaderObject := glCreateShader(GL_VERTEX_SHADER);
FragmentShaderObject := glCreateShader(GL_FRAGMENT_SHADER);

[[glCreateShader]] dient zur Generierung eines leeren Shaderobjektes. Momentan unterstützt diese Funktion VertexShader und FragmentShader.

Nachdem wir nun also zwei gültige Shaderobjekte haben, wollen wir diese auch mit entsprechendem Quellcode versorgen :

glShaderSource(VertexShaderObject, 1, @ShaderText, @ShaderLength);
glShaderSource(FragmentShaderObject, 1, @ShaderText, @ShaderLength);

Via [[glShaderSource]] setzen wir den Quellcode eines Shaderobjektes ''komplett'' neu. Zum Laden des Quellcodes bietet sich unter Delphi übrigens eine TStringList geradezu an. Es sollte beachtet werden, dass der Quellcode zu diesem Zeitpunkt ''nicht geparst'' wird, also keine Fehleruntersuchung stattfindet.

Der Quellcode wurde jetzt also an unsere Shaderobjekte gebunden und sollte dann natürlich auch noch kompiliert werden :

glCompileShader(VertexShaderObject);
glCompileShader(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShader]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der Shadercompiler (je nach Treiber) recht detaillierte Infos aus. Wie man an diese Infos kommt könnt ihr gleich nachlesen.

Wenn unsere Shader dann kompiliert werden konnten, ist es Zeit, diese an unser anfangs erstelltes Programmobjekt anzuhängen :

glAttachShader(ProgramObject, VertexShaderObject);
glAttachShader(ProgramObject, FragmentShaderObject);

Nachdem die Shaderobjekte nun an das Programmobjekt angehängt wurden, werden diese nicht mehr benötigt und ihre Resourcen können freigegeben werden :

glDeleteShader(VertexShaderObject);
glDeleteShader(FragmentShaderObject);

Am Schluß müssen wir dann noch unsere ans Programmobjekt gebundenen Shader linken :

glLinkProgram(ProgramObject);

Während [[glCompileShader]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgram]] die angehangenen Shader zu einem ausführbaren Shader gelinkt. Folgende Bedingungen führen zu einem '''Linkerfehler''':

* Die Zahl der von der Implementation unterstützten Attributvariablen wurde überschritten
* Der Speicherplatz für Uniformvariablen wurde überschritten
* Die Zahl der von der Implementation angebotenen Sampler wurde überschritten
* Die main-Funktion fehlt
* Die Liste der Varying-Variablen des Vertexshaders stimmt nicht mit der des Fragmentshaders überein
* Funktions- oder Variablenname nicht gefunden
* Eine gemeinsame Globale ist mit unterschiedlichen Werten oder Typen initialisiert worden
* Zwei Sampler unterschiedlichen Typs zeigen auf die selbe Textureneinheit
* Ein oder mehrere angehangene(r) Shader wurden nicht erfolgreich kompiliert

Die Nutzung von glSlang im eigenen Programm ist wie oben erkennbar also nicht wirklich schwer und innerhalb kurzer Zeit realisiert. Natürlich ist es auch möglich z.B. nur einen VertexShader oder nur einen FragmentShader an ein Programmobjekt zu binden.

Noch eine kleine Notiz zum Löschen der Shader mittel [[glDeleteShader]] : Da Shader(objekte) einen Referenzzähler besitzen und erst gelöscht werden wenn diese nirgendwo mehr benötigt werden, ist es nicht falsch diese vor dem Linkvorgang zu löschen. Allerdings spielt es letztendlich keine Rolle ob die Löschanweisung vorher der nachher ausgeführt wird.

==Fehlererkennung==
Natürlich wird es ohne Fehlerausgabe recht schwer, etwaige Probleme in einem Vertex- oder Fragmentshader zu finden. Doch auch in diesem Bereich wurde glSlang recht gut durchdacht und es wurden zwei Funktionen eingeführt, welche im Zusammenspiel die Fehlersuche recht einfach machen, nämlich [[glGetShaderInfoLog]] und [[glGetShader]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH}}. Erstere Funktion liefert uns einen Logstring, während uns letztere Funktion dessen Länge angibt. Der Logstring wird verändert, sobald ein Shader kompiliert oder ein Programm gelinkt wird.

Um die Ausgabe dieses Logs so einfach wie möglich zu machen, bietet es sich an beide in einer einfach Funktion unterzubringen :

<source lang="pascal">function glSlang_GetInfoLog(pShader : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetShaderiv(glObject, GL_INFO_LOG_LENGTH , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetShaderInfoLog(pShader, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</source>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetShaderiv}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetShaderInfoLog}} in {{INLINE_CODE|InfoLog}} ausgeben und liefern diesen als Ergebnis zurück.

Wie bereits gesagt wird nur nach dem Kompilieren eines Shaders bzw. dem Linken eines Programmobjektes ein Infolog erstellt. Es bietet sich dadurch an, direkt danach einen solchen Aufruf zu machen :

glCompileShader(VertexShaderObject);
ShowMessage(glSlang_GetInfoLog(VertexShaderObject));

Wenn unser Vertex Shader komplett fehlerfrei kompiliert werden konnte, dann sehen wir als Ergebnis nur einen leeren Dialog. Ist dies nicht der Fall, so werden wir vom Treiber mit recht detaillierten Fehlerinformationen "belohnt", z.B. so :

[[Bild:GLSL_error_vshader.jpg]]

Auch das Infolog nach dem Linken des Programmobjektes dürfte, selbst wenn keine Fehler vorkommen, recht interessant sein, das sieht dann nämlich so aus :

[[Bild:GLSL info programobject.jpg]]

Wie zu sehen, wird uns nach dem erfolgreichen Linken auch gesagt, ob und welcher Shader in Hardware bzw. Software läuft. Für Debuggingzwecke sicherlich eine mehr als brauchbare Information.

==Shader benutzen==
Um den Shader auch für die nächsten Polygone zu benutzen oder Uniformparameter übergeben zu können, ruft man die Funktion
glUseProgramt(ProgramObject);
um alle Shader zu deaktivieren, ruft man dieselbe Funktion mit dem Parameter 0.

==Parameterübergabe==
Uniformparameter (mehr dazu später) stellen die Schnittstelle zwischen eurem Programm und dem Shader dar, werden also genutzt um Daten aus dem Programm heraus an einen Shader zu übergeben. Zur Übergabe dieser Parameter bietet OpenGL diverse Funktionen, die alle Abkömmlinge von [[glUniform]] sind. Während mit {{INLINE_CODE|glUniform4f}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fv}} ganze Matrizen schnell und einfach übergeben. Ausserdem gibt es nun die Möglichkeit Uniformparameter direkt über ihren Namen, statt wie unter ARB_FP/VP über einen festen Index zu adressieren. Die Funktion [[glGetUniformLocationARB]] gibt anhand des übergebenen Parameternamens dessen Position zurück. Man kann also ganz einfach über den Namen drauf zugreifen :

glUniform3f(glGetUniformLocation(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1i(glGetUniformLocation(ProgramObject, PGLCharARB('texSamplerTMU3')), 3);

Wichtig ist hier, das man je nach Parametertyp auch die passende Anzahl von Argumenten übergibt. Also für einen 4-Komponenten Floatvektor {{INLINE_CODE|glUniform4fARB}} und für einen einfachen Integerwert (z.B. Textureinheit für einen Sampler) glUnifrom1iARB. Auch nicht vergessen dürft ihr, das die Namen der Parameter genauso wie im Shader geschrieben werden müssen, also Groß- und Kleinschreibung beachtet werden muß.

=Die Shadersprache=

Nachdem wir uns mit der Einbindung der glSlang-Shader in unser Programm beschäftigt haben, wollen wir uns in den folgenden Kapiteln um die Sprachelemente von glSlang kümmern. Wie schon gesagt basiert glSlang auf ANSI-C, wurde allerdings um speziell auf den Zielbereich angepasste Vektor- und Matrixtypen und einige C++-Features wie das freie deklarieren von Variablen an jeder Stelle und das Funktionsüberladen auf Basis des Argumenttyps erweitert. Wer sich ein wenig mit C/C++ auskennt sollte also in der nun folgenden Materie keine Probleme bekommen.

'''Obligatorische Hinweise für verwöhnte Delphi-Nutzer : '''
*Wie von C/C++ her gewohnt, spielt auch in glSlang die Groß- und Kleinschreibung eine wichtige Rolle, also bitte achtet darauf. gl_Position ist eine komplett andere Variable als z.B. gl_position.
*Es findet keine automatische Typenkonvertierung statt. Das bedeutet also das float MyFloat = 1 ungültig ist und es in dem Falle float MyFloat = 1.0 heissen muss. Typecasts müssen also immer manuell stattfinden, z.B. MyFloat = float(MyInt).

'''Kleine Programmstrukturkunde für C-Unkundige :'''<br>
Da sicherlich einige Delpher nie richtig was mit C gemacht haben, zeige ich mal anhand eines kleinen Beispieles (das auf keinen Fall nen brauchbaren Shader darstellt) den grundlegenden Aufbau eines glSlang-Shaders, der natürlich dem Aufbau eines C-Programmes stark ähnelt :
<source lang="glsl">
uniform vec4 VariableA;
float VariableB;
vec3 VariableC;
const float KonstanteA = 256.0;

float MyFunction(vec4 ArgumentA)
{
float FunktionsVariableA = float(5.0);

return float(ArgumentA * (FunktionsVariableA + KonstanteA));
}

// Ich bin ein Kommentar
/* Und ich auch */
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Sieht doch recht bekannt aus, unser Programmaufbau. Delphi und C haben ja so einige Grundlagen gleich, darunter auch der ungefähre Programmaufbau. Ausserhalb jeglicher Funktionen legen wir am Programmanfang unsere Variablen, Konstanten und Attribute fest, die dann ''global'' nutzbar sind, also in jeder Funktion.

Darunter deklarieren wir dann eine kleine Funktion. Wie auch bei den Variablendeklarationen wird hier der Rückgabetyp nicht wie bei Pascal nach dem Funktionsnamen untergebracht, sondern davor. Innerhalb der Funktion können dann wieder Variablen deklariert werden, die dann allerdings ''lokal'', also nur in dieser Funktion nutzbar sind. Vorteil dieser Deklaration ist die Tatsache, dass je nach Grafikkarte nur bestimmt viele globale Variablen deklariert werden können. Wenn möglich sollte man also mit lokalen Vorlieb nehmen. Unsere Funktion gibt dann natürlich noch via return einen Wert zurück, ''was gemacht werden muss'', sofern man diese nicht als void deklariert hat (entspräche dann einer Prozedur in Pascal). Wird dies nicht getan, so spuckt der Compiler einen Fehler aus.

Auch wichtig sind natürlich Kommentare. Erste Variante (Doppelslash) ist auch in der Pascalwelt verfügbar und kommentiert eine einzelne Zeile aus. Die Variante darunter kann man für Kommentarblöcke nutzen (/* .. */) und entspricht den Kommentaren in geschweiften Klammern in Delphi.

Danach kommt dann die '''wichtigste Funktion''' des Shaders, nämlich '''main''', die in keinem Shader fehlen darf. Sie stellt quasi den Programmkörper dar und ist oft auch die einzige Funktion in einem Shader. Sie erhält weder ein Argument, noch gibt sie einen Wert zurück.

Soviel also zum grundlegenden Aufbau eines Shader. Hoffe das jetzt alle die in C nicht so bewandert sind damit klar kommen, und dann bald ihre ersten glSlang-Shader schreiben können.

==Datentypen==

Obwohl einige Datentypen aus C übernommen wurden, sieht man der Typenliste an, das diese speziell auf den 3D-Bereich zugeschnitten wurde. Variablen müssen vor ihrer Nutzung eindeutig deklariert sein, Typecasting erfolgt über Konstruktoren (dazu später mehr). Folgende Datentypen stehen sowohl im Vertex- als auch Fragmentshader zur Verfügung :

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|void
|Für Funktionen die keinen Wert zurückgeben
|-
|bool
|Konditionaler Typ, entweder true (wahr) oder false (falsch)
|-
|int
|Vorzeichenbehafteter Integerwert
|-
|float
|Fließkommaskalar mit Singlegenauigkeit (32 Bit)
|-
|vec2
|2-Komponenten Fließkommavektor
|-
|vec3
|3-Komponenten Fließkommavektor
|-
|vec4
|4-Komponenten Fließkommavektor
|-
|bvec2
|2-Komponenten Booleanvektor
|-
|bvec3
|3-Komponenten Booleanvektor
|-
|bvec4
|4-Komponenten Booleanvektor
|-
|ivec2
|2-Komponenten Integervektor
|-
|ivec3
|3-Komponenten Integervektor
|-
|ivec4
|4-Komponenten Integervektor
|-
|mat2
|2x2 Fließkommamatrix
|-
|mat3
|3x3 Fließkommamatrix
|-
|mat4
|4x4 Fließkommamatrix
|}

Die sampler-Typen stellen eine besondere Klasse zum Zugriff auf Texturen dar, und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

{|{{Prettytable_B1}}
!Datentyp
!Erklärung
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler2DRect
|Zugriff auf Texturen die nicht 2^n * 2^n entsprechen ("non power-of-two", NPOT)
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|samplerCubeShadow
|Zugriff auf Tiefentextur in einer Cubemap (z.b. für omni-diretionale Lichtquellen)
|-
|sampler2DRectShadow
|Zugriff auf 2D-NPOT-Tiefentextur
|-

|sampler1DArray
|Zugriff auf ein array aus 1D-Texturen
|-
|sampler2DArray
|Zugriff auf ein array aus 2D-Texturen
|-
|sampler1DArrayShadow
|Zugriff auf ein array aus 1D-Tiefentexturen
|-
|sampler2DArrayShadow
|Zugriff auf ein array aus 2D-Tiefentexturen
|-
|samplerBuffer
|Zugriff auf eine Puffertextur (1D-Texutr zum Speichern von Pufferobjekten)
|-
|sampler2DMS
|Zugriff auf eine 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|sampler2DMSArray
|Zugriff auf einarray aus 2D-Textur mit mehreren Samplepunkten (z.b. für Multisampling)
|-
|}

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<source lang="glsl">
float temp[3];
</source>
beginnt also bei Index 0 und endet bei Index 2. Im Gegensatz zu C lassen sich Arrays in glSlang allerdings ''nicht bei der Initialisierung vorbelegen''. Wenn ein Array als Parameter einer Funktion deklariert wird, so darf dieses keine Dimensionierung erhalten.

===Strukturen===

Neu ggü. ARB_FP/VP ist nun auch die Möglichkeit, Strukturen in einem Shader zu deklarieren. Vor allem die Übersicht komplexerer Shader kann dadurch stark verbessert werden. Strukturen werden wie gewohnt mit dem Schlüsselwort {{INLINE_CODE|struct}} eingeleitet und können dann zur Typisierung von Variablen genutzt werden. Folgendes Beispiel dürfte die Nutzung verdeutlichen :
<source lang="glsl">
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</source>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<source lang="glsl">
light LightSource[3];
</source>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<source lang="glsl">
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</source>

==Typenqualifzierer==

Zusätzlich zur Typendeklaration kann eine Variable noch einen Typenqualifizerer vorangestellt bekommen, der an den Anfang der Deklaration gehört.

* '''const'''
: Festgelegte (nur lesen) Konstante bzw. nur lesbarer Funktionsparameter.

* '''uniform'''
: Ein den ganzen Shader über gleichbleibender Wert, der eine Schnittstelle zwischen dem Shader und der OpenGL-Anwendung darstellt. Ein Uniformwert wird in der Hauptanwendung an den entsprechenden Shader übergeben und kann dort dann genutzt werden.

* '''attribute'''
: Nur lesbare Werte die eine Verbindung zwischen dem Shader und der OpenGL-VertexAPI darstellen (z.B. VertexParameter eines VertexArrays). Natürlich nur in einem Vertex Shader nutzbar.

* '''varying'''
: Stellt die Verbindung zwischen einem Vertex- und einem FragmentShader dar. Werden im VertexShader geschrieben und dann perspektivisch korrekt über die Primitive interpoliert, um dann im Fragment Shader gelesen werden zu können. Nutzbar sind hier nur die Typen float, vec2, vec3, vec4, mat2, mat3 und mat4, Strukturen und andere Datentypen können nicht varying sein. Die Namen einer varying-Variable müssen sowohl im VertexShader als auch im FragmentShader gleich sein.

* '''in'''
: Für Variablen die an eine Funktion übergeben und dort ausgelesen werden.

* '''out'''
: Für Variablen die von einer Funktion nach aussen zurückgegeben werden.

* '''inout'''
: Für Variablen die sowohl an eine Funktion übergeben als auch von dieser zurückgegeben werden.

Um obige Auflistung nicht leer im Raum stehen zu lassen zeige ich ein paar Beispiele die hoffentlich zum Verständnis beitragen :

===Beispiel A===
Vertexnormale soll an einen FragmenShader (interpoliert) übergeben werden :

:Im VertexShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</source>
:Im FragmentShader :
<source lang="glsl">
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</source>

===Beispiel B===
Uniformparameter zur nachträglichen Farbänderung der Szene wird im Programm übergeben :

:Im VertexShader :
<source lang="glsl">
uniform vec4 GlobalColor;
...
gl_FrontColor = GlobalColor * gl_Color;
</source>
:Im Programm :

glUniform4fARB(glSlang_GetUniLoc(ProgramObject, 'GlobalColor'), Col[0], Col[1], Col[2], Col[3]);

===Beispiel C===
Konstante zur festen Farbänderung :

:Im VertexShader :
<source lang="glsl">
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</source>
==Konstruktoren==

Um in einem Shader ''Vektoren'' oder ''Matrizen'' mit Werten zu belegen, gibt es sogenannte Konstruktoren (nicht zu verwechseln mit z.B. Klassenkonstruktoren unter Delphi), die im Endeffekt nichts anderes als Funktionen zur Vorbelegung von Vektoren oder Matrizen darstellen. Dabei trägt der Konstruktor den selben Namen wie die Typendeklaration, also lässt sich eine Variable vom Typ {{INLINE_CODE|vec4}} mit dem Konstruktor {{INLINE_CODE|vec4(float, float, float, float)}} initialisieren.

Allerdings hat man sich recht viel Mühe bei dieser Konstruktorgeschichte gemacht, so dass man einen vec4 nicht unbedingt mit einem {{INLINE_CODE|vec4}}-Konstruktor vorbelegen muss, sondern es vielseitige Möglichkeiten gibt. Um dies zu verdeutlichen gibts ein paar Beispiele :
<source lang="glsl">
vec4 Color = vec4(1.0, 0.0, 0.0, 0.0);
vec4 Color = vec4(MyVec3, 1.0);
vec4 Color = vec4(MyVec2_A, MyVec2_B);

vec3 LVec = vec3(MyVec4);
vec2 Tmp = vec2(MyVec3);
</source>

Trotz der recht wenigen Beispiele sollte schnell erkennbar sein, das man hier wirklich sehr viele Kombinationsmöglichkeiten hat, die dann gültig sind ''wenn man mindestens auf die benötigte Anzahl der Argumente kommt''. Im vorletzten Beispiel wird z.B. ein 3-Komponentenvektor aus einem 4-Komponentenvektor initialisiert. Das erzeugt keinen Fehler, sondern führt dazu das {{INLINE_CODE|vec3.x, vec3.y, vec3.z}} aus MyVec4 übernommen werden und MyVec4.w einfach ignoriert wird.

Das Umkehrbeispiel, also
<source lang="glsl">
vec4 Color = vec4(MyVec3)
</source>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<source lang="glsl">
vec4 Color = vec4(MyVec3, 0.0)
</source>
heissen.

Obiges gilt natürlich auch für ''Matrixkonstruktoren'', hier sind z.B. folgende Konstuktoren denkbar, obwohl eigentlich alle Möglichkeiten nutzbar sind, ''solange die benötigte Zahl an Argumenten erreicht wird'' :
<source lang="glsl">
mat4 MyMatrix = mat4(MyVec4, MyVec4, MyVec4, MyVec4);
mat2 MyMatrix = mat4(1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
0.0, 0.0, 0.0, 1.0);
</source>

==Vektor- und Matrixkomponenten==

Was natürlich in keiner Shadersprache fehlen darf, ist der leichte Zugriff auf die einzelnen Komponenten eines Vektors. glSlang bietet, je nach Anwendungsgebiet gleich drei Namensets für den Zugriff auf die Komponenten eines solchen Vektors, welches Set man nutzen will bleibt natürlich frei und ist unabhängig von der Deklaration eines Vektors. Man sollte nur darauf achten, beim gleichzeitigen Zugriff auf mehrere Komponenten im gleichen Namenset zu verbleiben :

* {x, y, z, w}
:Für den Zugriff auf Vektoren die Punkte, Normale oder sonstige Vertexdaten repräsentieren.

* {r, g, b, a}
:Für den Zugriff auf Vektoren die Farbwerte repräsentieren.

* {s, t, p, q}
:Für den Zugriff auf Vektoren die Texturkoordinaten repräsentieren.

Ein paar Beispiele zur Unterstreichung des oben gesagten :
<source lang="glsl">
v4.rgba = vec4(1.0, 0.0, 0.0, 0.0); // gültig
v4.rgzw = vec4(1.0, 1.0, 1.0, 2.0); // Ungültig, da verschiedenen Namensets
v2.rgb = vec3(1.0, 2.0, 1.0); // Ungültig, da vec2 nur r+g besitzt
v2.xx = vec2(5.0, 3.0); // Ungültig, da 2 mal gleiche Komponente
</source>

Auch der Zugriff auf die Komponenten einer Matrix geht leicht von der Hand. Namensets wie bei den Vektoren gibt es hier natürlich keine, aber folgende Beispiele sollen den Zugriff aufzeigen :
<source lang="glsl">
MyMat4[2] = vec4(1.0); // Setzt die 3.Zeile der Matrix komplett auf 1.0
MyMat4[3][3] = 3.5; // Setzt das Element unren rechts auf 3.5
</source>

Ein Zugriff auf Matrixelemente ausserhalb ihrer Dimension (also z.B. MyMat4[4][4]) liefert unvorhersehabre Ergebnise, also sollte man auf diese Fälle prüfen.

==Vektor- und Matrixoperationen==

Wie von C gewohnt sind in glSlang so ziemlich alle Operatoren die man auf Matrizen oder Vektoren anwenden kann überladen, so das man nicht umständlich über selbstgeschriebene Funktionen kombinieren muss. Darüber hinaus ist es in den meisten Fällen auch möglich ohne Konvertierung Fließkommawerte mit kompletten Matrizen oder Vektoren zu kombinieren. Folgende Beispiele zeigen einige der vielfältigen Kombinationsmöglichkeiten auf :
<source lang="glsl">
vec3 dest;
vec3 source;
float factor;

vec3 dest = source + factor;

// Ist gleich
dest.x = source.x + factor;
dest.y = source.y + factor;
dest.z = source.z + factor;
</source>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<source lang="glsl">
vec3 dest;
vec3 source;
mat3 MyMat;

dest = source * MyMat;

// Ist gleich
dest.x = dot(source, MyMat[0]);
dest.y = dot(source, MyMat[1]);
dest.z = dot(source, MyMat[2]);
</source>

Auch hier sind die Möglichkeiten fast unbeschränkt und zeigen wieder wie flexibel glSlang ausgelegt ist.

==Operatoren==

glSlang bietet (momentan) folgende Operatoren, die Liste ist nach ihrer Gewichtung sortiert (Anfang = höchste). Alle ''reservierten'' Operatoren werden erst in kommender Hardware/glSlang-Versionen nutzbar sein :

<div align="center">
{|{{Prettytable_B1}}
!Operatorklasse
!Operatoren
!Assoziation
|-
|Gruppering
|()
| -
|-
|Arrayindizierung<br>Funktionsaufrufe und Konstruktoren<br>Strukturfeldwahl und Swizzle<br>Postinkrement und -dekrement<br>
|[]<br>()<br>.<br>++ --
|Links n. Rechts
|-
|Prefixinkrement- und dekrement<br>Einheitlich (~ reserviert)
| ++ --<br> + - ~ !
|Rechts n. Links
|-
|Mulitplikation (% reserviert)
|* / %
|Links n. Rechts
|-
|Additiv
| + -
|Links n. Rechts
|-
|Bitweises Verschieben (reserviert)
|<< >>
|Links n. Rechts
|-
|Relation
|< > <= >=
|Links n. Rechts
|-
|Vergleich
|== !=
|Links n. Rechts
|-
|Bitweises AND (reserviert)
|&
|Links n. Rechts
|-
|Bitweises XOR (reserviert)
|^
|Links n. Rechts
|-
|Bitweises OR (reserviert)
| <nowiki>|</nowiki>
|Links n. Rechts
|-
|Logisches AND
|&&
|Links n. Rechts
|-
|Logisches XOR
|^^
|Links n. Rechts
|-
|Logisches OR
| <nowiki>||</nowiki>
|Links n. Rechts
|-
|Auswahl
|?:
|Rechts n. Links
|-
|Zuweisung<br>Arithmetrische Zuweisung<br>(Modulis, Shift und bitweise Op. reserviert)
|<nowiki>=</nowiki><br> <nowiki>+= -= *= /= %=</nowiki> <br> <nowiki><<= >>= &= ^= |=</nowiki>
|Rechts n. Links
|-
|Aufzählung
|,
|Links n. Rechts
|-
|}
</div>

==Funktionen==

Ein großer Vorteil von Hochsprachen ist u.A. die Möglichkeit oft genutzte Codeteile in Funktionen (bzw. auch Prozeduren unter Pascal) zu verpacken um so Flexibilität als auch Übersichtlichkeit zu steigern. Wer schonmal was in C geschrieben hat, der wird sich jetzt sicherlich kein Kopfzerbrechen machen müssen. Funktionen werden in glSlang genauso nach folgendem Prinzip deklariert :
<source lang="glsl">
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</source>

Funktionen die ''nichts zurückgeben'' müssen mit dem RückgabeTyp {{INLINE_CODE|void}} deklariert werden, ausserdem entfällt dann logischerweise das {{INLINE_CODE|return}}. Falls die Funktion eines ihrere Argumente nach aussen übergeben soll, muss dieses Argument mit dem Typenqualifizierer out (Siehe Kapitel 4.2) versehen werden. ''Arrays'' können nur als Eingabeargumente übergeben werden und dürfen nich dimensioniert als Argument verwendet werden, sondern müssen mit leeren Klammern argumentiert werden.
Ein paar Beispiele :
<source lang="glsl">
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</source>

Diese Funktion gibt ''nichts'' zurück, aber gibt EingabeWert*MyConstValue im Ausgabeargument AusgabeWert nach aussen.
<source lang="glsl">
float MeineFunktion(float EingabeWert)
{
return EingabeWert*MyConstValue;
}
</source>

Bietet genau die selbe Funktionalität wie das Beispiel darüber. Allerdings wird hier der berechnete Wert als Ergebnis der Funktion zurückgeliefert.
<source lang="glsl">
float VektorSumme(float v[])
{
return v[0]+v[1]+v[2]+v[3];
}
</source>

Wie bereits gesagt darf ein Array als Argument keine Dimensionierung enthalten. Wenn man der Funktion also ein Array übergibt, sollte man vorher drauf achten das es entsprechend der in der Funktion genutzten Indizes dimensioniert wurde.

==if-Anweisung==

Selektion über eine if-Anweisung darf auch in keiner Hochsprache fehlen. Genauso wie in C oder Delphi erwartet auch hier die If-Anweisung einen boolschen Ausdruck (Wahr oder Falsch) und wird dann ausgeführt (wahr) bzw. verzweigt auf ein (wenn vorhanden) else (falsch). Verschachtelung ist wie erwartet auch möglich.

'''Hinweis : '''
Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten im Fragmentshader kein Early-Out, was zur Folge hat das bei einer If-Anweisung immer alle Zweige ausgeführt werden. Am Ende wird dann aber nur ein Ergebnis geschrieben, die anderen verworfen. Auf solchen Karten bringen If-Anweisungen also im Normalfall keine Geschwindigkeitssteigerung, sondern oft eher das Gegenteil.
Neuere SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall, da hier dynamische Verzweigungen und auch Early-Out von der Hardware implementiert werden.

==Schleifen==

Auch Schleifen, ein wichtiges Konzept jeder Hochsprache haben ihren Weg in glSlang gefunden. Unterstützt werden folgende Schleifentypen :

* '''for'''-Schleife
<source lang="glsl">
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck)
{
statement
}
</source>

* '''while'''-Schleife
<source lang="glsl">
while (Durchlaufbedingung)
{
statement
}
</source>

* '''do'''-while-Schleife
<source lang="glsl">
do
{
statement
}
while (Durchlaufbedingung)
</source>

'''Hinweis :''' Grafikkarten auf dem Stand des Shadermodells 2.0 (Radeon 9x00, Radeon X8x0, GeForceFX 5x00) unterstüzten Schleifen nicht in Hardware. Schleifen werden dann beim Kompilieren vom Treiber entrollt, wodurch natürlich Shader mit weitaus mehr Instruktionen als erwartet generiert werden. Von daher sollte man auf solchen Karten möglichst auf Schleifen verzichten, oder diese nur recht kurz halten. Bei SM3.0-Karten (Radeon X1x00, GeForce6x00 und höher) ist dass nicht mehr der Fall.

=Eingebaute Variablen, Attribute und Konstanten=
Nachdem wir uns nun lange genug mit den minderinterssanten Elementen der glSlang-Syntax beschäftigt haben, gehts jetzt endlich an die wirklich interessanten Dinge. Wie schon ARB_VP/ARB_FP bringt auch glSlang jede Menge eingabauter Variablen, Attribute und Konstanten mit, deren Aliase sie recht leicht identifizierbar machen (ganz im Gegensatz zum Indexgewusel bei den DX-Shadern).

==Variablen im Vertex Shader==
Exklusiv im Vertex Shader stehen die folgenden Variablen zur Verfügung :

* vec4 gl_Position muss geschrieben werden
:Dieser Variable '''muss''' im Vertexshader ein Wert zugewiesen werden, wird dies nicht getan ist das Ergebnis (sprich die Position des Vertex) undefiniert. Vorgesehen ist diese Variable für die ''homogene Position des Vertex'' und wird u.a. zum Clipping und Culling verwendet. Sie darf natürlich auch (mehrfach) geschrieben und ausgelesen werden.

* float gl_PointSize kann geschrieben werden
:Diese Variable wurde dazu vorgesehen um dort im VertexShader die Punktgröße in Pixeln hineinzuschreiben.

* vec4 gl_ClipVertex kann geschrieben werden
:Falls genutzt, sollten hier die Vertexkoordinaten die im Zusammenhang mit benutzerdefinierten Clippingplanes genutzt werden abgelegt werden. Wichtig ist, das gl_ClipVertex im selben Koordinatenraum wie die Clippingplane definiert ist.

==Attribute im Vertex Shader==

Folgende Attribute stehen nur im Vertex Shader zur Verfügung und '''können nur gelesen werden''' :

* vec4 gl_Color
: Farbwert des Vertex.
* vec4 gl_SecondaryColor
:Sekundärer Farbwert des Vertex.
* vec4 gl_Normal
:Normale des Vertex.
* vec4 gl_Vertex
:Koordinaten des Vertex;
* vec4 gl_MultiTexCoord0..7
:Texturkoordinaten auf Textureinheit 0..7.
* float gl_FogCoord
:Nebelkoordinate des Vertex.

==Variablen im Fragment Shader==

Im Fragment Shader sind folgende Variablen exklusiv nutzbar :

* vec4 gl_FragColor
: Speichert den Farbwert des Fragmentes, der von folgenden Funktionen der festen Pipeline genutzt wird. Wird dieser Variable nichts zugewiesen, so ist ihr Inhalt undefiniert und darauf aufbauende Ergebnisse ebenfalls.

* vec4 gl_FragData[0..15]
: Ersetzt gl_FragColor bei der Verwendung von multiplen Rendertargets.

* float gl_FragDepth
: Durch schreiben dieser Variable kann man den von der festen Funktionspipeline ermittelten Tiefenwert überspringen, der mit {{INLINE_CODE|gl_FragCoord.z}} ausgelesen werden kann. Wird dieser Wert nicht geschrieben, nutzen folgende Funktionen der Pipeline den vorher fest berechneten Wert.

* vec4 gl_FragCoord nur lesen
: In dieser Variable ist die Position des Fragmentes relativ zur Fensterposition im Format x,y,z,1/w abgelegt, wobei z den von der festen Funktionspipeline berechneten Tiefenwert enthält.

* bool gl_FrontFacing nur lesen
: Gibt an ob das Fragment zu einer nach vorne zeigenden Primitive gehört (=true).

Im Bezug auf {{INLINE_CODE|gl_FragColor}} und {{INLINE_CODE|gl_FragDepth}} sei noch anzumerken das diese ''nicht'' in den Wertebereich 0..1 gebracht werden müssen, da dies später durch die feste Funktionspipeline automatisch gemacht wird.

==Eingebaute Varyings==

Wie bereits in Kapitel 4.2 erwähnt, stellen Varyings eine Schnittstelle zwischen dem Vertex und dem Fragment Shader dar. Sie werden im Vertex Shader geschrieben und können dann im Fragment Shader ausgelesen werden, ohne das die folgenden Varyings dafür explizit deklariert werden müssen :

* vec4 gl_FrontColor
: Farbe der Vorderseite des Vertex.

* vec4 gl_BackColor
: Farbe der Rückseite des Vertex.

* vec4 gl_FrontSecondaryColor
: Sekundäre Farbe der Vorderseite des Vertex.

* vec4 gl_BackSecondaryColor
: Sekundäre Farbe der Rückseite des Vertex.

* vec4 gl_TexCoord[x]
: Texturkoordinaten des Vertex auf Textureinheit x, wobei x die von der Hardware zur Verfügung gestellte Zahl der Textureinheiten-1 nicht überschreiten darf.

* float gl_FogFragCoord
: Nebelkoordinate des Fragmentes.

Die Varyings {{INLINE_CODE|gl_FrontColor, gl_FrontSecondaryColor, gl_BackColor}} und {{INLINE_CODE|gl_BackSecondaryColor}} können im FragmentShader nur unter den Aliases gl_Color bzw. gl_SecondaryColor gelesen werden. Welcher Wert des Vertex Shaders im Fragment Shader dort eingesetzt wird ist abhängig davon ob das Fragment zu einer nach vorne oder nach hinten zeigenden Primitive gehört.

==Eingebaute Konstanten==
Auch diverse Konstanten wurden definiert um darauf schnell im Shader zugreifen zu können. In den Klammern stehen die von einer GL-Implementation als Mindestanforderung anzubietenden Werte. Alle Konstanten sind sowohl im Vertex als auch im Fragment Shader abrufbar :

: OpenGL 1.0/1.2 :
* int gl_MaxLights (8)
* int gl_MaxClipPlanes (6)
* int gl_MaxTextureUnits (2)

: ARB_Fragment_Program :
* int gl_MaxTextureCoordsARB (2)

: Vertex_Shader :
* int gl_MaxVertexAttributesGL2 (16)
* int gl_MaxVertexUniformFloatsGL2 (512)
* int gl_MaxVaryingFloatsGL2 (32)
* int gl_MaxVertexTextureUnitsGL2 (1)

: Fragment_Shader :
* int gl_MaxFragmentTextureUnitsGL2 (2)
* int gl_MaxFragmentUniformFloatsGL2 (64)

==Eingebaute Uniformvariablen==

Um den Zugriff auf OpenGL-Staten zu vereinfachen wurden in glSlang diverse Uniformvariablen zur direkten Verwendung im Shader eingebaut. Wie gewohnt wurden auch hier sinnvolle Namen verwendet, so dass eine tiefere Erklärung unnötig sein dürfte :

* mat4 gl_ModelViewMatrix
* mat4 gl_ProjectionMatrix
* mat4 gl_ModelViewProjectionMatrix
* mat3 gl_NormalMatrix
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die invertierten und anschließend transponierten oberen 3x3 Werte der {{INLINE_CODE|gl_ModelViewMatrix}}.
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]

* float gl_NormalScale
: Gibt den unter OpenGL festgelegten Faktor zur Skalierung der Normalen zurück.

* struct gl_DepthRangeParameters
<source lang="glsl">
struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;
</source>
: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
<source lang="glsl">
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</source>
*struct gl_MaterialParameters
<source lang="glsl">
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</source>
*struct gl_LightSourceParameters
<source lang="glsl">
struct gl_LightSourceParameters
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
vec4 position;
vec4 halfVector;
vec3 spotDirection;
float spotExponent;
float spotCutoff;
float spotCosCutoff;
float constantAttenuation;
float linearAttenuation;
float quadraticAttenuation;
};
gl_LightSourceParameters gl_LightSource[gl_MaxLights];
</source>
*struct gl_LightModelParameters
<source lang="glsl">
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</source>
*struct gl_LightModelProducts
<source lang="glsl">
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</source>
*struct gl_LightProducts
<source lang="glsl">
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</source>
* vec4 gl_TextureEnvColor[gl_MaxFragmentTextureUnitsGL2]
* vec4 gl_EyePlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_EyePlaneQ[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneS[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneT[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneR[gl_MaxTextureCoordsARB]
* vec4 gl_ObjectPlaneQ[gl_MaxTextureCoordsARB]

*struct gl_FogParameters
<source lang="glsl">
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</source>
Diese recht umfangreiche GL-Stateliste sollte eigentlich jeden Bedarf decken und momentan gibts kaum einen OpenGL-Status den man so nicht in einem Shader abfragen bzw. nutzen kann.

=Eingebaute Funktionen=
glSlang ist mit diversen Skalar- und Vektorfunktionen ausgestattet, die teilweise (idealerweise) sogar direkt in der Hardware ausgeführt werden, weshalb einer fertigen Funktion ggü. gleichwertigen eigenen Berechnungen immer der Vorzug zu geben ist.
{{Hinweis| ''genType'' kann vom Type float, vec2, vec3 oder vec4 sein, ''mat'' vom Typ mat2, mat3 oder mat4.}}

==Trigonometrie und Winkel==
Alle übergebenen Winkel sollten, soweit nicht anders vermerkt, in Radien angegeben werden.

* genType radians (genType degrees)
: Wandelt von Grad nach Radien.
* genType degrees (genType radians)
: Wandelt von Radien nach Grad.
* genType sin (genType angle)
: Gibt den Sinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType cos (genType angle)
: Gibt den Cosinus von Angle zurück, wobei Angle in Radien angegeben wird.
* genType tan (genType angle)
: Gibt den Tangens von Angle zurück, wobei Angle in Radien angegeben wird.
* genType asin (genType x)
: Liefert den Arcsinus von x zurück, also den Winkel dessen Sinus x ergeben würde.
* genType acos (genType x)
: Liefert den Arccosinus von x zurück, also den Winkel dessen Cosinus x ergeben würde.
* genType atan (genType y, genType x)
: Liefert den Winkel zurück, dessen Tangens x/y ergeben würde.
* genType atan (genType y_over_x)
: Liefert den Winkel zurück, dessen Tangens x über y ergeben würde.

==Exponentiell==
* genType pow (genType x, genType y)
: Gibt x hoch y zurück.
* genType exp2 (genType x)
: Gibt 2 hoch x zurück.
* genType log2 (genType x)
: Gibt den Logarithmus zur Basis 2 von x zurück.
* genType sqrt (genType x)
: Gibt die Wurzel von x zurück.
* genType inversesqrt (genType x)
: Gibt die umgekehrte Wurzel von x zurück.

==Standardfunktionen==
* genType abs (genType x)
: Liefert den absoluten Wert von x zurück.
* genType sign (genType x)
: Gibt -1.0 zurück, wenn x < 0.0, 0.0 wenn x = 0.0 und 1.0 wenn x > 0.0.
* genType floor (genType x)
: Gibt denn nächsten Integerwert zurück, der kleiner oder gleich x ist.
* genType ceil (genType x)
: Gibt den nächsten Integerwert zurück, der größer oder gleich x ist.
* genType fract (genType x)
: Gibt den Nachkommateil von x zurück.
* genType mod (genType x, float y)
* genType mod (genType x, genType y)
: Gibt den Modulus zurück. (=x-y * floor(x/y))
* genType min (genType x, genType y)
* genType min (genType x, float y)
: Liefert y zurück wenn y < x, ansonsten x.
* genType max (genType x, genType y)
* genType max (genType x, float y)
: Liefert y zurück wenn x < y, ansonsten x.
* genType clamp (genType x, genType minVal, genType maxVal)
* genType clamp (genType x, float minVal, float maxVal)
: Zwängt x in den Bereich minVal..maxVal.
* genType mix (genType x, genType y, genType a)
* genType mix (genType x, genType y, float a)
: Liefert den linearen Blend zwischen x und y zurück. (= x * (1-a) + y * a)
* genType step (genType edge, genType x)
* genType step (float edge, genType x)
: Liefert 0.0 zurück, wenn x <= edge, ansonsten 1.0.
* genType smoothstep (genType edge0, genType edge1, genType x)
* genType smoothstep (float edge0, float edge1, genType x)
: Liefert 0.0 zurück, wenn x <= edge und 1.0 wenn x >= edge. Dabei wird eine weiche Hermite Interpolation zwischen 0 und 1 durchgeführt.

==Geometrie==
* float length (genType x)
: Gibt die Länge des Vektors x (= sqrt(x[0]² + x[1]² + ... + x[n]²) zurück.
* float distance (genType p0, genType p1)
: Gibt die Distanz zwischen den zwei Vektoren p0 un p1 (= length(p0-p1)) zurück.
* float dot (genType x, genType y)
: Gibt das Punktprodukt von x und y zurück (=x[0]*y[0] + x[1]*y[1] + ... + x[n]*y[n]).
* vec3 cross (vec3 x, vec3 y)
: Gibt das Kreuzprodukt von x und y zurück.
* genType normalize (genType x)
: Normalisiert den Vektor x auf die Länge 1.
* vec4 ftransform()
: Nur im Vertex Shader. Die Funktion stellt sicher, das das eingehende Vertex haargenau so transformiert wird wie in der festen Funktionspipeline. gl_Position = ftransform() wird dann also gebraucht, wenn in mehreren Durchgängen sowohl im Shader als auch in der festen Pipeline gerendert wird, um sicherzustellen das in beiden Fällen die gleiche Vertexposition herauskommt.
* genType faceforward (genType N, genType I, genType Nref)
: Gibt einen nach vorne zeigenden Vektor N zurück. (If dot(NRef, I) < 0 return N else return -N)
* genType reflect (genType I, genType N)
: Gibt den an der Flächenausrichtung N reflektierten Vektor I zurück. (=I-2 * dot(N,I) * N)

==Matrixfunktionen==
* mat matrixCompMult (mat x, mat y)
: Multipliziert Matrix X mit Matrix Y komponentenweise. Um eine normale lineare Matrixmultiplikation durchzuführen, sollte der "*"-Operator genutzt werden.

==Vektorvergleiche==
Die meisten Vektorvergleichsfunktionen liefern als Ergebnis einen boolvektor zurück, da die Vergleiche per Komponente stattfinden. Wenn man also x = vec4(1.0, 3.0, 0.0, 0.0) mit y = vec4(2.0, 1.5, 1.5, 0.0) via lessThan(x, y) vergleicht, erhält man als Ergebnis bvec(true, false, true, false).

* bvec lessThan (vec x, vec y)
* bvec lessThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x < y zurück.
* bvec lessThanEqual (vec x, vec y)
* bvec lessThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x <= y zurück.
* bvec greaterThan (vec x, vec y)
* bvec greaterThan (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x > y zurück.
* bvec greaterThanEqual (vec x, vec y)
* bvec greaterThanEqual (ivec x, ivec y)
: Gibt den komponentenweisen Vergleich x >= y zurück.
* bvec equal (vec x, vec y)
* bvec equal (ivec x, ivec y)
* bvec equal (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x == y zurück.
* bvec notEqual (vec x, vec y)
* bvec notEqual (ivec x, ivec y)
* bvec notEqual (bvec x, bvec y)
: Gibt den komponentenweisen Vergleich x != y zurück.
* bool any (bvec x)
: Liefert true zurück, wenn mindestens eine der Komponenten von x true ist.
* bool all (bvec x)
: Liefert true zurück, wenn alle Komponenten von x true sind.
* bvec not (bvec x)
: Liefert die logische Negation von x zurück.

==Texturenzugriffe==

Diese wichtige Funktionskategorie dient dazu, Werte aus einer an eine Textureinheit gebundenen Textur zu ermitteln. Die Texturenzugriffe können sowohl im Vertex (!) als auch im Fragment Shader ausgeführt werden, wobei der optionale Parameter bias im Vertex Shader ignoriert wird. Allerdings gibt es zusätzlich Funktionen die auf "Lod" enden und nur im Vertex Shader genutzt werden dürfen um eben dieses Manko zu umgehen. Funktionen mit dem Suffix "Proj" geben einen projizierten Texturenwert zurück.

: '''1D-Texturen :'''
* vec4 texture1D (sampler1D sampler, float coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec2 coord [, float bias])
* vec4 texture1DProj (sampler1D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture1DLod (sampler1D sampler, float coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec2 coord, float lod)
* vec4 texture1DProjLod (sampler1D sampler, vec4 coord, float lod)

: '''2D-Texturen :'''
* vec4 texture2D (sampler2D sampler, vec2 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec3 coord [, float bias])
* vec4 texture2DProj (sampler2D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture2DLod (sampler2D sampler, vec2 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec3 coord, float lod)
* vec4 texture2DProjLod (sampler2D sampler, vec4 coord, float lod)

: '''3D-Texturen :'''
* vec4 texture3D (sampler3D sampler, vec3 coord [, float bias])
* vec4 texture3DProj (sampler3D sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 texture3DLod (sampler3D sampler, vec3 coord, float lod)
* vec4 texture3DProjLod (sampler3D sampler, vec4 coord, float lod)

: '''Cubemap :'''
* vec4 textureCube (samplerCube sampler, vec3 coord [, float bias])
: Nur im Vertex Shader :
*vec4 textureCubeLod (samplerCube sampler, vec3 coord, float lod)

: '''Tiefentextur (Shadowmap) :'''
* vec4 shadow1D (sampler1DShadow sampler, vec3 coord [, float bias])
* vec4 shadow2D (sampler2DShadow sampler, vec3 coord [, float bias])
* vec4 shadow1DProj (sampler1DShadow sampler, vec4 coord [, float bias])
* vec4 shadow2DProj (sampler2DShadow sampler, vec4 coord [, float bias])
: Nur im Vertex Shader :
* vec4 shadow1DLod (sampler1DShadow sampler, vec3 coord, float lod)
* vec4 shadow2DLod (sampler2DShadow sampler, vec3 coord, float lod)
* vec4 shadow1DProjLod (sampler1DShadow sampler, vec4 coord, float lod)
* vec4 shadow2DProjLod (sampler2DShadow sampler, vec4 coord, float lod)

Wie bereits eingangs gesagt ist dieses Kapitel ein sehr wichtiges, denn eine 3D-Szene ohne Texturen ist heute kaum denkbar. Darüber hinaus lassen sich durch Texturenzugriffe recht viele interessante Sachen machen, z.B. ein einfacher Blurfilter oder das freie überblenden bestimmter Texturenteile. Deshalb führe ich hier kurz ein paar Beispiele an, welche die Nutzung dieser Funktionen verdeutlichen sollen :

===Beispiel A===
Eine Textur gebunden die einfach ausgegeben werden soll

''Im Vertex Shader'' :
<source lang="glsl">
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>
Der Vertex Shader ist recht minimal. Neben der homogenen Vertexposition leiten wir hier nur die im OpenGL-Programm angegebenen Texturkoordinaten weiter. ''Dies ist aber unbedingt nötig!'' Ohne die letzte Zeile hätten wir im Fragment Shader keine gültigen Texturkoordinaten auf TMU0, was in einer Fehldarstellung enden würde.

''im Fragment Shader'' :
<source lang="glsl">
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</source>
Zuerst deklarieren wir hier einen 2D-Texturensampler, wichtig : '''Texturensampler müssen IMMER als uniform deklariert werden!''' In der Hauptfunktion weisen wir dann einfach den über die Funktion texture2D aus unserer gebundenen Textur ausgelesenen Farbwert, anhand der vom Vertex Shader übergebenen Texturkoordinaten, zu.

===Beispiel B===
Zwei Texturen, jeweils auf TMU0 und TMU1. Fragmentfarbe soll eine Multiplikation der beiden Texturen darstellen.

In diesem Beispielfall (der recht häufig vorkommt) müssen wir im Programm festlegen, ''welcher Sampler welche Textureinheit adressiert'', genau deshalb müssen die Texturensampler auch als uniform deklariert werden. Die Standardtextureneinheit eines Samplers ist TMU0, was in unserem Falle natürlich nicht brauchbar ist. Also müssen wir unserem zweiten Textursampler im Programm mitteilen das er seine Daten aus TMU1 beziehen soll :

glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);

Dies ist also unbedingt zu machen, sobald ein Texturensampler eine Textureinheit > GL_TEXTURE_0 adressieren will. Die Textureneinheit des Samplers lässt sich also nicht im Shader selbst festlegen. Der Fragment Shader ist nun allerdings schnell hergeleitet (Vertex Shader verändert sich nicht, da TMU1 die Texturkoordinaten auch von TMU0 bezieht) :

im Fragment Shader :
<source lang="glsl">
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

void main(void)
{
gl_FragColor = texture2D(texSamplerTMU0, vec2(gl_TexCoord[0])) *
texture2D(texSamplerTMU1, vec2(gl_TexCoord[0]));
}
</source>

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich [[GLSL noise|Noisefunktionen]] nutzen, mit deren Hilfe sich eine gewisse "Zufälligkeit" simulieren lässt (wirklich zufällige Werte sind es natürlich nicht). Ein zurückgegebener Wert liegt dabei immer im Bereich [-1..1] und ist immer bei gleichem Eigabewert auch immer gleich. Die Verwendung empfiehlt sich derzeit allerdings eher nicht, da nicht alle aktuellen Treiber die Funktionen unterstützen und eine Noisetextur wahrscheinlich performanter ist.

* float noise1 (genType x)
* vec2 noise2 (genType x)
* vec3 noise3 (genType x)
* vec4 noise4 (genType x)

==Discard==
Eigentlich keine Funktion, sondern eine Abbruchbedingung '''nur im Fragment Shader'''. Das Schlüsselwort {{INLINE_CODE|discard}} verwirft das aktuell bearbeitete Fragment und beendet gleichzeitig den Shader. Es kann z.B. genutzt werden um Alphamasking manuell durchzuführen.
Man sollte dabei jedoch beachten dass ein Großteil der aktuellen Hardware kein "early-out" (frühes Beenden) im Fragmentshader unterstützt. Wenn dort also ein {{INLINE_CODE|discard}} auftaucht, wird trotzdem auch der Code danach ausgeführt und einfach verworfen. Einen Geschwindigkeitsvorteil durch diesen Befehl wird man also erst auf neueren Karten feststellen, die dieses Faeature auch so unterstützen wie es angedacht war.

=Beispielshader=
Wen bis hierhin nicht der Mut verlassen hat, und wer aufmerksam gelesen hat, dürfte jetzt also zumindest in der Lage sein kleinere Shader in glSlang zu schreiben und diese auch im Programm zu nutzen. Ich habe im Themenbereich "glSlang" versucht alle Bereiche der Shadersprache selbst anzusprechen und hoffe das auch brauchbar rübergebracht zu haben. Um oben erlerntes (hoffe ich doch mal) nochmal zu vertiefen werde ich jetzt (wie ich das bereits bei meinem ARB_VP-Tutorial getan habe) einen simplen Beispielshader (Vertex und Fragment Shader) auseinanderpflücken um so u.a. auch die Programmstruktur für alle die in C nicht so bewandert sind zu erörtern.

==Der Vertex Shader==
<source lang="glsl">
uniform vec4 GlobalColor;

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color * GlobalColor;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</source>

Wie gesagt recht simpel. Angefangen wird mit der Deklaration einer globalen Uniformvariable namens {{INLINE_CODE|GlobalColor}}. Wie wir uns erinnern gibt der Typenqualifizierer uniform an, das wir den Wert dieser Variable (ein 4-Komponentenvektor, da Farbwerte aus R,G,B und A bestehen) in unserem Programm an den Shader übermitteln.

Danach gehts ohne Umwege direkt in unsere Hauptfunktion, da wir im Vertex Shader keine anderen Funktionen benötigen. Dort berechnen wir zuerst die homogene Position unseres Vertex, die sich aus der eingehenden Vertexposition multipliziert mit der Modelansichtsmatrix ergibt. Wie schonmal gesagt '''muss diesem Wert etwas zugewiesen werden''', da sonst alle darauf aufbauenden Funktionen unvorhersehbare Ergebnisse liefern.
Ausserdem wollen wir die Frontfarbe unseres Vertex jedesmal mit der im Programm übergebenen GlobalColor multiplizieren, so dass wir den Farbwert der gesamten Szene aus unserem Programm heraus manipulieren können. Zu guterletzt geben wir dann noch unsere aus der festen Funktionspipeline erhaltenen Texturkoordinaten auf Textureinheit 0 weiter. Wenn im Fragmentshader Texturkoordinaten verwendet werden, '''muss das getan werden'''.

==Der Fragment Shader==
<source lang="glsl">
uniform sampler2D Texture0;
uniform sampler2D Texture1;
uniform sampler2D Texture2;
uniform sampler2D Texture3;

void main(void)
{
vec2 TexCoord = vec2( gl_TexCoord[0] );
vec4 RGB = texture2D( Texture0, TexCoord );

gl_FragColor = texture2D(Texture1, TexCoord) * RGB.r +
texture2D(Texture2, TexCoord) * RGB.g +
texture2D(Texture3, TexCoord) * RGB.b;
}
</source>

Auch hier passiert nicht wirklich viel Großartiges. Wir deklarieren beim Shaderanfang zuerst vier Texturensampler, da wir insgesamt vier verschiedene Texturen im Shader auslesen wollen, eine Verlaufstextur und drei Oberflächentexturen. Auch hier sei wieder gesagt das man Sampler '''immer als uniform deklarieren muss'''. In der Hauptfunktion deklarieren wir dann einen Farbvektor, der auch direkt einen Farbwert aus Textureinheit 0 zugewiesen bekommt. Auf Textureinheit 0 haben wir ihm Hauptprogramm eine Verlaufstextur gebunden, die angibt wie die drei folgenden Texturen ineinander geblendet werden.
Danach schreiben wir dann den Farbwert des Fragmentes, der '''im Fragment Shader ausgegeben werden muss'''. Der besteht wie einfach zu erkennen aus Farbwert von Textureinheit 1 * Rotwert von Textureinheit 0 + Farbwert von Textureinheit 2 * Grünwert von Textureinheit 0 + Farbwert von Textureinheit 3 * Blauwert von Textureinheit 0. So ist z.B. an Stellen an denen in der Verlaufstextur reines blau liegt nur die dritte Textur sichtbar.

So viel also zu unserem kleinen Beispielshader. Er ist weder besonders toll noch besonders sinnvoll, sollte aber auch eher dazu dienen euch glSlang ein wenig zu veranschaulichen, was mir hoffentlich gelungen ist.

Wenn ihr in den vorangegangenen Kapiteln zumindest ein wenig aufgepasst habt, dann könnt ihr euch vor eurem inneren Auge hoffentlich vortstellen was der Shader macht : Er blendet drei Texturen weich anhand der Verlaufstextur ineinander über. Sowas kann man z.B. für ein Terrain nutzen, um dieses anhand einer Farbtextur zu texturieren. Für alle, die damit Probleme haben hier zwei Bilder die den Shader veranschaulichen. Links die Verlaufstextur, die angibt wo welche Textur wie stark gewichtet wird und rechts dann das Ergebnis :

<div align="center"> [[BILD:GLSL_sample_shader_a.jpg]] [[BILD:GLSL_sample_shader_b.jpg]]</div>

=Post Mortem=
Das wars also, meine "Einführung" in die OpenGL Shader Sprache. Ich hoffe es hat euch nicht gelangweilt und auch die von mir zur Verfügung gestellten Informationen haben euch hoffentlich ausgereicht. Mit der Veröffentlichung dieser Einführung geht übrigens auch die Eröffnung eines Shaderforums hier auf der DGL einher, in der ihr dann also fleissig Fragen zum Thema stellen oder eure Shader präsentieren könnt. In diesem Post Mortem gehe ich jetzt noch kurz auf die Zukunft von glSlang ein und zeige ein paar Screenshots (damit die Augen entspannen können), bevor ihr euch dann selbst in die Shaderwelt stürzen könnt.

=Beispiele=

Anbei ein paar exemplarische Screenshots. Da man mit GLSL aber alle möglichen Effekte berechnen kann (u.a. auch 1:1 die feste Funktionspipeline) ist es hier unmöglich einen Überblick aller möglichen Techniken zu geben.

[[Datei:tut_glsl_eigenershader_01.png]] [[Datei:tut_glsl_eigenershader_02.png]] [[Datei:tut_glsl_eigenershader_03.png]]

Wie im ersten (und dritten) Screenshot zu sehen ist es natürlich auch möglich mehrere Techniken innerhalb einer Szene zu nutzen. Hier sind letztendlich bis auf Hardwarelimitationen keine Grenzen gesetzt.

=Die Zukunft=
Als dieses Tutorial geschrieben wurde, war noch nicht ganz abzusehen dass bzw. ob sich GLSL auch durchsetzen würde. ARB-Shadr und NVidias cG waren damals die Platzhirsche, aber inzwischen werden ARB-Shader nicht mehr genutzt (und auch schon länger nicht mehr weiterentwickelt) und auch NVidia setzt primär auf GLSL. GLSL wird permanent weiterenwtickelt und Hersteller können dank des flexiblen Extensionsystems auch in GLSL eigene Extensions offenlegen um die aktuellsten Features (wie z.b. den Tesselator auf aktuellen ATI-Karten) nutzen zu können. GLSL it als inzwischen auch offizielle die Shadersprache frü OpenGL und wird permanent an die neusten technischen Entwicklungen im Grafikkartenbereich angepasst.

Wer also unter OpenGL etwas mit Shadern machen möchte, kommt an GLSL nicht vorbei!

Also viel Spaß beim Experimentieren und Shaderschreiben! Und nicht vergessen : Wir wollen sehen was ihr so treibt,

Euer
:Sascha Willems

{{TUTORIAL_NAVIGATION|-|[[Tutorial_glsl2]]}}
[[Kategorie:Tutorial|GLSL]]

Feste Funktionspipeline

2011-07-15T20:31:53Z

Phlegmatiker: Rechtschreibfehler korrigiert

{{Unvollständig|Es Fehlt Matrix Kontrolle, Feedback, Eingabe Konvertierung, Lighting und Texture Koordinaten generierung. }}

Fixe Funktionspipeline für OpenGL 1.1

= Vertex Pipeline =
[[Bild:VertexPipeline.GIF|framed|right|Die Vertexpipeline]]

== Eingabe Konvertierung ==
Hier erhält die [[Vertex]] Pipeline durch entsprechende Konvertierung(en) eine standardisierte Form eines [[Vertex|Vertices]].<br>
Siehe auch: [[glVertex]], [[glVertexPointer]], [[glArrayElement]]

== [[Modelview]] Muliplikation ==
Der [[Vertex]] wird mit der im [[Modelview]] [[Matrix]] [[Stack]] oben aufliegenden Matrix multipliziert.<br>
Siehe auch: [[glMatrixMode]], [[glPushMatrix]], [[glPopMatrix]], [[glTranslate]], [[glScale]], [[glRotate]], [[glMultMatrix]], [[glLoadMatrix]], [[glLoadIdentity]]

== [[Primitive]] erstellen ==
Hier werden die Eingabedaten über die Art des [[Primitiv|Primitives]] gegebenenfalls konvertiert und weiter gereicht.<br>
Siehe auch: [[glBegin]], [[glEnd]], [[glDrawElements]], [[glDrawArrays]]

== [[Flat Shading]] ==
Gegebenenfalls wird der bereits berechnete Farbwert für das Flat Shading für alle Punkte des [[Primitiv|Primitives]] gleich gesetzt.<br>
Siehe auch: [[glShadeModel]]

== Benutzerdefinierte [[Clipping Plane|Clipping Planes]] ==
Hier werden gegebenenfalls die [[Primitiv|Primitive]] an benutzerdefinierten Ebenen abgeschnitten, weiter gereicht oder komplett verworfen.<br>
Siehe auch: [[glClipPlane]]

== Projection Multiplikation ==
Hier werden die [[Vertex|Vertices]] mit der am [[Projection]] [[Matrix]] Stack oben aufliegenden [[Matrix]] multipliziert.<br>
Siehe auch [[glOrtho]], [[glFrustum]], [[gluPerspective]], [[glMatrixMode]]

== [[Kamera]] Clipping ==
Das clippen am [[Kamera]] Sichtkörper<br>
Siehe auch: [[Clipping Plane]]

== Division durch w ==
Hier werden x, y und z Koordinaten des [[Vertex|Vertices]] durch die w Koordinate dividiert. In diesem Schritt erfolgt bei der perspektivischen Projektion die eigentliche Projektion auf den Bildschirm (oder andere Ausgabemedien).

== Viewport Multiplikation ==
Hier wird der x und y Teil des [[Vertex]] mit der [[Viewport]] [[Matrix]] multipliziert. Das Ergebnis sind die Pixelcoordinaten des [[Vertex]].<br>
Siehe auch: [[glViewport]]

== Z Anpassung ==
Hier wird der zuerst im Bereich [-1|1] liegende z Teil des [[Vertex]] auf den für den [[Tiefenpuffer|Z Buffer]] benötigten Bereich [0|1] gescaled.<br>
Siehe auch: [[glDepthRange]]

== [[Polygon]] [[Backface Culling|Culling]] ==
Das [[Backface Culling|Front- bzw. Backface Culling]] findet hier statt.<br>
Siehe auch [[glFrontFace]], [[glCullFace]]

== [[Polygon]] mode ==
Gegebenenfalls wird hier 1 3eck in 3 Linien oder 3 Punkte zerlegt. Das typische Wireframe kommt häufig hier zustande.<br>
Siehe auch: [[glPolygonMode]]

== Rasterizer ==
Hier werden aus dem Primitiv die Fragmente berechnet.

<br>
<br>

= Fragment Pipeline =
[[Bild:FragmentPipeline.png|framed|right|Die Fragmentpipeline]]

== Rasterizer ==
Die Aufgabe des Rasterizers ist es, aus 2 dimensionalen Primitiven die durch 1, 2 oder 3 [[Vertex|Vertices]] gegeben sind die Pixel zu berechnen die gezeichnet werden sollen. Jedes Pixel das gezeichnet werden soll wird weiter durch die Fragment Pipeline geschickt wo es noch ein Reihe von Tests durchlaufen muss bis es endgültig in den Frame Buffer gelangt. Für jedes Fragment werden folgende Werte berechnet und weiter gereicht:
*Koordinaten innerhalb des Frame Buffers
*Interpolierte Tiefe (Z-Wert)
*Interpolierte [[Texturkoordinaten]] (gegebenenfalls auch mehrere [[Texturkoordinaten]])
*Interpolierter Farbwert (gegebenenfalls auch 2 Farbwerte)
*gegebenenfalls Deckung für [[Antialiasing]]
Auf moderneren Grafikkarten werden hier die erzeugten Fragmente auf mehrere Fragment Prozessoren aufgeteilt und parallel berechnet um eine höhere Füllrate zu erzielen.

=== Punkte ===
Größe des Punkte wird kontrolliert durch [[glPointSize]]. Wenn Punkt antialiased (siehe auch [[glEnable]]( GL_POINT_SMOOTH ), [[Aliasing]] und [[Antialiasing]]) gezeichnet werden sollen, so wird die prozentuelle Deckung des Pixels für später berechnet und gespeichert gespeichert. Ein Antialiased Punkt ist ein Kreis, nicht antialiased Punkte werden als Quadrat dar gestellt.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glPointSize]]

=== Linien ===
Breite der Linie wird kontrolliert durch [[glLineWidth]]. [[Antialiasing]] von Linien wird durch [[glEnable]]( GL_LINE_SMOOTH ) erreicht. Ist GL_LINE_STIPPLE aktiviert, so werden hier die nicht entsprechenden Fragmente verworfen bzw. nicht erzeugt.<br>
Siehe auch: [[glEnable]], [[glDisable]], [[glLineWidth]] und glLineStipple]]

=== 3ecke ===
Mit GL_POLYGON_SMOOTH kann hier das Antialiasing erreicht werden.

{{Warnung|GL_POLYGON_SMOOTH schaltet sehr häufig in Softwaremodus um, da nicht in Hardware verfügbar. Und auch im Softwaremodus werden häufig die Edge Flags bei geclippten 3ecken nicht richtig gesetzt (siehe [[glEdgeFlag]] und [[Clipping Plane]]).}}

Mit [[glPolygonStipple]] kann man auch hier das erzeugen von Fragmenten verhindern werden. Gegebenenfalls wird die Tiefe (Z-Wert) noch mit [[glPolygonOffset]] modifiziert.<br>
Siehe auch: [[glEnable]], [[glDisable]], [[glPolygonOffset]] und [[glPolygonStipple]]

== [[Texel]] Generierung ==
Berechnung der Farbwerte der Texel. Hier werden für eine [[Trilineare Filterung]] zuerst die beiden [[Mipmap|Mipmaps]] welche verwendet werden sollen berechnet, danach werden die 8 umliegenden Texel (4 in jedem Mipmap) entsprechend interpoliert.<br>
Siehe auch: [[glGenTextures]], [[glDeleteTextures]], [[glTexImage1D]], [[glTexImage2D]], [[glTexImage3D]], [[glTexSubImage1D]], [[glTexSubImage2D]], [[glTexSubImage3D]], [[gluBuild1DMipmaps]], [[gluBuild2DMipmaps]], [[glTexParameter]], [[glEnable]], [[glDisable]] und [[glBindTexture]]

== Texel Anwendung (Berechnung) ==
Ausgehend von Farbe ([[glColor]]), Texelfarbe(n) und Texturfarb konstante ([[glTexEnv]]) wird hier ein neuer Farbwert für das Fragment berechnet.<br>
Siehe auch: [[glTexEnv]], [[glColor]] und [[GL_ARB_texture_env_combine]]

== Nebel Berechnung ==
Wenn GL_FOG aktiviert ist, so werden hier die Distanz basierten Nebelberechnungen so wie durch [[glFog]] definiert mit Hilfe des Z-Wertes des Fragmentes durchgeführt.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glFog]]

== Deckungsberechnung Antialiasing ==
Hier wird im RGBA Modus der Alpha Wert eines Fragmentes anhand der Deckung die durch den Rasterizer berechnet wurde modifiziert.<br>
Siehe auch: [[glEnable]]( GL_POLYGON_SMOOTH ), [[glEnable]]( GL_LINE_SMOOTH ), [[glEnable]]( GL_POINT_SMOOTH ) und [[glDisable]]

== Pixel Besitzer Test ==
Prüft ob der aktuelle OpenGL Context (siehe [[wglMakeCurrent]]) im Besitz des Pixels, welches gezeichnet werden soll, ist. Ist dies nicht der Fall (Beispielsweise durch ein darüber liegendes Fenster welches das Pixel verdeckt), so wird beim Fenstersystem angefragt was zu tun ist. Eine Mögliche Reaktion ist beispielsweise das Verwerfen des Fragmentes.<br>
Siehe auch: [[wglCreateContext]], [[wglDeleteContext]], [[wglMakeCurrent]] und [[wglGetCurrentContext]]

== Scissor Test ==
Wenn GL_SCISSOR_TEST aktiviert ist, so wird hier geprüft ob das Fragment innerhalb des Rechtecks liegt welches mit [[glScissor]] definiert wurde. Ist dies nicht der Fall, so wird das Fragment verworfen.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glScissor]]

== Alpha Test ==
Wenn GL_ALPHA_TEST aktiviert ist, so wird geprüft ob der Alpha Wert des Fragmentes die mit [[glAlphaFunc]] definierte Bedienung erfüllt. Wird die Bedienung nicht erfüllt, so wird das Fragment verworfen.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glAlphaFunc]]

== Stencil Test ==
Wenn GL_STENCIL_TEST aktiviert ist, so wird geprüft ob der Stencil Teil des aktuellen [[Framebuffer]] an der Fragmentposition die Bedienung, welche mit [[glStencilFunc]] angegeben wurde, erfüllt. Ist dies nicht der Fall, so wird das Fragment verworfen.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glStencilFunc]]

== Tiefen Test ==
Wenn GL_DEPTH_TEST aktiviert ist, so wird geprüft ob der Tiefen Teil des aktuellen [[Framebuffer]] an der Fragmentposition die Bedienung, welche mit [[glDepthFunc]] angegeben wurde, erfüllt. Ist dies nicht der Fall, so wird das Fragment verworfen.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glDepthFunc]]

== Blending ==
Wenn GL_BLEND aktiviert ist, so wird die Farbe des Fragmentes und die Farbe aus dem aktuellen [[Framebuffer]] an der Fragmentposition anhand der oder des Alphawertes und der mit [[glBlendFunc]] angegebenen Funktion interpoliert.<br>
Siehe auch [[glEnable]], [[glDisable]], [[glBlendFunc]] und [[GL_ARB_imaging]]

== [[Dithering]] ==
For allem im Farbindex-Modus wird hier die Illusion von mehreren unterschiedlichen Farben und weiche Übergänge erzeugt. Die Bedienung für diesen Algorithmus ist allerdings, das er nur am aktuelle Fragment basiert (Beispielsweise Fensterposition und Farbwert), was die Berechnungsmöglichkeiten etwas einschränkt.<br>
Siehe auch: [[glEnable]]( GL_DITHER ), [[glDisable]], [[Antialiasing]] und [[Dithering]]

== Logische Operationen ==
Hier können auf Bit-Ebene logische Operationen durchgeführt werden. Wenn im RGBA Modus GL_COLOR_LOGIC_OP aktiviert ist, so wird dafür Blending ausgeschalten.<br>
Siehe auch: [[glEnable]], [[glDisable]] und [[glLogicOp]]

== Farb Maskierung ==
Hier kann mittels [[glIndexMask]], [[glColorMask]], [[glDepthMask]] und [[glStencilMask]] gesteuert werden, welche Werte in den [[Framebuffer]] geschrieben werden sollen und welche nicht. Was genau rein geschrieben wird, kann für den Stencil Buffer entweder hier oder auch schon beim Stencil Test durch [[glStencilOp]] festgelegt werden.<br>
Siehe auch: [[glIndexMask]], [[glColorMask]], [[glDepthMask]], [[glStencilMask]] und [[glStencilOp]]

== Frame Buffer Kontrolle ==
Dieser Teil übernimmt die Kontrolle über alle vorhandenen [[Framebuffer]]. Beispielsweise durch [[glDrawBuffer]] kann der aktuelle Frame Buffer gewechselt werden.

== Siehe auch ==

[[SwapBuffers]] und [[glDrawBuffer]]

[[ShaderModel]] für die Änderung an der Pipeline mit Einführung von [[Shader]]n.

== Ressourcen ==
<ul>
<li>[http://www.opengl.org/documentation/specs/version1.1/state.pdf OpenGL 1.1 State Machine (PDF)]</li>
<li>[http://www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf OpenGL 1.2.1 Specification (PDF)]</li>
</ul>