opengl texture sampling

[Aeluned]

yeah, gl_TextureMatrix is an array of texture
matrices with a size of the available number of
texture units.

you can query this value using
GL_MAX_TEXTURES_UNITS i believe, but I’ve never
seen more than 4 units exposed to an application.

not sure about Cg, i don’t use it.

and what sort of matrix is the texture matrix? 4x4 i figure. is there anyway to use a 2 dimensional texture matrix to save cycles?

You’re always fighting what’s already in
place

How exactly would that save cycles?
This stuff is done in hardware using 4x4
homogenous matrices.
I also think it would break affine transformations.

I’m pretty sure there’s a reason things are in
place the way they are.
Anyway, I don’t know much about using a 2x2
matrix.

[michagl]

Originally posted by Aeluned:
[b]yeah, gl_TextureMatrix is an array of texture
matrices with a size of the available number of
texture units.

you can query this value using
GL_MAX_TEXTURES_UNITS i believe, but I’ve never
seen more than 4 units exposed to an application.

not sure about Cg, i don’t use it.

[quote]
and what sort of matrix is the texture matrix? 4x4 i figure. is there anyway to use a 2 dimensional texture matrix to save cycles?

You’re always fighting what’s already in
place

How exactly would that save cycles?
This stuff is done in hardware using 4x4
homogenous matrices.
I also think it would break affine transformations.

I’m pretty sure there’s a reason things are in
place the way they are.
Anyway, I don’t know much about using a 2x2
matrix.[/b][/QUOTE]oh yeah… multitexture eh. seems silly to use the texture matrices just to get around opengl’s loopy sampling. do game artist adjust their texture coordinates so they hit on the center i wonder? it seems just to much to ask without providing an alternative method. especially because the centers change depending on the width and height of the texture i believe.

as for 3x3 vs 4x4, support is built into the high level language shaders, but i guess it is just more for storage than anything else. if people actually used texture transforms regularly and were not penalized for doing so, it might be worth providing hardware for 3x3 (2d affine) matrix transform… the same hardware could be used for non translatable matrices as well. anyhow, it never hurts to ask.

this issue is really burning. me i don’t want to have to have an internal texture coordinate format, i wan’t coordinates to be transparent, and i don’t want end users to have to worry about this issue. its a pain in the ass really. even if i used the texture matrix to side step… two versions of custom shaders would need be maintaned depending on whether the matrix is used or not.

i’m really disappointed with this. its a lose lose situation no matter how i go about it. center sampling is just weird for software subsampling.

i’m pretty sure i know what i have to do. setting it up will just be a pain though. i still don’t see what the benefit of center sampling is. numericly its all cockeyed. why can’t people just agree on an approach. and the burden of the approach should be put on the hardware, and not end users.

[zeckensack]

[b]i’m really disappointed with this. its a lose lose situation no matter how i go about it. center sampling is just weird for software subsampling.

i’m pretty sure i know what i have to do. setting it up will just be a pain though. i still don’t see what the benefit of center sampling is. numericly its all cockeyed. why can’t people just agree on an approach. and the burden of the approach should be put on the hardware, and not end users.[/b]
Don’t “set up” anything!
If you’re trying to be clever about this it only shows that you didn’t understand it. Really, don’t do anything. Use naive texture coordinates and everything will just work. OTOH try to be clever and something will break.

Can you actually show an example of this “issue” in action or did you arrive at your conclusion (GL texture sampling = bad) through pure theory?

Unless you can provide some shots, or code, or just anything that we as your humble audience can verify, this feels like nothing more than a huge waste of time. For all I know, your “issue” may simply be a matter of CLAMP_TO_EDGE vs CLAMP and not related to texture coords at all. There’s just no substance here to merit all this lamentation. Until some comes up, I hereby tip my head and withdraw from this “discussion”.

Re benefits: it just works, independent of texture size and aspect ratio, object size and viewport size. Demonstrate the opposite if you can.

[knackered]

This is typical of michagl.
How much time would it take for you to just read the GL spec? All this waffling, pontificating, and procrastination has taken so much more time than to simply read the spec…and that would have just involved one person reading, not a whole bunch arguing.

[michagl]

everyone appears to agree that the specs say opengl samples at the center. and i could see how this could be useful for maybe rendering to a texture where it is only logical that opengl should sample its rasterization targets just like it would in screen space.

but no one thinks about textures this way in reality. and in my experience modeling environments like maya and what have you don’t reflect this fact conceptually.

simply put this gets by because you will never notice if you are not looking at the texture at the subpixel level.

yes this is very much a problem, but it looks like i will just have to learn to live with it.

to see the effects yourself, just setup a heightmap which uses subpixel sampling to fill in vertices between the pixels. your height values will not match opengls colour map for instance using the same texture coordinates… unless you are doing opengl style sampling in your app, which as described is much more convoluted, in the fact that whole numbers never reliably fall on texel edges or centers. this makes mapping to a discrete buffer a pain.

for instance for a 10x10 heightmap, values like 0.1, 0.2, 0.3, 0.4 for the most part would neither fall on edges or centers.

opengl appears to base its mapping on setting 0.0 and 0.1 for identity texture matrix, to the center of the corner pixels… everything inbetween is just a matter of interpolation.

since no one else seems to care. just don’t respond.

this seems like a big deal to me though. and as at least a couple of people have stated. they were not previosly thinking of texel sampling in these terms.

if you don’t care about your filtering being off by a half a texel. then go on your marry way. otherwise you should be thinking about modifying your systems.

if you are using a high resolution displacement map, and a low resolution colour map. this disparity can be ignormous. for instance i’ve worked with a 10000 width height field, and a 512 colour map. the colour map can be off by 100’s of kilometers. oceans can land on hills. its pretty ugly stuff.

