AF-comparison between ATi and Nvidia

[mboeller]

this is IMHO an nice comparison between Nvidia and ATi, showing the ATi worst case situations very clearly :

http://www.skenegroup.net/tertsi/aniso/

I really hope they improve the AF-algo. with the next cards (R4xx).


found the link in the 3DCenter.de - Forum. Thanks

 

[Hyp-X]

It also shows the aliasing problem with ATI's application aniso under OpenGL.
I wonder when will they fix their drivers...

 

[StealthHawk]

It also shows the aliasing problem with ATI's application aniso under OpenGL.
I wonder when will they fix their drivers...

Why is it doing that, anyway? Change of LOD when AF is set to app for extra performance? Bug?

 

[Hyp-X]

Why is it doing that, anyway? Change of LOD when AF is set to app for extra performance? Bug?

It doesn't apply anisotropic filtering, only bilinear at the area where only the first mipmap is used. Once it starts to blend into the second mipmap the rendering is correct.

I think it's a bug, because - altough it might improve performance a little bit - it is only affecting application mode, which is rarely used by reviewers.
If you force aniso in the control panel the rendering is correct.

This bug is in the ATI drivers for a long time - strange that noone complained about it before.

 

[Dio]

Would this 'bug' be that the R300 series obeys the DX9 mag filter anisotropic / linear setting, rather than applying the min filter anisotropic / linear setting to magnification filter as well, as some other cards are rumoured to do?

I find it hard to see how obeying the API's commands can be a bug.

 

[OpenGL guy]

Would this 'bug' be that the R300 series obeys the DX9 mag filter anisotropic / linear setting, rather than applying the min filter anisotropic / linear setting to magnification filter as well, as some other cards are rumoured to do?

I find it hard to see how obeying the API's commands can be a bug.

Because people think that the behavior of some other IHV is correct, regardless of what the API specifies. I thought you knew this already?

 

[K.I.L.E.R]

Would this 'bug' be that the R300 series obeys the DX9 mag filter anisotropic / linear setting, rather than applying the min filter anisotropic / linear setting to magnification filter as well, as some other cards are rumoured to do?

I find it hard to see how obeying the API's commands can be a bug.

I wander that myself sometimes.

 

[StealthHawk]

Would this 'bug' be that the R300 series obeys the DX9 mag filter anisotropic / linear setting, rather than applying the min filter anisotropic / linear setting to magnification filter as well, as some other cards are rumoured to do?

I find it hard to see how obeying the API's commands can be a bug.

Mmm...I'm not sure I understand as we are talking about OpenGL and not D3D?

D3D: control panel AF and app AF look pretty much the same to me. Good stuff all around http://www.skenegroup.net/tertsi/aniso/d3d/aniso24.html

