[gking]

That seems to be what the 8500 is doing at the moment and only works optimally on horizontal and vertical surfaces

I wouldn't be so sure. If the 8500 is using the partial derivatives (which I'm not sure it does), it is ignoring the smaller component, which is why the 8500 only samples on lines parallel with U or V. Using all the components of the partial derivative would yield lines in texture space of any slope, not just along the principle axes.

Also, this system generalizes well for 3D and cubic textures, and the R200 can't do MIP mapping or anisotropic filtering on those.

dot product ends up being better in this case because you can automatically throw out back-facing surfaces.

The issue with the dot product is that while it should yield a value corresponding to the number of samples you need, it doesn't indicate the line of anisotropy. If you want to use dot products, you would probably be better off using the surface tangent and surface binormal vectors, rather than the surface normal, since T and B are (normally) defined relative to the U and V texture space axes.

umh, wouldn't forward-mapping through hyperbolic interpolation along the major and minor axes of the ellipse basically do the job?

You would still need to compute the weights for texels that aren't completely contained in the ellipse, if you want to do it properly, and that requires a whole lot more silicon than just taking the arithmetic mean of all samples.

[Althornin]

Originally Posted by arjan de lumens

Correction: the dot product will be 1 if the (unit) nomal vectors are parallel, and 0 when they are perpendicular. Also, this method only works when you are doing parallel projection, not when you are doing perspective division. To see why, consider the a scene where you are watching down a long corridor. In this scene, the (eye-space) normal vector to every wall/floor/ceiling is perpendicular to the normal vector of the screen, giving a dot product of 0, thus indicating erroneously that none of the walls/floor/ceiling of the corridor should be drawn at all.

Of course, you are right on the prallel/perpendicular thing. Stupid typo on my part.
As for the perspective issue - you arent understanding what i am saying - I mean the normal of the actual surface as it is displayed by the monitor - after perspective is already done on it. IE, in your long corridor example, those polygons are displayed not perpendicular to the screen, but already perspective corrected. If you use that surface as your basis for the normal, then it works fine.

[arjan de lumens]

Originally Posted by Althornin

Of course, you are right on the prallel/perpendicular thing. Stupid typo on my part.
As for the perspective issue - you arent understanding what i am saying - I mean the normal of the actual surface as it is displayed by the monitor - after perspective is already done on it. IE, in your long corridor example, those polygons are displayed not perpendicular to the screen, but already perspective corrected. If you use that surface as your basis for the normal, then it works fine.

Makes me wonder in what kind of space you would compute that normal vector. In the corridor example, the walls would come closer and closer to being perpendicular to the screen towards the far end of the corridor, so your normal vector would have to change across the surface of the wall from the near end to the far end of the corridor. Hmmm - how would you compute such a normal vector?

Also, the entire dot product method fails badly when used on a stretched or sheared texture map - in such a case, you should be doing anisotropic mapping even on a surface parallel to the screen for correct result, but the dot product method would tell you not to.

[Brutal Deluxe]

Comparing the shots I see the testure aliasing you guys pointed out, but my personal opinion is that the R8500 looks much better. It looks much more rich and vivid. Almost alive, while the GF one looks dead.

I see the same in Chalnoth's UT images, the showing testure aliasing looks much more alive. Actually its especially aparent on those. Check out the face of the small pillers on the right side. Especially the first one not covered by the gun. In my opinion it looks much better.

Why isnt there a comparison between Nvida and ATI both using 8x aniso? If that is what people say is causing the seemingly better detail on the RADEON shot, maybe it is also causing the aliasing.

And about what implementation being "right", I see no conclusive answer. I prefer the looks of the RADEON shots, in this case(I have neither card to try myself). And seeing that they also have ~5 times less perfomance hit, I would prefer buying a Radeon(its cheaper too).

[pcchen]

Texture aliasing is much less noticeable in static screenshots than in motion. Therefore, you need to see that in motion to decide whether method is better for you.

Personally I prefer GF3/4's anisotropic because Radeon 8500 have some problems with slope planes. Most games do not have too many slope planes, but flight simulators do.

IMHO the computation of anisotropic filtering will become better in future products. Many things in real-time 3D graphics have similar development. For an example, early 3D chips have no per-pixel mipmap, or wierd mipmap LOD selection. Now per-pixel mipmap is normal, and LOD selection is less wierd Some early 3D chips fake trilinear (linear_mipmap_linear) by dithering. Now it is rare. Therefore, I think when we have enough transistor budget and bandwidth, IHVs will implement good anisotropic filtering into their 3D chips.

[Mintmaster]

Originally Posted by gking

