Anistropic Debate

[Doomtrooper]

This posted on Raged3D and Nvnews, although not too indepth there is alot of screen shots to look at, and judging by this review the Geforce 4 is taking a massive 60%-70% performance hit with new engine games with 8X anistropic enabled.

I am well aware of the differences in quality (IMO not much different between the two) so in the future what do you think will be done to get a happy medium between ATI's and Nvidias approach.
Obviously Trilinear and Ansitropic is not the way to go, and some skeptics gripe about the mip map borders that can occasionally be seen on Ripmapping.

So where do we go next..


http://195.38.1.194/test/

[John Reynolds]

Please don't drag flame wars from fan sites over here.

[LeStoffer]

So where do we go next..


I would like both ATI, nVidia and [vendor] to give the user the option of using either Performance AF or Quality AF. Implement both for crying out loud!

Regards, LeStoffer

[Joe DeFuria]

Well, the "happy medium" to me is simple: someone should implement both rip-mapping and "true" anisotropic, and give the user the choice of which one to use.

I'm waiting for the day when some company with give complete control over the "filtering method" to the end user based on a control panel applet. Choices should include:

1) Bi-linear
2) Tri-linear. (With sub-options for "true" trilinear, or "fast" trilinear.) "Fast" tri-linear might be implemented differently by different companies. Some might use auto mip-map generation with proper blending, some might use mip-map dithering instead of blending, etc.

In addition to those options, the user could also apply "anisotropic" on top of the above:

a) "True" anisotropic, with desired tap level
b) "Rip-Mapping" (which would force bi-linear, AFAIK).

I really wish some hardware vendor would introduce something like that...

[Mephisto]

Doomtrooper, your conclusion is wrong. You can implement anisotropic filtering without a performance loss compared to trilinear if you spend enough time on engeneering and enough space on your silicon.

It's all a question of question of cache size, caching algorithms and TMU design. GF3/4 looses a lot of performance because it is designed to fetch only 8 texels/clock and it has small texture caches.

R200 does not loose that much performance because it has the better caching due to the different, more cache friendly but lower quality texture sampling algorithm as well as the smaller amount of data (just one mipmap to read from).

I'm pretty sure future parts will offer both, high quality anisotropic filtering with mipmap interpolation and small(er) performance hit.

[Doomtrooper]

Please don't drag flame wars from fan sites over here.

Excuse me Johnny Boy, how is talking about what needs to be done to improve anistropic performance and visuals a flame war.

Grow up.
:roll:

[Doomtrooper]

Well, the "happy medium" to me is simple: someone should implement both rip-mapping and "true" anisotropic, and give the user the choice of which one to use.

I'm waiting for the day when some company with give complete control over the "filtering method" to the end user based on a control panel applet. Choices should include:

1) Bi-linear
2) Tri-linear. (With sub-options for "true" trilinear, or "fast" trilinear.) "Fast" tri-linear might be implemented differently by different companies. Some might use auto mip-map generation with proper blending, some might use mip-map dithering instead of blending, etc.

In addition to those options, the user could also apply "anisotropic" on top of the above:

a) "True" anisotropic, with desired tap level
b) "Rip-Mapping" (which would force bi-linear, AFAIK).

I really wish some hardware vendor would introduce something like that...

I like the idea of having that option too and a LOD slider like 3DFX did as adjusting the LOD will help with mip map borders with the bilinear option.

[Typedef Enum]

Personally, I like choice...and as such, I think the obvious 'happy medium' is to give the end user the choice between a Performance and Quality mode, much like ATI does with SmoothVision.

I think the main problem you have in getting such a thing from nVidia is the fact that they seem to strongly believe in doing things certain ways...and in this case, they seem to feel that there is a definite right vs. wrong way of implementing this feature...despite the advantage to the end user and the fact that there isn't a written-in-stone approach...but it's clear that they make a distinction between what they offer vs. ATI.

Honestly, if there were enough people barking down their tree wanting to have a certain feature, I wouldn't be surprised to see them do it...But I don't think they would do it otherwise.

As a point of reference, consider the 4xs AA mode...I asked a long time ago about the possibility of getting support in OpenGL, and was flat out told "No..."...Since the debut, one of the interviews (cant recall which) with an nVidia rep point-blank said that their engineers were working on the OGL implementation...I think they're responding to both people asking, "Why only D3D?" and also wanting to give people an additional reason to purchase such a card (in the cases where users already have, say, a GF3).

About 1.5 years ago, it was all about getting better FSAA performance...and I think that has been achieved (more or less)...a short time later, a little more emphasis was placed on Quality (IE SmoothVision and 4xs)...and now the trend clearly is to bring that up a couple of notches, to include anisotropic performance.

I will be really dissapointed if the true next-gen parts don't offer better aniso. performance AND better/higher quality AA.

[Doomtrooper]

Looking at the AA peformance of the Ti4600 I'd say FSAA peformance is maturing and all I see on future cards including the R300 is more attention spent on FSAA. I play with Anistropic on all the time and I personally feel it gives a better visuals effect than FSAA.
So I hope there is some work being done to improve anistropic too. :-?

[Mephisto]

and in this case, they seem to feel that there is a definite right vs. wrong way of implementing this feature...despite the advantage to the end user and the fact that there isn't a written-in-stone approach...but it's clear that they make a distinction between what they offer vs. ATI.


