So is ATI's aniso method rip-mapping or not?

I've read a lot on this board...and accordingly the r200 anisotropic method is based on rip-mapping and there have been posts and little gifs and programs about it as such...
Though this is from Hardocp latest gf4 4200 review

~When we apply Anisotropic filtering it goes a long way to improve the image quality, but also goes a long way to decrease performance. The first thing you will notice is how well ATI's cards are doing with Anisotropic enabled. It's important to note that ATI is not doing "True" Anisotropic filtering. The ATI cards are using a method known as Rip-Mapping which is not as accurate as a true Anisotropic renderer.

(editor's note: "Rip-mapping" is the not the technique used as stated above. Here is a statement from ATi with some very good information that dispel the rip-mapping myths. Sorry for adding to the confusion that is already there.)

I was just reading through your recent GeForce4 Ti4200 preview. On page 2 under the Serious Sam benchmarks you mention that the RADEON 8500/8500LE "are using a method known as Rip-Mapping which is not as accurate as a true Anisotropic renderer." Despite what you may have heard, this is not true. The RADEON 8500 & 7500 products use true anisotropic filtering, not rip-mapping. They achieve the high performance they do with AF because they have the unique ability to dynamically select the number of texture samples taken for each pixel. Thus, pixels that would get no visual benefit from AF use only a single bilinear texture sample, while those that are at very sharp angles and would get the most benefit can use up to 16 bilinear samples (in 16x mode). Since 16x samples requires 16x bandwidth, and only a small fraction of the pixels on the screen ever require this many samples, the RADEON products can offer the full visual quality improvement with almost no performance hit.

David Nalasco
Technology Marketing Manager
Desktop Business Unit
ATi Technologies Inc.

This sounds like they state that it is some sort of adaptive anisotropic?
So what's the actual truth...as this being that it's from their marketing manager...is it PR BS* or is their anisotropic method in actuality-adaptive on the fly
 
"True" AF should be usuable with trilinear filtering enabled. The Radeon-AF apply the filtering only in X or Y-direction. This is RIP-Mapping. May be they dont call it "RIP-Mapping" because it's not a trademark by ATI :)

The performance hit is so small because they take 4 texels for each pixel. Every AF implementation is dynamic and dont use the maximum amout of texels in every case yet, only if its needet.

edit: It is possible to confirm or deny the RIP-Mapping-Theory: You need a texture with a texelwise checker-pattern. (Every "checkerfield" is only 1 texel!)
A (linear filtered) RIP-Map has no checker-pattern anymore.

"True" unidirectional bilinear AF shows some more details than RIP-Mapping.
 
Tygrus_Artesiaoa said:
They achieve the high performance they do with AF because they have the unique ability to dynamically select the number of texture samples taken for each pixel.
LOL, in how far would that be "unique"? Considering only ATI products...?
 
aths said:
"True" AF should be usuable with trilinear filtering enabled. The Radeon-AF apply the filtering only in X or Y-direction. This is RIP-Mapping. May be they dont call it "RIP-Mapping" because it's not a trademark by ATI :)

The performance hit is so small because they take 4 texels for each pixel. Every AF implementation is dynamic and dont use the maximum amout of texels in every case yet, only if its needet.

Actually, you're wrong. ATI applies the filtering in all directions. I have made a program with a star texture (many intersecting lines at various angles) and all lines get filtered correctly. ATI cards have the ability to do proper anisotropic filtering, and don't do rip-mapping.

However, they do have a problem in determining WHEN it should be used. If the polygon is at a 45 degree angle to the screen on the roll axis (not the alignment of the texture as in rip-mapping), then there is a problem. This is not a symptom associated with rip-mapping, but an oversight in their calculation of anisotropy.

As for using trilinear, they probably did not implement AF with the ability to take samples from two textures (or mip-maps) simultaneously. If the speed issue is only due to the lack of trilinear with ATI, why doesn't NVidia just disable the trilinear from their AF? Chances are that it wouldn't do much for NVidia, as they can do trilinear samples fine, but struggle with extra anisotropic samples.

ATI probably has the ability to take extra samples for anisotropy in exchange for the second mip-map samples used in trilinear filtering. This may be part of what they mean by 'dynamic', as they are using the texture sampling silicon that is normally used in trilinear, but for AF instead

Besides, on most textures the bilinear mipmap transitions are hardly noticeable anyway with AF on. Why? A mip map is just a downsampled texture. If ATI takes up to 16 texture samples, they will have a similar blend to the result you get with blending samples from two mip-maps in trilinear filtering.
 
There is not only a problem at 45 degree.

The quality grows while the angle is goto 90° and get more worse while it goes to 45°. In fact at 45° its only bilinear mipmapping. Of course the texture is filtered correctly, but in the near of 45° its very blurry, while no longer AF effects. The Radeon is not able to filter anisotropic in 45 degree direction. (Or this feature is not enabled yet.)
 
Yes because of the way it detects the aniso needed, not becuase of the aniso it uses.

From the results it gives I think that the 8500 takes four measurements from each pixel to work out the anisotropy needed.

1. The u distance on the texture covered by the width of the pixel
2. The v distance """"
3. The u distance covered by the height of the pixel
4. The v distance """"

For something like the floor in a game then this works fine:

If the texture coordinates are lined up with the veiwer then:

2 and 3 are zero, 1 is small and 4 is large so anisotropy is used

If the texture coords are at 45 degrees then 1 and 2 are small but 3 and 4 are large so anisotropy is still used.

The problem comes when the plane is angled. As the camera is rolled then the differences between the values become smaller and so ess anisotropy is used even though it is actually needed.

At 45 degrees then regardless of the orientation of the texture then 1,2,3 and 4 are all the same, no anisotropy is detected so none is used.

I'm fairly sure you can force the gf3 and 4 into using bilinear aniso.

My gf1 certainly could and it still took a noticable performance hit considering it was only doing 2x aniso.
 
aths said:
There is not only a problem at 45 degree.

The quality grows while the angle is goto 90° and get more worse while it goes to 45°. In fact at 45° its only bilinear mipmapping. Of course the texture is filtered correctly, but in the near of 45° its very blurry, while no longer AF effects. The Radeon is not able to filter anisotropic in 45 degree direction. (Or this feature is not enabled yet.)

Yes I know, that's what I meant by 45 degrees. Perfect at right angles, nothing at 45 degrees, and a blend of the two inbetween.

Still, these are are angles of the polygon on the camera roll axis. Rip-mapping has problems when you don't look along the texture axes (generally called U and V axes, not X and Y like you called them), and its worst at 45 degrees to the texture axes. ATI cards don't have this problem - the texture is filtered anisotropically no matter what direction you look at the texture, provided the texture is horizontal or vertical. The problem arises when the polygon that the texture is on is not horizontal or vertical, but its normal lies at an angle to both of the coordinate screen axes.

There is a discussion about this in another thread. We've established that it is not rip-mapping, but a problem in how ATI determines what to apply anisotropic filtering to.

http://216.12.218.25/domain/www.beyond3d.com/forum/viewtopic.php?t=564[/url]
 
Bambers,

I thought your Quake 3 shot showed ripmapping was not being used at the 45 degree angle on the floor. Possibly posting that shot would prove that point.
 
Mintmaster,

in my opinion there is an easy way to check if it is RIP-Mapping or not. Easely look, if the Radeon uses RIP-Maps :)

