View Full Version : texture coordinates

10-15-2003, 03:50 AM

I am developing an application which integrates Cg vertex and fragment programs with OpenGL API.

I am required to query texels from textures. I know the coordinates of the texel, which I have normalised. Do I pass this as it is after normalisation to my fragment program, so that appropriate texel is queried?

I am confused as for certain cases I got negative x and y coordinates to query; and do not know what this mean. I think -ve x-value means the projected point is not in texture and can be ignored or left as it is. And -ve y-value is because textures are stored from bottom left corner (inverted).

Please help and Thanx for your time.

10-15-2003, 05:46 AM
For vertex and fragment programs having "strange" texcoords will simply work. The result is however, dependant from texture object state (mainly wrap mode).

If you want to do it on the CPU, I suggest to just multiply the coord by the texture pixel size and then use the result to look up a 2x2 box of texels in the texcoord array. Lerping this correctly is fairly easy then but there will be some differences (always the same floating point error stuff).

10-16-2003, 04:18 AM
I do not wish to compute and access textures in CPU. I wish to do it within Nvidia GeForce 5900 series itself.

My texture wrap mode is set to GL_CLAMP in both 'S' and 'T' direction.

By ur post then, u mean i do not need to worry about -ve coordiantes in both x and y direction? It would work! I would offcourse still require to normalise the coordinates as am using CLAMP.

I will try this, lets see wt the outcome is.

Thanks for ur help. http://www.opengl.org/discussion_boards/ubb/smile.gif

10-16-2003, 06:32 AM
Here's another way to look at it:

Parameters set with TexEnv get subsumed by the fragment program pipeline, and won't have effect when you're enaling fragment programs.

Parameters set with TexParameter are still part of the texture object, which isn't replaced by fragment programs (except for the detail of depth compare coverage filtering).

The spec pretty much says as much, but not in quite those two, contrasting sentences :-)