IMO this is part of their marketing concept. They want make fansites believe that ATis way doing anisotropic filtering is wrong and Ati "cheats" somehow.

[LeStoffer]

As a point of reference, consider the 4xs AA mode...I asked a long time ago about the possibility of getting support in OpenGL, and was flat out told "No..."...Since the debut, one of the interviews (cant recall which) with an nVidia rep point-blank said that their engineers were working on the OGL implementation...

Good idea: You and others with connection to nVidia should start asking whether they are able to implement a quick and dirty AF or not. Just challenge them and I'm sure you will get some kind of response or another.

Regards, Lestoffer

[Fred]

IMO ATI's ripmapping is the wrong way to go. Nvidia's method looks better, and while it takes a speed hit at this time/generation, silicon shouldn't be wasted on an inferior image quality solution. That would be like if we wanted to go back to Ogss compared to quincunxx.

In fact, a nice gaussian filter would be even more ideal (and probably coming soon) and smarter adaptive anisotropic logic would be a more elegant solution.

[John Reynolds]

Excuse me Johnny Boy, how is talking about what needs to be done to improve anistropic performance and visuals a flame war.

Grow up.
:roll:

You have been repeatedly warned by Wavey about name calling and personal attacks. I have never been disrespectful to you and I would appreciate that courtesy being returned.

This topic has been nothing but a giant flame war between the regulars at Rage3D and NVNews. Personally, if someone wanted to objectively discuss the differences between Nvidia and ATi hardware, I don't think they'd initiate the discussion by citing a 'review' that does nothing but bench at 16x12x32 to show what a "massive performance hit" one piece of hardware takes while downplaying the IQ issues of the other ("some skeptics").

You're welcome to post on these boards, but I'd like to see the fanboy noise levels turned down a notch or two. I honestly do believe that heavy-handed moderation is counter-productive, so I don't want to edit/delete your posts. Just please try to keep things on a more even keel on these boards.

[Typedef Enum]

"They want make fansites believe that ATis way doing anisotropic filtering is wrong and Ati "cheats" somehow."

I don't believe they perceive ATI to be cheating...it's just the simple fact that their method doesn't address the issue across the board. Clearly, they're not wrong in this regard.

Now, whether or not you think nVidia's implementation is worth the performance hit is another question. As I said, I would be OK with a perf. vs. quality choice, though I would probably tend to go with Quality the vast majority of the time.

[Mephisto]

Nvidia's method looks better, and while it takes a speed hit at this time/generation, silicon shouldn't be wasted on an inferior image quality solution.

According to this argumentation, Nvidia shoudn't have "wasted" silicon space for their inferior multisampling and should have used supersampling instead.

That would be like if we wanted to go back to Ogss compared to quincunxx.

Quincunx is the blur filter I think we all don't like.

What you probably mean is going back from a RG pattern to a OG pattern in general.

[Doomtrooper]

You have been repeatedly warned by Wavey about name calling and personal attacks. I have never been disrespectful to you and I would appreciate that courtesy being returned.

This topic has been nothing but a giant flame war between the regulars at Rage3D and NVNews. Personally, if someone wanted to objectively discuss the differences between Nvidia and ATi hardware, I don't think they'd initiate the discussion by citing a 'review' that does nothing but bench at 16x12x32 to show what a "massive performance hit" one piece of hardware takes while downplaying the IQ issues of the other ("some skeptics").

You're welcome to post on these boards, but I'd like to see the <bleep> noise levels turned down a notch or two. I honestly do believe that heavy-handed moderation is counter-productive, so I don't want to edit/delete your posts. Just please try to keep things on a more even keel on these boards.

Well what happens on Rage3D and Nvnews has nothing to do what I posted here. I titled it a debate as I think this is a important subject .
The review was important also because it shows what I was talking about with screen shots.
Your free to edit my posts because honestly its a sure sign of BIAS. I never posted any negetives about any product besides a massive performance hit mentioned, and for a $700 dollar video card where I live, if it can't Deliver MAX Anistropic at 1600 x 1200 there is a problem..dig.

There was some good comments on this thread too bad it was ruined by a moderator that maybe too hasty with the extreme power approach. Or didnt like the review :-?

[Fred]

The difference Mephisto, is that you don't lose any image quality with multisampling compared to supersampling as long as you are using anisotropic filtering. (well assuming you neglect or precheck alpha textures)

An argument can be made, that Quincunx generally looks better than the equivalent sample ogss mode, although at a speed cost.

But sure, rgss compared to ogss works too, for the line of argument.

All i'm saying, is that it strikes of shortsightedness to go for a solution that is inferior in image quality, but with a slight speedup.

These engineering trade offs are also not made in a vacuum. Adding silicon for ripmapping say on an Nvidia part would be ... questionable. Is the added heat/power cost/clock reduction/die space lost really worth it?

[Sharkfood]

Flamewars only arise when uneven/biased comparisons of products are sadly attempted to be made. I don't think there is anyone here stupid enough to fall for those tactics.

Although I agree with "more is better" and that having tunable texture filtering, LOD Bias and other such control left for the user, I don't think the average website reviewer could handle this amount of complexity.

It would simply become a war of default settings, which is what we have today. Information on the web is like "facts in a vacuum" at current as none of the ratings systems or product score/evaluations out there really pay any attention to the end result- and if they do, it's done for reasons of agenda as they will do a mutli-page derogatory analysis in favor of one products weaknesses and completely glance over anything that might hint at the reverse. Selective information.

