View Full Version : really mysterious gl_TexCoord[0] in fragment shader

05-26-2004, 05:39 AM
i tried a little rim light shader .. no big problem, but i found a really mysterious thing .. i'm not sure if it should be like this ..

first my vertex shader:

uniform vec4 lightPos;
uniform vec4 eyePos;

varying vec3 N;
varying vec3 V;

void main(void)
gl_TexCoord[0] = gl_MultiTexCoord0;

vec3 P = vec3(gl_ModelViewMatrix * gl_Vertex);

N = gl_NormalMatrix * gl_Normal;
V = vec3 (gl_ModelViewMatrix * eyePos) - P;

gl_Position = ftransform();
no problem in here .. everything is really fine ..

so lets have a look in the fragment shader code .. its what we know from dawn demo ..

uniform vec4 rimColor;
uniform float rimPower;

varying vec3 N;
varying vec3 V;

void main (void)

vec3 nN = normalize(N);
vec3 nV = normalize(V);

float rim = pow(1.0 - max(dot(nV, nN), 0.0), rimPower);

gl_FragColor = rimColor * rim;
.. this one is working .. but if i delete the sensless gl_TexCoord[0]; in the fragment shader, i get different results .. ??? .. why do i need this line of code ???


05-26-2004, 09:15 AM
This sounds like a bug. Which driver do you use?

05-26-2004, 09:40 AM
I just test your shaders in ShaderDesigner. Both shaders comile and link with no errors, but gl_TexCoord[0] line has no effect in FP asm output (with or without this line). Tested with FW 61.32, FX5900XT.


05-26-2004, 10:00 AM
Sounds weird.

Is there any reason to use gl_TexCoord (.xy) instead of varying vec2 TexCoord; ?

05-26-2004, 08:08 PM
If you're using fixed function fragment processing with a GLSL vertex shader, then you need to output to gl_TexCoord[0] to ensure it's written to the right interpolator. But when you use a vertex and fragment shader pair there's no point in using gl_TexCoord[n] as opposed to varying variables. In fact, using varyings give more flexibility to the driver and is more readable IMO.

05-27-2004, 12:47 AM
.. i'm working with a fireGl x2 (fgl 9800) APG 4x/8x on an xp system .. driver .. i'm thinking it's the newest one ..

i have the same problem with an other shader .. exactly the same problem ..