DGL Wiki - Benutzerbeiträge [de]

glUnmapBuffer

2008-02-24T02:48:25Z

Oc2k1: /* Name */

= glMapBuffer =

== Name ==
'''glUnmapBuffer''' - Ermöglicht es andern Befehlen wieder auf den Buffer zuzugreifen, in dem es ihn vom Client zurückholt.

== Delphi-Spezifikation ==
function '''glUnmapBuffer'''(''target'' : TGLenum) : TGLboolean

== Parameter ==

{| border="1" rules="all"
! ''target''
| Mögliche Werte: '''GL_ARRAY_BUFFER''' oder '''GL_ELEMENT_ARRAY_BUFFER'''
|}

== Beschreibung ==
Ein mit [[glMapBuffer]] in den Client Adressraum übertragener Buffer, wird wieder zurückgeholt, damit OpenGL Befehle wieder auf ihn zugreifen können. Der Pointer vom [[glMapBuffer]] Aufruf wird dadurch ungültig. Der GL_BUFFER_MAPPED Status des Objektes wechselt auf FALSE, der Status GL_BUFFER_MAP_POINTER wechselt zu NULL (in C++).

Der Befehl '''glMapBuffer''' gibt TRUE zurück, wenn der Buffer nicht beschädigt wurde, wärend er sich im Client Adressraum befandt. Andernfalls wird FALSE zurückgegeben.

== Fehlermeldungen ==
'''GL_INVALID_OPERATION''' wird generiert wenn sich der Buffer bereits nicht mehr im Client Adressraum befindet.

[[glBindBuffer]], [[glBufferData]], [[glBufferSubData]], [[glDeleteBuffers]], [[glGenBuffers]], [[glGetBufferParameter]], [[glGetBufferPointerv]], [[glGetBufferSubData]], [[glIsBuffer]], [[glMapBuffer]]
[[Kategorie:GL|UnmapBuffer]]

glUnmapBuffer

2008-02-24T02:47:50Z

Oc2k1: /* Delphi-Spezifikation */

= glMapBuffer =

== Name ==
'''glMapBuffer''' - Ermöglicht es andern Befehlen wieder auf den Buffer zuzugreifen, in dem es ihn vom Client zurückholt.

== Delphi-Spezifikation ==
function '''glUnmapBuffer'''(''target'' : TGLenum) : TGLboolean

== Parameter ==

{| border="1" rules="all"
! ''target''
| Mögliche Werte: '''GL_ARRAY_BUFFER''' oder '''GL_ELEMENT_ARRAY_BUFFER'''
|}

== Beschreibung ==
Ein mit [[glMapBuffer]] in den Client Adressraum übertragener Buffer, wird wieder zurückgeholt, damit OpenGL Befehle wieder auf ihn zugreifen können. Der Pointer vom [[glMapBuffer]] Aufruf wird dadurch ungültig. Der GL_BUFFER_MAPPED Status des Objektes wechselt auf FALSE, der Status GL_BUFFER_MAP_POINTER wechselt zu NULL (in C++).

Der Befehl '''glMapBuffer''' gibt TRUE zurück, wenn der Buffer nicht beschädigt wurde, wärend er sich im Client Adressraum befandt. Andernfalls wird FALSE zurückgegeben.

== Fehlermeldungen ==
'''GL_INVALID_OPERATION''' wird generiert wenn sich der Buffer bereits nicht mehr im Client Adressraum befindet.

[[glBindBuffer]], [[glBufferData]], [[glBufferSubData]], [[glDeleteBuffers]], [[glGenBuffers]], [[glGetBufferParameter]], [[glGetBufferPointerv]], [[glGetBufferSubData]], [[glIsBuffer]], [[glMapBuffer]]
[[Kategorie:GL|UnmapBuffer]]

Boneanimation per Vertexshader

2007-05-15T02:08:43Z

Oc2k1: /* Vorwort */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Auch Kenntnisse über Quaternionen oder Matrizen sind vorausgesetzt.

Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Modeldaten==

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

==Vertexshader==

Hier werden die beiden Varianten von Vertexshadern beschrieben.

===Matrix basierende Boneanimation===

Zum gewichten werden pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==CPU side Stuff==

Wer gedacht hat das war es schon, wird nun leider entäuscht werden, es ist zwar nur ein geringes Problem um die uniform arrays mit fertigen Posen zu füllen, die man z.B. mit einem Blender exporter erzeugen könnte, jedoch macht es mehr Sinn ein eine Armature zu bauen über die man das Modell manipulieren kann. Zur inversen Kinematik ist es dann nur noch ein kleiner Schritt. Die Armature kann Quaternion als auch Matrix basierend aufgebaut werden. Für alle die Quaternionen noch etwas fremdes sind, hilft es sehr wenn man diese als eine andere Form von Rotationsmatrizen betrachted, auch wenn sie etwas andere Eigenschaften haben.

Grundsätzlich sind folgende Eigenschaften für jeden Bone unverzichtbar:

Initial Joint Position, einem Positionsvektor mit 3 Kompoinenten.
Aktuelle Joint Position, ebenfalls einem Positionsvektor.
Die Rotation, sie kann durch ein Quaternion oder eine Rotationsmatrix dargestellt werden.
Eine Liste aller Children.

Unnötig sind dagegen:
Ein zweites Boneende, wie viele Editoren es verwenden.

Wird ein Bone rotiert muss die müssen alle Children mit rotiert werden. Das beiduetet, das sich deren Rotationen und Jointpositionen ändern. Alle Joints müssen dabei um den eigenen Joint mit der entsprechnden Rotation rotiert werden.

To continue...

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die benötigten Daten zu erzeugen.

Boneanimation per Vertexshader

2007-05-14T23:46:41Z

Oc2k1: /* Externe Links */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Modeldaten==

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

==Vertexshader==

Hier werden die beiden Varianten von Vertexshadern beschrieben.

===Matrix basierende Boneanimation===

Zum gewichten werden pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==CPU side Stuff==

Wer gedacht hat das war es schon, wird nun leider entäuscht werden, es ist zwar nur ein geringes Problem um die uniform arrays mit fertigen Posen zu füllen, die man z.B. mit einem Blender exporter erzeugen könnte, jedoch macht es mehr Sinn ein eine Armature zu bauen über die man das Modell manipulieren kann. Zur inversen Kinematik ist es dann nur noch ein kleiner Schritt. Die Armature kann Quaternion als auch Matrix basierend aufgebaut werden. Für alle die Quaternionen noch etwas fremdes sind, hilft es sehr wenn man diese als eine andere Form von Rotationsmatrizen betrachted, auch wenn sie etwas andere Eigenschaften haben.

Grundsätzlich sind folgende Eigenschaften für jeden Bone unverzichtbar:

Initial Joint Position, einem Positionsvektor mit 3 Kompoinenten.
Aktuelle Joint Position, ebenfalls einem Positionsvektor.
Die Rotation, sie kann durch ein Quaternion oder eine Rotationsmatrix dargestellt werden.
Eine Liste aller Children.

Unnötig sind dagegen:
Ein zweites Boneende, wie viele Editoren es verwenden.

Wird ein Bone rotiert muss die müssen alle Children mit rotiert werden. Das beiduetet, das sich deren Rotationen und Jointpositionen ändern. Alle Joints müssen dabei um den eigenen Joint mit der entsprechnden Rotation rotiert werden.

To continue...

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die benötigten Daten zu erzeugen.

Boneanimation per Vertexshader

2007-05-14T23:45:44Z

Oc2k1: /* Technik */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Modeldaten==

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

==Vertexshader==

Hier werden die beiden Varianten von Vertexshadern beschrieben.

===Matrix basierende Boneanimation===

Zum gewichten werden pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==CPU side Stuff==

Wer gedacht hat das war es schon, wird nun leider entäuscht werden, es ist zwar nur ein geringes Problem um die uniform arrays mit fertigen Posen zu füllen, die man z.B. mit einem Blender exporter erzeugen könnte, jedoch macht es mehr Sinn ein eine Armature zu bauen über die man das Modell manipulieren kann. Zur inversen Kinematik ist es dann nur noch ein kleiner Schritt. Die Armature kann Quaternion als auch Matrix basierend aufgebaut werden. Für alle die Quaternionen noch etwas fremdes sind, hilft es sehr wenn man diese als eine andere Form von Rotationsmatrizen betrachted, auch wenn sie etwas andere Eigenschaften haben.

Grundsätzlich sind folgende Eigenschaften für jeden Bone unverzichtbar:

Initial Joint Position, einem Positionsvektor mit 3 Kompoinenten.
Aktuelle Joint Position, ebenfalls einem Positionsvektor.
Die Rotation, sie kann durch ein Quaternion oder eine Rotationsmatrix dargestellt werden.
Eine Liste aller Children.

Unnötig sind dagegen:
Ein zweites Boneende, wie viele Editoren es verwenden.

Wird ein Bone rotiert muss die müssen alle Children mit rotiert werden. Das beiduetet, das sich deren Rotationen und Jointpositionen ändern. Alle Joints müssen dabei um den eigenen Joint mit der entsprechnden Rotation rotiert werden.

To continue...

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:18:55Z

Oc2k1: /* Matrix basierende Boneanimation */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Matrix basierende Boneanimation===

Zum gewichten werden pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:16:13Z

Oc2k1: /* Gewichten der Bones */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Matrix basierende Boneanimation===

Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:15:21Z

Oc2k1:

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal;
//T = m3 * Tangent;
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:14:22Z

Oc2k1: /* Gewichten der Bones */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

N = m3 * gl_Normal);
//T = m3 * Tangent);
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:13:34Z

Oc2k1: /* Quaternionen im Vertexshader */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;
for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)" cast

N = m3 * gl_Normal);
//T = m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:09:11Z

Oc2k1: /* Quaternionen im Vertexshader */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;
for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)" cast

N = m3 * gl_Normal);
//T = m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll. Die W-komponente wird dabei durch die Indexnummer des Joints ersetzt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
Die qrot Funktion rotiert einen Vektor mit hilfe eines Quaternions.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren:
<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ProjectionMatrix * vert;

N = qrot(quaternion, gl_Normal);
//T = qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T23:01:43Z

Oc2k1: /* Quaternionen im Vertexshader */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;
for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)" cast

N = m3 * gl_Normal);
//T = m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;

uniform vec3 Joints[32];
uniform vec4 Quaternions[32];
varying vec3 T,B,N;

vec3 qrot( vec4 q, vec3 v ){
return v + 2.0*cross(q.xyz, cross(q.xyz ,v) + q.w*v);
}

void main(void){
vec4 quaternion = vec4(0.0, 0.0, 0.0, 0.0);

for ( int i = 0; i < 4; i++){
quaternion += Quaternions[Bones[i]] * fract(Bones[i]);
}

normalize(quaternion);

vec4 vert = vec4(qrot(quaternion,gl_Vertex.xyz) + Joints[gl_Vertex.w] ,1.0)
gl_Position = gl_ModelViewProjectionMatrix * vert;

N = gl_NormalMatrix * qrot(quaternion, gl_Normal);
//T = gl_NormalMatrix * qrot(quaternion, Tangent);
//B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren.

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T22:58:22Z

Oc2k1: /* Gewichten der Bones */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern. Jedoch sollten variablen die über das ganze Model gleich bleiben, auf der CPU berechnet werden.

Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke (Joints) verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei bis vier Float4 vektoren benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn das nicht ausreicht macht es Sinn bei Objekte mit vielen Bones Teile wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen.
Um die größe der Geometriedaten (Attribute) klein zu halten macht es Sinn. Den Index mit der Gewichtung zu addieren. Da die Summe aller gewichungen 1.0 ist, ist das trennen im shader kein problem. Lediglich der Sonderfall der Gewichtung von 1.0, muss auf zwei Gewichtungen zu 0.5 aufgeteilt werden.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier kann ein Quaternion basierendes Animationsystem zu mehr Qualität helfen.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann, prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 4 Vector MADDs (Multiplikation und Addition) benötigt. Insgesamt werden 16 Vector MADD instructions benötigt.

<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;

for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ModelViewProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)"

N = gl_NormalMatrix * (m3 * gl_Normal);
//T = gl_NormalMatrix * (m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Als Optimierung kann es sinvoll sein die Modelviewmatrix mit den Bonematrizen zu multiplizieren, da so der Vertexshader entlasted werden kann:
<glsl>
attribute vec4 Bones;
attribute vec3 Tangent;
uniform mat4 Pose[32];
varying vec3 T,B,N;

void main(void){
mat4 mat = 0.0;
for ( int i = 0; i < 4; i++){
mat += Pose[int(Bones[i])] * fract(Bones[i]);
}

gl_Position = gl_ProjectionMatrix * (mat *gl_Vertex);

mat3 m3 = mat3(mat[0].xyz, mat[0].xyz, mat[0].xyz); // "mat3(mat)" cast

N = m3 * gl_Normal);
//T = m3 * Tangent);
//B = cross (T,N);
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

===Quaternionen im Vertexshader===

Lange gab es die diskusion ob Quaternion in shadern überhaupt Sinn machen, bei der Boneanimation im Vertexshader, hat sich herausgestellt, das die Anzahl der benötigten Instruktionen ähnlich ist wie bei der Matrix basierenden Variante. Der entscheidene Vorteil ist das sie für organische strukturen qualitativ besser ist und das nur zwei Uniform Float4 Vektoren pro Joint/Bone verbraucht werden.
Etwas problematisch ist, dass die Vertexpositionen nicht mehr absolut zum Modelnullpunkt, sondern relativ zu dem Joint angegeben werden muss um das eine spherische Interpolation durchgeführt werden soll.

Auch hier kann es sinnvoll sein, die Joints in den Modelviewspace zu transformieren und die Quaternionen mit der Normalmatrix (gegebenfals in ein Quaternion umwandeln) zu rotieren.

==Externe Links==

http://lumina.sourceforge.net/?id=27 Beispiel in Lumina. Der mit Lumina mitgelieferte Blenderexporter ist in der Lage die für

Boneanimation per Vertexshader

2007-05-14T22:56:07Z

Oc2k1:

Boneanimation per Vertexshader

2007-05-14T22:51:10Z

Oc2k1: /* Quaternionen im Vertexshader */

Boneanimation per Vertexshader

2007-05-14T22:50:08Z

Oc2k1: /* Quaternionen im Vertexshader */

Boneanimation per Vertexshader

2007-05-14T22:48:58Z

Oc2k1:

Boneanimation per Vertexshader

2007-05-14T22:12:43Z

Oc2k1: /* Kompression der Matrizen */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei oder drei Float4 benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von [[Quaternion|Quaternionen]] im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern.
Eine gepackte Matrix kommt mit 8 Floats aus. Für Quarternionen wäre mit zusätzlichem Translationsteil 7 Floats nötig. Einen wirklichenSinn machen Quarternionen im Vertexshader also definitiv nicht

===Überlagerung meherer Animationen===

Sicher werden am Anfang statische Posen ausreichen. Jedoch ist es mit einer Matrixmultiplikation pro Bone möglich zwei Posen zu überlagern. z.B. kann man so verschiedene Posen einer Hand an einen Arm binden. In diesem Fall müssen die Matrizen der Handanimation mit den Matrizen der Körperanimation Multipliziert werden.
Alle von der Teilanimation nicht betroffenen Matrizen müssen dabei einheitsmatrizen entsprechen, damit die Multiplikation keine Auswirkung hat.

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Blenderexporter

2006-12-16T12:53:54Z

Oc2k1: /* Daten für Indizierte VBOs exportieren */

{{Offline}}

==Vorwort==

Hier werde ich einige Codeschnipsel zeigen, mit denen man sich einen eigenen Blenderexporter bauen kann. Der Schwerpunkt liegt dabei darauf, die Daten so vorzubereiten, dass sie direkt als VertexBufferObjekt in die Grafikkarte hochgeladen werden können.

Dieses Tutorial, soll kein festes Format beschreiben. Es ist sowohl möglich die Daten sauber in XML zu kapseln, als auch ganz dirty mal eben ein Includierbares C oder Pascalfile zu erzeugen. Der Compiler wird einen dafür aber mit erheblich längeren compelierungszeiten bestrafen.

Prinzipell bin ich der Meinung, das eine eigene Engine nicht zwangshaft mit einem Universalformat wie Collada verwendet werden muss. Auch beliebte Formate wie 3DS haben gewaltige Nachteile, da sie nicht alle Daten speichern können, die beim Arbeiten mit Shadern benötigt werden. 3DS ist eine gut wahl, solang man nicht viel mehr als Vertices, Normals und UV Coordinaten benötigt. Sobald Bones Vertexgruppen, TBN Matrizen und möglicherweise weitere eigene Daten gespeichert werden müssen gibt es große Probleme.

==Aufbau eines Exporters==

Jeder Blenderexporter verfügt über einen Header, in dem Daten stehen, wie er in die Menüstruktur eingefügt wird. Anschließen folgt der Python code. Näheres dazu steht in den Wikibooks.
<python>
#!BPY
"""
Name: 'DGL Wiki'
Blender: 241
Group: 'Export'
Tooltip: 'DGL Wiki Exporter'
"""
import Blender

#Hier werden zusätzliche Funktionen eingefügt, die zum schreiben benötigt werden

def write(filename):
out = file(filename, 'w')
obj = Blender.Object.GetSelected()[0]
msh = obj.getData()

#hier wird Code eingefügt, der die zu exportierende Daten schreibt

out.close()
Blender.Window.FileSelector(write, "Export")
</python>
code getestet

Wichtig ist, das man bei Python die Einrückungen beachtet. Als erstes wird eine Funktion definiert, die vom Fileexportdialog aus aufgerufen wird. Dabei wird der Filename als Argument übergeben. Die folgenden Zeilen öffnen ein File zum schreiben und hohlen sich die Meshdaten des erstem selektiertem Objektes.
Starten tut das Script eigendlich erst in der letzten Zeile, die den Exportdialog aufruft.

==Vorbereiten der Daten==