Adding more end user control will just be additional fuel for the selective presentation of facts.

How many reviews now have tons of pictures of anisotropy- rotated, zoomed, anim gifs and the like? And how many have the same attention put towards Antialiasing? It just seems such scrutiny and criticism over image quality, albeit NOT a bad thing, is very specific and completely blind with similarly excessive IQ differences.. which are conveniently skipped over and ignored. If an analysis is to be comprehensive, it should be just that... not what we have today.

What it's really coming down to is- what is good for the gamer and end consumer is not good for a company selling it's products. The more settings end user reachable, the more conservative the defaults will be set to and the more uneven comparisons will be... or more uneven with incredibly selective commentary and analysis.

So I don't know an answer to all of this, at least until the "cookie cutter" benchmark graphs and "9 out of 10" review process is made obsolete and the emphasis is returned on the final resultant image and non-selective information. The moment this occurs will be the moment videocard manufacturers can start putting emphasis on real value versus fictional website races.

It would be a bold leap for ATI, NVIDIA, Matrox or anyone else to put a comprehensive and fully adjustable set of parameters into their drivers... and one that would stand to reason to be exploited if past history is any indication.

[ben6]

EDITED: Sorry for any confusion, but I won't be posting anything regarding anisotropic filtering in this thread...


Ben

[Ante P]

here's a "nice" nvnews discussion

http://nvnews.net/forum/showthread.php?s=&threadid=12569

I'm Undac in there. Most of them seem to hate me, honestly I don't know why :-?

[Livecoma]

Hmmmm.. I've been using the R200 for a few months now, and its anisotropic solution can be just as counter productive as it is productive.

Mip Map lines are soooooooooo 90's :lol:


When I had my GF3 I just left 64tap turned on constantly, and adjusted resolution according to performance. The performance hit is definatly greater, but to my eyes the IQ difference is night and day most of the time.

Oh BTW I noticed halfway through reading the benchmarks the reviewer (who I assume is just a simple gamer) said this...

"GF4 only...ATI card sold"


:evil:

[LeStoffer]

Hmmmm.. I've been using the R200 for a few months now, and its anisotropic solution can be just as counter productive as it is productive.

Huh? What do you mean by counter productive?

Regards, LeStoffer

[Typedef Enum]

I suspect he meant that the noise/banding/error (call it what you will) is disturbing to the point of <fill in the blank>.

I wouldn't go quite that far, but there is a definite difference....Anybody who claims that they're on par with one another is simply not being honest.

I would believe the guy who says, "You know...I can see what you're talking about...But honestly...For me, it's just not that big of a deal...and it certainly is worth the minimal performance drop..."

...as opposed to the other guy who swears up and down, "I cannot tell a single bit of difference..."

[Doomtrooper]

Well as a owner of both cards also I never used 64 Tap Anistropic on our Geforce 3 as the peformance hit was big, especially games like Unreal Tournament. We ran with 32 tap or nothing at all.
Ever since this debate started a couple of days ago I fired up every game I had and started looking, and I mean really looking..
The worst game I saw some mip map borders was some Quake 3 maps, the least was Madden 2002 and Nascar 4. I could not see artifacts on 95% of the games.
I don't want to this to turn into a mine is better than yours debate as it always ends up in a war, I wanted to see what some of the more knowlegeable members here thought about future implementations of anistropic filtering.

:-?

[Matt]

I agree, using anisotropic filtering is like night and day in games, at least with NVIDIA's implementation. Not so sure about ATI's ripmapping. Personally just like playing games in 800x600, I'd rather stick bamboo shoots under my fingernails than play games with mipmap lines in them.

When I had the R8500, I did like how it made a few games look better with anisotropic filtering, such as in Madden NFL 2002 where the far end of the field was a little clearer (lines were line across the field) as opposed with the GF3 I had at the time. That was one of the few game where it looked noticably better to me.

Edit: Typos.

[Livecoma]

Hmmmm.. I've been using the R200 for a few months now, and its anisotropic solution can be just as counter productive as it is productive.

Huh? What do you mean by counter productive?

Regards, LeStoffer

What Typedef said pretty much.

The mipmap lines and all the additional minor to moderate filtering artifacts I've observed while playing games. If I use one word to describe it I would say it is "dirty". Well not super dirty, but defiantly not clean.

NVIDIA's anisotropic filtering so far has suited my taste better then ATi's. That and perhaps the games I play are better geared towards NVIDIA cards. YMMV

Aside from all that, what have we always equated a lower performance hit for a particular feature with? Defiantly not BETTER IQ.

[Simon F]

The difference Mephisto, is that you don't lose any image quality with multisampling compared to supersampling as long as you are using anisotropic filtering. (well assuming you neglect or precheck alpha textures)

Well that's not strictly true. Perhaps I'm being a bit picky, but it's quite feasible, for example, that a polygon edge could run along a region of high rate of change in the texture. Ignoring the visibility information in the texture filter would thus give the wrong result.

[LeStoffer]

Just a quick question regards the AF on GF3/4:

What happens if you use, say, AF at 2x, and decrease (or is it increase) the LOD? Textures would be sharper, but would there also be a performance hit like in 4x or 8x?

