anisotropic filtering on stretched textures

[malcolm]

Im thinking about games where the textures are projected from top on the map so on very steep parts the textures are stretched.
Would anisotropic filtering work ok on that if the width of the texels gets smaller then the screenpixels?
If it does i think adaptive anisotropic wouldnt so this might be where normal anisotropic is better?

 

[OpenGL guy]

Would anisotropic filtering work ok on that if the width of the texels gets smaller then the screenpixels?

I'm not sure what you mean, but I think you'd want mipmaps in this case.

 

[malcolm]

Would anisotropic filtering work ok on that if the width of the texels gets smaller then the screenpixels?

I'm not sure what you mean, but I think you'd want mipmaps in this case.

I mean when the texels are stretched so that even when the polygon isnt at an angle, a texel can be 3 screenpixels long and only a half screenpixel wide.
So i was wondering if anisotropic would work on this, because normal isotropic filtering wouldnt get a lot of detail here.
Im asuming that with isotropic it would mipmap so the texels are 1x6 pixel size ore more?
I dont realy know how this works, but this is the same problem that you get with polygons at an angle.
So if anisotropic would work on this, i think adaptive wouldnt because the polygon isnt at an angle.

 

[malcolm]

Well im asking ok, i dont know how this works
I hope you understand my question now.

 

[OpenGL guy]

I mean when the texels are stretched so that even when the polygon isnt at an angle, a texel can be 3 screenpixels long and only a half screenpixel wide.

Again, you'd want mipmapping here. The mip level is only dependent on du/dx, du/dy, dv/dx and dv/dy, the z values don't matter at all.

If you enable anisotropic filtering, you'd first compute the degree of anisotropy, which, again, doesn't depend on z, then use that to compute the required miplevel.

See:
http://www.opengl.org/developers/do...ec1.1/node83.html#SECTION00681000000000000000

[note to self]Add a shortcut to this link as I seem to paste is a lot.[/note to self]

 

[malcolm]

thanks, it will take a while to know what it sais on those pages tough

 

[Xmas]

To give you a short and simple answer: yes, that's exactly what anisotropic filtering is intended to do.

It does not matter where this "texel stretching" comes from, whether from the perspective transformation or from trying to fit a square texture onto a non-square primitive.


ps. What do you mean with "adaptive anisotropic"? I don't know of an aniso implementation that is not adaptive.

 

[malcolm]

ps. What do you mean with "adaptive anisotropic"? I don't know of an aniso implementation that is not adaptive.

What i meant was a variable number of texture samples depending on something im not sure...
I tought what ati did was look what angle the polygon has in the view and depending on that select the number of texture samples.
But so it looks at something else than that?
If the adaptive sample number would depend on the polygon angle then anisotropic would be disabled on the stretched textures if the polygon is parallel to the screen.
But anyways, seems they dont do it like this?
I just tought i read this somewhere... but if this has nothing to do with polygon rotation then what caused the problems with the rotating on the z-axis?

 

[malcolm]

So then there are no drawbacks from the speeding up adaptive thing that ati uses?

 

[Bambers]

There was a flaw in the version in the 8500 that cuased polygons rotated at 45 degrees around the z axis to not be detected as needing aniso.

The 9700s version has fixed this.

 

[Xmas]

To make this clear: every implementation of anisotropic filtering is "adaptive". Adaptive in the sense that it takes a different number of samples depending on the amount of "stretchedness" of the projection of a texel into screen space.

Implementations differ in how this "stretchedness" is computed (or approximated ) and where the transitions to the next higher number of samples occur.

As OpenGL guy already wrote the degree of anisotropy depends on du/dx, du/dy, dv/dx and dv/dy, just like mip mapping.
u and v are coordinates in texture space, x and y are screen space coordinates. That d means you take the difference of each of these values wrt where you previously calculated it.
Ie. if you calculate the degree of anisotropy once every 8 pixels in a row, dx is 8 and du is the change of texture coordinate u over those 8 pixels.

 

[Xmas]

Oh, and there are no drawbacks in doing adaptive anisotropic filtering in general. And I really mean no drawbacks, it does not make any sense to take a fixed amount of samples in the first place.

However, I think ATI's implementation (in R7x00/8x00/9000) has its drawbacks, because it does a bad job in determining the number of samples needed. Not only does it have problems at certain angles, also the transitions between different levels of anisotropy happen very late, for the sake of performance. While it really saves a lot of speed, this could lead to "aniso banding", ie the visible transition from one level of anisotropy to another.