Da OpenGL nicht gut auf die gemischten Quads und Triangles klar kommt ist es sehr Sinnvoll sie gleich am Anfang vor dem Exportieren umzuwandeln:
<python>
def quad2tri(msh):
flist=[]
for face in msh.faces:
if (len(face.v)==3):
flist += [face]
else:
d1 =(msh.verts[face.v[0].index].co.x - msh.verts[face.v[2].index].co.x) ** 2
d1+=(msh.verts[face.v[0].index].co.y - msh.verts[face.v[2].index].co.y) ** 2
d1+=(msh.verts[face.v[0].index].co.z - msh.verts[face.v[2].index].co.z) ** 2
d2 =(msh.verts[face.v[1].index].co.x - msh.verts[face.v[3].index].co.x) ** 2
d2+=(msh.verts[face.v[1].index].co.y - msh.verts[face.v[3].index].co.y) ** 2
d2+=(msh.verts[face.v[1].index].co.z - msh.verts[face.v[3].index].co.z) ** 2
if (d1<d2):
flist += [Blender.NMesh.Face([face.v[0],face.v[1],face.v[2]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[1],face.uv[2]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[2]]
flist[len(flist)-1].smooth=face.smooth

flist += [Blender.NMesh.Face([face.v[0],face.v[2],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[2],face.uv[3]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[2]]
flist[len(flist)-1].smooth=face.smooth
else:
flist += [Blender.NMesh.Face([face.v[0],face.v[1],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[1],face.uv[3]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[3]]
flist[len(flist)-1].smooth=face.smooth

flist += [Blender.NMesh.Face([face.v[1],face.v[2],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[1],face.uv[2],face.uv[3]]
flist[len(flist)-1].col=[face.col[1],face.col[2],face.col[3]]
flist[len(flist)-1].smooth=face.smooth
msh.faces=flist
return msh

</python>
Das Prinzip ist Relativ leicht zu verstehen. "flist" ist eine Liste in der die neuen Dreiecke zwischengespeichert werden. Dreiecke werden einfach kopiert. Bei Quads wird die kürzere Diagonale zum Teilen gesucht und aus den Daten des Quads zwei neue Triangles erzeugt. Zum Schluss wird noch die temporäre Liste im Mesh gespeichert und as ganze zurückgegeben.

==Exportieren der Daten==

hier beschreiben ich wie man die wichtigsten Daten exportieren kann. Um ein anderes Format zu erhalten, müssen die Stings entsprechend angepasst werden. Eine neue Zeile erhält man durch "\n" In den Beispielen werde ich mich weitgehend an Werten gekapselt in einem XMLformat halten. Durch simple Modifikationen sind auch andere Formate kein problem.

Es gibt zwei Möglichkeiten die Vertexdaten zu speichern: Interleaved oder getrennte Blöcke. Beim interleaved Format verliert man die Flexibilität und die Daten werden noch unübersichtlicher. Ein Geschwindigkeitsgewinn ist auch nicht zu erwarten.

In einigen Codestücken wird auffallen, das die Convertierung von Quads nach Triangles immer wieder vorgenommen wird. In einem komplettem Exporten macht es durchaus Sinn, alle Daten erst zu sammel, dann zu sortieren, umwandeln und erst zum Schluss zu schreiben. Dabei wäre es allerdings nicht mehr möglich einzelne Beispiele zu liefern.

Eine besonder Problematik ist, dass Blender Quads beforzugt, jedoch Quads und Triangles gemischt vorliegen können. Um diese Mischung zu vermeiden sollte man entweder den Exporter so schreiben, dass er die Quads in 3 Triangles zerlegt oder vor dem Exportieren alle Quads in Triangles umwandelt und Speichert (Intern bleiben die Daten sonst anscheined immer noch Quads)

Einfachen Text, der keine zu exportierenden Daten enhält lässt sich so in die Datei schreiben. Hier ein möglicher begin der XML Datei:

<python>
out.write('<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n')
</python>

Wichtig ist hier wieder die Einrückung. Sie muss genauso weit eingerück sein wie die vorige Zeile, oder weiter eingerück werden wenn es sich um eine Schleife handelt.

Eine kleines Problem kann entstehen, wenn die letzte Zeile eines Datensatzes kein Komma enthalten darf. Der einfachste Weg ist eine Dummyzeile mit Nullwerten anzuhängen.

===Name des Objektes und Anzahl der Vertices===

In einem XML format ist es nicht alzuwichtig den Objektnamen aus Blender zu behalten. Jedoch kann es sehr nützlich sein wenn man andere Formate schreibt oder mehrere Objekte in einer Datei speichert. Wir bringen diese Daten einfach im VBO Tag unter, welches alle unsere Vertexdaten kapseln wird:

<python>
out.write('<vbo name="%s" verts="%i" type="GL_TRIANGLE">\n' % (msh.name, len(msh.faces)*3))
</python>

Zum Schluss sollte noch folgende Zeile angehängt werden um den VBO tag wieder zu schließen:
<python>
out.write('</vbo>')
</python>

===Vertices===
Da man den Index eines Vertexarray nicht in einem VBO verpacken kann. Ist es besser die Triangles nicht indiziert in einem VBO zu speichern. Der Speicherbedarf ist hier allerdings höher. Trotz der erhöten Datenmenge scheint diese Variante schneller zu sein, da hier keine Arrays vom Prozessor abgearbeitet werden müssen.
Unter der Annahme, das nur Triangles vorhanden sind, reicht dieser Code:

<python>
out.write('<vertices comp="3">\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f %f %f' % (msh.verts[vert.index].co.x, msh.verts[vert.index].co.y, msh.verts[vert.index].co.z))
out.write('\n')
out.write('</vertices>\n')
</python>

===Textur-Koordinaten===

Kaum schwerer als die Vertexdaten sind die Texturkoordinaten zu exportieren. Da die Texturkoordinaten innerhalb der Faces gespeichert werden. Sinvollerweise überprüfen wir voher noch ob überhaupt Texturdaten vorhanden sind:

<python>
if (msh.hasFaceUV()==1):
out.write('<texturecoords comp="2">\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f %f %f %f %f %f\n' % (face.uv[0][0],face.uv[0][1],face.uv[1][0],face.uv[1][1],face.uv[2][0],face.uv[2][1]) )
out.write('</texturecoords>\n')
</python>

===Normals===

Normalvektoren sind in Blender sowohl per Vertex als auch per Face abgespeichert. Abhängig, davon ob eine Fläche als Smooth (per Vertex) oder Solid (per Face) dargestellt wird, werden die die entsprechenden Normalvektoren ausgewählt. Damit auch Klötze mit Kanten dargestellt werden können müssen beide Fälle berücksichtigt werden. Im Fall Solid müssen für alle Vertices der Fläche der Normalvektor der Fläche verwendet werden. Im Fall Smooth muss hier der Normalvektor der Vertices benutz werden.
Auf keinen Fall sollte man nun die Vervielfachung der Vertices als Problem ansehen, da die verschiedenen Normalvektoren, diesen Nachteil wieder volkommen ausgleichen.

Tip: Da ganze Flächen als Solid keinerlei Optische Rundungen zulassen, ist der einzige Weg, echte Kanten an runden Objekten zu erzeugen in dem man das Mesch an der Stelle splittet. Leider muss man zum Splitten einen vollständigen Edgeloop auswählen. An Stellen die nicht kantig sein sollen muss man dann beide Vertices Makieren und mit "remove doubles" vereinen.

Auch hier ersst einmal ein einfaches Beispiel was haufig schon genügen sollte:

<python>
out.write('<normals>\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f, %f, %f,' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z) )
out.write('\n')
out.write('</normals>\n')
</python>

Besser wird es, wenn Smooth/Solid berücksichtigt wird.
<python>
out.write('<normals>\n')
for face in msh.faces:
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f, %f, %f,' % (face.no.x, face.no.y, face.no.z))
out.write('\n')
out.write('</normals>\n')
</python>

===Tangenvektor / TBN Matrix ===

Ohne die TBN Matrix lässt sich in den shadern kein sinvolles Bumpmapping durchführen. Weder Dot3, Offset, Parallax noch
Reliefmapping sind ohne TBN Matrix möglich.
Eine TBN Matrix besteht aus drei Vektoren, die den Texturespace aufspannen:

Normal

Er steht immer Senkrecht zur Oberfläche. Er entspricht genau dem Normalvektor wie wir ihn kennen.
Beim Paralax und Reliefmapping repräsentiert seine Länge den Masstab für die dritte Texturkoordinate (Im Editor wäre sie W, auch wenn die Texturkoordinaten in OpenGL s, t, p und q sind).

Tangent

Er liegt tangential auf der Textur und ist dort zur U Achse ausgerichtet. Wieder einmal kann man überlegen ob es nun beteutet Senktrecht zum Normal oder Parallel zu Fläche des Dreieckes. Wer keine Kopfschmerzen hat macht sich welche.

Bitangent

Häufig wird er auch Binormal genannt, jedoch beschreibt Bitangent die Funktion besser. Er ist wie der Tangent tangential zur V Achse der Textur ausgerichtet.
Wer meint Bitangent lässt sich durch das Kreutzprodukt von Normal und Tangend berechnen, hat nur recht wenn die Textur keine Scherung enthällt.

So lange die Textur nicht verzert wird, ist eine normalisierte TBN Matrix problemlos verwendbar, wenn jedoch die Tiefenkomponente der Textur nicht auf kubischen Texeln basiert, ist es sinvoller die Korrektur im Shader vorzunehmen, als die Komonenten dern TBN Matrix zu verzerren.

Da ich es jetzt anscheinend verstanden habe wie ich die zusätzlichen komponenten der TBN Matrix berechnen kann. Kommt hier der Code zum erzeugen der Tangent und Bitangentvektoren pro Face und Vertex:
<python>
def createFaceTan(msh):
ftan = []
for face in msh.faces:
tan = msh.verts[face.v[2].index].co - msh.verts[face.v[0].index].co
if (face.uv[2][1] != face.uv[1][1]):
m = (face.uv[2][1]-face.uv[0][1])/(face.uv[2][1]-face.uv[1][1])
tan += (msh.verts[face.v[1].index].co - msh.verts[face.v[2].index].co) * m
tan.normalize()
ftan += [tan]
return ftan

def createFaceBit(msh):
fbit = []
for face in msh.faces:
bit = msh.verts[face.v[1].index].co - msh.verts[face.v[0].index].co
if (face.uv[1][0] != face.uv[2][0]):
m = (face.uv[1][0]-face.uv[0][0])/(face.uv[1][0]-face.uv[2][0])
bit += (msh.verts[face.v[2].index].co - msh.verts[face.v[1].index].co) * m
bit.normalize()
fbit += [bit]
return fbit

def interpolate(msh,ftan):
vtan = []
for vert in msh.verts:
vtan += [Blender.NMesh.Vert().co]
for face in msh.faces:
if (face.smooth == 1):
for vert in face.v:
vtan[vert.index] += ftan[vert.index]
for i in range(0,len(msh.verts)):
vtan[i].normalize()
return vtan

ftan = createFaceTan(msh)
vtan = interpolate(msh,ftan)
fbit = createFaceBit(msh)
vbit = interpolate(msh,fbit)
</python>
Hier noch der Link zum Artikel wo ich die Berechnung erkläre:
http://wiki.delphigl.com/index.php/TBN_Matrix

Mit folgenden Codeschnipseln, lassen sich Tangent, Bitanget und die TBN Matrix ausgeben. Sinvoll ist es natürlich nur die Einzelkomponenten zusätzlich zum Normalvektor zu schreiben oder die TBN Matrix ohne Normalen zu verwenden.

<python>
out.write('<tan>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vtan[vert.index].x, vtan[vert.index].y, vtan[vert.index].z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (ftan[i].x, ftan[i].y, ftan[i].z))
out.write('\n')
out.write('</tan>\n')

out.write('<bit>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vbit[vert.index].x, vbit[vert.index].y, vbit[vert.index].z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (fbit[i].x, fbit[i].y, fbit[i].z))
out.write('\n')
out.write('</bit>\n')

out.write('<tbn>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vtan[vert.index].x, vtan[vert.index].y, vtan[vert.index].z))
out.write( ' %f %f %f' % (vbit[vert.index].x, vbit[vert.index].y, vbit[vert.index].z))
out.write( ' %f %f %f\n' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z))
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (ftan[i].x, ftan[i].y, ftan[i].z))
out.write( ' %f %f %f' % (fbit[i].x, fbit[i].y, fbit[i].z))
out.write( ' %f %f %f\n' % (face.no[0], face.no[1], face.no[2]))
out.write('</tbn>\n')
</python>
Warnung: Die Vektoren scheinen alle Senkrecht zu einander zu stehen, jedoch ist noch nicht überprüft ob die Matrizen wirklich brauchbar sind. Es wäre durchaus möglich, dass noch komponenten verdreht oder gespiegelt sind.

Aufgrund des Mangels an Atributevariablen, ist es nicht sehr Sinvoll die volle TBN Matrix zu übergeben. Sinvoller ist es nur den Tangendvektor (Bitangent kann durch ein Kreutzprodukt neu berechnet werden) oder den Tangentvektor zumammen mit dem Bitangentvektor als Atribute zu übergeben.

===Vertuxgruppen / Bones ===

Ohne Vertexgruppen und Bones lassen sich keine Animationen mit Hilfe des Vertexshaders realisieren. Diesen Teil können alle überspringen, die keine Vertexshader zum Animieren benutzen wollen.
Die Daten liegen in Blender in einer für Vertexshader leicht unbrauchbaren Form vor und müssen etwas aufbereitet werden. In jeder Vertexgruppe, auf die man auch noch über Ihren Namen zugreifen muss, liegt eine Liste mit der Vertexnummer und der Gewichtung.
Für einen Vertexshader benötigen wir pro Vertex einen Index, der die Vertexgruppe/Bone beschreibt und die Gewichtung. Außerdem müssen wir uns voher entscheiden, wie viele Bones wir maximal pro Vertex berücksichtigen.

Bei Mangel an "attribute" Variablen macht es Sinn, die Gewichtung (muss kleiner als 1 sein) mit den Indizies zu addieren. Im Shader könnte man die dann wieder herausrechnen. Auf heutiger Hardware sind 16 Atribute Variablen möglich.

Als erstes den Codeblock zum aufbereiten der Daten. Es ist wichtig, dass die Variable num_of_vertexgroups.val die erwünschte Anzahl von Vertexgruppen enthällt:
<python>
vertGroupData = []
groups = msh.getVertGroupNames()
for vert in msh.verts:
list = []
count = 1
for group in groups:
if (len(msh.getVertsFromGroup(group,0,[vert.index]))==1):
list += [(msh.getVertsFromGroup(group,1,[vert.index])[0][1],count)]
count += 1
list.sort()
list.reverse()
for i in range(0,num_of_vertexgroups.val):
list += [(0.0, 0)]
vertGroupData += [(list[0:num_of_vertexgroups.val])]
</python>
Hinweis: Es gibt noch mit getVertexInfluences() eine bessere Methode zum ermitteln welche Vertexgruppe zu einem Vertex gehöhrt. Dann wäre jedoch der einsatz eines Dictonarys nötig.

Nun noch der Code zum schreiben:
<python>
out.write('<vertexgroups comp="%i">\n<weight>\n' % num_of_vertexgroups.val)
for face in msh.faces:
for vert in face.v:
for group in vertGroupData[vert.index]:
out.write( ' %f' % (group[0]))
out.write('\n')
out.write('</weight>\n<index>\n')
for face in msh.faces:
for vert in face.v:
for group in vertGroupData[vert.index]:
out.write( ' %i' % (group[1]))
out.write('\n')
out.write('</index>\n</vertexgroups>\n')
</python>

==Optimierung der Daten==

Bisher haben wir uns Hauptsachlich damit beschäftig wie wir die Daten aus der Blenderstruktur auszulesen und in ein Vertexbufferobjekt kompatible daten unzuformen. Wen die Modelle größer werden oder komplette Level in Blender realisiert werden sollen macht es Sinn die Daten so umzusortieren, das Triangles mit ähnlichen Eigenschaften wie Ort oder Ausrichtung nah im Vertexbufferobjekt beieinander liegen.

===Octree===

Beim Octree werden nur die Teile gerender, bei denen voher bekannt ist, dass sie sichtbar sind, leider ist die Baumstruktur eines Octtrees auf dem erstem Blick völlig inkompatibel zu dem linearem Verlauf des Vertexbuffersobjektes.

Um die Faces in den Octree einzusortieren muss von jedem der Schwerpunkt berechnet werden. Die Position im Octree wird mit einer art Hashfunktion berechnet, die erst aus den X Y und Z Koordinaten Integerwerte von 0 bis 1023 bildet und deren Bits so zusammensortiert, dass ein einziger Wert von 0 bis 2^30-1 ensteht. Nach dem die Faces sortiert werden:

<python>
def octree(msh):
# Boundingbox for Octree.
# Warnung: bei mehreren VBOs sollte die gleiche Boundingbox verwendet werden,
# damit nur einmal auf sichbarkeit überprüft werden muss
mini = msh.verts[0].co * 1.0
maxi = msh.verts[0].co * 1.0
for vert in msh.verts:
mini.x = minimum (mini.x,vert.co.x)
mini.y = minimum (mini.y,vert.co.y)
mini.z = minimum (mini.z,vert.co.z)
maxi.x = maximum (maxi.x,vert.co.x)
maxi.y = maximum (maxi.y,vert.co.y)
maxi.z = maximum (maxi.z,vert.co.z)
size = max (maxi.x-mini.x,maxi.y-mini.y,maxi.z-mini.z)
#Hashberechnung
optindex = []
count = 0
for face in msh.faces:
center = msh.verts[0].co * 0.0
for vert in face.v:
center += msh.verts[vert.index].co
#range 0.0 ... 1.0
center *= 1.0 /( len(face.v) * size * 2.0)
center.x += 0.5
center.y += 0.5
center.z += 0.5
ix = int (center.x * 1023)
iy = int (center.y * 1023)
iz = int (center.z * 1023)
sortby = (ix&512)<<18 | (ix&256)<<16 |(ix&128)<<14 | (ix&64)<<12 |(ix&32)<<10 | (ix&16)<<8 |(ix&8)<<6 | (ix&4)<<4 |(ix&2)<<2 | (ix&1)<<0
sortby |= (iy&512)<<19 | (iy&256)<<17 |(iy&128)<<15 | (iy&64)<<13 |(iy&32)<<11 | (iy&16)<<9 |(iy&8)<<7 | (iy&4)<<5 |(iy&2)<<3 | (iy&1)<<1
sortby |= (iz&512)<<20 | (iz&256)<<18 |(iz&128)<<16 | (iz&64)<<14 |(iz&32)<<12 | (iz&16)<<10|(iz&8)<<8 | (iz&4)<<6 |(iz&2)<<4 | (iz&1)<<2
optindex += [(sortby,count)]
count += 1
#Umsortierung der Daten
optindex.sort()
flist=[]
for i in optindex:
flist += [msh.faces[i[1]]]
msh.faces=flist
#Hier sollten noch die Verwaltungsdaten für den Octree geschrieben werden
#Diese Code fehl allderings noch

return msh
</python>
Diese Funktion sollte dierekt nach dem umwandeln der Quads in Triangles aufgerufen werden, da die Reihfolge der Triangles geändert wird.

Prinzipiell gibt es für jedes würfelförmige Volumen nur eine Start und Stopindexnummer die beim Rendern übergeben werden muss:
<cpp>
glDrawArrays( GL_TRIANGLES, start, stop - start);
</cpp>
Grundsätz sollte beachtet werden, dass es bei der Verwendung von VBOs möglichst viele Triangles auf einmal gerendert werden sollen. Wo die untergrenze Pro volumen liegt lässt sich schwer sagen, es mach aber Sinn, diese jenseits der 1000-10000 anzusetzten.

===Vorsortierung nach Vertexgruppen/Bones===

Es ist zwar noch kein Algoritmus zum sortieren vorhanden, jedoch ist es bei animierten Modellen sinnvoll möglichst ganze Bones auf einmal abzuarbeiten, da ein Bone ganze 12 Uniform Floats im Vertexshader verbraucht (9 für eine Rotationsmatrix und 3 für das Gelenk). Laut GLSL Spezifikation soll man minimal 512 davon haben, was maximal 40 Bones entspricht. Dummerweise scheint es so als wenn einige Grafikkarten nur 256 Uniform Floats zur Verfügung stellen, was zur Folge hat, das nur noch 20 Bones möglich wären.
Eine primitive Optimierung wäre nur einen halbes Model zu speichen. und für die zweite hälfte das gleiche Mesh gespiegelt mit neuen Bones zu verwenden.

Die Sinvollste Variante ist die schon erzeugten Vertexgruppendaten zum Sortieren zu benutzen: Die Gruppe mit der höchsten Gewichtung wird zum einsortieren benutzt. Alle Vertices die nicht in einer Gruppe sind, landen in einer extra gruppe. Diese Gruppen werde nun so umsortiert, dass Gruppen mit gegenseitigem Einfluss na beieinander landen. und Vertexgruppen die sih nicht beeinflussen weit von einander im VBO entfernt liegen.

==Daten für Indizierte VBOs exportieren==

Lange Zeit hab ich dieses Thema umgangen da der export relativ komplex ist. Alle Daten aus Blender müssen komplett neu umgeornet und neu indiziert werden, da Blender die Texturkoordinaten nicht per Vertex, sondern per Face abspeichert. Als Beispiel wird diesmal ein vereinfachter OBJ exporter dienen, der allerdings um tangentvektoren ergänst wird.

<python>
#!BPY
"""
Name: 'VBO Wiki'
Blender: 241
Group: 'Export'
Tooltip: 'VBO Wiki Exporter 3 C version'
"""
import Blender
from Blender import NMesh
from Blender.BGL import *
from Blender.Draw import *
import math
from math import *

#leicht verständliche funktion jedoch sehr ineffezient
def lfind(liste,key):
for i in range(0, len(liste)):
if liste[i]==key: return i

def write(filename):
global num_of_vertexgroups,TBNMenu,Optimise
filename=replace(filename,".blend",".obj")
out = file(filename, 'w')

objs = Blender.Object.GetSelected()
if (len(objs)==0):
objs = Blender.Object.Get()
#eigendlich nur 1 durchlauf sinnvoll
for obj in objs:
if (obj.getType()=='Mesh'):

msh = obj.getData()
# quad2tri könnte von obern hier eingesetzt werden
# msh = quad2tri(msh)
raw_index = []
for face in msh.faces:
for i in range (0,len (face.v)):
vert = []
vert += [face.v[i].index]
vert += [face.uv[i][0]]
vert += [face.uv[i][1]]
raw_index += [vert]

raw_index.sort()
last =raw_index[-1]
for i in range(len(raw_index)-2, -1, -1):
if last==raw_index[i]:
del raw_index[i]
else: last=raw_index[i]

out.write('g Index\n')

for i in raw_index:
v = msh.verts[i[0]].co
out.write('v %f %f %f\n' % (v.x,v.y,v.z))

for i in raw_index:
v = msh.verts[i[0]].no
out.write('vn %f %f %f\n' % (v.x,v.y,v.z))

for i in raw_index:
out.write('vt %f %f\n' % (i[1],i[2]))

tan = [Blender.Mathutils.Vector(0,0,0) for i in range(0,len(raw_index))]
for face in msh.faces:
v1 = face.v[1].co - face.v[0].co
v2 = face.v[2].co - face.v[0].co
t1 = face.uv[1][1] - face.uv[0][1]
t2 = face.uv[2][1] - face.uv[0][1]

sdir = v1 * t2 - v2 * t1
sdir.normalize()
for i in range (0,len (face.v)):
vert = [face.v[i].index,face.uv[i][0],face.uv[i][1]]
tan[lfind(raw_index, vert)] += sdir

for i in range (0,len(raw_index)):
normal = msh.verts[raw_index[i][0]].no
otan = tan[i] - normal * Blender.Mathutils.DotVecs( tan[i], normal )
otan.normalize()
out.write('tan %f %f %f\n' % (otan.x,otan.y,otan.z))

for face in msh.faces:
out.write('f')
for i in range (0,len (face.v)):
vert = [face.v[i].index,face.uv[i][0],face.uv[i][1]]
out.write(' %i' % (lfind(raw_index, vert)))
out.write('\n')

out.close()
Exit()

#Blender.Window.FileSelector(write, "Export")
write ("out.obj")
</python>

==Zusätzliche Optionen Abfragen==

Ein Exporter ist schön, etwas unschön ist es bis jetzt, das die Ausgabe immer statisch nach dem gleichem Schema erfolgt. Um bestimmte Optionen aktivirbar und deaktivirbar zu machen, ist es nötig einen Dialog zu öffene, dessen eingaben in globalen Variablen abgelegt werden. Aus codetechnischer sicht ist es einfacher die Optionen vor dem Filedialog abzufragen.
Damit ein Dialog verwendet werden kann sind ein paar Änderungen am Code nötig.

Folgende Funktionen und globale Variablen müssen eingefügt werden:

<python>
num_of_vertexgroups = Create(4)
TMenu = Create(1)
EVENT_NOEVENT = 1
EVENT_EXPORT = 2
EVENT_CANCEL = 3

def draw():
global num_of_vertexgroups,TMenu
global EVENT_NOEVENT,EVENT_EXPORT
glClear(GL_COLOR_BUFFER_BIT)
glRasterPos2d(10, 125)
Text("DGL Exporter Options")

TMemu = Menu("Normal|Normal+Tangent|TBN-Matrix",EVENT_NOEVENT,10,75,210,18, 1)
num_of_vertexgroups= Number("No of Vertgroups: ", EVENT_NOEVENT, 10, 55, 210, 18,num_of_vertexgroups.val, 0, 10, "Number of Vertgroups per Vertex");
Button("Export",EVENT_EXPORT, 140, 10, 80, 18)
Button("Cancel",EVENT_CANCEL, 10, 10, 80, 18)

def event(evt, val):
if (evt == QKEY and not val):
Exit()

def bevent(evt):
global EVENT_NOEVENT,EVENT_EXPORT
if (evt== EVENT_EXPORT):
Blender.Window.FileSelector(write, "Export")
elif (evt == EVENT_CANCEL):
Exit()
</python>
Code noch nicht fertig

Die letzte Zeile, welche den Filedialog geöffnet hat, wird durch folgende ersetzt:
<python>
Register(draw, event, bevent)
</python>

Damit die write funktion keine Endloschleife verursacht, sollte sie noch um Exit() ergänst werden.

==Externe Links==

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Advanced_Tutorials/Python_Scripting/Export_scripts
[[Kategorie:Anleitung]]

Blenderexporter

2006-12-16T12:46:42Z

Oc2k1: /* Zusätzliche Optionen Abfragen */

{{Offline}}

==Vorwort==

Hier werde ich einige Codeschnipsel zeigen, mit denen man sich einen eigenen Blenderexporter bauen kann. Der Schwerpunkt liegt dabei darauf, die Daten so vorzubereiten, dass sie direkt als VertexBufferObjekt in die Grafikkarte hochgeladen werden können.

Dieses Tutorial, soll kein festes Format beschreiben. Es ist sowohl möglich die Daten sauber in XML zu kapseln, als auch ganz dirty mal eben ein Includierbares C oder Pascalfile zu erzeugen. Der Compiler wird einen dafür aber mit erheblich längeren compelierungszeiten bestrafen.

Prinzipell bin ich der Meinung, das eine eigene Engine nicht zwangshaft mit einem Universalformat wie Collada verwendet werden muss. Auch beliebte Formate wie 3DS haben gewaltige Nachteile, da sie nicht alle Daten speichern können, die beim Arbeiten mit Shadern benötigt werden. 3DS ist eine gut wahl, solang man nicht viel mehr als Vertices, Normals und UV Coordinaten benötigt. Sobald Bones Vertexgruppen, TBN Matrizen und möglicherweise weitere eigene Daten gespeichert werden müssen gibt es große Probleme.

==Aufbau eines Exporters==

Jeder Blenderexporter verfügt über einen Header, in dem Daten stehen, wie er in die Menüstruktur eingefügt wird. Anschließen folgt der Python code. Näheres dazu steht in den Wikibooks.
<python>
#!BPY
"""
Name: 'DGL Wiki'
Blender: 241
Group: 'Export'
Tooltip: 'DGL Wiki Exporter'
"""
import Blender

#Hier werden zusätzliche Funktionen eingefügt, die zum schreiben benötigt werden

def write(filename):
out = file(filename, 'w')
obj = Blender.Object.GetSelected()[0]
msh = obj.getData()

#hier wird Code eingefügt, der die zu exportierende Daten schreibt

out.close()
Blender.Window.FileSelector(write, "Export")
</python>
code getestet

Wichtig ist, das man bei Python die Einrückungen beachtet. Als erstes wird eine Funktion definiert, die vom Fileexportdialog aus aufgerufen wird. Dabei wird der Filename als Argument übergeben. Die folgenden Zeilen öffnen ein File zum schreiben und hohlen sich die Meshdaten des erstem selektiertem Objektes.
Starten tut das Script eigendlich erst in der letzten Zeile, die den Exportdialog aufruft.

==Vorbereiten der Daten==

Da OpenGL nicht gut auf die gemischten Quads und Triangles klar kommt ist es sehr Sinnvoll sie gleich am Anfang vor dem Exportieren umzuwandeln:
<python>
def quad2tri(msh):
flist=[]
for face in msh.faces:
if (len(face.v)==3):
flist += [face]
else:
d1 =(msh.verts[face.v[0].index].co.x - msh.verts[face.v[2].index].co.x) ** 2
d1+=(msh.verts[face.v[0].index].co.y - msh.verts[face.v[2].index].co.y) ** 2
d1+=(msh.verts[face.v[0].index].co.z - msh.verts[face.v[2].index].co.z) ** 2
d2 =(msh.verts[face.v[1].index].co.x - msh.verts[face.v[3].index].co.x) ** 2
d2+=(msh.verts[face.v[1].index].co.y - msh.verts[face.v[3].index].co.y) ** 2
d2+=(msh.verts[face.v[1].index].co.z - msh.verts[face.v[3].index].co.z) ** 2
if (d1<d2):
flist += [Blender.NMesh.Face([face.v[0],face.v[1],face.v[2]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[1],face.uv[2]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[2]]
flist[len(flist)-1].smooth=face.smooth

flist += [Blender.NMesh.Face([face.v[0],face.v[2],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[2],face.uv[3]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[2]]
flist[len(flist)-1].smooth=face.smooth
else:
flist += [Blender.NMesh.Face([face.v[0],face.v[1],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[0],face.uv[1],face.uv[3]]
flist[len(flist)-1].col=[face.col[0],face.col[1],face.col[3]]
flist[len(flist)-1].smooth=face.smooth

flist += [Blender.NMesh.Face([face.v[1],face.v[2],face.v[3]])]
flist[len(flist)-1].uv=[face.uv[1],face.uv[2],face.uv[3]]
flist[len(flist)-1].col=[face.col[1],face.col[2],face.col[3]]
flist[len(flist)-1].smooth=face.smooth
msh.faces=flist
return msh

</python>
Das Prinzip ist Relativ leicht zu verstehen. "flist" ist eine Liste in der die neuen Dreiecke zwischengespeichert werden. Dreiecke werden einfach kopiert. Bei Quads wird die kürzere Diagonale zum Teilen gesucht und aus den Daten des Quads zwei neue Triangles erzeugt. Zum Schluss wird noch die temporäre Liste im Mesh gespeichert und as ganze zurückgegeben.

==Exportieren der Daten==

hier beschreiben ich wie man die wichtigsten Daten exportieren kann. Um ein anderes Format zu erhalten, müssen die Stings entsprechend angepasst werden. Eine neue Zeile erhält man durch "\n" In den Beispielen werde ich mich weitgehend an Werten gekapselt in einem XMLformat halten. Durch simple Modifikationen sind auch andere Formate kein problem.

Es gibt zwei Möglichkeiten die Vertexdaten zu speichern: Interleaved oder getrennte Blöcke. Beim interleaved Format verliert man die Flexibilität und die Daten werden noch unübersichtlicher. Ein Geschwindigkeitsgewinn ist auch nicht zu erwarten.

In einigen Codestücken wird auffallen, das die Convertierung von Quads nach Triangles immer wieder vorgenommen wird. In einem komplettem Exporten macht es durchaus Sinn, alle Daten erst zu sammel, dann zu sortieren, umwandeln und erst zum Schluss zu schreiben. Dabei wäre es allerdings nicht mehr möglich einzelne Beispiele zu liefern.

Eine besonder Problematik ist, dass Blender Quads beforzugt, jedoch Quads und Triangles gemischt vorliegen können. Um diese Mischung zu vermeiden sollte man entweder den Exporter so schreiben, dass er die Quads in 3 Triangles zerlegt oder vor dem Exportieren alle Quads in Triangles umwandelt und Speichert (Intern bleiben die Daten sonst anscheined immer noch Quads)

Einfachen Text, der keine zu exportierenden Daten enhält lässt sich so in die Datei schreiben. Hier ein möglicher begin der XML Datei:

<python>
out.write('<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n')
</python>

Wichtig ist hier wieder die Einrückung. Sie muss genauso weit eingerück sein wie die vorige Zeile, oder weiter eingerück werden wenn es sich um eine Schleife handelt.

Eine kleines Problem kann entstehen, wenn die letzte Zeile eines Datensatzes kein Komma enthalten darf. Der einfachste Weg ist eine Dummyzeile mit Nullwerten anzuhängen.

===Name des Objektes und Anzahl der Vertices===

In einem XML format ist es nicht alzuwichtig den Objektnamen aus Blender zu behalten. Jedoch kann es sehr nützlich sein wenn man andere Formate schreibt oder mehrere Objekte in einer Datei speichert. Wir bringen diese Daten einfach im VBO Tag unter, welches alle unsere Vertexdaten kapseln wird:

<python>
out.write('<vbo name="%s" verts="%i" type="GL_TRIANGLE">\n' % (msh.name, len(msh.faces)*3))
</python>

Zum Schluss sollte noch folgende Zeile angehängt werden um den VBO tag wieder zu schließen:
<python>
out.write('</vbo>')
</python>

===Vertices===
Da man den Index eines Vertexarray nicht in einem VBO verpacken kann. Ist es besser die Triangles nicht indiziert in einem VBO zu speichern. Der Speicherbedarf ist hier allerdings höher. Trotz der erhöten Datenmenge scheint diese Variante schneller zu sein, da hier keine Arrays vom Prozessor abgearbeitet werden müssen.
Unter der Annahme, das nur Triangles vorhanden sind, reicht dieser Code:

<python>
out.write('<vertices comp="3">\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f %f %f' % (msh.verts[vert.index].co.x, msh.verts[vert.index].co.y, msh.verts[vert.index].co.z))
out.write('\n')
out.write('</vertices>\n')
</python>

===Textur-Koordinaten===

Kaum schwerer als die Vertexdaten sind die Texturkoordinaten zu exportieren. Da die Texturkoordinaten innerhalb der Faces gespeichert werden. Sinvollerweise überprüfen wir voher noch ob überhaupt Texturdaten vorhanden sind:

<python>
if (msh.hasFaceUV()==1):
out.write('<texturecoords comp="2">\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f %f %f %f %f %f\n' % (face.uv[0][0],face.uv[0][1],face.uv[1][0],face.uv[1][1],face.uv[2][0],face.uv[2][1]) )
out.write('</texturecoords>\n')
</python>

===Normals===

Normalvektoren sind in Blender sowohl per Vertex als auch per Face abgespeichert. Abhängig, davon ob eine Fläche als Smooth (per Vertex) oder Solid (per Face) dargestellt wird, werden die die entsprechenden Normalvektoren ausgewählt. Damit auch Klötze mit Kanten dargestellt werden können müssen beide Fälle berücksichtigt werden. Im Fall Solid müssen für alle Vertices der Fläche der Normalvektor der Fläche verwendet werden. Im Fall Smooth muss hier der Normalvektor der Vertices benutz werden.
Auf keinen Fall sollte man nun die Vervielfachung der Vertices als Problem ansehen, da die verschiedenen Normalvektoren, diesen Nachteil wieder volkommen ausgleichen.

Tip: Da ganze Flächen als Solid keinerlei Optische Rundungen zulassen, ist der einzige Weg, echte Kanten an runden Objekten zu erzeugen in dem man das Mesch an der Stelle splittet. Leider muss man zum Splitten einen vollständigen Edgeloop auswählen. An Stellen die nicht kantig sein sollen muss man dann beide Vertices Makieren und mit "remove doubles" vereinen.

Auch hier ersst einmal ein einfaches Beispiel was haufig schon genügen sollte:

<python>
out.write('<normals>\n')
for face in msh.faces:
for vert in face.v:
out.write( ' %f, %f, %f,' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z) )
out.write('\n')
out.write('</normals>\n')
</python>

Besser wird es, wenn Smooth/Solid berücksichtigt wird.
<python>
out.write('<normals>\n')
for face in msh.faces:
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f, %f, %f,' % (face.no.x, face.no.y, face.no.z))
out.write('\n')
out.write('</normals>\n')
</python>

===Tangenvektor / TBN Matrix ===

Ohne die TBN Matrix lässt sich in den shadern kein sinvolles Bumpmapping durchführen. Weder Dot3, Offset, Parallax noch
Reliefmapping sind ohne TBN Matrix möglich.
Eine TBN Matrix besteht aus drei Vektoren, die den Texturespace aufspannen:

Normal

Er steht immer Senkrecht zur Oberfläche. Er entspricht genau dem Normalvektor wie wir ihn kennen.
Beim Paralax und Reliefmapping repräsentiert seine Länge den Masstab für die dritte Texturkoordinate (Im Editor wäre sie W, auch wenn die Texturkoordinaten in OpenGL s, t, p und q sind).

Tangent

Er liegt tangential auf der Textur und ist dort zur U Achse ausgerichtet. Wieder einmal kann man überlegen ob es nun beteutet Senktrecht zum Normal oder Parallel zu Fläche des Dreieckes. Wer keine Kopfschmerzen hat macht sich welche.

Bitangent

Häufig wird er auch Binormal genannt, jedoch beschreibt Bitangent die Funktion besser. Er ist wie der Tangent tangential zur V Achse der Textur ausgerichtet.
Wer meint Bitangent lässt sich durch das Kreutzprodukt von Normal und Tangend berechnen, hat nur recht wenn die Textur keine Scherung enthällt.

So lange die Textur nicht verzert wird, ist eine normalisierte TBN Matrix problemlos verwendbar, wenn jedoch die Tiefenkomponente der Textur nicht auf kubischen Texeln basiert, ist es sinvoller die Korrektur im Shader vorzunehmen, als die Komonenten dern TBN Matrix zu verzerren.

Da ich es jetzt anscheinend verstanden habe wie ich die zusätzlichen komponenten der TBN Matrix berechnen kann. Kommt hier der Code zum erzeugen der Tangent und Bitangentvektoren pro Face und Vertex:
<python>
def createFaceTan(msh):
ftan = []
for face in msh.faces:
tan = msh.verts[face.v[2].index].co - msh.verts[face.v[0].index].co
if (face.uv[2][1] != face.uv[1][1]):
m = (face.uv[2][1]-face.uv[0][1])/(face.uv[2][1]-face.uv[1][1])
tan += (msh.verts[face.v[1].index].co - msh.verts[face.v[2].index].co) * m
tan.normalize()
ftan += [tan]
return ftan

def createFaceBit(msh):
fbit = []
for face in msh.faces:
bit = msh.verts[face.v[1].index].co - msh.verts[face.v[0].index].co
if (face.uv[1][0] != face.uv[2][0]):
m = (face.uv[1][0]-face.uv[0][0])/(face.uv[1][0]-face.uv[2][0])
bit += (msh.verts[face.v[2].index].co - msh.verts[face.v[1].index].co) * m
bit.normalize()
fbit += [bit]
return fbit

def interpolate(msh,ftan):
vtan = []
for vert in msh.verts:
vtan += [Blender.NMesh.Vert().co]
for face in msh.faces:
if (face.smooth == 1):
for vert in face.v:
vtan[vert.index] += ftan[vert.index]
for i in range(0,len(msh.verts)):
vtan[i].normalize()
return vtan

ftan = createFaceTan(msh)
vtan = interpolate(msh,ftan)
fbit = createFaceBit(msh)
vbit = interpolate(msh,fbit)
</python>
Hier noch der Link zum Artikel wo ich die Berechnung erkläre:
http://wiki.delphigl.com/index.php/TBN_Matrix

Mit folgenden Codeschnipseln, lassen sich Tangent, Bitanget und die TBN Matrix ausgeben. Sinvoll ist es natürlich nur die Einzelkomponenten zusätzlich zum Normalvektor zu schreiben oder die TBN Matrix ohne Normalen zu verwenden.

<python>
out.write('<tan>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vtan[vert.index].x, vtan[vert.index].y, vtan[vert.index].z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (ftan[i].x, ftan[i].y, ftan[i].z))
out.write('\n')
out.write('</tan>\n')

out.write('<bit>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vbit[vert.index].x, vbit[vert.index].y, vbit[vert.index].z))
out.write('\n')
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (fbit[i].x, fbit[i].y, fbit[i].z))
out.write('\n')
out.write('</bit>\n')

out.write('<tbn>\n')
for i in range(0,len(msh.faces)):
face = msh.faces[i]
if (face.smooth==1):
for vert in face.v:
out.write( ' %f %f %f' % (vtan[vert.index].x, vtan[vert.index].y, vtan[vert.index].z))
out.write( ' %f %f %f' % (vbit[vert.index].x, vbit[vert.index].y, vbit[vert.index].z))
out.write( ' %f %f %f\n' % (msh.verts[vert.index].no.x, msh.verts[vert.index].no.y, msh.verts[vert.index].no.z))
else:
for vert in range(0,3):
out.write( ' %f %f %f' % (ftan[i].x, ftan[i].y, ftan[i].z))
out.write( ' %f %f %f' % (fbit[i].x, fbit[i].y, fbit[i].z))
out.write( ' %f %f %f\n' % (face.no[0], face.no[1], face.no[2]))
out.write('</tbn>\n')
</python>
Warnung: Die Vektoren scheinen alle Senkrecht zu einander zu stehen, jedoch ist noch nicht überprüft ob die Matrizen wirklich brauchbar sind. Es wäre durchaus möglich, dass noch komponenten verdreht oder gespiegelt sind.

Aufgrund des Mangels an Atributevariablen, ist es nicht sehr Sinvoll die volle TBN Matrix zu übergeben. Sinvoller ist es nur den Tangendvektor (Bitangent kann durch ein Kreutzprodukt neu berechnet werden) oder den Tangentvektor zumammen mit dem Bitangentvektor als Atribute zu übergeben.

===Vertuxgruppen / Bones ===

Ohne Vertexgruppen und Bones lassen sich keine Animationen mit Hilfe des Vertexshaders realisieren. Diesen Teil können alle überspringen, die keine Vertexshader zum Animieren benutzen wollen.
Die Daten liegen in Blender in einer für Vertexshader leicht unbrauchbaren Form vor und müssen etwas aufbereitet werden. In jeder Vertexgruppe, auf die man auch noch über Ihren Namen zugreifen muss, liegt eine Liste mit der Vertexnummer und der Gewichtung.
Für einen Vertexshader benötigen wir pro Vertex einen Index, der die Vertexgruppe/Bone beschreibt und die Gewichtung. Außerdem müssen wir uns voher entscheiden, wie viele Bones wir maximal pro Vertex berücksichtigen.

Bei Mangel an "attribute" Variablen macht es Sinn, die Gewichtung (muss kleiner als 1 sein) mit den Indizies zu addieren. Im Shader könnte man die dann wieder herausrechnen. Auf heutiger Hardware sind 16 Atribute Variablen möglich.

Als erstes den Codeblock zum aufbereiten der Daten. Es ist wichtig, dass die Variable num_of_vertexgroups.val die erwünschte Anzahl von Vertexgruppen enthällt:
<python>
vertGroupData = []
groups = msh.getVertGroupNames()
for vert in msh.verts:
list = []
count = 1
for group in groups:
if (len(msh.getVertsFromGroup(group,0,[vert.index]))==1):
list += [(msh.getVertsFromGroup(group,1,[vert.index])[0][1],count)]
count += 1
list.sort()
list.reverse()
for i in range(0,num_of_vertexgroups.val):
list += [(0.0, 0)]
vertGroupData += [(list[0:num_of_vertexgroups.val])]
</python>
Hinweis: Es gibt noch mit getVertexInfluences() eine bessere Methode zum ermitteln welche Vertexgruppe zu einem Vertex gehöhrt. Dann wäre jedoch der einsatz eines Dictonarys nötig.

Nun noch der Code zum schreiben:
<python>
out.write('<vertexgroups comp="%i">\n<weight>\n' % num_of_vertexgroups.val)
for face in msh.faces:
for vert in face.v:
for group in vertGroupData[vert.index]:
out.write( ' %f' % (group[0]))
out.write('\n')
out.write('</weight>\n<index>\n')
for face in msh.faces:
for vert in face.v:
for group in vertGroupData[vert.index]:
out.write( ' %i' % (group[1]))
out.write('\n')
out.write('</index>\n</vertexgroups>\n')
</python>

==Optimierung der Daten==

Bisher haben wir uns Hauptsachlich damit beschäftig wie wir die Daten aus der Blenderstruktur auszulesen und in ein Vertexbufferobjekt kompatible daten unzuformen. Wen die Modelle größer werden oder komplette Level in Blender realisiert werden sollen macht es Sinn die Daten so umzusortieren, das Triangles mit ähnlichen Eigenschaften wie Ort oder Ausrichtung nah im Vertexbufferobjekt beieinander liegen.

===Octree===

Beim Octree werden nur die Teile gerender, bei denen voher bekannt ist, dass sie sichtbar sind, leider ist die Baumstruktur eines Octtrees auf dem erstem Blick völlig inkompatibel zu dem linearem Verlauf des Vertexbuffersobjektes.

Um die Faces in den Octree einzusortieren muss von jedem der Schwerpunkt berechnet werden. Die Position im Octree wird mit einer art Hashfunktion berechnet, die erst aus den X Y und Z Koordinaten Integerwerte von 0 bis 1023 bildet und deren Bits so zusammensortiert, dass ein einziger Wert von 0 bis 2^30-1 ensteht. Nach dem die Faces sortiert werden:

<python>
def octree(msh):
# Boundingbox for Octree.
# Warnung: bei mehreren VBOs sollte die gleiche Boundingbox verwendet werden,
# damit nur einmal auf sichbarkeit überprüft werden muss
mini = msh.verts[0].co * 1.0
maxi = msh.verts[0].co * 1.0
for vert in msh.verts:
mini.x = minimum (mini.x,vert.co.x)
mini.y = minimum (mini.y,vert.co.y)
mini.z = minimum (mini.z,vert.co.z)
maxi.x = maximum (maxi.x,vert.co.x)
maxi.y = maximum (maxi.y,vert.co.y)
maxi.z = maximum (maxi.z,vert.co.z)
size = max (maxi.x-mini.x,maxi.y-mini.y,maxi.z-mini.z)
#Hashberechnung
optindex = []
count = 0
for face in msh.faces:
center = msh.verts[0].co * 0.0
for vert in face.v:
center += msh.verts[vert.index].co
#range 0.0 ... 1.0
center *= 1.0 /( len(face.v) * size * 2.0)
center.x += 0.5
center.y += 0.5
center.z += 0.5
ix = int (center.x * 1023)
iy = int (center.y * 1023)
iz = int (center.z * 1023)
sortby = (ix&512)<<18 | (ix&256)<<16 |(ix&128)<<14 | (ix&64)<<12 |(ix&32)<<10 | (ix&16)<<8 |(ix&8)<<6 | (ix&4)<<4 |(ix&2)<<2 | (ix&1)<<0
sortby |= (iy&512)<<19 | (iy&256)<<17 |(iy&128)<<15 | (iy&64)<<13 |(iy&32)<<11 | (iy&16)<<9 |(iy&8)<<7 | (iy&4)<<5 |(iy&2)<<3 | (iy&1)<<1
sortby |= (iz&512)<<20 | (iz&256)<<18 |(iz&128)<<16 | (iz&64)<<14 |(iz&32)<<12 | (iz&16)<<10|(iz&8)<<8 | (iz&4)<<6 |(iz&2)<<4 | (iz&1)<<2
optindex += [(sortby,count)]
count += 1
#Umsortierung der Daten
optindex.sort()
flist=[]
for i in optindex:
flist += [msh.faces[i[1]]]
msh.faces=flist
#Hier sollten noch die Verwaltungsdaten für den Octree geschrieben werden
#Diese Code fehl allderings noch

return msh
</python>
Diese Funktion sollte dierekt nach dem umwandeln der Quads in Triangles aufgerufen werden, da die Reihfolge der Triangles geändert wird.

Prinzipiell gibt es für jedes würfelförmige Volumen nur eine Start und Stopindexnummer die beim Rendern übergeben werden muss:
<cpp>
glDrawArrays( GL_TRIANGLES, start, stop - start);
</cpp>
Grundsätz sollte beachtet werden, dass es bei der Verwendung von VBOs möglichst viele Triangles auf einmal gerendert werden sollen. Wo die untergrenze Pro volumen liegt lässt sich schwer sagen, es mach aber Sinn, diese jenseits der 1000-10000 anzusetzten.

===Vorsortierung nach Vertexgruppen/Bones===

Es ist zwar noch kein Algoritmus zum sortieren vorhanden, jedoch ist es bei animierten Modellen sinnvoll möglichst ganze Bones auf einmal abzuarbeiten, da ein Bone ganze 12 Uniform Floats im Vertexshader verbraucht (9 für eine Rotationsmatrix und 3 für das Gelenk). Laut GLSL Spezifikation soll man minimal 512 davon haben, was maximal 40 Bones entspricht. Dummerweise scheint es so als wenn einige Grafikkarten nur 256 Uniform Floats zur Verfügung stellen, was zur Folge hat, das nur noch 20 Bones möglich wären.
Eine primitive Optimierung wäre nur einen halbes Model zu speichen. und für die zweite hälfte das gleiche Mesh gespiegelt mit neuen Bones zu verwenden.

Die Sinvollste Variante ist die schon erzeugten Vertexgruppendaten zum Sortieren zu benutzen: Die Gruppe mit der höchsten Gewichtung wird zum einsortieren benutzt. Alle Vertices die nicht in einer Gruppe sind, landen in einer extra gruppe. Diese Gruppen werde nun so umsortiert, dass Gruppen mit gegenseitigem Einfluss na beieinander landen. und Vertexgruppen die sih nicht beeinflussen weit von einander im VBO entfernt liegen.

==Daten für Indizierte VBOs exportieren==

Lange Zeit hab ich dieses Thema umgangen da der export relativ komplex ist. Alle Daten aus Blender müssen komplett neu umgeornet und neu indiziert werden, da Blender die Texturkoordinaten nicht per Vertex, sondern per Face abspeichert. Als Beispiel wird diesmal ein vereinfachter OBJ exporter dienen, der allerdings um tangentvektoren ergänst wird.

<python>
#!BPY
"""
Name: 'VBO Wiki'
Blender: 241
Group: 'Export'
Tooltip: 'VBO Wiki Exporter 3 C version'
"""
import Blender
from Blender import NMesh
from Blender.BGL import *
from Blender.Draw import *
import math
from math import *

def lfind(liste,key):
for i in range(0, len(liste)):
if liste[i]==key: return i

def write(filename):
global num_of_vertexgroups,TBNMenu,Optimise
# filename=replace(filename,".blend",".obj")
out = file(filename, 'w')

objs = Blender.Object.GetSelected()
if (len(objs)==0):
objs = Blender.Object.Get()
for obj in objs:
if (obj.getType()=='Mesh'):

msh = obj.getData()

# msh = quad2tri(msh)
raw_index = []

for face in msh.faces:
for i in range (0,len (face.v)):
vert = []
vert += [face.v[i].index]
vert += [face.uv[i][0]]
vert += [face.uv[i][1]]
raw_index += [vert]

print len(raw_index)
#print raw_index
raw_index.sort()
last =raw_index[-1]
for i in range(len(raw_index)-2, -1, -1):
if last==raw_index[i]:
del raw_index[i]
else: last=raw_index[i]

print len(raw_index)

out.write('g Index\n')

for i in raw_index:
v = msh.verts[i[0]].co
out.write('v %f %f %f\n' % (v.x,v.y,v.z))

for i in raw_index:
v = msh.verts[i[0]].no
out.write('vn %f %f %f\n' % (v.x,v.y,v.z))

for i in raw_index:
out.write('vt %f %f\n' % (i[1],i[2]))

tan = [Blender.Mathutils.Vector(0,0,0) for i in range(0,len(raw_index))]
for face in msh.faces:
v1 = face.v[1].co - face.v[0].co
v2 = face.v[2].co - face.v[0].co
s1 = face.uv[1][0] - face.uv[0][0]
t1 = face.uv[1][1] - face.uv[0][1]
s2 = face.uv[2][0] - face.uv[0][0]
t2 = face.uv[2][1] - face.uv[0][1]

sdir = v1 * t2 - v2 * t1
#sdir = Blender.Mathutils.Vector(0,0,1)
sdir.normalize()
for i in range (0,len (face.v)):
vert = [face.v[i].index,face.uv[i][0],face.uv[i][1]]
tan[lfind(raw_index, vert)] += sdir

for i in range (0,len(raw_index)):
#tan[i].normalize
normal = msh.verts[raw_index[i][0]].no
otan = tan[i] - normal * Blender.Mathutils.DotVecs( tan[i], normal )
#otan = tan[i]
otan.normalize()
out.write('tan %f %f %f\n' % (otan.x,otan.y,otan.z))

for face in msh.faces:
out.write('f')
for i in range (0,len (face.v)):
vert = [face.v[i].index,face.uv[i][0],face.uv[i][1]]
out.write(' %i' % (lfind(raw_index, vert)))
out.write('\n')

out.close()
Exit()

#Blender.Window.FileSelector(write, "Export")
write ("dummy.obj")
</python>

==Zusätzliche Optionen Abfragen==

Ein Exporter ist schön, etwas unschön ist es bis jetzt, das die Ausgabe immer statisch nach dem gleichem Schema erfolgt. Um bestimmte Optionen aktivirbar und deaktivirbar zu machen, ist es nötig einen Dialog zu öffene, dessen eingaben in globalen Variablen abgelegt werden. Aus codetechnischer sicht ist es einfacher die Optionen vor dem Filedialog abzufragen.
Damit ein Dialog verwendet werden kann sind ein paar Änderungen am Code nötig.

Folgende Funktionen und globale Variablen müssen eingefügt werden:

<python>
num_of_vertexgroups = Create(4)
TMenu = Create(1)
EVENT_NOEVENT = 1
EVENT_EXPORT = 2
EVENT_CANCEL = 3

def draw():
global num_of_vertexgroups,TMenu
global EVENT_NOEVENT,EVENT_EXPORT
glClear(GL_COLOR_BUFFER_BIT)
glRasterPos2d(10, 125)
Text("DGL Exporter Options")

TMemu = Menu("Normal|Normal+Tangent|TBN-Matrix",EVENT_NOEVENT,10,75,210,18, 1)
num_of_vertexgroups= Number("No of Vertgroups: ", EVENT_NOEVENT, 10, 55, 210, 18,num_of_vertexgroups.val, 0, 10, "Number of Vertgroups per Vertex");
Button("Export",EVENT_EXPORT, 140, 10, 80, 18)
Button("Cancel",EVENT_CANCEL, 10, 10, 80, 18)

def event(evt, val):
if (evt == QKEY and not val):
Exit()

def bevent(evt):
global EVENT_NOEVENT,EVENT_EXPORT
if (evt== EVENT_EXPORT):
Blender.Window.FileSelector(write, "Export")
elif (evt == EVENT_CANCEL):
Exit()
</python>
Code noch nicht fertig

Die letzte Zeile, welche den Filedialog geöffnet hat, wird durch folgende ersetzt:
<python>
Register(draw, event, bevent)
</python>

Damit die write funktion keine Endloschleife verursacht, sollte sie noch um Exit() ergänst werden.

==Externe Links==

http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro/Advanced_Tutorials/Python_Scripting/Export_scripts
[[Kategorie:Anleitung]]

Boneanimation per Vertexshader

2006-10-09T15:30:58Z

Oc2k1: /* Kompression der Matrizen */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei oder drei Float4 benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern.
Eine gepackte Matrix kommt mit 8 Floats aus. Für Quarternionen wäre mit zusätzlichem Translationsteil 7 Floats nötig. Einen wirklichenSinn machen Quarternionen im Vertexshader also definitiv nicht

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

===Überlagerung meherer Animationen===

Sicher werden am Anfang statische Posen ausreichen. Jedoch ist es mit einer Matrixmultiplikation pro Bone möglich zwei Posen zu überlagern. z.B. kann man so verschiedene Posen einer Hand an einen Arm binden. In diesem Fall müssen die Matrizen der Handanimation mit den Matrizen der Körperanimation Multipliziert werden.
Alle von der Teilanimation nicht betroffenen Matrizen müssen dabei einheitsmatrizen entsprechen, damit die Multiplikation keine Auswirkung hat.

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-10-09T15:24:08Z

Oc2k1: /* Quaternionen im Vertexshader */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei oder drei Float4 benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern.
Eine gepackte Matrix kommt mit 8 Floats aus. Für Quarternionen wäre mit zusätzlichem Translationsteil 7 Floats nötig. Einen wirklichenSinn machen Quarternionen im Vertexshader also definitiv nicht

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-10-09T15:22:18Z

Oc2k1: /* Limits */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 bis 1024 Uniformvariablend des Typs Float4. Für einen Bone werden zwei oder drei Float4 benötigt. Damit lassen sich etwa 80 bis 500 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellen diese Werte kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert durch Spiegelung fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-10-09T15:16:56Z

Oc2k1: /* Grundlagen */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes unbewegliches Gelenk verbunden sind sollten umbedingt vermieden werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-10-09T15:14:00Z

Oc2k1: /* Vorwort */

{{Offline}}
==Vorwort==

Dieser Artikel richtet sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Tutorial glsl2

2006-10-08T23:09:37Z

Oc2k1: /* GLSL Ergänzungen und Beispiele */

= GLSL Ergänzungen und Beispiele =

== Vorwort ==
Willkommen zu meinem zweiten Tutorial für die DelphiGL-Community. Da ich kein Freund großer Worte bin (was auch mein Deutsch-Kursleiter immer bemängelt ;) ) werde ich so schnell wie möglich mit dem Wichtigen beginnen. Ich werde nur schnell einiges anmerken:
Dieses Tutorial sollte nicht als zweiter Teil zu Sascha Willems hervorragendem ersten GLSL-Tutorial angesehen werden, sondern eher als Anhang verstanden werden. Auf keinen Fall empfiehlt es sich, sofort mit diesem Tutorial in die Materie einzusteigen. Arbeitet es einfach direkt nach dem ersten durch als ob dieses gar nicht aufgehört hat. Zweitens soll in diesem Tutorial im Gegensatz mehr der praktische Part überwiegen. Nach der doch etwas trockenen Materie, die Sascha meiner Meinung nach exzellent aufgearbeitet hat ist etwas Praxis und Anwendung gefragt. Drittens wollte ich noch anmerken, dass ich dieses Tutorial eher als Sammlung mehrerer kleiner Tutorials als ein Großes ansehe. Die einzelnen Teile werden nur bedingt aufeinander aufbauen.

== Ergänzungen ==
Im Laufe meiner eigenen, ersten Schritte im Bereich der [[Shader]]entwicklung sind mir selbst einige Dinge aufgefallen, die nicht ganz unerwähnt bleiben sollten, da sie schnell für Frust sorgen können:

Die NVidia-Treiber und ihre Pendants von ATI sind unterschiedlich tolerant was die Compilierung der Shader-Quellcodes angeht. Aus Kompatibilitätsgründen empfehle ich durchgehend für Zahlen, die in eine Float-Variable hineingerechnet werden, keine Integerwerte zu verwenden. Ganz konkret:
<glsl>
float TestVariable = 1.0 / 2
</glsl>
ist den offiziellen Spezifikationen nach nicht zulässig. Die zwei muss wenn dann als Float (2.0) geschrieben werden. NVidia-Karten werden zwar beim Starten weder eine Warnung noch einen Fehler anzeigen, ATI-Karten weisen den Shader dagegen jedoch strikt zurück. Gewöhnt es euch deswegen an, einfach so gut wie immer
<glsl>
float TestVariable = 1.0 / 2.0
</glsl>
zu schreiben.

Da OpenGL eine Statemachine ist bleiben die Shader, wenn sie einmal per [[glUseProgramObjectARB]](LichtShader) aktiviert wurden, solange aktiv bis sie wieder per glUseProgramObjectARB(0) deaktiviert werden. Ihr könnt wirklich verdammt viel Rechenzeit sparen, wenn Ihr die Shader-Programme nur auf gewollte Objekte anwendet.

Bei Shadern ist eine Struktur extrem wichtig, um das Ganze übersichtlich zu halten. Glaubt es mir! Vor allem am Anfang werdet ihr bei etwas komplexeren Shadern nur schwer den Überblick behalten können. Überlegt euch vielleicht ein System, wann ihr Variablen deklariert, wie ihr kommentiert usw. Shader sind hochmathematisch und oft hat man bald vergessen was eine Zeile bewirken soll, weil ihr so taktisch gerechnet habt. Dann könnte ein Hinweis nicht schaden.

In Shadern gibt es sowas Schönes, dass schimpft sich Interpolation von varying Variablen. Durch Interpolation werden Berechungen, die im Vertexshader auf einzelne Vertices angewendet werden, automatisch im Fragmentshader für jedes Fragment angewendet.

Ein Beispiel:

Wenn ihr im Vertexshader die Variable ''pos'' mit der Vertexposition belegt, dann hat sie beim Auslesen im Fragmentshader die genaue Position des Fragments. Genauso verhält es sich beispielsweise mit Texturkoordinaten. Es hat mir ganz schön Kopfzerbrechen bereitet bis ich das verstanden hatte. Eventuell ist meine Erklärung lückenhaft oder schlicht falsch. Bis jetzt hat es mir aber noch keine Probleme bereitet.

Wer C++ kennt, der wird natürlich wissen, dass man andere Source-Files per ''#include'' einbinden kann. Damit kann man seine Shader sehr schön strukturieren.

Noch ein paar Informationen zu [[glUniform]] bzw. [[glVertexAttrib]] die einem sehr viel Kopfzerbrechen sparen können. Bildlich gesprochen bezieht sich glUniform nämlich auf ganze Polygone, hat seinen Platz also vor [[glBegin]]. Wird es in einem glBegin/glEnd-Block eingesetzt wird zwar kein Fehler angezeigt aber die Werte werden einfach nicht übergeben. Natürlich braucht man auch eine Funktion wie glVertexAttrib, die Werte für einen Vertex setzt. Diese Funktion kann dann ruhig auf jeden Vertex mit anderen Werten angewendet werden. Einen kleinen Nachteil gibt es aber trotzdem. Sobald ihr glVertexAttrib verwendet, werden [[glVertex]], [[glNormal]] und [[glTexCoord]] nutzlos. Diese Funktionen machen eigentlich auch nichts anderes als Vertexattribute zu setzen. Nun hat man die Wahl. Entweder man übergibt auch Position, Normalen und Texturkoordinaten über glVertexAttrib oder man wendet Trick 17 an und übergibt Vertexattribute mit Multitexturkoordinaten. Die kann man dann im Shader ganz bequem auslesen. Vielen Dank an Lars Middendorf für diesen Tipp!

== Beispiele ==
=== Ein Shader, der die Hardware T&L- Einheit simuliert ===
Fangen wir mit einer einfachen Aufgabe an. Dem schrittweisen Aufbau eines Shaders, der eigentlich nichts anderes macht als das, was OpenGL ohne Shader auch machen würde. Ziemlich sinnlos ;). Aber ich glaube als Übung bietet sich das recht schön an. Beginnen wir mit dem leeren Shader, der nur das Nötigste enthält:

Vertexshader:
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
</glsl>
Fragmentshader:
<glsl>
void main(void)
{
gl_FragColor = 1.0;
}
</glsl>
Wer in Saschas Tutorial aufgepasst hat, dem dürfte klar sein, dass dieser Vertexshader jeden Vertex an seine Position setzt und der Fragmentshader jedes zu einem Polygon gehörende [[Pixel]] weiss einfärbt. Nun kommt schon der nächste Schritt: Wir färben das Polygon nicht mehr weiss sondern mit der Farbe, die wir in OpenGL immer per [[glColor]] angeben. Ein kurzer Blick in die Referenz offenbart uns die vordeklarierte Variable ''gl_FrontColor''. Dieser übergeben wir jetzt im Vertexshader den Wert ''gl_Color''. Das ist die Farbe, die wir im Programmcode per glColor angegeben haben:

Vertexshader:
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_FrontColor = gl_Color;
}
</glsl>
Im [[Fragment]]shader lesen wir den Wert, den wir im Vertexshader an ''gl_FrontColor'' gegeben haben, wieder mit ''gl_Color'' aus.

Fragmentshader:
<glsl>
void main(void)
{
gl_FragColor = gl_Color;
}
</glsl>
[[bild:Tutimg_glsl_ext_schritt1.jpg|256px]]

Voilà! Das ist ja schon einmal ein schöner Anfang. Aber in welchem 3D-Programm gibt es bloß einfarbige Polygone? Also müssen wir jetzt noch Texturen hinzufügen. Erst einmal arbeiten wir nur mit einer Textureinheit. Wie gewohnt ladet ihr eine Textur, bindet diese per [[glBindTexture]] und weist ihr Koordinaten zu. Den Vertexshader lassen wir jetzt erst einmal die Texturkoordinaten auslesen:

Vertexshader:
<glsl>
void main(void)
{
gl_Position= gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0]= gl_MultiTexCoord0;
}
</glsl>
Diese Koordinate wird dann interpoliert und der Fragmentshader liest dann für jedes Fragment mit diesen Koordinaten die Textur aus und gibt ''gl_FragColor'' die Farbe. Dazu deklarieren wir am Anfang eine uniform-Variable für die Textur. Vorerst übergeben wir aus dem Programmcode dieser Variable keinen Wert. Ich werde später darauf zurückkommen. Sie teilt dem Fragmentshader nur mit in welcher Textureinheit er nach der Textur suchen soll. In diesem Fall ist der Wert also 0, bzw. ein Pointer auf die Textur in der Einheit 0. Fragt mich aber nicht, warum man diesen Wert nicht direkt eingeben kann O_o!

Fragmentshader:
<glsl>
uniform sampler2D Texture0;

void main(void)
{
gl_FragColor = texture2D(Texture0, vec2(gl_TexCoord[0]));
}
</glsl>
[[bild:Tutimg_glsl_ext_schritt2.jpg|256px]]

Sieht ja schon einmal recht ansehnlich aus. Ohne viele Umschweife komme ich gleich zum [[Multitexturing]]. Dazu müssen wir zuerst in unseren Programmcode gehen. Hier belegen wir zwei Textureinheiten mit....ja...mit Texturen (immer diese verdammten Wiederholungen, mein Deutschkursleiter würde mich hauen). Danach kommt wieder etwas Spezifisches zu Shadern:
Wir weisen den uniform-Variablen (''uniform sampler2D Texture0'') im Shader ihre Textureinheit zu.

Programmcode:
<pascal>glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, Textur);
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, Textur2);

glUniform1iARB(glGetUniformLocationARB(shader, 'Texture0'), 0);
glUniform1iARB(glGetUniformLocationARB(shader, 'Texture1'), 1);</pascal>

Nun geht es wieder ab in den Shadercode. Wieder übergeben wir hier nur die Texturkoordinaten. Wenn für die unterschiedlichen Textureinheiten dieselben Texturkoordinaten gesetzt wurden würde der Shader von vorhin ausreichen. So spart man sich eine Zeile. Soviel zur Optimierung ;).

Vertexshader:
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>
Im Fragmentshader auch nichts wirklich Neues. Wir binden die zweite Textur ein und bringen sie mit ''gl_FragColor'' ins Spiel. Ich hab im Beispielcode einfach mal beide Texturen multipliziert aber ihr könnt damit eigentlich anstellen was ihr wollt. Probiert einfach mal ein paar Sachen aus!

Fragmentshader:
<glsl>
uniform sampler2D Texture0;
uniform sampler2D Texture1;
void main(void)
{
gl_FragColor = texture2D(Texture0, vec2(gl_TexCoord[0]))
* texture2D(Texture1, vec2(gl_TexCoord[1]));
}
</glsl>
[[bild:Tutimg_glsl_ext_schritt3.jpg|256px]]

Sodala, is ja schon was. *überleg* was gehört denn noch zur Standard-OGL-Ausrüstung? Hmm, achja, Licht! OpenGL arbeitet ja normalerweise nur mit Per-Vertex-Berechnungen. Das wird schon ein bisschen anspruchsvoller. Wir werden ein wenig Mathematik betreiben müssen. Aber das werden wir schon wuppen! Außerdem ist mir aufgefallen, dass wenn man das ganze selber gemacht hat man das OpenGL-Licht auch gleich viel besser versteht. Als erstes empfehle ich euch einen Blick in folgendes Dokument von Tom Nuydens:
[http://www.delphi3d.net/articles/viewarticle.php?article=phong.htm Phong For Dummies]

In diesem Dokument erhaltet ihr einen Einblick in das derzeit meist verwendete Beleuchtungsmodell. Es ist nicht perfekt realistisch, kommt dem aber recht nahe und ist sehr ressourcensparend. Wichtig ist für uns hier nur der Diffuse-Term. Diese Gleichung sagt uns im Prinzip nur, ob ein Vertex beleuchtet wird oder nicht. Außerdem werden die Ränder schön gefadet. Mit Per-Pixel-Lighting kommt dann später noch der Specular-Term dazu, der die Oberfläche glänzen lässt. Weil die Glanzfläche so klein ist macht das hier aber noch keinen Sinn, denn die Wahrscheinlichkeit, dass sie auf ein Vertex fällt ist ziemlich gering.

Nun aber ran an die Arbeit. Als erstes baut ihr in eurem Programmcode die Standard-OpenGL-Beleuchtung ganz ohne Shader ein und schaut, ob es funktioniert. Damit können mögliche Fehler nur noch am Shadercode liegen. Dann bindet ihr den Shader ein. Für die Berechnung brauchen wir zwei Vektoren: Den Vektor von unserem Vertex zur Lichtquelle und die Flächennormale. Um Ersteren zu berechnen, multiplizieren wir die Position unseres Vertex mit der Modelviewmatrix und subtrahieren das Ergebnis von der Position der Lichtquelle (''gl_LightSource[0].position''):

Vertexshader:
<glsl>
void main(void)
{
...
vec3 Position = vec3(gl_ModelViewMatrix * gl_Vertex);
vec3 Light = vec3(normalize(vec3(gl_LightSource[0].position) - Position));
...
}
</glsl>
Die Flächennormale können wir im Vertexshader jedoch nicht berechnen, da dieser nur mit einzelnen Vertices arbeiten kann, für die Berechnung aber mindestens drei notwendig sind. Also berechnen wir sie im Programmcode. Wie das geht, steht in folgendem DGL-Tutorial: [[Tutorial_Lineare_Algebra|Lineare Algebra]].
Im Programmcode übergebt ihr die Normale wie gewohnt per glNormal und im Shader lesen wir sie dann ganz einfach mit ''gl_Normal'' aus. Die Normale multiplizieren wir noch schnell mit der Normalmatrix:

Vertexshader:
<glsl>
...
vec3 Normal = normalize(gl_NormalMatrix * gl_Normal);
...
</glsl>
Nun können wir endlich die Beleuchtung berechnen. Wie der ein oder andere bereits wissen dürfte, setzt sich die Beleuchtung in dem von unserem verwendeten Modell aus dem Ambient- und dem Diffuse-Term zusammen. Der Ambient-Term bestimmt eigentlich nur was für eine Farbe ein Pixel haben soll, der überhaupt nicht beleuchtet wird. Den berechnen wir einfach indem wir den Ambient-Wert der Lichtquelle mit dem des Materials multiplizieren:

Vertexshader:
<glsl>
...
vec3 Ambient = vec3(gl_FrontMaterial.ambient) * vec3(gl_LightSource[0].ambient);
...
</glsl>
So. Nun kommt der Clou des Ganzen: Wir berechnen den Diffuse-Term! Aus dem oben verlinkten Dokument von Delphi3D.net holen wir uns folgende Formel:

Vertexshader:
<glsl>
...
Diffuse = max(dot(Normal, Light), 0.0);
...
</glsl>
Die Funktion ''dot'' berechnet eigentlich nur den Kosinus des Winkels zwischen den beiden Vektoren Normal und Light (mehr dazu in o.g. Tutorial von DGL). Dadurch bekommen wir automatisch einen nichtlinearen Verlauf der Beleuchtung. ''max'' vergleicht die Werte x und y und liefert automatisch den höheren der beiden zurück. So erreichen wir, dass wir keinen Wert kleiner 0 bekommen. Damit auch das diffuse Licht eine Farbe bekommt multiplizieren wir noch schnell mit den jeweiligen Farben der Lichtquelle und des Materials:

Vertexshader:
<glsl>
...
Diffuse *= gl_LightSource[0].diffuse * gl_FrontMaterial.diffuse;
...
</glsl>
Dann weisen wir gl_FrontColor nur noch die Werte zu, die wir berechnet haben und geben dem Ganzen noch eine vierte Dimension:

Vertexshader:
<glsl>
...
gl_FrontColor = vec4(Diffuse + Ambient, 1.0);
...
</glsl>
Nun noch schnell im Fragmenthader gl_FragColor einen Wert zuweisen:

Fragmentshader:
<glsl>
void main(void)
{
gl_FragColor = gl_Color;
}
</glsl>
Die Anfangs erwähnte Interpolation sorgt automatisch dafür, dass die Farbe von Vertex zu Vertex schön weich verläuft.

[[bild:Tutimg_glsl_ext_schritt4.jpg|256px]]

Warum die Farben nicht ganz mit der OpenGL-hauseigenen Beleuchtung zusammenpassen, kann ich leider nicht sagen. Zum Abschluss möchte ich euch gerne noch zeigen, wie ihr per Shader Cubemaps einbaut, vor allem für so schöne Effekte, wie spiegelndes Wasser solltet ihr diese Technik schon beherrschen. Da ich euch nicht mit dem Laden der Cubemap langweiligen will, fangen wir in der Renderprozedur an. Ein geeigneter Loader für die Texturen wäre beispielsweise eine modifizierte Version von Lossy eX' [[glbitmap_loader|glBitmap]].
Im Quelltext binden wir einfach die Cubemap für die [[glbitmap_loader|glBitmap]] üblich mit FCubeMap.Bind;
Das Objekt, auf welches draufprojeziert werden soll muss Texturkoordinaten und eine Normale haben. Das sollte eigentlich kein Problem sein. Nun kommt der Shader dran. Wir deklarieren wieder eine uniform-Textur, diesmal aber nicht ''sampler2D'' sondern ''samplerCube''. Eigentlich logisch. Um jetzt für jedes Pixel unseres Polygons den geeigneten Wert aus der Cubemap auszulesen nehmen wir die normale Texturkoordinate und addieren die Flächennormale dazu. Dass ergibt wiederum eine dreidimensionale Texturkoordinate, die wir in die Shaderfunktion ''textureCube'' einlesen, die sich fast genauso wie ''texture2D'' benutzen lässt:

Fragmentshader:
<glsl>
uniform samplerCube Texture0;

varying vec3 normal;
void main(void)
{
vec3 TexCoord = vec3(gl_TexCoord[0]);
gl_FragColor= textureCube(Texture0, normal + TexCoord);
}
</glsl>
[[bild:Tutimg_glsl_ext_schritt5.jpg|256px]]

Damit haben wir unsere selbstprogrammierte Hardware T&L-Einheit schon fertig! War doch gar nicht so schlimm. Im Folgenden entfernen wir uns dann ein bisschen von der herkömmlichen Programmiererei und machen mal ein paar schöne Effekte.

=== Per-Pixel-Lighting ===
Ein wirklich schöner Effekt, den man auch in Spielen bisher recht selten sieht.
Eigentlich haben wir im Per-Vertex-Lighting schon alles gemacht. Wir müssen nun nur unsere Berechnungen, die wir Per-Vertex durchgeführt haben, in den Fragmentshader verlegen. Und dann berechnen wir noch den Specularwert, der angibt wie sich das Licht spiegelt und zurückgeworfen bzw. dem Betrachter zugeworfen wird. Um diesen Wert zu berechnen gibt es zwei Lösungsmöglichkeiten, die sich aber nicht sehr unterscheiden. Es handelt sich um sogenanntes Phong bzw Blinn-Phong Lighting. Wir werden Phong-Lighting einbauen, das Blinn-Phong könnt ihr ja als Übungsaufgabe machen ;). Die geometrischen Grundlagen findet ihr wieder in oben genanntem Artikel von Delphi3D.
Für uns wichtig sind folgende Formeln:
<glsl>
Reflected = 2 * (Normal Light) * Normal - Light //wird unten mittels der
</glsl>
glSlang eigenen Funktion reflect berechnet

und
<glsl>
Specular = SpecularLight * SpecularMaterial * pow(max(dot(Reflected, Eye), 0), Shininess)
</glsl>
Wie der Name vermuten lässt berechnen wir mit der ersten Formel den an der Oberfläche reflektierten Lichtvektor. Mit der zweiten vergleichen wir dann diesen Vektor mit dem des Beobachters.
Im Vertexshader berechnen wir die einzelnen Vektoren, die dann wie üblich interpoliert werden:

Vertexshader:
<glsl>
varying vec3 normal;
varying vec3 v;
varying vec3 lightvec;
void main(void)
{
normal = normalize(gl_NormalMatrix * gl_Normal);
v = vec3(gl_ModelViewMatrix * gl_Vertex);
lightvec = normalize(gl_LightSource[0].position.xyz - v);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
</glsl>
Im Fragmentshader bringen wir jetzt die Berechnungen aus dem Per-Vertex-Lighting und die des Specular zusammen:

Fragmentshader:
<glsl>
varying vec3 normal;
varying vec3 v;
varying vec3 lightvec;

void main(void)
{
vec3 Eye = normalize(-v);

vec3 Reflected = normalize( reflect( -lightvec, normal ));
//hat den selben effekt wie
//vec3 Reflected = normalize( 2.0 * dot(normal, lightvec) * normal - lightvec);

vec4 IAmbient = gl_LightSource[0].ambient;
vec4 IDiffuse = gl_LightSource[0].diffuse * max(dot(normal, lightvec), 0.0);
vec4 ISpecular = gl_LightSource[0].specular * pow(max(dot(Reflected, Eye), 0.0), gl_FrontMaterial.shininess);
gl_FragColor = gl_FrontLightModelProduct.sceneColor + IAmbient + IDiffuse + ISpecular;
}
</glsl>
Erklärung zu reflect:
Man sollte nach Möglichkeit immer glSlang eigene Funktionen nutzen, da diese ggf. vom Hersteller der Grafikkarte direkt in Hardware implementiert wird und somit zu einem Performenz zuwachs führen kann. Der Compiler kann jedoch die von Hand geschriebenen Funktionen kaum auf die Hardware mappen, was diesen Performenz zuwachs natürlich wieder aufheben würde.

[[bild:Tutimg_glsl_ext_perpixellicht.jpg|256px]]

== Nachwort ==
Sodala. Fertig! Ich hoffe, ihr habt etwas gelernt und ich all' eure Fragen beantworten konnte. Wenn nicht, dann werden wir euch im DGL-Forum Rede und Antwort stehen. Auch Kritik ist dort gern gesehen, denn nur so können zukünftige Tutorials weiter an Qualität gewinnen. Ich würde mich auch sehr freuen, wenn ihr im Shaderforum eure Ergebnisse postet, egal wie langweilig sie auch seien mögen ihr beherrscht jetzt immerhin Shader :-).
Also, ich packs jetzt, sonst packts mich.

'''Euer''' <br>
'''La_Boda''' (-pdl-_at_web.de)

== Anhang ==
[http://www.delphigl.com/do_download.php?f=3250 Source Code (VCL)]<br>

{{TUTORIAL_NAVIGATION|[[Tutorial_glsl]]|-}}

[[Kategorie:Tutorial|GLSL2]]

Tutorial glsl

2006-10-08T15:38:21Z

Oc2k1: /* Beispiel B */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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'' :
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
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'' :
<glsl>
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</glsl>
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 :
<glsl>
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
<glsl>
uniform vec4 GlobalColor;

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

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==
<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;
}
</glsl>

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:37:32Z

Oc2k1: /* Beispielshader */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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'' :
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
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'' :
<glsl>
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</glsl>
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 :
<glsl>
glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);
</glsl>
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 :
<glsl>
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
<glsl>
uniform vec4 GlobalColor;

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

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==
<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;
}
</glsl>

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:36:16Z

Oc2k1: /* Beispiel B */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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'' :
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
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'' :
<glsl>
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</glsl>
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 :
<glsl>
glUniform1iARB(glSlang_GetUniLoc(ProgramObject, 'texSamplerTMU1'), 1);
</glsl>
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 :
<glsl>
uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
uniform vec4 GlobalColor;

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

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==
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;
}

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:34:57Z

Oc2k1: /* Beispiel A */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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'' :
<glsl>
void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>
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'' :
<glsl>
uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}
</glsl>
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 :

uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
uniform vec4 GlobalColor;

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

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==
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;
}

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:33:38Z

Oc2k1: /* Eingebaute Uniformvariablen */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

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

*struct gl_PointParameters
<glsl>
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;
</glsl>
*struct gl_MaterialParameters
<glsl>
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;
</glsl>
*struct gl_LightSourceParameters
<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];
</glsl>
*struct gl_LightModelParameters
<glsl>
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;
</glsl>
*struct gl_LightModelProducts
<glsl>
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;
</glsl>
*struct gl_LightProducts
<glsl>
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];
</glsl>
* 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
<glsl>
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;
</glsl>
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.}}

