really mysterious gl_TexCoord[0] in fragment shader

[andreasMank]

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)
{
  gl_TexCoord[0];
 
  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 ???

thx

[Corrail]

This sounds like a bug. Which driver do you use?

[yooyo]

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.

yooyo

[Sunray]

Sounds weird.

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

[Humus]

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.

[andreasMank]

.. i'm working with a fireGl x2 (fgl 9800) APG 4x/8x on an xp system .. driver 6.14.10.6404 .. i'm thinking it's the newest one ..

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