Fragment coordinates in fragment shader

[imported_Budric]

Hi,
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.

Thanks.

[imported_Budric]

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:
http://www.gamedev.net/community/forums/topic.asp?topic_id=376169
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.

[Zengar]

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

[imported_CRasterImag]

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.

[system]

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.