==Trigonometire 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'' :

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}

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'' :

uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}

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 :

uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
uniform vec4 GlobalColor;

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

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==
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;
}

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:28:24Z

Oc2k1: /* Schleifen */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl>

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

* struct gl_DepthRangeParameters

struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;

: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;

*struct gl_MaterialParameters
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;

*struct gl_LightSourceParameters
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];

*struct gl_LightModelParameters
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;

*struct gl_LightModelProducts
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;

*struct gl_LightProducts
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];

* 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
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;

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.}}

==Trigonometire 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'' :

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}

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'' :

uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}

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 :

uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
uniform vec4 GlobalColor;

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

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==
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;
}

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

Tutorial glsl

2006-10-08T15:24:55Z

Oc2k1: /* Die Shadersprache */

=Präambel=
Ave und willkommen bei meiner "Einführung" in die recht frische und mit OpenGL1.5 eingeführte Shadersprache "glSlang". 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 glSlang 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 3DLabs 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 glSlang?=
Wie Eingangs kurz angesprochen handelt es sich bei glSlang 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 glSlang 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 Vertexe (VertexShader) oder Fragmente (FragmentShader) angewendet, andere noch nicht programmierbare Teile der GL-Pipeline wie z.B. die Rasterisierung können momentan noch nicht über Shader beeinflusst werden.

