Anistropic Debate

I wasn't able to get the road to rotate either, using WinXP too. I did take a shot using the above listed settings (except max aniso is set at 8x). Using 28.32 drivers on a GF4 Ti4600.

mipmap.jpg


Simon:

I was mentioning it in regards to the ATI R8500 doing aniso in bilinear, not on NVIDIA cards. When I had the R8500, I noticed the different artifacts too using aniso, although at the time I could only enable it on OpenGL applications, as there was no way to enable it in D3D back then.
 
Simon says (hehe)...

"Err Anisotropic filtering shouldn't be necessary to remove MIP map boundary lines from the texturing - Trilinear should be sufficient for that. It sounds more like the way the particular filtering is implemented."

Yes...very true...you do realize that the 8500 cannot enable trilinear + anisotropic filtering, right? I believe that if this were possible, it would greatly reduce the issue...but it would also reduce the performance as well (though very likely higher/better than nVidia's...)
 
I'll check the "unable to rotate" issue when I get home this weekend (I have a box with WinXP at home). I can't promise anything though, I'll have a trip to Japan next week :)
 
Hmm... Well, make sure that you have the latest version (0.21, I believes). I think there was a bug in a earlier version.
Furthermore, make sure that it is not "paused" (in the File menu, or press space key). Choosing "Rotate road" does not reset the pause status.
 
Ahh, the main downfall of rip-mapping,....angle funkiness :)
aniso effect decreases towards 45degrees, then gets to no effect, then goes back up to full at 90degrees, repeat.

Oh well.
However, why can one not do trilinear with rip-mapping?
 
Althornin said:
Ahh, the main downfall of rip-mapping,....angle funkiness :)
aniso effect decreases towards 45degrees, then gets to no effect, then goes back up to full at 90degrees, repeat.

If the filtering quality is constantly shifting as your moving through 3d space that would exlpain the dirty impression I get of its IQ. Wouldn't that be something thats only totally noticible in motion as well, and not screenshots?
 
Hi Althornin,
Oh well.
However, why can one not do trilinear with rip-mapping?
I don't see a reason why this wouldn't work. Due to the additional samples, speed improvements might be hit a tad harder than most would like, though. IMO it was a design decision for Radeon chipsets to go the bilinear route. I remember some rather funky coloured MIP-map screenshots from Serious Sam (or was it Q3A?) from the old boards which showed a rather weird implementation of trilinear filtering--looked more like blended bilinear filtering to me, but might have been a driver issue.

Could perhaps someone here provide some coloured MIP-map screenshots with trilinear filtering on a Radeon? Thanks. :D

Edit: Found it: http://www.beyond3d.com/messageview...=1692&highlight_key=y&keyword1=mipmap

The image was provided by Neeyik: trilinear Filtering on R8500

ta,
.rb
________
strawberry cough
 
Last edited by a moderator:
Doom is quite correct; I redid the old check that I had performed in Q3A with the 9021 drivers and you can see everything is decidedly "fuzzier" ;):

trilinear_new_mipcolor.jpg
 
Althornin said:
Ahh, the main downfall of rip-mapping,....angle funkiness :)
aniso effect decreases towards 45degrees, then gets to no effect, then goes back up to full at 90degrees, repeat.

the angle between the u/v-axis and the viewplane is still the same in both the ground-aligned and the 45degr rolled shot - nothing should have changed in regards to rip-mapping. the exhibited effect seems to me to be more a matter of funky |du, dv| -to- dx/dy ratios. ..which brings memories of talks of r200 not doing proper per-pixel mip-lod selection.
 
Livecoma said:
Althornin said:
Ahh, the main downfall of rip-mapping,....angle funkiness :)
aniso effect decreases towards 45degrees, then gets to no effect, then goes back up to full at 90degrees, repeat.

If the filtering quality is constantly shifting as your moving through 3d space that would exlpain the dirty impression I get of its IQ. Wouldn't that be something thats only totally noticible in motion as well, and not screenshots?


That really depends on the game. For a game that is basically flat (most fist person shooters) its hard to see that rotation difference. Take CS, which really restricts your movement. Here is a game that I find it very hard to notice these things. Other games with more degrees of freedom like a flight sim should show this much better.
 
I noticed that if I checked the wide road texture option, the 'angle-funkiness' was almost eliminated.

Why is this? What does that tell the unintiated?
 
The "wide road texture" option selects a 1:4 texture for road instead of normal 1:1 texture. Since the road texture always has the same orientation, it can mimic some anisotropic effects. Actually it is like a partial ripmap. You can turn off anisotropic filtering and compare the result with and without wide road texture to see the differences.

However, if the rotation axis is up-down, this trick will not work, since the road texture will not always have the same ratio.
 
the angle between the u/v-axis and the viewplane is still the same in both the ground-aligned and the 45degr rolled shot - nothing should have changed in regards to rip-mapping. the exhibited effect seems to me to be more a matter of funky |du, dv| -to- dx/dy ratios. ..which brings memories of talks of r200 not doing proper per-pixel mip-lod selection.

No, your not getting how rip-mapping works. The angle to the viewplane has NOTHING to do with how rip-mapping works (any more than in any aniso implimentation). Its the fact that rip-mapping uses pre-generated mip-maps like this:
rip-mapping.jpg

Note that at a 45 degree angle, the only mip-map that fits is the "normal" mip-map, not any of the pre ANISO'd rip-maps. Thats why the flaw is at 45degree angle...

Article:
http://www.sgi.com/software/performer/brew/anisotropic.html
 
One thing that puzzles me is how ripmapping fits into the API's ... I mean, the driver still receives 256x256, 128x128,64x64 .. and so on, not 256x256,256x128,128x256, 256x64, 64x256 ... etc. If the driver downsampled all those from the original 256x256 texture, then mipmap coloring wouldn't work. If this really is what's done in the Radeons, then how is this handled by the driver? Where does it get those other mipmap levels from? :-?
 
Back
Top