It's a hack alright, but maybe worth it for some...

http://www.digit-life.com/articles/gf4/index6.html

Edit: Added link to digit-life who tried it but didn't benchmark the LOD change.

[rhink]

There would be a performance hit, and you'd introduce texture aliasing... which kinda defeats half the purpose of anisotropic filtering in the first place.

[Dave Baumann]

Adding silicon for ripmapping say on an Nvidia part would be ... questionable. Is the added heat/power cost/clock reduction/die space lost really worth it?

Would there even need to be any 'added silicon'? AFAIK Rip-mapping is basically using mip-mapping slightly differently - if you have hardware capable of automatically generating mip-maps then you could probably twist them to create the rip-maps(?).

[Nil Einne]

Could someone give me a screenshot which shows the ATI 8500 aniso banding problem at it's worth and a similar GF3/4 aniso shot?

Thanks (that review has a lot of shots!)

[Ante P]

PC Gamers took a screenshot of what they percived as the problem
http://w1.461.telia.com/~u46115957/PC%20GAMERS.jpg

I tried to reproduce it but I couldn't
http://w1.461.telia.com/~u46115957/ME.jpg

[Simon F]

I agree, using anisotropic filtering is like night and day in games, at least with NVIDIA's implementation. Not so sure about ATI's ripmapping. Personally just like playing games in 800x600, I'd rather stick bamboo shoots under my fingernails than play games with mipmap lines in them.

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.

Aniso' should improve the image where the projection of the texture causes it to be 'squashed' unevenly.

[MfA]

Ante ... try using the same resolution of the window and not downscaling the picture. If you include a picture make sure its one for which we dont have to believe you on your word :) If I downscale the PC gamer picture it looks fine too.

[Doomtrooper]

Anyone have the link for that little program, I can't remember who made it and the old forums are fading fast.

[Neeyik]

It was made by pcchen (sp?) and I've got it on my webspace...God help my bandwidth:

http://www.btinternet.com/~neeyik/files/mipmap_021.zip

Oh and if you use the following settings on a Radeon 8500:

Anisotropic Sampling
Linear Mipmap
Max Anisotropy Level = 16

You can see the aforementioned issue from PC Gamer.

[jb]

Ante P,

I took that image right when the program was released using the first set of beta drivers for the ATI 8500. As soon as the angle changes to near 45 like in that image, rip maping will drop back into bi-linear only. There was a nice thread on the old board in which Joe, Dave and others were able to orignally post this. I just verified it and upload it for my own benifit. Of course I have not re-looked at that with newer drivers so it may not be as bad now....

I also have that mirrored:
http://www.pc-gamers.net/jb/reviews/ati8500/mipmap.zip

For me I can see the mip lines, but in the games I play they are not that big of an eye sore. Just my own tastes...

[Neeyik]

Using the 9021 (Radeon 8500) drivers for WinME and with the settings listed above in full screen:

Flat
http://www.btinternet.com/~neeyik/comparison/flat.jpg


45 degree rotation
http://www.btinternet.com/~neeyik/comparison/45degree.jpg


Sorry for the picture size but it's the best way to see this!

[Doomtrooper]

Thx for hosting the file Neeyik I deleted lots of goodies by accident doing some house cleaning a while back :roll:

[Doomtrooper]

Thomas,

I tried getting the road to rotate with WinXP ICD 6043 Rev 2 and unless my computer is so fast the and road is rotating at Warp 10 its :

1) Not working in WinXP
2) I still haven't woke up

:P

[Matt]

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.

http://www.3dgpu.com/misc_images/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.

[Typedef Enum]

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...)

[pcchen]

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 :)

[rhink]

pcchen, I don't think it's an XP related issue... the demo works just fine on XP using my GF3 Ti200.

[Bambers]

When I first d/led it a month ago it wouldnt rotate (98SE). I tried it today and it works fine. :-?

[pcchen]

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.

[Althornin]

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?

[Livecoma]

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?

[nggalai]

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.cfm?catid=3&threadid=1692&highlight_ke y=y&keyword1=mipmap