==Voraussetzungen==

glSlang ist ein recht neues Feature, dass mit OpenGL1.5 eingeführt wurde, weshalb eine entsprechend moderne Grafikkarte (DX9-Generation) inklusive aktuellster Treiber von Nöten ist.
''Aktueller Stand (November 2005) ist wie folgt :''

[http://www.ati.com ATI] haben bereits seit fast 2 Jahren (Catalyst 3.10) glSlang-fähige Treiber, allerdings kommt es besonders mit neueren Treibern hier und da immernoch zu Fehlern (oder es werden gar neue Fehler eingführt) und ATI zeigt momentan kein sehr starkes Interesse am fixen dieser Fehler.

[http://www.nvidia.com NVidia] haben sich etwas mehr Zeit gelassen, allerdings ist deren glSlang-Implementation inzwischen recht ausgereift. Bugs gibts allerdings trotzdem hier und da, aber NVidias Entwicklersupport ist da recht offen für Fehlerberichte. Die aktuellen Treiber der 80er Reihe sind daher für glSlang-Nutzer bestens geeignet.

[http://www.3dlabs.com 3DLabs], die glSlang quasi erfunden haben, haben natürlich hervorragenden glSlang Support in ihren Treiber, allerdings sind deren Wildcat-Karten kaum verbreitet.

Natürlich benötigt ihr auch einen passenden OpenGL-Header der die für glSlang nötigen Extensions und Funktionen exportiert. Ich verweise dazu auf unseren internen OpenGL-Header [[DGLOpenGL.pas]] der da einwandfrei seine Dienste verrichtet und auch in der Beispielanwendung Verwendung findet.

==Neue 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.

==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_ARB''' oder '''GL_FRAGMENT_SHADER_ARB'''.

==Resourcen==
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 natürlich die [http://www.3dlabs.com/support/developer/ogl2/index.htm GL2-Seite von 3D-Labs], wo u.a. auch ein OGL2-SDK und diverse Whitepapers als PDFs angeboten werden, in denen auch stattgefundene Änderungen an glSlang dokumentiert sind.

=glSlang 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|glHandleARB}} eingeführt, der ein Objekthandle repräsentiert. Wir deklarieren also wie folgt :

ProgramObject : GLhandleARB;
VertexShaderObject : GLhandleARB;
FragmentShaderObject : GLhandleARB;

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

ProgramObject := glCreateProgramObjectARB;

Die Funktion [[glCreateProgramObjectARB]] 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 := glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
FragmentShaderObject := glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);

[[glCreateShaderObjectARB]] 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 :

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

Via [[glShaderSourceARB]] 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 :

glCompileShaderARB(VertexShaderObject);
glCompileShaderARB(FragmentShaderObject);

Der glSlang-Compiler des Treibers wird bei einem Aufruf von [[glCompileShaderARB]] versuchen, unsere Shader zu kompilieren. Sofern diese keine Fehler aufweisen, sollte dies auch erfolgreich sein. Wenn nicht, dann spuckt uns der ShaderKompiler 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 :

glAttachObjectARB(ProgramObject, VertexShaderObject);
glAttachObjectARB(ProgramObject, FragmentShaderObject);

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

glDeleteObjectARB(VertexShaderObject);
glDeleteObjectARB(FragmentShaderObject);

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

glLinkProgramARB(ProgramObject);

Während [[glCompileShaderARB]] unsere Shader auf syntaktische Fehler innerhalb ihres lokalen Raums geprüft hat, werden beim Linken durch [[glLinkProgramARB]] 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.

==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 [[glGetInfoLogARB]] und [[glGetObjectParameterivARB]] mit dem Argument {{INLINE_CODE|GL_OBJECT_INFO_LOG_LENGTH_ARB}}. 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 :

<pascal>function glSlang_GetInfoLog(glObject : GLHandleARB) : String;
var
blen,slen : GLInt;
InfoLog : PGLCharARB;
begin
glGetObjectParameterivARB(glObject, GL_OBJECT_INFO_LOG_LENGTH_ARB , @blen);
if blen > 1 then
begin
GetMem(InfoLog, blen*SizeOf(GLCharARB));
glGetInfoLogARB(glObject, blen, slen, InfoLog);
Result := PChar(InfoLog);
Dispose(InfoLog);
end;
end;</pascal>

Die Funktion ist recht leicht erklärt : Zuerst lassen wir uns über {{INLINE_CODE|glGetObjectParameterivARB}} mitteilen wie lang der aktuelle Infolog ist. Sollte dort tatsächlich etwas drinstehen (blen > 1), dann lassen wir uns dessen Inhalt via {{INLINE_CODE|glGetInfoLogARB}} 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 :

glCompileShaderARB(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|center]]

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|center]]

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.

==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 [[glUniformARB]] sind. Während mit {{INLINE_CODE|glUniform4fARB}} z.B. ein Vier-Komponentenvektor an das Programmobjekt übergeben wird, kann man mittels {{INLINE_CODE|glUniformMatrix4fvARB}} 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 :

glUniform3fARB(glGetUniformLocationARB(ProgramObject, PGLCharARB('LightPosition')), LPos[0], LPos[1], LPos[2]);
glUniform1iARB(glGetUniformLocationARB(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 :
<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;
}
</glsl>

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 :

<div align="center">
{|{{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
|-
|sampler1D
|Zugriff auf 1D-Textur
|-
|sampler2D
|Zugriff auf 2D-Textur
|-
|sampler3D
|Zugriff auf 3D-Textur
|-
|samplerCube
|Zugriff auf Cubemap
|-
|sampler1DShadow
|Zugriff auf 1D-Tiefentextur mit Vergleichsoperation
|-
|sampler2DShadow
|Zugriff auf 2D-Tiefentextur mit Vergleichsoperation
|-
|}
</div>
Die sampler-Typen stellen eine besondere Klasse dar und werden im Kapitel 6.7 genauer erklärt, inklusive einiger Anwendungsbeispiele.

===Arrays===

Natürlich unterstützt glSlang auch Arrays, die wie in C deklariert werden und deren Index bei 0 beginnt. Folgendes Array im Shader :
<glsl>
float temp[3];
</glsl>
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 :
<glsl>
struct light
{
bool active;
float intensity;
vec3 position;
vec3 color;
};
</glsl>
Im Shader können dann neue Variablen von diesem Typ ganz einfach deklariert werden :
<glsl>
light LightSource[3];
</glsl>
Der Zugriff auf die Elemente der Struktur erfolgt dann wie gewohnt über den Punkt :
<glsl>
LightSource[3].position = vec3(1.0, 1.0, 5.0);
</glsl>

==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 :
<glsl>
varying vec3 VertexNormal;
...
VertexNormal = normalize(MV_IT * gl_Normal);
</glsl>
:Im FragmentShader :
<glsl>
varying vec3 VertexNormal;
...
TempVector = VertexNormal*...
</glsl>

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

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

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

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

:Im VertexShader :
<glsl>
const vec4 ColorBias = vec4(0.2, 0.3, 0.0, 0.0);
...
gl_FrontColor = ColorBias * gl_Color;
</glsl>
==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 :
<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);
</glsl>

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
<glsl>
vec4 Color = vec4(MyVec3)
</glsl>
funktioniert allerdings nicht, da hier die Zahl der benötigten Argumente nicht erreicht wird. In diesem Falle müsste es dann
<glsl>
vec4 Color = vec4(MyVec3, 0.0)
</glsl>
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'' :
<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);
</glsl>

==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 :
<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
</glsl>

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 :
<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
</glsl>

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 :
<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;
</glsl>

Matrix * Vektor ist auch ohne manuelle Konvertierung möglich :
<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]);
</glsl>

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 :
<glsl>
RückgabeTyp FunktionsName(Typ0 Argument0, Typ1, Argument1, ... , TypN, ArgumentN)
{
return RückgabeWert;
}
</glsl>

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 :
<glsl>
void MeineFunktion(float EingabeWert; out float AusgabeWert)
{
AusgabeWert = EingabeWert*MyConstValue;
}
</glsl>

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

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

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
<glsl>
for (Startausdruck; Durchlaufbedingung; Wiederholungsausdruck;)
{
statement
}
</glsl>

* '''while'''-Schleife
<glsl>
while (Durchlaufbedingung)
{
statement
}
</glsl

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

'''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
* mat4 gl_TextureMatrix[gl_MaxTextureCoordsARB]
:{{INLINE_CODE|gl_NormalMatrix}} repräsentiert die inversen oberen 3x3 Werte der Modelansichtsmatrix. {{INLINE_CODE|gl_TextureMatrix[x]}} adressiert maximal Anzahl Textureinheiten-1-Texturmatrizen.

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

* struct gl_DepthRangeParameters

struct gl_DepthRangeParameters
{
float near;
float far;
float diff;
};
gl_DepthRangeParameters gl_DepthRange;

: Clippingplanes :
* vec4 gl_ClipPlane[gl_MaxClipPlanes]

*struct gl_PointParameters
struct gl_PointParameters
{
float size;
float sizeMin;
float sizeMax;
float fadeThresholdSize;
float distanceConstantAttenuation;
float distanceLinearAttenuation;
float distanceQuadraticAttenuation;
};
gl_PointParameters gl_Point;

*struct gl_MaterialParameters
struct gl_MaterialParameters
{
vec4 emission;
vec4 ambient;
vec4 diffuse;
vec4 specular;
float shininess;
};
gl_MaterialParameters gl_FrontMaterial;
gl_MaterialParameters gl_BackMaterial;

*struct gl_LightSourceParameters
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];

*struct gl_LightModelParameters
struct gl_LightModelParameters
{
vec4 ambient;
};
gl_LightModelParameters gl_LightModel;

*struct gl_LightModelProducts
struct gl_LightModelProducts
{
vec4 sceneColor;
};
gl_LightModelProducts gl_FrontLightModelProduct;
gl_LightModelProducts gl_BackLightModelProduct;

*struct gl_LightProducts
struct gl_LightProducts
{
vec4 ambient;
vec4 diffuse;
vec4 specular;
};
gl_LightProducts gl_FrontLightProduct[gl_MaxLights];
gl_LightProducts gl_BackLightProduct[gl_MaxLights];

* 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
struct gl_FogParameters
{
vec4 color;
float density;
float start;
float end;
float scale;
};
gl_FogParameters gl_Fog;

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.}}