I wouldn't be so sure. If the 8500 is using the partial derivatives (which I'm not sure it does), it is ignoring the smaller component, which is why the 8500 only samples on lines parallel with U or V. Using all the components of the partial derivative would yield lines in texture space of any slope, not just along the principle axes.

I don't know how many times we have to go through this. ATI does NOT only sample parallel to U and V axes. That can be done with ripmapping, which ATI does NOT do. If you make a texture with a star shape (like *), each line is sharp, and there is no severe texture aliasing due to infinite LOD. ATI is sampling fine, they just can't figure out correctly where to sample.

Bamber's explanation is very good. Man, I think I should just make a damn program to show everybody ATI's sampling is NOT limited to lines along U and V. I know X-bit labs or Digit-Life (can't remember which) made an article on this, and I don't know where they got that BS from. Their animated GIF's that showed ATI's drawback were no proof of sampling along U and V only.

[Doomtrooper]

Yes I think its time to show some Canadian code ..make it a Maple Leaf
It would be nice to finally lay that same comment that seems to be brought up daily to rest once and for all...

[Chalnoth]

Originally Posted by Brutal Deluxe

I see the same in Chalnoth's UT images, the showing testure aliasing looks much more alive. Actually its especially aparent on those. Check out the face of the small pillers on the right side. Especially the first one not covered by the gun. In my opinion it looks much better.

This is exactly why I posted it.

The truth is, if you saw that shot in motion, you'd gack. It truly looks terrible.

Not only that, but (at least to me), the texture aliasing is not apparent in the least in that screenshot. It is for this reason that every time I see texture aliasing in a screen shot, I gack. It's just so hard to see in static images that I know I'll notice it when the shot is in motion.

[OpenGL guy]

Originally Posted by Chalnoth

The truth is, if you saw that shot in motion, you'd gack. It truly looks terrible.

"But at 60 fps, you'll never notice!" - paraphrase of some 3dfx dude


P.S. Don't ask me to comment on 8500's anisotropic: I don't know a thing about the implementation.

[Hellbinder]

Please....

I play multitudes of games with my Radeon 8500 and virtually always use 16x Aniso.... sometimes Ill use 2x Quality SV and 16x Aniso. I especially play UT and Half-life.. I just dont get the "horrid-shimmering" you are talking about. Perhaps becuase I play both with OpenGL. All this talk about FPS games.. and the occational mention of Flight sims..

1. Madden 2002 looks Fantastic with 16x Aniso turned on. Makes the Field and Stadium very smooth and detailed. You can even see the yards markers all the way to the goal line from the opposite endzone.

2. Star Trek Empires at War II. Looks flipping great. and you can play this game at 1024x768x32 with 4x Quality SV and 16x ansio..

3. Project entropa. 16x aniso makes the vast wide open terrain look fantastic.

4. Dungeon Siege 16x ansio looks fantastic, takes a very minimal hit.

5. Spider-Man the movie. very pretty game, looks fantastic with 16x aniso. this is a good test of aniso as you get some crazy wierd angles due to the wall crawling. Dont see any noticable issues or shimmering.

While I have indeed noticed some shimmering with one or two game demos i have downloaded, and perhaps a coupple other times.. It is simply not very often, or very bad. I have not noticed any since moving to the latest 6071 drivers. Neither have i ever walked upo to soem surface in a game and said.. EEEE GAD.. what the hell is with that non Aniso'd surface, it looks so horrible compared to the floor etc etc..

Apparently, you really have to be looking for it.

[Chalnoth]

I just have to say that just as with most visual artifacts, you often times don't notice them until you've played without them for a while.

Quick example:
When I had my GeForce DDR, I played at 1024x768x32 w/ no AA. Now that I've been playing at at least 2x FSAA in every game, it's immediately obvious to me even at 1600x1200 when AA is disabled.

Btw, one little thing, with those screenshots I posted earlier, I didn't mean to imply that I thought the Radeon shots were certainly indicative of very bad aliasing, just that screenshots can lie.

[SvP]

Chalnoth, do you absolutely have to reply to every post/opinion where is mentioned, that R8500 may actually look better to somebody? I guess we all already know what you think, you don't have to make posts like "maybe yes, but I prefer ..." 10 times a day to make your opinion heard.

C. and H., please don't ruin this thread 8)

[Chalnoth]

Hey, I gotta do something to give me an excuse not to study...

[Hellbinder]

SvP,

So basically the previous 4 pages of arguing back and forth regarding ansio are "ok". But if I post an opinion... or add a comment about someone elses.. then thats "ruining" a thread.....

Oh ok, At least now i understand how the game is played. I'll go ahead leave the endless bickering back and forth to the other members of the forum and just not get involved... 8)

[silent mode is now online]

[Brutal Deluxe]

Originally Posted by Chalnoth

Hey, I gotta do something to give me an excuse not to study...

Hehe same here, in 2 days I have the mother of all exams. "Compiler design". The exam that has never had a failing percentage under 70.

[DemoCoder]

You don't notice texture shimmering unless you know what its like to play with *rock solid* AA textures. It's like Star Wars on Film vs Star Wars on Digital Projection. Immediately, from the first frame on DLP, you notice the main difference between DLP and film: absolutely rock solid display, no jittering (from film projector), no flickering, no scratches.

Another example: travel to Europe or China and look at a TV at 50hz if you're used to NTSC. You instantly notice that every TV is flickering badly. Or, bump your monitor from 72Hz to 100+Hz on a good monitor, big difference. However, if've you never see different refresh rates, you're like a fish in water -- you were born in it and don't see it.

Hopefully, in the next year, people will be playing on cards with 128-tap filtering and 16XFSAA enabled (hopefully, with some jittering). I guarantee you that when they go back to the 8500 or GF3, they are going to see a big difference, althought right now, it may be hard to fathom how much different it will look.

[MfA]

Not every TV, theres a lot of em which use framerate up-conversion now :)