The image was provided by Neeyik: trilinear Filtering on R8500 (http://www.btinternet.com/~neeyik/comparison/radeon8500_trilinear.jpg)

ta,
.rb
________
strawberry cough (http://trichomes.org/marijuana-strains/deep-chunk-x-strawberry-cough/deep-chunk-x-strawberry-cough)

[Doomtrooper]

The newer official and leaked drivers have fixed that issue, link below has lots of shots with different games and you can see the transition looks much better.

http://photos.yahoo.com/bc/beagz2001/lst?.dir=/My+Photos/trilinear+comparison&.src=ph&.order=&.view=t&.done =http%3a//photos.yahoo.com/bc/beagz2001/lst%3f.dir=/My%2bPhotos%26.src=ph%26.view=t

[Neeyik]

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" :wink::

http://www.btinternet.com/~neeyik/comparison/trilinear_new_mipcolor.jpg

[nggalai]

Excellent! Thanks for the update, Neeyik. :)

ta,
.rb
________
SL90 (http://www.cyclechaos.com/wiki/Honda_SL90)

[nggalai]

And: nice comparative screenshots, Doom. Might come in handy.

*bows*

ta,
.rb
________
free wordpress themes (http://themesfree.org)

[darkblu]

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.

[jb]

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.

[Randell]

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?

[pcchen]

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.

[Althornin]

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:
http://swc2.hccs.cc.tx.us/evan/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

[Humus]

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? :-?

[Dave Baumann]

I'd imagine the hardware will generate the mipmaps itself.

[rhink]

hmm.... well, in case the user supplies the mipmaps, why wouldn't they just generate the rip maps from each new mip level? You've got the 256x256 original, so generate your 256 texel wide rip maps from that, generate your 128 texel rip maps from the 128x128, and so on...

[Dave Baumann]

There's no actual guarantees that the supplies mip-level's will be a precise filter - it's probably best to generate the ripmaps directly from the texture to ensure there's no errors.

Plus, the rip-map is only filtering in one direction, wheras pre-supplied mip maps would already be filtered in two.

[Bambers]

Darkblu is right, throughout the entire rotation of the road the textures are lined up perfectly for rip mapping. In fact ATIs implementation is even fine at angles where the u,v directions of the texture are at 45 to the screen.

Look:

http://www.jamesbambury.pwp.blueyonder.co.uk/q3aniso.jpg

Note missing ammo box as proof of being taken on an 8500 :-?

That shot is anisoed very nicely even directly ahead where the texture is at 45 degrees, the reason atis implementation (and the one at sgi) goes wrong (regardless of the texture orientation) at the 45 degrees of the road demo is because they use the screen axis to detect the ratio of the texture needed not the true derivative axes.

When the road is at 45 degrees then the u and v texture distance covered by the height and width of the pixel will all be the same. With only this limited detection system there is no way to tell with the result above whether the suface is parallel or at an angle to the screen plane so normal mip maps are used.

For games like q3 and most other FPS then (apart from atis lack of trilinear noticable on a few textures) you'd find it difficult to tell atis aniso from nvidias.

[Humus]

hmm.... well, in case the user supplies the mipmaps, why wouldn't they just generate the rip maps from each new mip level? You've got the 256x256 original, so generate your 256 texel wide rip maps from that, generate your 128 texel rip maps from the 128x128, and so on...

Well, if the app provides the 256x256, 128x128, 64x64 ect, where would the driver get for instance the 256x128 level from? With you method the only mipmap level that would make sense is the 256x256 level. For the 256x64 you'd still need to downsample it from the 256x256, this goes down even to 256x1, which means only the base mipmap level is used. But if this is what's done then color mipmapping wouldn't work, but obviously it does as seen in Q3 and SS etc, so it cannot be handled this way. The way I see it this must mean that it cannot be using ripmapping, but something similar that uses normal mipmap levels.

[pcchen]

Yeah. From the screenshots provided by Bambers, it does not look like ripmap.

So it is possible that R200 does not use ripmap, but has some strange restriction on kernel shape, perhaps it only handles rectangular shapes well (the screenshots provided by Bambers has most footprint shape as rectangle or trapezoids, but the rotated "road texture" program has most footprint shape as diamond).

Another possiblity is scanline based LOD selection, which exhibits similar results.

[Doomtrooper]

So what are we saying here, that the 8500 is not doing rip-mapping ??

If its not doing rip-mapping whats it doing :-?

[Livecoma]

Would be nice if somebody from ATi could give us the final answer on this!

Atleast one person who frequents this forum works for ATi. Come on time to spill the beans ATi people! :D

[MikeC]

I would be interested to see how anisotropic filtering on the Radeon 8500 renders the target area in Scene 2:

Scene 1:
http://www.nvnews.net/previews/geforce4/images/page_3/position_1.jpg

Scene 2:
http://www.nvnews.net/previews/geforce4/images/page_3/position_2.jpg

Target area in Scene 2:

Trilinear:
http://www.nvnews.net/previews/geforce4/images/page_3/trilinear_angle.jpg

2X Anisotropic:
http://www.nvnews.net/previews/geforce4/images/page_3/2x_anisotropic_angle.jpg

4X Anisotropic:
http://www.nvnews.net/previews/geforce4/images/page_3/4x_anisotropic_angle.jpg

[Sharkfood]

Here ya go:
http://shark_food.tripod.com/aniso/quake3.html

[Ante P]

Here ya go:
http://shark_food.tripod.com/aniso/quake3.html

doesn't work

[Dave Baumann]

Its fine here.

[Mintmaster]

Darkblu is right, throughout the entire rotation of the road the textures are lined up perfectly for rip mapping. In fact ATIs implementation is even fine at angles where the u,v directions of the texture are at 45 to the screen.

Look:

http://www.jamesbambury.pwp.blueyonder.co.uk/q3aniso.jpg

Note missing ammo box as proof of being taken on an 8500 :-?

That shot is anisoed very nicely even directly ahead where the texture is at 45 degrees, the reason atis implementation (and the one at sgi) goes wrong (regardless of the texture orientation) at the 45 degrees of the road demo is because they use the screen axis to detect the ratio of the texture needed not the true derivative axes.

When the road is at 45 degrees then the u and v texture distance covered by the height and width of the pixel will all be the same. With only this limited detection system there is no way to tell with the result above whether the suface is parallel or at an angle to the screen plane so normal mip maps are used.

For games like q3 and most other FPS then (apart from atis lack of trilinear noticable on a few textures) you'd find it difficult to tell atis aniso from nvidias.

I noticed this two, and that's why I was very skeptical that ATI did rip-mapping. I also have a semi-confirmation that ATI walks along the texture rather than pre-filter it like rip-mapping does. The very strange thing is the 45-degree angle thing on the camera roll axis.

[Mintmaster]

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.

I totally agree with this. The 45-degree rolled shot should have no effect on the texture mip-map or aniso decisions whatsoever. Whether rip-mapping is used or true anisotropic filtering is used, the roll axis should be fine. What could possibly be causing this? You're probably right in the way you say that the du, dv, dx, and dy quantities and ratios are not considered properly by the R200 hardware.

The good thing is that nearly all games use vertical or horizontal surfaces for the objects that really need anistropic filtering. Even though there isn't trilinear filtering, I think ATI's method makes the mip-map boundaries mostly unnoticeable because the mip-map are just downsampled textures anyways, so you can calculate the texel for the next mip-map by just sampling the current texture in adjacent places. It's not even close to the mip-map problem you get with bilinear filtering on its own.

[Basic]

OpenGL texture minification for nearest/bilinear/trilinear filtering works like this:

(u, v) = texture cordinates
(x, y) = screen coordinates

(I omitted some scaling.)

rho = max( sqrt((du/dx)^2+(dv/dx)^2), sqrt((du/dy)^2+(dv/dy)^2) )
lambda = log2(rho)

Rho and lambda is calculated per pixel. But aproximations that are less computationally expensive is alowed. The integer part of lamda+K is used for mipmap selection, and the fractional part for weighting the two mipmaps in trilinear. (I don't care to describe exactly what K is, it's just a small constant.)

One 'natural' way to extend that idea for anisotropic filtering would be to calc another value (I just changed a 'max' to 'min'):

rho2 = min( sqrt((du/dx)^2+(dv/dx)^2), sqrt((du/dy)^2+(dv/dy)^2) )
lambda2 = log2(rho2)

Use lambda2 for mipmap selection, and rho/rho2 is the level of anisotropy.

Too bad that it doesn't work in all angles. It gives the same kind of errors that is shown in this thread. But I'd guess that this is what is done, possibly with some aproximation of sqrt((du/d*)^2+(dv/d*)^2).

What should be done is to set rho and rho2 to the large respectively small absolute values of the eigenvalues to the matrix:
[ du/dx du/dy ]
[ dv/dx dv/dy ]

While I understand that they don't want to do it exactly that way, I still hope they can find a better aproximation than what they use now.

[Nil Einne]

I've you're having probs with sharkfood try refreshing the pictures until they work. Worked for me :-) Or maybe download the pictures manually.

Have to say that the Sharkfood's Radeon 8500 seems better at both 2x and 4x and trilinear altho it's hard to be sure with one small picture....

[MikeC]

Here ya go:
http://shark_food.tripod.com/aniso/quake3.html

Thanks for the pics Shark. Was expecting a difference, but it goes to show you that I still don't know jack about anisotropic filtering :) After closer examination, I noticed that the Radeon pics are "sharper" than the GeForce4 pics (although I've yet to experiment with the GeForce4's LOD settings).

[Basic]

MikeC:
Were you expecting some bluring like on the road in the texture filtering demo? The difference here is that one of the screen axises (y) is paralell to a texture axis that isn't compressed a lot. So if I may refer to my previous post, you still got a rho2 that is significantly smaller than rho.

Furthermore, if you're looking for bluriness in the vertical lines above the fire, then you're looking at lines that goes in the wrong direction to reveal errors from lack of anisotropy.

[jb]

But it does go to show you be it rip mapping or what not, its better than nothing :) And pretty darn good in some cases

[MikeC]

MikeC:
Were you expecting some bluring like on the road in the texture filtering demo?

Yes. But I'll have to read this thread closely to determine why.

The difference here is that one of the screen axises (y) is paralell to a texture axis that isn't compressed a lot. So if I may refer to my previous post, you still got a rho2 that is significantly smaller than rho.

Now I know why I decided not to pursue a major in math after taking linear algebra :)