==Trigonometire 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'' :

void main(void)
{
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}

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'' :

uniform sampler2D texSampler;

void main(void)
{
gl_FragColor = texture2D(texSampler, vec2(gl_TexCoord[0]));
}

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 :

uniform sampler2D texSamplerTMU0;
uniform sampler2D texSamplerTMU1;

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

==Noisefunktionen==
Sowohl im Vertex als auch im Fragment Shader lassen sich Noisefunktionen nutzen, mit deren Hilfe sich einge 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.

* 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==
uniform vec4 GlobalColor;

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

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==
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;
}

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.

=Screenshots=

Um eure Augen ein wenig zu verwöhnen und zu zeigen was man mit glSlang alles machen, v.a. da man jetzt Shader schön lesbar in einer Hochsprache verfassen kann, mal ein paar Screens. Besonders der zweite Shot sieht animiert noch besser aus :

<center>[[BILD:GLSL_sample_Kugel.jpg]] [[BILD:GLSL_sample_Alien.jpg]] </center>

Die Zahl möglicher Effekte ist bei einer so flexiblen Shadersprache natürlich nahezu unbegrenzt, und besonders auf kommender Hardware werden bisher ungesehen Effekte den Einzu in die Echtzeitgrafik finden. Man darf also mehr als gespannt sein.

