Fragment coordinates in fragment shader

I have rendered something into a texture and now need to access that pixel in the fragment shader. The problem is I don’t know how to get the coordinates.

First gl_FragCoord doesn’t seem to work at all. The following runs at 5 frames per second in ShaderDesigner cube rendering:

 gl_FragColor = (gl_FragCoord + 1.0) / 2.0; 

And the cube is of uniform white colour, so the coordinates aren’t changing according to fragment.

Second, I tried doing:

varying vec4 pos;
void main()
	gl_TexCoord[0] = gl_MultiTexCoord0;
	gl_Position = ftransform();
	pos = gl_Position.xyzw;

varying vec4 pos;
void main()
        vec2 texc = ((pos.xy / pos.z) + 1.0) / 2.0; 

The code above works, however only when I set the near clipping plane to 0, which is not what I want to do. I’m not sure why that is.


Oops, I should have been dividing by pos.w in the second example I gave. My mistake.

Still don’t know why gl_FragCoord don’t work at all. Found this other topic discussing the same issue I’m having:
I’m using ATI X1600 Catalyst 7.9

Don’t really care now about the gl_FragCoords, but it would satisfy my curiosity to know.

I suspect ATI implementations don’t support this variable in hardware or have some bugs…

I remember trying to use fragcoord before on an ATI and having some problems. I also had trouble making my own varying variables work. I solved my problem by using a texcoord from a texture I had selected into one of the texture units, that happened to have the same dimentions as the view.

I ran into many problems with ATI cards. Shaders that worked fine on NVidia cards would have “too many instructions” on an ATI card. Lots of headaches.

Yeah, ATI doesn’t support gl_FragCoord in hardware for many older cards. I believe they try to emulate it with a free texcoord when possible. I know the “heat-haze” shaders in Doom3 use fragment.position in the ARB shaders, and I never had problems with Doom3 on 9700 Pro, 9800 Pro, or X1600 Pro.

I’ve also encountered the drop in framerate in my own programs. I would recommend just using a free texcoord. If you don’t have one, you’ll get un-usable framerates on ATI hardware anyway.

Also, I think the coordinate that gets returned is not normalized: it’s in range of (0-W), (0-H). I could be very wrong about that.

Now that I think about it, I originally tried to access a 2D texture with the unnormalized coordinate, thinking it was normalized. I got low framerates, but not like it was going through a software path. When I changed the shader to expect an unnormalized coordinate, it ran at normal speed. I think that was on the X1600 Pro.

I hope my reply helps and doesn’t mis-lead you.

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