If I may ask, how were you able to determine "that one of the screen axises (y) is paralell to a texture axis that isn't compressed a lot." Was it a result of looking at the image or was there some other underlying methodology? How would the scene have to change in order to see the differences in the anisotropic filtering methods?

[Bambers]

To find a visible difference in aniso methods between the 8500 and gf3/4 you need no stand next to a wall, look straight up and turn so that the wall is going diagonally across the screen. The orientation of the texture makes no difference.

[Basic]

Now I know why I decided not to pursue a major in math after taking linear algebra.

You should think the opposite way. With that major in math, you would have understod how simple it realy is. :)


Everything is much clearer if you understand the meaning of what I wrote in my first post, so I'll give a more geometrical explanation.

Imagine that you project the screen pixel grid back to the texture (yes, that's backwards), then Lx=sqrt((du/dx)^2+(dv/dx)^2) (that occured a few times in my first post) will be the length of the side of a pixel in texture space.
Ly=sqrt((du/dy)^2+(dv/dy)^2) is the length of the other side. If you don't like the maths, just think of it as this projection instead.

The idea is now to select a small enough mipmap that the back projected pixel only cover one texel. Let's give some examples of how the back projected pixels look in texture space:
http://hem.passagen.se/basic3/fora/beyond3d/antialiasingstretch.gif
If there's problem loading the image, try this:
http://hem.passagen.se/basic3/fora/beyond3d/antialiasingstretch.gif

The quad represent one pixel, Lx and Ly are the lengths of the red arrows at the quads edges.

The first image could be from pcchens filtering demo when looking at the road in a 'good' angle. Notice that Lx is small and Ly large => the algorithm understand that it can use a high anisotropy. Also notice that the pixel is extended along one of the textures coordinate axises => rip-mapping is possible.

The second image could be from the 45º rotated view. This time both Lx and Ly are large even though the projected pixel is quite stretched => the algorithm fails to detect the anisotropy. Also notice that the pixel is still stretched along one of the texture coordinates => if a better algorithm to detect the anisotropy were used, rip-mapping would still work.

The third image could be from Bambers example far away on the ground. Lx is small and Ly large => the algorithm understands the high anisotropy. But the pixel is stretched diagonaly wrt the texture coordinates => rip-mapping wouldn't work.

The fourth image is from the area above the fire in your example. (The methodology was to look at the image, and imagine a back projected pixel.) Same conclusion as for image three (except that Lx is large and Ly is small). And as Bambers just hinted, I should've used a different formulation on what you quoted. As soon as we've seen that rip-mapping isn't used, the texture orientation doesn't matter.


In short, if you want to see:
if it's rip-mapping or not, compare case one and three.
if they detect anisotropy in a good way, compare case one and two.

In any case, the effects are most visible if the texture has lines in the same direction as the pixels are stretched, or in other words away from you.

Edit:
Some problems with the image.

[Doomtrooper]

Basic,

Bambers posted a shot on the previous page that shows Ripmapping might not be what the 8500 is doing, what are your thoughts on this. I know ATI uses some form of Adaptive Anistropic so is this the result were seeing here ?

[Basic]

I believe that rip-mapping is a hack that is rather useless except when you're guaranteed to look in one direction. This could work for the road in a driving sim, or the runway in a flight sim. But in more free environments, it wouldn't help that much.

The picture Bambers posted looked like there was no rip-mapping, but it wasn't a very high contrast texture. It would be easier to see if the floor texture had bright lines runing 45º against the texture axises, and then view it along those lines.

My first idea about what ATI was doing (long time ago) was that they do some similar sampling to what nVidia does. Taking multiple bilinear samples along the texture in the direction the pixel is stretched. (Nvidia can of course make trilinear samples instead.) But maybe sampling to sparse, and that way get the speedup and lesser quality.

But I've only got a GF2, and haven't looked much into it. (And don't think I've got time to do it either.)

[Althornin]

I still dont see why that shot denies the possibility of rip-mapping.

[Basic]

Althorin:
To quote what someone said earlier in this thread :lol: :
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.


Only problem was that the quote were refering to angles in wrong coordinate system. The planes angle relative the screen axises aren't important wrt if rip-mapping works well. The important angle is between the direction a projected pixel is stretched and the texture axises.

The ground in Bambers image were viewed in the bad angle for rip-mapping, but still looked rather good. Or did you mean that you don't think it looks good? Then I agree that it would be clearer with a texture with better contrasts.

[Ante P]

still can't access that tripod page
direct links to the pics or mirros would be GREAT :)

