Really mysterious gl_TexCoord[0] in fragment shader

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 ???


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

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.


Sounds weird.

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

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.

… 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 …

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.