NV und ATI verlangen utf-8 Kodierte bzw. ANSI-Kodierte Shader, wobei ANSI in UTF-8 ab zu bilden ist und damit das beste ist immer UTF8 zu nehmen.
Beide Hersteller wollen auch genau wissen wie du sie übergibst. so kannst du z.B. als 0terminierten String übergeben(länge=0) und nicht terminierter String(z.B. bei String von Delphi praktisch länge=str[0] aber als array und nicht direkt übergeben) aber dazu muss man entsprechend die Parameter bei glShaderSource befehl setzen(letzter parameter). Sonnst kommen da echt schöne Fehler zustande .
http://wiki.delphigl.com/index.php/glShaderSource

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bei mir (OpenGL Shader Builder unter OSX) lässt sich der Shader einwandfrei kompilieren.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Ich habs einfach mal auf meiner Geforce 6700 eingebunden. Es sagt mir dort:

Ich weis jetzt nicht wie viel das weiterhilft aber ich denke es ist ein bischen genauer.

_________________
You even trying ...

Website: http://rise-of-light.de/

Erstmal Danke für die Antworten.

@mori & TAK2004: Ich habe den Shader jetzt nochmal in UTF-8 kodiert und versucht zu kompilieren. Die Fehlermeldung ist beim Vertexshader die gleiche wie bei mori. Beim Fragmentshader habe ich folgendes:

Des weiteren habe ich meinen funktionierenden Shader (der sich auf eine Lichtquelle beschränkt) nochmal genommen und ihn Schritt für Schritt dem geposteten angenähert bis eine Fehlermeldung kam. Dabei habe ich sogar eine überraschend humane Fehlermeldung vom Treiber bekommen:

Eine Google-Suche hat ergeben, dass meine GraKa im Fragmentshader keine selbst angelegten Arrays mit Variablen indizieren kann (geht erst ab GeForce 8xxx). In meinem Fall ist das Array vLight[]. Also habe ich dort die for()-Schleife durch ein
ersetzt. Egal ob ich es als UTF-8 oder ANSI abspeichere, die Fehlermeldung beschränkt sich jetzt auf folgendes:

Eine erste Google-Suche (während ich diesen Beitrag schreibe ) hat ergeben, dass ich wohl zu viele varyings verwende. Das halte ich für gar nicht so unwahrscheinlich, schließlich bemängelt der Treiber ja gerade *die letzten* beiden varyings. Wenn ich mal die varying floats zusammenzähle, komme ich auf gerade mal 28 - die 16 wird "innerhalb" von tangentToEyeMatrix überschritten. Liegt das Limit also schon bei 16 oder 24? Wenn ich alle vec3 zu vec4 aufrunde und die mat3 zu einer mat4, dann komme ich sogar auf 40.

Was glaubt ihr, wieviele varyings sind wohl realistisch? Gibt es in GLSL vielleicht die immer wieder von Nvidia gepriesenen halfs?

Edit: Gestern habe ich übrigens auch den GeForce-Treiber auf die aktuelle Version 191.07 gebracht, jedoch ohne Besserung. Das was diese Seite hier als Cool-Smiley interprtiert, ist natürlich eine 8 mit schließender Klammer

Gruß mrtrain

Okay, ich habe den Shader jetzt zum laufen bekommen.

Meine GraKa unterstützt offenbar nur 24 varying floats , sodass ich ein wenig quetschen musste. cAmbient im Fragmentshader berechnen (der wird voll das Bottleneck ), die mat3-Matrix durch 3 vec4 ersetzen. In die w-Koordinaten kommt vPos - genauso wird vLight[4] zu vLight[3] zusammengestaucht, dafür mit einer Komponente mehr.

Weniger varyings gehen nicht, als nächstes müsste ich mich auf weniger als 4 Lichtquellen beschränken (soviele werde ich wahrscheinlich eh sogut wie nie verwenden). Falls jemand noch irgendwelche Verbesserungsvorschläge hat oder meine Frage zu den halfs beantworten will, kann er sie ja posten. Ansonsten erkläre ich das Problem mal als gelöst

Ein dickes Dankeschön an alle, die mir geholfen haben!

Gruß mrtrain

Die Berechnung von vLight[ i ] im Vertexshader ist nicht sinnvoll. Bedenke das der Wert für den Fragmentshader von drei Vertices interpoliert wird. Wahrscheinlich erhältst du ein besseres Ergebnis, wenn du nur die Postion an den Fragmentshader übergibst und die Berechnung dort durchführst. Das einzig aufwendige an der Berechnung ist sowieso das normalize, welches so oder so im Fragmentshader benötigt wird (fehlt im Moment), wenn das Ergebnis korrekt sein soll.

Die Bi-Tangente kannst du dir sparen, da sich diese leicht über das Kreuzprodukt berechnen lässt. Die Berechnung der tangentToEyeMatrix im Vertexshader ist hier wieder nicht sinnvoll, da auch hier interpoliert wird. Wenn verschiedene Matrizen interpoliert werden ist das Ergebnis nicht mehr zwangsläufig eine Orthogonalmatrix, und die brauchst du hier aber....

cAmbient müsste eigentlich das gleiche sein wie gl_FrontLightProduct[ i ], die Summe davon gibt es allerdings nicht. Trotzdem bietet sich hier ein Uniform an, da der Wert für alle Vertices und Fragmente gleich ist.

Edit: Bevor du Normale und Tangente an den Fragmentshader übergibst solltest du sie noch mit gl_NormalMatrix transformieren und normalisieren.

_________________
Yeah!

Danke, Coolcat. Das sind sicher einige nützliche Tipps. Nur eines verstehe ich nicht: Für mein Bumpmapping ist die tangentToEyeMatrix unverzichtbar. Irgendwie muss ich ja die Normalen vom Tangent Space in den World Space bringen. Und auf die mit attribute deklarierten Variablen kann ich nunmal nicht im Fragmentshader zugreifen...

So war das gemeint:

Vertexshader:
[glsl]attribute vec3 attrTangent;

varying vec3 vNormal;
varying vec3 vTangent;

// ...

void main() {

// ...

vNormal = normalize(gl_NormalMatrix * gl_Normal);
vTangent = normalize(gl_NormalMatrix * attrTangent);

// ...

}[/glsl]

Fragmentshader:
[glsl]varying vec3 vNormal;
varying vec3 vTangent;

// ...

void main() {

// ...

vec3 normal = normalize(vNormal);
vec3 tangent = normalize(vTangent);
vec3 bitangent = cross(normal, tangent); // ggf. auch cross(tangent, normal)

mat3 tangentToEyeMatrix = mat3(normal, tangent, bitangent);

// ...

}[/glsl]

_________________
Yeah!