OpenGL: control panel AF and app AF do not look the same. App AF exhibits texture aliasing(if that's what it is). In any case, OpenGL app AF looks a lot worse than OpenGL control panel AF, D3D control panel AF, or D3D app AF. http://www.skenegroup.net/tertsi/aniso/opengl/aniso24.html

 

[bloodbob]

Umm there is download link for the application ( and also the source so we can make sure it is actually applying the write texture filtering ) umm so we all going by some screen shots?

 

[madshi]

OpenGL guy, does the aliasing come from the "mag problem" in this specific case? Thanks!

 

[[maven]]

Applications

I think they are
Direct 3D
and
OpenGL...

 

[OpenGL guy]

OpenGL guy, does the aliasing come from the "mag problem" in this specific case? Thanks!

Without looking at the source code for the app. or checking in the driver for the app's behavior, I can't say for sure, but I'd say it's likely.

OpenGL and D3D both specify a variety of filters for textures. In D3D you have MIN, MAG and MIP. In OpenGL you have MIN and MAG only, but the encodings for MIN contain the MIP filter as well. If you select, anisotropic filtering for the MIN filter, then you should also select this filtering mode for the MAG filter, else you won't be filtering everything in an anisotropic manner.

Selection of the MIN filter should not dictate what happens to the MAG filter.

 

[madshi]

OpenGL and D3D both specify a variety of filters for textures. In D3D you have MIN, MAG and MIP. In OpenGL you have MIN and MAG only, but the encodings for MIN contain the MIP filter as well. If you select, anisotropic filtering for the MIN filter, then you should also select this filtering mode for the MAG filter, else you won't be filtering everything in an anisotropic manner.

Selection of the MIN filter should not dictate what happens to the MAG filter.

Thanks for commenting.

One question: Does it actually make sense for an application to select anisotropic filtering for the MIN filter only? Or is this clearly nonsense? Thank you!

 

[Hyp-X]

Would this 'bug' be that the R300 series obeys the DX9 mag filter anisotropic / linear setting, rather than applying the min filter anisotropic / linear setting to magnification filter as well, as some other cards are rumoured to do?

I find it hard to see how obeying the API's commands can be a bug.

Hello?
I said OpenGL!

 

[Hyp-X]

OpenGL guy, does the aliasing come from the "mag problem" in this specific case? Thanks!

Without looking at the source code for the app. or checking in the driver for the app's behavior, I can't say for sure, but I'd say it's likely.

OpenGL and D3D both specify a variety of filters for textures. In D3D you have MIN, MAG and MIP. In OpenGL you have MIN and MAG only, but the encodings for MIN contain the MIP filter as well. If you select, anisotropic filtering for the MIN filter, then you should also select this filtering mode for the MAG filter, else you won't be filtering everything in an anisotropic manner.

Selection of the MIN filter should not dictate what happens to the MAG filter.

There's no such MIN filter as anisotropic in the OpenGL API.

GL_EXT_texture_filter_anisotropic defines a anisotropy setting that is orthogonal to MIN/MAG filtering.

Should there be a particular anisotropic texture filtering minification
and magnification mode?

RESOLUTION: NO. The maximum degree of anisotropy should control
when anisotropic texturing is used. Making this orthogonal to
the minification and magnification filtering modes allows these
settings to influence the anisotropic scheme used.

Edit: I was asked to chill down so...

 

[Hyp-X]

One question: Does it actually make sense for an application to select anisotropic filtering for the MIN filter only?

Note: My answer applies to D3D only! (If you read my previous post it should be obvious why.)

Yes, because some cards do not support anisotropic filtering mode for the MAG filter.
Setting a mode that a card doesn't support is not good practice and can produce a lot of warning messages with the debug runtime.

The problem is appearently the lack of clear specification regarding when is the MIN filter or MAG filter should be applied.
The particular problem case is, when the texture is minified at one axis but magnified at other.
The refrast sometimes uses the MIN filter, sometimes the MAG filter in this case...

 

[OpenGL guy]

OpenGL guy, does the aliasing come from the "mag problem" in this specific case? Thanks!

Without looking at the source code for the app. or checking in the driver for the app's behavior, I can't say for sure, but I'd say it's likely.

OpenGL and D3D both specify a variety of filters for textures. In D3D you have MIN, MAG and MIP. In OpenGL you have MIN and MAG only, but the encodings for MIN contain the MIP filter as well. If you select, anisotropic filtering for the MIN filter, then you should also select this filtering mode for the MAG filter, else you won't be filtering everything in an anisotropic manner.

Selection of the MIN filter should not dictate what happens to the MAG filter.

You know as well as I do there's no such MIN filter as anisotropic in the OpenGL API.

GL_EXT_texture_filter_anisotropic defines a anisotropy setting that is orthogonal to MIN/MAG filtering.

So why are you spreading false information?

Because I didn't know the definition of the extension? I looked for it before posting, but didn't see any comment about anisotropic filtering in the GL 1.5 specs.

Sheesh, chill a little.

 

[Hyp-X]

I didn't know the definition of the extension. I looked for it before posting, but didn't see any comment about anisotropic filtering in the GL 1.5 specs.

Sheesh, chill a little.

Ok, I chilled (edited) my post.
I was a little bit disappointed about two ATI guys attacking me (without really addressing the issue I was talking about.)

So what do you think now?
To my best knowledge the most an application can do is:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 16);

How can this code be changed to get correct(*) rendering?
(Correct: aliasing free, like with the control panel forced aniso or in D3D.)

 

[[maven]]

One question: Does it actually make sense for an application to select anisotropic filtering for the MIN filter only? Or is this clearly nonsense? Thank you!

AFAIK, specifying anything but linear for magnification (i.e. anisotropic) doesn't make sense, because anisotropy simply does not apply when magnifying textures...

 

[OpenGL guy]

]

One question: Does it actually make sense for an application to select anisotropic filtering for the MIN filter only? Or is this clearly nonsense? Thank you!

AFAIK, specifying anything but linear for magnification (i.e. anisotropic) doesn't make sense, because anisotropy simply does not apply when magnifying textures...

However, this is false. Anisotropy affects magnification because your pixel footprint is likely not square.