Tex Coord for Middle of a Texture Rectangle

jwatte accurately described what I was suggesting.

The “correct” model is to project the pixel to texture space and compute a weighted average of the texels in the footprint.

Normal GL_LINEAR effectively assumes that the footprint is a 1-texel by 1-texel axis-aligned square centered around the sample point.

Normal mipmapping tries picks LODs where the real footprint is “closest” to this one-texel square.

Anisotropic filtering does a more complicated (oblong) sample pattern that more closely approximates the true footprint.

You can obviously think about this in other ways – that’s just my mental model.

My explanation in the previous post might not have been real clear. A “graph paper” example of what I’m talking about might be helpful.

Let’s say our (u,v) coordinate is (1,1). Then the 1-texel square centered around the sample point goes from (0.5, 0.5) to (1.5, 1.5). 1/4 of the square lies in each of the (0,0), (1,0), (0,1), and (1,1) cells, so you blend them together equally.

If the (u,v) coordinate is (0.75, 0.75), the square goes from (0.25,0.25) to (1.25, 1.25). More than half of that square (0.75^2) lies inside (0,0). Only 1/16th of the square (0.25^2) lies inside (1,1). So you blend them together with weights that favor (0,0).

This set up explains which texels are sampled and how the filter weights work in an intuitive way (at least intuitive to me).

But it’s probably completely identical to the tent filter model discussed by Cass without the requirement of knowing what a tent filter is. :slight_smile:

Ok, thanks Pat and jwatte.

I get it now.

Cass

A more deep understanding can be achieved by reading the source code of mesa. http://cvs.sourceforge.net/cgi-bin/viewc…viewcvs-markup

Notice the macro
#define COMPUTE_LINEAR_TEXEL_LOCATIONS(wrapMode, S, U, SIZE, I0, I1)
#define COMPUTE_NEAREST_TEXEL_LOCATION(wrapMode, S, SIZE, I)

and function
sample_2d_linear
sample_2d_nearest

[This message has been edited by inet (edited 10-02-2002).]

Maybe someone should write a paper on this, describing all the details.

I have a related question:
With cubemaps, why does everyone ( including me ) set the wrap parameter for the R coordinate ? After the face is selected, isn’t it just S and T that are used ?

Paul,

Right - it is meaningless to set the wrap mode for R with cube mapping. I have been guilty of this in the past as well.

Cass

So what happens if you use LINEAR and REPEAT at coordinate 0.0 and 1.0?

I guess it doesn’t sample from the opposing edge, and this is why BORDER is used.

Does anyone think that border is really needed in glTexImage? Why not just have GL_CLAMP behave like CLMAP_TO_EDGE and have artists deal with the textures to get the right effect in things like skyboxes.

V-man

Originally posted by V-man:
[b]So what happens if you use LINEAR and REPEAT at coordinate 0.0 and 1.0?

I guess it doesn’t sample from the opposing edge, and this is why BORDER is used.

Does anyone think that border is really needed in glTexImage? Why not just have GL_CLAMP behave like CLMAP_TO_EDGE and have artists deal with the textures to get the right effect in things like skyboxes.

V-man[/b]

If by “at coordinate 0.0 and 1.0” you are referring to the (s,t,r) coordinates – not scaled by the texture size – then LINEAR/REPEAT does wrap around to the other side. You’ll get 50% left edge, 50% right edge if you’re dealing with the s coordinate.

Texture borders can “automagically” patch together pieces of a larger texture. With PixelStore, it’s trivial to make small textures from large images. You still have to slice your geometry apart to get the right results.

You can achieve much of the same functionality by breaking your textures up into overlapping pieces. You do need more pieces without borders.

As a naive example, you might split up an 8x8 texture into 9 overlapping 4x4 slices. Along one diagonal, the slices would go from (0,0)-(3,3), (2,2)-(5,5), and (4,4)-(7,7). You still slice up the geometry and texture, but the border is effectively inside the image.

Why not just have GL_CLAMP behave like CLMAP_TO_EDGE and have artists deal with the textures to get the right effect in things like skyboxes.

Because that’s how GL was originally designed. That is something that can only be fixed by GL2.0.

>>>Texture borders can “automagically” patch together pieces of a larger texture. With PixelStore, it’s trivial to make small textures from large images. You still have to slice your geometry apart to get the right results.<<<<

Meaning that when you need to use a texture larger than the maximum width supported by hardware, you are forced to break it up and also break up your geometry and rework your texture borders.

This could still be done by the application (game).

I’m looking forward to GL 2, but the next version was suggested as 1.5 for doing the arb_fragment thing.

V-man