[Ichneumon]

To find a visible difference in aniso methods between the 8500 and gf3/4 you need no stand next to a wall, look straight up and turn so that the wall is going diagonally across the screen. The orientation of the texture makes no difference.

hehe... now, i dunno if that was said in jest or not, but if it was meant seriously, then all I have to say is.... I'll take ATI's implementation any day.

It takes less than 1/3 the speed hit vs. doing it the "proper" way as Nvidia does... and yet for the majority of cases it looks as good or better.

However, i'd temper that with the fact that I would like to have the Option to use the "proper" method if the performance hit wasn't prohibitive in a particular app. (my minimum resolution for game playing is 1024x768... even with really great AA, anything below that is unacceptable).

[Randell]

well if you can see Sharks pictures you can see (for that small section anyway) that the aniso is doing a great job and I concur with Nil, Shark's pictures look sharper at all degrees of aniso. This is Gf2 though rather than Gf3/4 aniso right?

[Neeyik]

Something has been puzzling me about the Radeon 8500s anisotropic filtering settings for a couple of days now...

In tweaking programs, such as Radeonator, you can set the level of filtering from 2x all the way up to 128x. It's generally assumed that the "64x" (for example) refers to the maximum number of samples taken, or in other words, number of taps.

The R200 doesn't do trilinear anisotropic filtering - if that's the case, then how does it do 128 or even 64 taps? The setting goes through the level of anisotropic samples yes? What is the maximum number of taps per ani sample it can take?

[Humus]

The 128x notation is not 128tap, it's a maximum level of anisotrophy of 128, the registry key in question is OGLMaxAnisotrophy. If implemented the nVidia way a 128x anisotrophy would be the same as 1024tap. The reality is that the Radeon supports up to 16x anisotrophy (not to be confused with 16tap), but when this key is set to something higher some driver trick kicks in. What the driver is doing though I don't know, but it does have an effect to turn it up to higher than 16.

[Nil Einne]

[quote=Bambers]To find a visible difference in aniso methods between the 8500 and gf3/4 you need no stand next to a wall, look straight up and turn so that the wall is going diagonally across the screen. The orientation of the texture makes no difference.