A Texel-by-Texel-Checkerboard (black and white) RIP-filtered should be gray - without any pattern.
 
aths said:
Mintmaster,

in my opinion there is an easy way to check if it is RIP-Mapping or not. Easely look, if the Radeon uses RIP-Maps :)

A Texel-by-Texel-Checkerboard (black and white) RIP-filtered should be gray - without any pattern.

The problem is that even normal mip-maps would wind up being gray once they are created, so it doesn't matter what method you use. You average all texels in a 2x2 block to get a texel in the next mip-map, so a checkerboard pattern would give you gray. Even Nvidia cards would be going all gray. Unless, of course, you mean the same texel-by-texel checkerboard pattern for all mip-maps, but you would get a screwed up image then since the mip-maps wouldn't correspond with each other.

The star pattern is best. If it is rip-mapped, the lines of the star that aren't aligned with the U or V axes would look just like bilinear filtering, and blur. However, I told you they don't. I'll try to find some web space to show you some screenshots.
 
Mintmaster,

hm, you are right: Mipmaps are also gray (next time I should think twice before posting :))
 
Hmm...this caused a bit of ruckus at hardocp

So all in all...it is anisotropic that just screwed in some senses...doesn't do tri when aniso though NV can...which
then explains why there performance doesn't go down as much...
and I won't even get into the level/ how many taps it can go as that gets really confusing...
?
 
I've added a shot without aniso to show the difference:

Without aniso:
q3noaniso.jpg


and with:
q3aniso.jpg


The second shot is clearly more detailed (although the texture used wasnt the best) so the 8500 does do aniso at 45 degrees to the u and v axes.
 
Hi Bambers,

thanks for the screenshots. :)

Question: do you have any idea what's going on in the SS:SE screenshots posted by jb, here?

ta,
.rb
________
XV700
 
Last edited by a moderator:
The screenshots in the other thread show the weakness of the way the 8500 detects the anisotropy needed.

I think it works as I've said in my first post in this thread. This is the 3rd case where all 4 values it takes are the same so it does not detect any need for anisotropy and just uses bilinear filtering.
 
Thanks for the shots, Bambers.
Could you please do the same shots with color mipmaps on?
 
Yeah colour mipmaps would be great for those sorts of screenshots. You don't need to see the detail to see if the anisotropic filtering is working then.

Regardless is seems to be that anisotropic is working in that second shot.
 
Colourless said:
Yeah colour mipmaps would be great for those sorts of screenshots. You don't need to see the detail to see if the anisotropic filtering is working then.

Regardless is seems to be that anisotropic is working in that second shot.

Ok sorry for this question, but what do you hope to see with the color maps on? Alls I have noticed is that it pushes the mip map back. Also with ATI's Ansio you will not see any trilnear :

Here are some older screen shots I took with SS:FE:

http://www.pc-gamers.net/jb/reviews/ati8500/sstri_waniso.jpg

http://www.pc-gamers.net/jb/reviews/ati8500/sstri_waniso1.jpg

Again I was just wondering what to look for...

Thanks
 
Colour mipmaps will show if anisotropic was actually working or not. If it was not working that mipmaps would be closer in. When it's working they are pushed further back.

The 45 degree case when anisptropic is enabled where things don't work will have same mipmaps being used as bilinear at the same place.
 
Back
Top