=Die Zukunft=
Viele werden sich sicherlich fragen, warum sie z.B. statt ARB_VP/FP oder Nvidias cG denn überhaupt auf glSlang setzen sollen. Doch solche Zweifel dürften bei einem genauen Blick auf die neue Shadersprache schnell verworfen sein. Zum einen steckt hinter glSlang dank des ARBs fast die komplette 3D-Industrie und zum anderen hat man beim Entwurf der Shadersprache, wie z.B. an vielen reservierten Wörtern/Funktionen erkennbar versucht so weit wie möglich in die Zukunft zu planen. So sollen auch Karten der nächsten und übernächsten Generation mit glSlang ausnutzbar sein, und was danach kommt wird durch Spracherweiterungen erreicht. Sich also jetzt (besonders da es krachneu ist) mit glSlang zu befassen, um nicht ganz den Anschluss an kommende Entwicklungen im 3D-Bereich zu verlieren, ist der beste Weg.

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

Euer
:Sascha Willems ([mailto:webmaster@delphigl.de webmaster@delphigl.de])

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

GLSL Licht und Schatten

2006-10-08T15:12:42Z

Oc2k1: /* Oversampling der Schattenmap */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<glsl> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</glsl>

parabol.frag
<glsl>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</glsl>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</glsl>

final.frag
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Möglicher weise für ATI taugliche Variante:
<glsl>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<glsl>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</glsl>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<glsl>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</glsl>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<glsl>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</glsl>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

GLSL Licht und Schatten

2006-10-08T15:11:43Z

Oc2k1: /* Texturelookups vermeiden */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<glsl> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</glsl>

parabol.frag
<glsl>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</glsl>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</glsl>

final.frag
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Möglicher weise für ATI taugliche Variante:
<glsl>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<glsl>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</glsl>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<glsl>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</glsl>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<cpp>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</cpp>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

GLSL Licht und Schatten

2006-10-08T15:11:24Z

Oc2k1: /* Schatten durch Alphatest */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<glsl> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</glsl>

parabol.frag
<glsl>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</glsl>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</glsl>

final.frag
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Möglicher weise für ATI taugliche Variante:
<glsl>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<glsl>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</glsl>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<cpp>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</cpp>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<cpp>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</cpp>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

GLSL Licht und Schatten

2006-10-08T15:10:28Z

Oc2k1: /* Shader für den finalen Renderdurchgang */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<glsl> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</glsl>

parabol.frag
<glsl>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</glsl>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</glsl>

final.frag
<glsl>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Möglicher weise für ATI taugliche Variante:
<glsl>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</glsl>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<cpp>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</cpp>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<cpp>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</cpp>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<cpp>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</cpp>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

GLSL Licht und Schatten

2006-10-08T15:09:35Z

Oc2k1: /* Shader zum Rendern der Schattenmaps */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<glsl> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</glsl>

parabol.frag
<glsl>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</glsl>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<cpp>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</cpp>

final.frag
<cpp>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</cpp>

Möglicher weise für ATI taugliche Variante:
<cpp>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</cpp>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<cpp>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</cpp>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<cpp>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</cpp>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<cpp>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</cpp>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

GLSL Licht und Schatten

2006-10-08T15:08:39Z

Oc2k1: /* Shader */

{{Offline}}

==Vorwort==

Willkommen zu meinem erstem Tutorial. Schatten können sowohl Traum als auch Albtraum eines jeden OpenGL-Progrmamieres werden. Im Gegensatz zur einfachen Beleuchtung mit Lichtquellen, steigt der Rechenaufwand hier extrem an und ohne Optimierung zwingen die Schatten selbst die modernste Hardware in die Knie.
Für Schatten gibt es zwei praktikable Algoritmen: Den Stencilschatten und den projezierten Schatten. Hier möchte ich mich auf den projezierten Schatten beschränken, er bietet gegenüber dem Stencilschatten einige Vorteile:

*Die komplette Berechnung kann von der Grakfikkarte übernommen werden
*Es ist möglich Softshadows zu realisieren
*Die Shadowmaps können unter Umständen für mehr als ein Frame verwendet werden

Um den Rechenaufwand zu veringern werde ich hier zusätzliche Projektionstechniken zeigen, die über den Vertexshader realisiert werden: Die perspektivische Map und das parabolide Mapping.

Für sehr weit entfernte Lichtquellen und offene Szenen ist der Einsatz von perspektisch angepassten Maps sinvoll. Da das Licht quasi parallel ausgestrahlt wird. Ist ein winkelabhängiger Cube oder dualparabolische Map kaum möglich. Auch eine einfache quadratische Shadowmap zeigt deutliche Schwächen bei der Auflösung im Nahbereich und dem zu hohem Oversampling in der Entfernung.

Das parabolide Mapping ermöglicht nicht nur die Simulation eine Fischaugenoptik, sondern kann auch die Cubemap vollständig ersetzen. Durch einen geringfügig höheren Rechen- und Programieraufwand genügen zwei Renderpasses um eine vollständige Tiefen- oder Reflektionsmap zu erstellen. Was gegenüber der klassischen Cubemap den Prozessor und GPU um den Faktor 3 entlastet.

==Vorkenntnisse==
Dieses Tutorial basiert auf den grundlegenden Techniken, die erst in den letzten Jahren entwickelt wurden. Jeder der hier mit anfängt, sollte die zwei anderenen GLSL Tutorials gelesen haben und einfache Fragmentshader schreiben können. Auch das Laden und Einbinden von Texturen in die Shader sollte kein Problem mehr darstellen.

===Framebufferobjekte===
Für das Erstellen von dual paraboliden Tiefentexturen ist noch das Rendern in Framebufferobjekten Vorraussetzung (zu denen es leider noch kein Tutorial gibt). Damit der Einstieg nicht zu schwer wird sollte dieser Code helfen das FBO zu initialsisieren:

Als Erstes müssen die nötigen Extensions initialisiert werden
Dann sollten die benötigten Modelle als VBO in die Grafikkarte hochgeladen werden.
Nun muss das Framebufferobjekt (FBO) für die Schattenmaps erzeugt werdern.
So könnte die Initialsierung des FBOs aussehen. C code:

<cpp>GLuint shadow_map = 0; //
GLuint shadow_fbo = 0; // the shadow texture
GLuint shadow_size = 4096; //muss kleiner sein als die maximale Texturgröße sein

glGenTextures (1, &shadow_map); //In Pascal das & durch ein @ ersetzten
glBindTexture (GL_TEXTURE_2D, shadow_map);
glTexImage2D (GL_TEXTURE_2D, 0,GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0,GL_DEPTH_COMPONENT , GL_UNSIGNED_BYTE, NULL);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT (1, &shadow_fbo); //In Pascal das & durch ein @ ersetzten
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,GL_DEPTH_ATTACHMENT_EXT,GL_TEXTURE_2D,shadow_map, 0);
glDrawBuffer (GL_FALSE);
glReadBuffer (GL_FALSE);
GLenum status = glCheckFramebufferStatusEXT (GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</cpp>
ungetesteter Pascalcode:
<pascal>var shadow_map,
shadow_fbo,
shadow_size : GLuint;
status : GLenum;
begin
shadow_map := 0;
shadow_fbo := 0; // the shadow texture
shadow_size := 4096; // muss kleiner sein als die maximale Texturgröße sein

glGenTextures(1, @shadow_map);
glBindTexture(GL_TEXTURE_2D, shadow_map);
glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, shadow_size, shadow_size, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

glGenFramebuffersEXT(1, @shadow_fbo);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fbo);
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_TEXTURE_2D, shadow_map, 0);
glDrawBuffe (GL_FALSE);
glReadBuffer(GL_FALSE);
status := glCheckFramebufferStatusEXT(GL_FRAMEBUFFER_EXT); //noch ein wenig Code anfügen um den Status zu überprüfen.</pascal>

Jetzt sollten die Shader und weiter Texturen geladen werden.

===Beschleunigtes Rendern===

Ich empfehle auch die zu rendernden Daten als Vertexbufferobjekte zu übergeben, da sonst die Mehrfachverwendung der Daten zu einer extremen Bremse wird. Da es hierzu bereits ein Tutorial gibt werde ich hier nichts mehr darüber schrieben.
Alternativ sollte alles was zwischen glBegin und glEnd in Displaylisten gespeichter werden. Das Speichern von Texturwechseln usw ist nicht sinvoll, da diese nicht zum Rendern der Shadowmaps benötig werden.

Bei mehrfachen Lichquellen kann es wiederum Sinn machen den ersten Rendervorgang inclusive Shaderwechsel in einer Displayliste zwischenzuspeichen und die zusätzlichen Schadowmaps mit dieser zu rendern.

===Algemeines zu GLSL===
Ich möchte nocheinmal darauf hinweisen, das sich uniformvariablen nur setzten Lassen, wenn der entsprechnde shader gebunden ist. (Es funktionier nicht wenn der shader nicht gebunden ist. Warum man den shader dabei allerdings angeben muss ist mir nicht so ganz klar)
In den Beispielen werden nur die Uniformvariablen wärend des Rendervorgangs neu gesetzt die sich ändern. Die zuweisung der TMU zu einem Sampler gehöhrt in der Regel nicht dazu.

===Grundlegendes zu den Koordinatensystemen in den Shadern===

Im Vertexshader müssen alle komponenten von gl_Position in einem Bereich von -1.0 bis 1.0 gebracht werden. Besonders beim Z-Wert könnte es verwirrend, dass der Bereich von gl_FragDepth im Fragmentshader von 0.0 bis 1.0 geht. Auch muss beachtet werden, dass Texturkordinaten den bereich von 0.0 bis 1.0 nutzen, wärend die Rendertargets im Bereich on -1.0 bis 1.0 arbeiten.
In den Shadern werden daher öfters Multimplikationen mit 0.5 und einer anschließenden Addition von 0.5 auftreten.

==Perspektivische Maps==

In dem erstem Teil dieses Artikels geht es um perspektivisch angepasste Schattenmaps. Normale projezierte Schatten haben das Problem, das sie im Nahenbereich besonders stark verpixeln und in der Entfernung durch ein viel zu hohes Oversampling Bandbreite verschwenden.

Für eine globale Lichquelle wird nur ein Vektor gegeben, der die Richtung des Lichtes beschreibt. Die gedachte Lichtquelle ist quasi unendlich weit weg. Da eine Entfernungsberechnung zur Lichquelle unmöglich ist, muss die Schattenberechnung relativ zu einer Referenzebene durchgeführt werden. Diese Ebene kann sowohl Senkrecht zum Lichvektor, als auch parallel zum gedachtem Boden ausgerichtet werden. Die Ausrichtung der Referenzebene beeinflusst die später sichtbare Auflösung der Schatten.

Nach dem ein Vertex auf die Ebene projeziert wurde und der Abstand ein einen berech von 0.0...1.0 gebracht wurde, muss diese unendlich große Ebene noch auf eine endliche Größe projeziert werden, die auf eine Textur passt und die entfernungsabhängige Detailierung beachtet.

Wenn wir unsere Referenzebene einfachhalber den Horizont schneidet (und auch den Bildschirm in obere und untere Hälfte teilt) Könnte ein Algorimus in etwa so aussehen (Dieser lässt sich später in ein Vertexshaderprogramm umsetzten):

Projeziere den Vertex in die Modelview (Diese Schritt wurde auch bei den dualparaboliden Maps durchgeführt)
Ermittel den Schnittpunt des vom Vertex ausgehendem gedachtem Lichtstrahl und der Referenzebene.
Benutze den Abstand zwischen Schnittpunkt und Vertex um den Z-Wert zu ermitteln. (Es sind zwei zusätzlich referenzwerte nötig die die funktion Farclip und Nearclip übernehmen)
Projeziere die Ebene auf eine Ebene die in eine Textur passt pos/=abs(pos)+1.0 passt recht gut.
Anschließend wird noch die Schadowmap noch gestreckt und der Bereich hinter der Kammera entfernt.

Das wichtigste ist, dass beim auswerten der shadowmaps der gleiche Projektionsalgoritmus verwendet wird wie beim generieren.

Prinzipell sollte sich der Algoritmus schon auf einer Geforce 3 oder Radeon 8500 implementieren lassen. Da da der Code hier in GLSL geschrieben ist, sollte in etwa Shadermodel 2.0 unterstützt werden.

Geschwindigkeitsmäßig ist dieser Algoritmus den Stencilshadows deutlich überlegen. Auch bei Stencilshadows sind mehrere Renderpasses nötig. Vorallem das extruieren der Siluetten kostet einiges an Bandbreite. Der geschätzte Aufwand ist etwa 20 (Aufwendige Shader im Finalem Renderdurchgang)bis 80% (CPU limitiert Geometrieübergabe) Mehraufwand gegenüber einer Schattenlos gerenderten Scene.
Auch die Qualität ist nicht schlechter. Bei der Verwendung von weichen Schatten wirken Shadowmaps natürlicher als die extrem scharfen Stencilshadows.

===Hauptprogramm===

In der Hauptschleife könnte folgender Code verwendet werden:
<cpp>
glBindTexture(GL_TEXTURE_2D, 0 ); //Entfernt alle Texturen aus der ersten TMU
glUseProgramObjectARB(shadow); //lädt den Schattenshader
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb); //Bindet das Framebufferobjekt

glViewport (0, 0,shadow_sz,shadow_sz); //Anpassen des Viewportes
glClear(GL_DEPTH_BUFFER_BIT); //Z-Buffer löschen

render(); //Erster Renderdurchgang

glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0); //Normalen Framebuffer binden
glBindTexture(GL_TEXTURE_2D, shadow_tx ); //Tiefenmap an die erste TMU binden
glUseProgramObjectARB(final); //finalen shader binden

glViewport(0, 0, screen_size_x, screen_size_y);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); //Color und Z-Buffer löschen
render(); //rendern
</cpp>

===Shader===

Als erstes der Vertexshader zum generieren der Schadowmap. shadow.vert:
<glsl>
void main(void){

vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0)); //Lichtvektor in den Modelsprace rotieren
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex); //Vertex in den Modelspace projezieren
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y; //Schnittpunkt mit der XZ Referenzebene
pos = pos / (abs(pos)+1.0); //Projektion der Ebene auf ein Quadrat
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
gl_Position.xy = pos;
gl_Position.z = -mvertex.y ; // Der Bereich von +-1 über der Referenzebene wird erfasst
gl_TexCoord[0] = gl_MultiTexCoord0;
}
</glsl>