hehe... now, i dunno if that was said in jest or not, but if it was meant seriously, then all I have to say is.... I'll take ATI's implementation any day.

I think you're missing the point. This is the Ichneu's recommended way to look for the difference i.e. the easiest way that he/she knows of and probably the way that shows the difference the clearest. This does not mean you won't notice it in other cases, it's just that it might not be so clear or it may not be in all scenes or may only occur in a specific game or whatever. What I'm saying is it probably is noticeable in other games (especially non FPSes) to some extent (although how much is a debate which will probably never be solved).

If you still don't get it go look at my artifacts post. You will see lots of suggestions which involve running the card for a very long period of time. Normally, I'm unlikely to ever to this however these method are probably the simplest and easiest way and would produce the most visible artifacts. If I had to go to such extremese to get artifacts, I wouldn't worry but the fact is I don't have to. I will likely get artifacts in other cases but they may not be so noticeble. When I'm overclocking my card, I generally want a way which is easy and virtually guaranteed to produce the desired results...

[Randell]

Nil. I dont see the link here. We are talking about aniso quality, what has that to do with artifacts generated by heat & overclocking?

[Neeyik]

Humus - just to clarify with what you are referring to what you say "level of anisotropy". Is this just a driver setting a la NVIDIA (eg. level 8 is 64-tap anisotropic trilinear filtering) figure or is it an actual measurement of the amount of anisotropy?

Do you have any more information concerning the number of sample points taken during anisotropic filtering on the R200? You mentioned the change after 16x - what this be an alteration of the sampling pattern and/or number of samples taken?

Edit: something else I've just thought of Humus, since the R200 can't do trilinear anisotropic filtering, if the card does the setting the same way as a NVIDIA card does, then it would only be 512 taps and not 1024.

[Humus]

"Level of anisotrophy" is the ratio length/width of the sampling window, it should be selected by hardware on a perpixel basis but is constrained by a maximum level of anisotrophy which can either be set by the application or by the user in the driver, in this case by setting a value to the OGLMaxAnisotrophy setting. With a level of anisotrophy of 2 you thus get a 2x4 sampling window, that's 8tap, or 16tap with trilinear. Because of this and since the level of anisotrophy varies per pixel the tap notation doesn't really make any sense. The only real measurement of anisotropic filtering is thus the maximum level of anisotrophy, even though it doesn't garantuee any kind of quality or implementation.

I don't know though how the 8500 does samples, nor do I know what driver trick kicks in after 16x, but some ATi guy confirmed some time ago that it was something done by the driver at least I think.

And yes, if it did it the same as nVidia cards, but still only did bilinear with anisotropic, then it would only be 512tap.

[Dave Baumann]

I don't know though how the 8500 does samples, nor do I know what driver trick kicks in after 16x, but some ATi guy confirmed some time ago that it was something done by the driver at least I think.

In Serious Sam the 32/64/128 levels are visible, but if any of them are selected and applied it drops back to 16x.

[Humus]

Yeah, if you ask the driver what maximum level of anisotrophy it supports it'll say 16. I'm certain that if you try to set it to anything above 16 and then query the current value it'll still say 16, even if any driver tricks have kicked in.

[jb]

Well not like I want to kick a dead horse but saw something in SS:SE last night that reminded me of the program that we use to look at the rip mapping. Any ways check these out:


No rotation:
http://www.pc-gamers.net/jb/reviews/SSSE/ScreenShots/ansi_norot_SSSE.jpg

Then when the floor moved:
http://www.pc-gamers.net/jb/reviews/SSSE/ScreenShots/ansi_rot_SSSE.jpg

And yes I was too much of a Nacy boy to stay on the moving platform so I when to the door and fought them there. Not 100% sure of the level but its one at the first part of SS:SE...

Anyways I noticed it going nice, blurry, nice, blury just like in that texture filtering demo :)

[Sharkfood]

Good example jb

I found that map. Anyone wishing to try this, load up SS:SE, One Player, Custom level and load "The Pit"- the rotating floor level is about 6 or 7 rooms past the level begin in the water (just set 'please god' and chainsaw your way through). It's the room right after the bouncy headbomber room.

It appears to be the same with D3D as well as OGL.

[jb]

Yea just thought it was neat. Again I would perfer it to stay clear all the time, but its good enough for me until the next gen comes around :)

[noko]

Yes that was a good example, on my GF3 the floor stays sharp all the time. I hope ATI finds a better method in the future without the performance hit that the Nvidia cards have.

[Randell]

Shark or JB, as I dont have the full version of SS:SE, only the demo, I cannot verify this. Someone at Rage3d is suggesting that that issue iro angled surfaces on the 8500 has been fixed.

Can anybody test with latest drivers?

[Bambers]

Well I don't have SS either but it still there in the road test and in q3 on the 9026 drivers.

[jb]

I have the 6058 on win2k and sorry to say its still there. I will post screenies if you want to see em. Sorry was hoping it would have been fixed...

[Randell]

I beleive you, dont worry about posting screenies.

Damn :evil:

[jb]

You had me all excited that we might have found a fix. oh well :)

[Randell]

yeah sorry about that. Flexy (dont know his credentials) said on seeing your pictures posted at Rage3d, that that issue had been fixed. As the new drivers fixed a few things (e.g. those openGL extensions in win9x that stopped Humus's demo's running), I there may be some truth in the statement.