[Mintmaster]

Originally Posted by Doomtrooper

http://www.sgi.com/software/performe...isotropic.html

That SGI link describes rip-mapping. ATI doesn't do this. ATI's problem occurs as you approach a 45 degree roll angle in camera space. Rip-mapping's problem occurs when you look at a texture along a line approaching 45 degrees from the U and V axes of the texture. ATI walks along the texture just like you're supposed to.

Man, I don't know who started this rip-mapping fiasco, but Digit-Life made it wide-spread. In typical games, ATI's shortcoming in aniso probably only affects some 1-2% of on screen pixels, as there are very few surfaces rotated on the camera roll axis that need aniso. Ripmapping will cause noticeably incorrect anisotropic filtering of around 70% of those pixels that need the filtering, equalling around 10-20% of on screen pixels. ATI's method is a hell of a lot better than rip-mapping for sure.

I think this settles it. I'm going to make a small program like the one pcchen made, and hopefully someone can host it. I want to stop this rip-mapping myth.

[Doomtrooper]

Do it... :P

[Reverend]

Mintmaster, you can send your program (when it's done) to either me or Wavey.

[Chalnoth]

Originally Posted by Mintmaster

That SGI link describes rip-mapping. ATI doesn't do this. ATI's problem occurs as you approach a 45 degree roll angle in camera space. Rip-mapping's problem occurs when you look at a texture along a line approaching 45 degrees from the U and V axes of the texture. ATI walks along the texture just like you're supposed to.

I beg to differ. Given the obvious texture aliasing at the sides of the images posted before (Where the texture line would be at around 45 degrees to the U and V axes...), it does seem very probable that RIP mapping is what's going on. ATI's method just doesn't drop the LOD in those situations as it does for 45 degree rotated surfaces.

[arjan de lumens]

One issue with RIP-mapping is that, properly done, RIP-mapped texture maps take 3 times as much space as MIP-mapped texture maps. So if the ATI card uses RIP-mapping for Aniso (which I doubt, but don't know for certain), it should be rather easy to make it run out of texture memory.

[Chalnoth]

Originally Posted by arjan de lumens

One issue with RIP-mapping is that, properly done, RIP-mapped texture maps take 3 times as much space as MIP-mapped texture maps. So if the ATI card uses RIP-mapping for Aniso (which I doubt, but don't know for certain), it should be rather easy to make it run out of texture memory.

Well, the method discussed at the SGI site was primarily a software method. I don't see why ATI would need all of the asymetrical MIP maps...so, while this may not strictily be the software RIP mapping technique described at SGI's website, it certainly appears to have all of the same drawbacks (except, perhaps, for the increased texture memory requirement).

What I do find interesting is that that anisotropic implementation could apparently be done with any hardware that supports non-square textures.

[Althornin]

Originally Posted by Chalnoth

I beg to differ. Given the obvious texture aliasing at the sides of the images posted before (Where the texture line would be at around 45 degrees to the U and V axes...), it does seem very probable that RIP mapping is what's going on. ATI's method just doesn't drop the LOD in those situations as it does for 45 degree rotated surfaces.

Take an 8500. play any FPS game.
Look at the floor.
Rotate in a circle.
Does the teturing change at 45Degree incriments (indicative of ripmapping) - NO.
Ergo, it is not rip-mapping.

At first, when we all saw pcchens proggy, it looked as if it were doing rip-mapping. Later on, Bambers and mintmaster showed (using the above example) that it is NOT doing rip mapping.

[Chalnoth]

The better question is, does the amount of texture aliasing change at 45 degree increments? The only long-range texture shots I've seen have been looking at the textures along the u or v line of the texture.