there should be an open debate on this rather than a couple staunch actors just saying ‘sit down and shut up’.

[michagl]

i read this in a link i think ‘zed’ originally suggested. i don’t know why i forgot to look at that link. anyhow:

“Second, you should realize that “0,0” and “1,1” is the same texture coordinate, and sits right between all four corners of the texture, when you’re using REPEAT (and 0,0 is in the low-left corner of the low-left texel when using CLAMP). To sample the center of a texel, in a texture with side length L, you need to have a coordinate that is (0.5/L)+(N/L) where N is an integer.”

this appears to reject the possiblity that opengl samples on centers as far as this is true.

i have to wonder though what kind of relatively complex algorithm the hardware would use to decide which directin to interpolate through if it is given an edge from 0.0 to 1.0 if in fact they are the same singularity.

perhaps the quoted statement is not true, and opengl/hardware relies on the fact that 0.0 and 1.0 sample the centers of corner pixels just so that it can avoid ambiguity.

any thoughts?

i’ve never denied that my subsampling code may not be quite right. but i’ve stared at it for at least a couple hours, and have looked at many other third party examples of software texture sampling and texture generation.

[michagl]

i give up honestly… i think i will just ignore the problem and hope it goes away. hopefully some day i will notice a logical error in my code.

i apreciate your concerns.

sincerely,

michael

[system]

“Second, you should realize that “0,0” and “1,1” is the same texture coordinate, and sits right between all four corners of the texture, when you’re using REPEAT (and 0,0 is in the low-left corner of the low-left texel when using CLAMP). To sample the center of a texel, in a texture with side length L, you need to have a coordinate that is (0.5/L)+(N/L) where N is an integer.”

this appears to reject the possiblity that opengl samples on centers as far as this is true.

i have to wonder though what kind of relatively complex algorithm the hardware would use to decide which directin to interpolate through if it is given an edge from 0.0 to 1.0 if in fact they are the same singularity.
The equation has this component “(0.5/L)” because GL samples at the center of texels.

I think you are having trouble understanding texture coordinate addressing.
0.0 and 1.0 are special cases and yes, the hw has the appropriate circuit that handles sampling depending on the texcoord addressing state.

What problem are you trying to solve? How do you setup your texture?

a pipeline optimization paper someone here suggested i read said that using the texture matrix significantly cuts into performance. that is apparently the hardware is traditionally optimized for an identity texture matrix.
The vertex stage is typically not the bottleneck. I would not worry about 4 DP4 operations per tex stage.

[def]

Originally posted by michagl:
…for instance for a 10x10 heightmap, values like 0.1, 0.2, 0.3, 0.4 for the most part would neither fall on edges or centers.
That is just what does happen! 0.1 lies exactly on the edge between the first and second texel.

…if you are using a high resolution displacement map, and a low resolution colour map. this disparity can be ignormous. for instance i’ve worked with a 10000 width height field, and a 512 colour map. the colour map can be off by 100’s of kilometers. oceans can land on hills. its pretty ugly stuff.
Right. When sampling different resolutions the only way to do that (even without knowing the dimensions) is the way it is implemented in OpenGL. The square height field and the texture match edge to edge (0.0 - 1.0), so if you sample 0.25 in u from both, you get exactly the position one 4th across its width.
If this wouldn’t work, mipmapping would not work either.

[Overmind]

michagl, the other posters are not trying to argue with you if the OpenGL way is good or bad, they are trying to tell you that your assumption about 0.0 being the center of a texel is wrong.

I think you misunderstand a crucial fact:
OpenGL does sample on the center of the fragment, but that does not mean it will be the center of a texel. This has nothing to do with what you get for a particular texture coordinate, but with what texture coordinate is used in the lookup.

Lets just review the 1D case of a horizontal line for simplicity:

The texture coordinate 0.0 is the left edge of the first texel.
Now you draw a line, with a texture coordinate of 0.0 at the first vertex. OpenGL generates fragments from this line, and the left edge of the first fragment will have the texture coordinate 0.0.
But OpenGL samples at the center of fragments, so the texture coordinate of the (center of the) fragment will be 0.0 + half a pixel.
Now if for some reason pixels and texels are the same size, 0.0 + half a pixel will be the same as 0.0 + half a texel, which is the center of the first texel.

So you will get the center of the first texel on the first pixel, but not because 0.0 is the center. It’s because the lookup didn’t occur at 0.0, but at 0.0 + some small value…

You can easily verify this. Just draw a quad with texture coordinate 0.0 on every vertex, and clamp to border. This way the pixel size is 0 in texture coordinate space, so you will really get exactly 0.0 (== 0.0 + half a pixel ) as texture coordinate on every fragment. This should get you a 50% mix of the border color and the first texel, proving that 0.0 is actually the edge of a texel.

[michagl]

like i said before i apreciate the input. but there is just too much info here and apparently conclifting possibilities for me to wrap my head around.

for what its worth, i never had any issue with ‘fragments’, or rasterization. its just the texel sampling which doesn’t seem to be working out right for me.

someone asked how i am setting up matters. basicly i have a mesh, with texture coordinates. i’m displacing the vertices in the normal direction based on a filtered sampling of a heightmap done in a preprocessing step.

to arrive at my displacement sample. i take the texture coordinate of the vertex, chop off the fractional component, and pick the pixel that lies on the edge of the whole component. then i build a 3x3 kernel around that pixel, and use the fractional component to interpolate between the center and surrounding pixels.

after everything is done i render the mesh with a colour texture that matches the displacement map pixel for pixel.

from there it appears that the blended subpixel colours produced by the opengl linear mag filter do not align with the displaced vertices. that is there is about a half a pixel disparity between the corresponding colours and elevations.