Die Lichtrichtung wird vorläufig noch fest übergeben. Eine Auswertung einer Opengl Lichtquelle oder einer Uniformvariable wäre ebenfalls möglich. Anschließend wird der Vertex in die Modelview projeziert und der Schnittpunkt des vom Vertexausgehendem Lichstrahls mit der Referenszebene berechnet. Als letztes wird noch der Abstand zur Referenzebenein einem Bereich 0..1 umgerechnet und die Texturkoordinaten für eventuelles Alphamasking oder Heightmapping durchgeschleift. Soll Alphamasking verwendet werden, muss ein entsprechender Shader geschrieben werden der bei den freizulassenden pixeln discard(); aufruft. Dies sollte jedoch nur für die betroffenen Poligone stat finden, da die Grafikkarte dann keine Early-Z Optimierungen verwenden kann. Ansonsten ist der Fragmentshader ist sehr einfach: shadow.frag:
<glsl>
void main(void){}
</glsl>

Die für die Auswertung müssen wir im finalem Renderdurchgang exakt die gleichen Texturkoordinaten für die Shadowmap generieren. Allerdings gibt es eine Besonderheit: Die koordinaten einer Textur reichen von 0;0 bis 1;1, Die Koordinaten eines Rendertargets reichen jedoch von -1;-1 bis 1;1, so das eine zusätzliche korrektor nötig ist.
<glsl>
varying vec3 spos;

void main(void){
vec3 lightdir = gl_NormalMatrix * normalize(vec3(0.1,-1.0,0.0));
vec3 mvertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
vec2 pos = mvertex.xz + lightdir.xz * -mvertex.y/lightdir.y;
pos = pos / (abs(pos)+1.0);
pos = pos * vec2(1.0,1.8) + vec2(0.0,0.8); //Abschneiden des Bereiches hinter der Kammera
pos = pos * 0.5 + 0.5; //auf Texturkoordinaten umrechnen

spos.xy = pos; //Daten in einer Varying verpacken
spos.z = -mvertex.y * 0.5 + 0.5 - 0.005; // far and near clamping and Anti-Z-fighting-offset

gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex; //Die echte Transformation

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</glsl>

Die ersten 5 Zeilen der main() sollten exakt das gleiche tun wie der Vertexshader zum gnerieren dem Map.

Nun fehlt noch ein Fragmentshader für den letzten Durchgang:

Es muss noch der Noralvektor berücksichtigt werden!!!
<glsl>
uniform sampler2D Shadowmap;
varying vec3 spos;

void main(void){
if (texture2D(Shadowmap, spos.xy).r > spos.z ){
//Licht
gl_FragColor = vec4(1.0,1.0,1.0,1.0);
}
else{
//Schatten
gl_FragColor = vec4(0.5,0.5,0.5,1.0);
}
}
</glsl>

==Parabolide Maps==

Einfache parabolide Maps können für alle Punktlichquellen verwendet werden, deren Licht nicht in alle Richtungen abgestrahlt wird. Darunter fallen vorallem Spots und an Wänden oder Decken befestigte Lampen. Im gegensatz zur Paralelem Licht oder einer Punktlichquelle bringt eine solche Lichtquelle häufig eine Helligkeitsmap mit. Für die Helligkeitsmap und die Schattenmap können die gleichen Texturkoordinaten verwendet werden.

Bei kleinen Öffnungswinkeln hat die parabolide Map keinen Vorteil gegenüber einer normalen Projektion. Der Vortiel ist jedoch das der Code sich für Öffnungswinkel von bis zu ~240 Grad eignet.

Um eine solche Lichquelle zu beschreiben weden nicht weniger als drei Vektoren benötigt:

* Position
* Richtung
* Tangent

Wärend die Funktion der ersten beiden Vektoren klar ist, wird der Tangent wird dazu benötigt die Schattenmap und Helligkeitsmap auszurichten. Er ist Senkrecht zur Richtung tangential zur Textur ausgerichtet
Beschreiben lässt sich diese Funktion lässte sich am ehesten durch das Verdrehen einer Taschenlampe. Wenn die Schattenmap gegenüber den schattenwerfenden Objekten verdreht wird, sieht das Bild auf keinen Fall mehr natürlich aus.

Es ist sowohl möglich die Berechnungen im Vertexshader durchzuführen, als auch eine entsprechnede Matrix in den Uniformvariablen abzulegen. Wenn die Berechnungen per Matrix durchgefühert werden lässt sich das Prinzip der paraboliden Maps zuindest als Reflektionsmap nutzen. Ein weiterer Vorteil an einer vorberechneten Matrix ist, dass diese auch für shadowmap verwendet werdne kann die nicht jedes Frame neu berechnet werden.

==Dual Parabolide Maps==
Von OpenGL kennen wir zwei Projektionsmöglichkeiten: Orthografische und perspektivische Projektion. Beide Projektionen arbeiten ohne Verzerrung. Jede Gerade bleibt beim Transformieren eine Gerade. Wenn man dagegen das Bild eines Fischeyeobjektives betrachtet, allen einem sofort die zu Kurven verzerrten Geraden auf. Der entscheidene Vorteil an einer Fisheyeaufnahme ist, dass ein Öffnungswinkel von 180 Grad erfasst werden kann. Zwei entgegensetzte Aufnahmen können so problemlos den kompletten Raum um die Kamera erfassen.

Für das Erstellen der Tiefenmap ist es notwendig den Raum um das reflektierende Objekt in eine Textur zu rendern. Meistens wird hier eine Cubemap verwendet. Soll diese dynamisch generiert werden, ist es auffällig, dass die Scene ganze 6 mal gerendert werden muss. Mit der dual paraboliden Map sind nur noch zwei Rendervorgänge nötig, es wird zwar keine Füllrate eingespart, dafür müssen nun nur noch 1/3 der Daten transformiert werden, so das die Vertexshader und die CPU entlastet werden.

Eine weitere Optimierung ist unter Umständen möglich: Wenn bei einer Cubemap auf eine der Flächen verzichte werden kann. Z.B. wird die Reflektion im Lack eines Autos so gut wie nie verdeckte Straße zeigen. Auch ist für eine an einer Wand befestigten Lampe nur eine halbkugelförmige Shadowmap nötig. Wenn sie einen Abstand zur Wand hat, genügt es auch hier den Blickwinkel von 180 Grad etwas zu erweitern.

Die Projektion der dualparaboliden Map kann man sich am besten Bild eines Fisheyobjektives vorstellen. Mathematisch etwas genauer ist das Reflektionsbild der umgebenden Welt in einem Rotationsparaboliden.

Die Hardwareanforderungen an den Pixelshader sind nicht gerade gering. Der Pixelshader für die 8fachen Lichquellen kommt nach dem Compelieren auf über 170 Instruktions. Eine Shader 2.0 Karte wie z.B. die Radeon 9x00 sind hier hoffnungslos überfordert da sie nur an 3 Stellen im Programm auf die Textureinheiten zugreifen können und der Assembler nicht mehr in der Lage ist die Instruktions passend umzusortieren. Noch fataler wird es wenn die Texturelookups durch dynamisches Branching übersprungen weder sollen: Die Karte hat keine Chance mehr diese umzusortieren.

Wer dualparbolide Maps auf SM2.0 Karten einsetzten will sollte damit rechnen, dass das Limit bei 2 bis 4 Maps liegen sollte.

===Hauptprogramm===

So kann in der Hauptschleife das rendern der 16 paraboliden Maps und der anschließende Finale Renderdurchgang durchgeführt werden:
<cpp>//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for (int light;light<8;light++){
glViewport (shadow_size/2*(lights/4),shadow_size/4 *(light%4),shadow_size/4,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "light"),light);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),0);
render();
glViewport (shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light%4),shadow_size/4 ,shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, "renderpass"),1);
render();
}

// Framebufferobjekt deaktivieren
glBindFramebufferEXT (GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Vieport an Fenstergröße anpassen
glViewport(0, 0,Windowsize_X,Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
render();</cpp>

ungetesteter Pascalcode:
<pascal>
//Shader für Dualparabolische Mpas aktivieren
glUseProgramObjectARB(parabol);

//Framebufferobjekt aktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, shadow_fb);
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);

//Die 8 Lichtquellen Rendern
for light := 0 to 7 do
begin
glViewport(shadow_size/2*(lights/4), shadow_size/4 *(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'light'), light);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'), 0);
render();
glViewport(shadow_size/4+shadow_size/2*(lights/4), shadow_size/4*(light mod 4), shadow_size/4, shadow_size/4);
glUniform1iARB(glGetUniformLocationARB(parabol, 'renderpass'),1);
render();
end;

// Framebufferobjekt deaktivieren
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);

//Richtigen Shader aktivieren
glUseProgramObjectARB(final);
//Viewport an Fenstergröße anpassen
glViewport(0, 0, Windowsize_X, Windowsize_Y);

//Frame rendern
glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
render();</pascal>

===Die Shader===

====Shader zum Rendern der Schattenmaps====
parabol.vert
<cpp> uniform int renderpass;
uniform int light;
varying vec3 normal;
varying vec3 pos;

void main(void){

gl_Position = gl_ModelViewMatrix * gl_Vertex - gl_LightSource[light].position ;

float L= length (gl_Position.xyz);
gl_Position /= -L;
if (renderpass == 1) gl_Position.z *=-1.0;
gl_Position.z += 1.0;
gl_Position.xy /= gl_Position.z;
if (gl_Position.z >= 0.01){
gl_Position.z = L / 15.0;//Todo: optimieren
gl_Position.w = 1.0;
}
else{
gl_Position.z = -1.0;
gl_Position.w = -1.0;
}

gl_Position.z = 2.0 * gl_Position.z -1.0; //Todo: optimieren
pos=gl_Position.xyz;
}</cpp>

parabol.frag
<cpp>varying vec3 pos;
void main(void){
if (length(pos.xy)>1.005)discard; //Diese Zeile kann durchaus entfallen. Kosten/Nutzen unbekannt.
}</cpp>

Es gibt zwei Uniformaviablen, die gesetzt werden müssen: Eine ist die Nummer der aktuellen Lichtquelle und die zweite der Renderpass, der angibt ob die Vorder- oder Rückseite der parabolischen Map gerendert werden soll. Eine automatische Berechnung der Texturkoordinaten wäre zwar möglich, jedoch ist die Änderung des Viewports deutlich weniger Rechenaufwendig.

Statt einer Multiplikation des gl_Vertex mit der gl_ModelViewProjektionMatrix wird hier nur mit der gl_ModelViewMatrix multipliziert. Dadurch werden nur die Transformationen durchgeführt und die Projektion übersprungen.
Die Division durch -L entspricht weitgehend einer Normalsierung, spiegelt die Welt jedoch in die richtige Lage. L enthält jetzt die Tiefeninformation, gl_Position einen Vektor, der von der Kammera auf den Vertex zeigt. Mit den zwei folgenden Zeilen wird der Vektor parabolisch auf die Bildschirmkoordinaten projeziert (Intervall von -1.0 bis 1.0). Mit Hilfe der folgenden if-Abfrage werden alle Vertices hinter der Kammera geclipt. Nur sichtbare Vertices bekommen gültige z Werte für den Zbuffer im Intervall von -1.0 bis 1.0.

Der Fragmentshader ist extrem einfach, da wir aufgrund des nicht vorhandem Colorbuffers keinen Farbwert benötigen lassen wir diesen wie bei den perspektivischen Maps einfach undefiniert.
Zudem verlassen wir den Shader mit discard, wenn der der Pixel außerhalb der aktuellen paraboliden Map liegt. Die Voteil ist, das nur der kreisförmige Bereich der Map verwendet wird, der Nachteil, das durchaus eine Early-Z optimierung nicht mehr möglich ist. Sehr Sinvoll sollte dies sein, wenn die Shadowmaps dynamisch nach benötigter Größe angeordnet werden. Da sich Kreise besser als Quadrate packen lassen.

====Shader für den finalen Renderdurchgang====

final.vert
<cpp>varying vec3 Normal;
varying vec3 ModelVertex;

void main(void){
Normal = gl_NormalMatrix * gl_Normal;
ModelVertex = vec3 (gl_ModelViewMatrix * gl_Vertex);
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
gl_TexCoord[0] = gl_MultiTexCoord0;
}</cpp>

final.frag
<cpp>varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
uniform int MaxLights;

//Achtung folgende Zeile ist nicht GLSL konform.
//Workaround: Array als Uniform übergeben oder durch sehr aufwendige berechnung erstzten
//Sollte es auch auf ATI Karten funktinieren, frage ich mich warum es nicht erlaubt ist...
const vec2 texofset[8] = {vec2 (0.125,0.125), vec2 (0.125,0.375), vec2 (0.125,0.625), vec2 (0.125,0.875),
vec2 (0.625,0.125), vec2 (0.625,0.375), vec2 (0.625,0.625), vec2 (0.625,0.875)};
void main(void){
vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</cpp>

Möglicher weise für ATI taugliche Variante:
<cpp>
varying vec3 Normal;
varying vec3 ModelVertex;

uniform sampler2D Texture0; // Eine normale Textur
uniform sampler2D Shadowmap; //Damit ist auch die 4. TMU belegt..
const int MaxLights=8;

vec2 texofset[8];
void main(void){
texofset[0] = vec2 (0.125,0.125);
texofset[1] = vec2 (0.125,0.375);
texofset[2] = vec2 (0.125,0.625);
texofset[3] = vec2 (0.125,0.875);
texofset[4] = vec2 (0.625,0.125);
texofset[5] = vec2 (0.625,0.375);
texofset[6] = vec2 (0.625,0.625);
texofset[7] = vec2 (0.625,0.875);

vec4 light=vec4 (0.2, 0.2, 0.2, 0.0); //Emmitiertes Licht
vec3 normalvec =normalize(Normal.xyz);
for (int LightNum = 0;LightNum < MaxLights; LightNum++){
vec3 lightvec = ModelVertex - gl_LightSource[LightNum].position.xyz;
vec3 lightdir = normalize( lightvec );
vec2 parabol = texofset[LightNum];
if (lightdir.z > 0.0){
parabol.t += 0.25;
}
// parabolische Projektion für subtextur
parabol -= lightdir.xy * 0.125/ (abs (lightdir.z) + 1.0);
float shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol).r );
light += shadow * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));
}
vec4 color = texture2D(Texture0, vec2(gl_TexCoord[0])); //Textur auslesen;
gl_FragColor = light * color ;
}</cpp>

Diese Shader besitzen 3 Uniformvariablen, die unbedingt mit den richtigen Werten gefüllt werden müssen. Zwei davon sind Texturen, die dritte die Anzahl der aktiven Lichtquellen. Es ist wichtig zu wissen, dass der Shader nicht den OpenGL-Status der Lichquellen berücksichtigt und nur die Daten der Ersten bis MaxLights holt.
Während bei den Schattenmaps die meiste Arbeit im Vertexshader erledigt werden könnte, ist dieser sehr Fragmentshader lastig. Die Texturkoordinatenberechnung ist sehr ähnlich zu der im shadow.vert. Die größte Änderung ist, dass hier abhängig von der Lichtquellennummer ein Offset aufaddiert wird um die Untertextur auszuwählen. Ein zusätzlicher Offset wird dazuaddiert, wenn auf die zweite parabolide Map einer Lichtquelle zugegriffen wird.
Um ein dynamisches Branching zu vermeiden, wird mit der Stepfunktion ermittelt ob sich das Fragment im Schatten befindet.

==Optimierungen und Verbesserungen==
Hier sind noch einige Vorschläge, die helfen können um besser Qualität oder Leistungen im eigenem Programm zu bekommen. Eine uniververselle Lösung lässt sich nur auf kosten von Performance schreiben. Viel besser ist es, wenn man die Shader an die jeweilige Situation anpasst.

===Schatten durch Alphatest===
Der bisherige Schattenshader kann nur ganze Polygone einen Schatten werfen lassen. Wenn shadow.vert so ergänzt wird, das die Texturkoordinaten in den Fragmentshader weitergereicht werden, dann ist es mit folgendem Fragmentshader möglich Shatten in Abhängikeit einer Alphatextur zu rendern:

shadow.frag
<cpp>
uniform sampler2D Texture0;
void main(void)
{
if (texture2D(Texture0,vec2(gl_TexCoord[0])).a < 0.5) discard;
}</cpp>
Der Shader wird verlassen wenn das Texel einen Alphawert von kleiner als 50% hat. Damit lassen sich Schatten von Pflanzen wesentlich realistischer darstellen. Dieser Shader sollte natürlich nur dann verwendet werden, wenn eine Alphakanal in der Textur vorhanden ist. Auch Shader mit Paralax- oder Displacementmapping arbeiten kann man so um einen Schatten ergänzen, wenn die Polygone transparente Teile enthalten.
Es ist auch möglich den shader zu verlassen, wenn eine bestimmte Farbe in der Textur gefunden wird, dann nimmt die Alphamaske keinen Speicherplatz mehr weg.

===Farbiges Glas===

Schatten hat jetzt ja sachon fast jeder. Aber wie wäre es mal mit einfärben von dynamischen Lichtquellen?
Der Algoritmus ist nicht schwer:

* Alle Undurchichtigen Sceneteile in die Tiefenmaps gerendert.
* Zusätzlich wird eine Colormap gebunden und das Schreiben in den Zbuffer unterbunden.
* Die Colormap wird mit Weiß oder einer Helligkeitsmap initialisiert.
* Rendern aller transparenten Objekten
* Auf finales Rendern umschalten
* Alle undurchsichtigen Objekte mit hilfe der Schadowmap und der modifizierten Beleuchtungmap beleuchten.
* Alle Transparenten Objekte rendern, unter Berücksichtigung, dass die Lichtquelle bereits das gefilterte Licht aussendet. Dieses Blending sollte rückgängig gemacht werden.

Bei diesem Algoritmus bleibt noch das Alphablendingproblem mit der mehrfachen Überdeckung. Beim Modifizieren der Beleuchtungsmap gegebenfalls den Stencilbuffer zur Hilfe nehmen. Hier wäre ein denkbarer Algoritmus:

* Alle transparenten Poligone in den Zbuffer rendern. Dabei für alle Poligone, deren doppelte Filterung zu Fehlern führen kann mit verschiedenen Stencilwerte schreiben.
* Zbuffer und Colorbuffer Löschen.
* Helligkeitsmap in den Colorbuffer kopieren.
* Alle nicht transparanten Objekte in den Zbuffer Rendern.
* Alle transparenten Poligone mit den gleichen Stencilwerten wie im erstem Pass rendern. Die Bedingung ist, dass nur Polygone in den Zbuffer geschrieben werden, bei den Stencilwerte nicht mit den Stencilbuffer übereinstimmen. Die vordersten Polygone werden so aussortiert und nur die zweite Schicht landet im Zbuffer.
* Im letztem Rendervorgang müssen die gefilterten Lichtfarben der Transparenten Polygone in den Colorbuffer geschrieben werden. Die Bedingung ist das die Stencilwerte übereinstimmen müssen.

Auch wenn es wie ein großer Mehraufwand aussieht, ist der Anteil der transparenten Poligone doch eher gering. So das deren dreifacher Overdraw kaum eine Rolle spielt. Im Finalem Renderdurch gang gibt es bei den transparenten Polygonen noch eine Besonderheit: Stimmt die Entfernung aus der Shadowmap mit der Entfernung der Lichquellen (fast) überein, so wird das Poligon mit dem Licht aus der Colormap belauchtet. Ist die Entfernung aus der Shadowmap jedoch größer als die entfernung zu lichquellen, enthällt die Colormap die gefilterte Farbe des Lichtes hinter dem Poligon. Für die beleutung des Poligon muss also das Licht der Lichquelle benutzt werden. Sinvoll ist es die helligkeit für diesen Fall im Alphawert der Colormap zu Speichern.

Ansonsten noch ein paar Vorschläge:
* Objekte die aus dem gleichem Glas sind und auch einfarbig. Sollten mit dem gleichem Stencilwert verarbeitet werden. So sieht z.B. das gefärbte Licht einer zweifach durchstrahlten leicht gefäbten Glasskuppel natürlicher aus als ein Vollschatten. Auch wenn das Licht korrekter weise zwei mal hätte gefiltert werden müssen.
* Eventuel macht es sind mehrfarbige Objekte in mehrfache einfarbige Objekte zu zerlegen.
* Komplexe Mehrfachfilterungen sollten vermieden werden oder so gewählt werden, das sie natürlich ausehen. Gute Filter wären komplementärfarben, da dort ein echter Schatten erzeugt wird. Schlechte Kombinationen wären unter anderem Rot+Gelb, Blau+Gelb, usw...
* Um von den Farbfehlern abzulenken, farbige Objekte in einer rotverschobenen Farbe flourezieren lassen. (Violet-> Blau -> Grün -> Gleb -> Organge -> Rot) Durch blau gefärbte Fenster, blau gefilterte Licht welches Dinge grün aufleuchten lässt nimmt einem jeder PC Modder ab...

===Schattenmap durch eine Heightmap modifizieren===
Auch wennich hierzu noch kein Beispiel haben, ist es möglich gl_FragDepth mit hilfe einer Heightmap zu modifizieren. Prinzipiell entspricht dies einem einfachem Offsetmapping. Damit wäre durchaus eine Selbstschattierung von Bumpmaps möglich.

===Zweite parabolische Map vermeiden===
Lichtquellen, die nur in eine Richtung Licht werfen können, wie z.B. Spotlichter oder Lichter, die in Bodenähe oder Wandnähe befestigt sind, benötigen keinen vollständig erfassten Tiefenraum. Die Parabolische Map kann problemlos herein oder herausskaliert werden, so das Öffnungswinkel von 0 bis ca 240 Grad möglich sind.

Das verkleinern des Öffnungswinkels für zusätzliche Spotlichter ermöglicht auch kleinere Tiefenmaps, die in die 9 Zwischenräume der großen gepackt werden können. Die Zwischenräume können noch Maps mit einem Durchmesser von 40% der großen Maps aufnehmen.

===Texturelookups vermeiden===
Wenn das Skalarprodukt von normalvec und -lightdir negativ ist, dann ist die Oberfläche von der Lichtquelle abgewandt und Berechnungen für die Lichquelle können komplett übersprungen werden. Diverse Multiplikationen und vorallem Texturelookups können so übersprungen werden. Besondere aufwendige Algorithmen wie selbstschattierende Bumpmaps, können so deutlich Beschleunigt werden.

Für die Beleuchtung sollte dann allerdings auch folgende Zeile verwendet werden. (Das Skalarprodukt von vor der if Abfrage aber umbedingt wiederverwerten!)
<cpp>
light += gl_LightSource[0].diffuse * max(dot(normalvec, -lightdir), 0.0);
</cpp>

===Reichweite der Lichtquellen===
Leider bietet OpenGL nicht direkt die Möglichkeit die maximale Reichweite einer Lichquelle anzugeben. In den Shadern wird zur Zeit der Wert 15.0 als maximale Entfernung zur Lichtquelle verwendet. Für ein einfaches Programm ist es sicher ausreichend, ansonsten macht es Sinn diesen Wert durch eine Unformvariable zu ersetzten, oder um mehr Flexibiltät zu bekommen durch ein Array aus 8 Uniformfloats.

===Oversampling der Schattenmap===
Die Qualität lässt sich dadurch mehrere Samples auf der Schattenmap verbessern. Das folgende Codefragment nimmt 3 statt des einem Samples und glättet die Ränder des Schattens.

<cpp>const float pof =1.0 /4096.0 *0.7;
vec4 shadow = step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol +vec2(pof,0)).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,-pof/1.2) ).r );
shadow += step (length(lightvec)/15.0 -0.05, texture2D(Shadowmap, parabol+vec2(-pof/2.0,pof/1.2)).r );
light += shadow * 0.33 * gl_LightSource[LightNum].diffuse * abs(dot(normalvec, lightdir));</cpp>
Durch 9x Oversampling lässt sich schon eine sehr gute Qualität ereichen, sorgt aber bei 8 Lichtquellen durch die 72 Texturelookups für einen Zusammenbruch der Framerate.
Wichtig ist auch, dass man beachtet, dass die dualparaboliden Maps an Ihren Ränden undefiniert sind und so zu Artefakten kommen kann wenn man außerhalb des gültigem Bereichs sampled. Eine Möglichkeit wäre einen Bereich zu erfassen, der etwas größer als 180 Grad ist, um am Rand zusätzliche Texel zu schaffen.

===Ein zusätzlicher Renderpass===
Nach dem die Tiefenmap gerendert würde, wäre es möglich in einem weiterem Framebufferobjekt eine zusätzliche Map zu rendern, in der mit Hilfe einer Kantenerkennung die Helligkeit der Softshadows vorberechnet wird. Auch hier muss berücksichtigt werden, dass die dualparaboliden Maps einen Übergang haben.

===Dynamische Lichter in statische Lightmaps Rendern===
Wenn sich Lichtquellen nicht relativ zur Umgebung nicht bewegen, ist es möglich sie in eine Lightmap zu rendern. Unter der Annahme, dass Lightmapkoordinaten vorhanden sind (ohne geht es echt nicht gut), müssen diese nur per Vertexshader an den Pixelshader weitergegeben werden. Im Pixelshader kann dann wie im final.frag die Helligkeit berechnet werden und in der Lightmap abgespeichert werden.
Es ist immer noch möglich, das dynamische Objekte einen Schatten werfen: Es werden nur noch die beweglichen Objekte in die Tiefenmap gerendert. Im Schatten wird dann einfach das Licht der im Schatten liegenden Lichtquelle subtraiert.

===Statische Anteile in den Schattenmaps===
Es ist möglich mit einer zusätzlichen Matrix die Tiefenmaps zu den Weltkoordinaten auszurichten. Statische Anteile können dann aus einer zweiten Tiefenmap kopiert werden. Ein wenig problematisch ist das Entfernen der Rotation aus der gl_ModelViewMatrix. Das größte Problem ist, das die Positionen der Lichquellen bereits mit der gl_ModelViewMatrix multipliziert sind. Die einfachste Lösung ist, aus den den Rotationswinkeln eine neue Matrix zu erechnen, mit dessen Hilfe die Schattenvektoren für die Texturkoordinatenberechnung zurückgedreht werden. Diese Matrix sollte dann als Uniformvariable übergeben werden.
Wenn die Schatten durch einen zusätzlichen Renderdurchgang gefiltert werden. Ist es sinvoll die Maps erst hier zu vereinen. Von beiden Tiefenmaps muss nur immer der kleinere Wert genommen werden.

Boneanimation per Vertexshader

2006-10-08T15:06:35Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<glsl>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</glsl>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-09-27T20:30:39Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<cpp>
attribute vec4 weight;
attribute vec4 index; // ivec4 doesn't work. So I use vec4. Why does ivec4 not work?
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;
varying vec4 color;
void main(void){
vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[index[i] * 2];
temp2 += weight[i] * bones[index[i] * 2 + 1];
}
//Matrix decompression
mat3 mat;
mat[0] = temp1.xyz;
mat[1] = vec3(-temp1.y, temp1.w, temp2.w);
mat[2] = cross (mat[0].xyz,mat[1].xyz);

gl_Position = gl_ModelViewProjectionMatrix * vec4(mat * gl_Vertex.xyz + temp2.xyz,1.0);

//Untested TBN Code
N = gl_NormalMatrix * (mat * gl_Normal);
T = gl_NormalMatrix * (mat * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
color = weight.xywz; //for testing
}
</cpp>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-09-27T11:30:12Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<cpp>
#version 120
attribute vec4 weight;
attribute vec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[int(index[i]*2.0)];
temp2 += weight[i] * bones[int(index[i]*2.0+1.0)];
}
//Matrix decompression
mat[0].xyz = temp1.xyz;
mat[1].xyz = vec3(-temp1.y, temp1.w, temp2.w);
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz);
mat[3].xyz = temp2.xyz;

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);

//TBN Matrix Code
N = gl_NormalMatrix * (mat3(mat) * gl_Normal);
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-09-27T01:11:04Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<cpp>
#version 120
attribute vec4 weight;
attribute vec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[int(index[i]*2.0)];
temp2 += weight[i] * bones[int(index[i]*2.0+1.0)];
}
//Matrix decompression
mat[0].xyz = temp1.xyz;
mat[1].xyz = vec3(-temp1.y, temp1.w, temp2.w);
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz);
mat[3].xyz = temp2.xyz;

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);

//Untested TBN Code
N = gl_NormalMatrix * (mat3(mat) * gl_Normal);
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-09-27T01:01:42Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 48 Instruktions):
<cpp>
#version 120
attribute vec4 weight;
attribute vec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){

mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

vec4 temp1 = vec4(0.0, 0.0, 0.0, 0.0);
vec4 temp2 = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++){
temp1 += weight[i] * bones[int(index[i]*2.0)];
temp2 += weight[i] * bones[int(index[i]*2.0+1.0)];

}
//Matrix decompression
mat[0].xyz = temp1.xyz;
mat[1].xyz = vec3(-temp1.y, temp1.w, temp2.w);
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz);
mat[3].xyz = temp2.xyz;

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);

//Untested TBN Code
N = gl_NormalMatrix * (mat3(mat) * gl_Normal);
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent));
B = cross (T,N);

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Da code für die TBN Matrix kann bei bedarf teilweise gelöscht werden. Nur mit Normal werden etwa 38 Instruktions benötig und komplet ohne werden nur noch 32 instruktions benötigt.

Boneanimation per Vertexshader

2006-09-27T00:53:35Z

Oc2k1: /* Kompression der Matrizen */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden. Wichtig ist, das beachtet wird, das Opengl transponierte Matrizen verwendet.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||0
|-
|rot01 ||rot11 ||rot21 ||0
|-
|rot02 ||rot12 ||rot22 ||0
|-
|trans0 ||trans1 ||trans2 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||rot11
|-
|trans0 ||trans1 ||trans2 ||rot21
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute ivec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (N,T); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.

Boneanimation per Vertexshader

2006-09-25T11:57:54Z

Oc2k1: /* Woher kommen die Animationsdaten? */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen und Animationsdaten aus Blender übernommen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|rot01 ||rot11 ||rot21 ||trans1
|-
|rot02 ||rot12 ||rot22 ||trans2
|-
|0 ||0 ||0 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|trans2 ||rot11 ||rot21 ||trans1
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute ivec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (N,T); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.

Boneanimation per Vertexshader

2006-09-24T11:21:45Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|rot01 ||rot11 ||rot21 ||trans1
|-
|rot02 ||rot12 ||rot22 ||trans2
|-
|0 ||0 ||0 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|trans2 ||rot11 ||rot21 ||trans1
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute ivec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (N,T); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.

Boneanimation per Vertexshader

2006-09-22T12:03:14Z

Oc2k1: /* Kompression der Matrizen */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es wäre möglich die Cosinuswerte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären.

Sinvoller ist es einen Vektor aus dem Rotationsteil mit Hilfe eines Kreutzproduktes neu zu berechnen. Da bei reinen Rotations/Skalierungsmatrizen Die SUmmer von rot01 und rot10 Null ergibt, kann einer von beiden den den dritten Wert des Translationsteil aufnehmen.

Da nun nur noch 8 Werte gemittel werden müssen und der Aufwand für die Rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenleistung eingespart werden.

{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|rot01 ||rot11 ||rot21 ||trans1
|-
|rot02 ||rot12 ||rot22 ||trans2
|-
|0 ||0 ||0 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|trans2 ||rot11 ||rot21 ||trans1
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute ivec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (T,N); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.

Boneanimation per Vertexshader

2006-09-21T22:30:19Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es ist möglich die Cosinus werte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären. Wenn jedoch nur ein Cosinuswert weggelassen wird, kann das Vorzeichen aus den Vorzeichen der beiden anderen Cosinuswerte rekonstruiert werden, weil das Produkt aller Cosinuswerte einer Rotationsmatrix immer Positiv ist.
Der Gewinn ist, das nur noch 2 float4 Vektoren gemittelt werden müssen, jedoch kommt für die Rekonstruktion des driiten Cosinuswertes eine Wurzel und 3-4 Multiplikationen dazu.

Noch einfacher lassen sich 3 Komponenten des Rotationsteil der Matrix rekonstruieren, wenn sie durch das Kreutzprodukt neu Berechnen lassen. Da immernoch ein Wert redundant in der Matrix gespeichert ist, kann er den Z Wert des Translationsteil aufnehmen.
Da nun nur noch 8 Werte gemittel werden müssen und der aufwand für die rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenbleistung eingespart werden.
{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|rot01 ||rot11 ||rot21 ||trans1
|-
|rot02 ||rot12 ||rot22 ||trans2
|-
|0 ||0 ||0 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|trans2 ||rot11 ||rot21 ||trans1
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute ivec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute ivec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (T,N); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.

Boneanimation per Vertexshader

2006-09-21T22:25:49Z

Oc2k1: /* Code */

{{Offline}}
==Vorwort==

Dieser Artikel richted sich an alle, die schon weit Fortgeschritten sind. Ein sicherer Umgang mit Shadern und Vertexbufferobjekten ist hier Vorrausetzung. Bei der Boneanimation per Vertexshader geht es darum, möglichst viel Arbeit auf die Grafikkarte auszulagern.
Wer schon immer mal einen hochdetailierten Dinosaurier oder Octobus sein Unwesen treiben lassen will ist hier genau richtig.

==Grundlagen==

===Was sind Bones===

Bones entsprechen nicht nur Knochen. Mathematisch gesehen repräsenteriert jeder Bone eine Transformationsmatrix, der einen gewichteten Einfluss auf verschiedene Vertices nehmen kann. Da Bones sehr häufig in einem Animationsskelet zusammengefast sind, werden sie durch Gelenke verbunden, die Drehpunkten der Matrizen entsprechen.
Sehr häufig werden Bones als Stab oder ähnliches dargestellt, sie können jedoch auch komplexer Formen haben (z.B. das Becken einen Menschen). Bones die durch die durch ein festes Gelenk verbunden sind sollten umbedingt vermiedern werden, da sie nur Resurcen kosten ohne einen Nutzen zu bringen.
Grundsätzlich sollte alles was sich unabhängig voneinander bewegen können muss durch einen eigenen Bone dargestellt werden. Neben den nachgebildeten Kochen, gehören auch andere bewegliche Modelteile dazu wie Mimik und Augen.

===Woher kommen die Animationsdaten?===

Die Animationen können entweder aufgezeichnete Daten sein, durch Inverse Kinematik erzeugt werde oder aus einer Physikengine stammen. Bei einfachen Modellen ist es auch möglich diese Daten per Scripsprache zu erzeugen. In diesem Artikel werden die Bones eher als Schnittstelle dienen.

===Limits===

Aktuelle Grafikkarten erlauben 256 Uniformvariablend des Typs Float4. Für einen Bone werden 3 Float4 benötigt. Damit lassen sich etwa 80 Bones gleichzeitig verwenden. Wird dies schon beim Entwurf des Modells beachtet, stellt diese Wert kaum ein Limit dar. Bei einem symetrischem Modell lässt sich dieser Wert fast verdoppeln. Wenn die nicht ausreicht macht es Sinn Objekte mit vielen Bones wie Hände oder Gesichter getrennt zu Rendern.
Vorausgesetzt werden sollte eine Grafikkarte, die wenigstends das Shadermodel 2.0 unterstützt. Besser ist jedoch eine Grafikkarte, die Shadermodel3.0 unterstützt, damit der Code durch dynamisches Branching teilweise übersprungen werden kann.

==Technik==
===Modeldaten===

Das Vertexbufferobjekt muss zu den sonst verwendeten Daten wie Vertices, Normalen, Texturkoordinaten und gegebenfalls Tangent und Bitangent noch zusätzliche Daten über die Abhängigkeit zu den Bones gespeichert werden.

Im einfachstem Fall kann jedem Vertex nur ein Bone zugewiesen werden. Hier genügt ein einzelner Integer, der als Index dient.

Wenn zwischen meheren Bones interpoliert werden soll, ist als erstes ein Wert nötig nötig, der angibt wie viele Bones einen Einfluss auf den Vertex haben. Dann muss für jeden Bone die Gewichtung als Float und der Index als Int gespeichert werden. In den meisten Fällen sollte der Einfluss von vier Bones ausreichen. Sollten die Atributevariablen knapp werden ist es sinvoll die Gewichtung mit 0.999 zu Multiplizieren und die Indexnummer dazuzuaddieren. Solang dies nicht nötig ist koste es jedoch nur unötig Performance beim trennen.

In den Meisten Fällen beinflussen nur zwei Bones einen Vertex. Ein Knie sieht etwas seltsam aus wenn am Gelenk linear interpoliert wird. Hier lohnt sich der Aufwand die Gelenkposition zu speichern und den Abstand nach der Interpolation zu korrigieren.

===Gewichten der Bones===

Gerade im Vertexshader muss man genau überlegen, wo man Multiplikationen oder höhere Operationen einsparen kann prinzipell gibt es zwei Möglichkeiten. Die erste ist, dass die Matrizen anhand Ihrer Gewichtungen zu einer durchschnittlichen Matrix zusammenzurechnet werden. Pro Matrix werden 12 Multiplikationen und 12 Additionen benötigt, von denen je 3 aus Symetriegründen Wegrationalisiert werden können.
Bei der zweiten Variante werden erst die Vektoren mit den Matrizen multipliziert und anschließend gewichtet. Jedoch werden dann pro Matrix * Vektor Multiplikation 12 Multiplikationen gebraucht. Da aber neben dem Vertex auch noch der Normal und gegebenfals Tangentvektoren Multipliziert werden müssen, ist der Aufwand der ersten Variante deutlich geringer.

===Quaternionen im Vertexshader===

Der Sinn von Quaternionen im Vertexshader ist sehr fraglich. Sie wären möglich, jedoch langsamer, lediglicht die Multiplikation von Quaternionen mit einem zweitem Quartenion ist deulich schneller als eine Matrix * Matrixmultiplikation. Gerade diese Operationen werden sollten jedoch vor dem Vertexshader durchgeführt werden, da sie die Form des ganzen Skelletes beeinflussen und sich über das Frame nicht ändern. Da mit bleibt nur noch ein einziger Vorteil: Es werden nur noch 2 Flot4 Vektoren zum Speichern eines Bones benötigt. Der Preis sind allerdings 27 Multiplikationen und 18 Additionen für die Umwandlung.

===Kompression der Matrizen===

Eine vollständige Transformationsmatrix benötigt 16 Komponenten. 4 können direkt entfallen, da uns die W Komponente der Vektoren nicht interresiert. Der Rotationsteil der Matrix ist jedoch immernoch sehr redundant. Die 3 Sinuskomponenten sind mit umgekehrtem Vorzeichen doppelt verhanden. Es bleiben noch 9 Komponenten über, die sich dummerweise nicht auf zwei float4 Vektoren aufteilen lassen. Es ist möglich die Cosinus werte mit Hilfe des Pytagoras neu zu berechnen, allerdings geht hierbei das Vorzeichen verloren, so dass keine Rotationen von mehr als 90 Grad mehr möglich wären. Wenn jedoch nur ein Cosinuswert weggelassen wird, kann das Vorzeichen aus den Vorzeichen der beiden anderen Cosinuswerte rekonstruiert werden, weil das Produkt aller Cosinuswerte einer Rotationsmatrix immer Positiv ist.
Der Gewinn ist, das nur noch 2 float4 Vektoren gemittelt werden müssen, jedoch kommt für die Rekonstruktion des driiten Cosinuswertes eine Wurzel und 3-4 Multiplikationen dazu.

Noch einfacher lassen sich 3 Komponenten des Rotationsteil der Matrix rekonstruieren, wenn sie durch das Kreutzprodukt neu Berechnen lassen. Da immernoch ein Wert redundant in der Matrix gespeichert ist, kann er den Z Wert des Translationsteil aufnehmen.
Da nun nur noch 8 Werte gemittel werden müssen und der aufwand für die rekonstruktion sehr einfach ist, kann hier sowohl Platz in den Uniforvariablen als auch Rechenbleistung eingespart werden.
{| align="center"
|Normale Transformationsmatrix:

{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|rot01 ||rot11 ||rot21 ||trans1
|-
|rot02 ||rot12 ||rot22 ||trans2
|-
|0 ||0 ||0 ||1
|}

| Gepackte Transformationsmatrix:
{| border="1" cellspacing="0" align="center"
|rot00 ||rot10 ||rot20 ||trans0
|-
|trans2 ||rot11 ||rot21 ||trans1
|}
|}

==Code==
Einfacher Vertexshader für Bones (ca 96 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute vec4 index; //enthält die Bonummer mit 2 Multipliziert
uniform vec4 bones[2*32];
mat4 bone_matrix(int i){
mat4 mat; //neue Matrix
mat[0] = bones[i*2]; //erste komponete kopieren
mat[1] = bones[i*2+1]; //zweite
mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen
mat[3] = vec4 (0.0, 0.0, 0.0, 1.0); //dummy für 4x4 Matrix
return mat;
}

main(void){
vec4 pos = vec4(0.0, 0.0, 0.0, 0.0);

for (int i = 0; i<4; i++)
pos += weight[i] * bone_matrix(index[i]) * gl_Vertex;

gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Ein wenig Resourcensparender formuliert (ca 32 Instruktions):
<cpp>
attribute vec4 weight; //Die gewichtung aller Bones Summe = 1
attribute vec4 index; //enthält die Bonummer mit 2 Multipliziert

uniform vec4 bones[2*32];

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

vec4 pos = mat * gl_Vertex;
gl_Position = gl_ModelViewProjectionMatrix * pos;

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}

</cpp>

Boneanimationshader mit code zum Transformieren einer TBN Matrix (40 Instructions):
<cpp>
attribute vec4 weight;
attribute vec4 index;
attribute vec3 tangent;

uniform vec4 bones[2*32];

varying vec3 T,B,N;

void main(void){
mat4 mat= mat4(0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 0.0,
0.0, 0.0, 0.0, 1.0);

for (int i = 0; i<4; i++){
mat[0] += weight[i] * bones[index[i]];
mat[1] += weight[i] * bones[index[i]+1];
}

mat[2][3] = mat[1][0]; //Translations teil der 3 Spalte aus der 2. hohlen
mat[1][0] = -mat[0][1]; // Translationswert durch gespiegelten Kosinuswert ersetzten
mat[2].xyz = cross (mat[0].xyz,mat[1].xyz); //Wenn es nicht stimmt komponenten tauschen

gl_Position = gl_ModelViewProjectionMatrix * (mat * gl_Vertex);
N = gl_NormalMatrix * (mat3(mat) * gl_Normal); //Normal
T = gl_NormalMatrix * (mat3(mat) * vec3(tangent)); //Tangent
B = cross (T,N); //Bitangent

gl_TexCoord[0] = gl_MultiTexCoord0;
gl_TexCoord[1] = gl_MultiTexCoord1;
}
</cpp>
Besonders beachtet werden sollten die Klammern bei der Berechnung, da MatrixMatrixmultiplikationen erheblich mehr Instruktions erzeugen.