Which way to optimize? Aniso vs FSAA

[Fred]

I'm curious, assuming there was tradeoffs to be made, which would you choose

1) Optimization for Anisotropic filtering alone, at the expense of FSAA performance

2) Optimization for FSAA at the expense of Afiltering

3) optimization for the combo of Afiltering and FSAA, but at the expense of both individually and possibly rendering w/0 either.

 

[lurtz]

personally I am an AF man. Jaggies don't bother me zdn I like to see the textures (that's what high-end graphics are about right?).

Just MHO.

 

[John Reynolds]

Depends on the game. If it's a shooter, I prefer AF. If it's a game like Freedom Force, I prefer good AA.

 

[Doomtrooper]

AF + High Rez

 

[Ailuros]

I don't think that question can be answered that easily without ignoring the differences in implementation or algorithms in today's hardware.

I personally -if it would come to "tradeoffs"- prefer high quality/high sample adaptive algorithms, where you can combine High resolutions, High sample antialiasing and High sample anisotropic filtering. Difference being that said algorithms will not utilise X amount of samples while antialiasing, rather up to X amount of samples in a given scene (same for texture filtering), while at the same time saving large amounts of bandwidth .

 

[Sharkfood]

I dont want compromise.

If you can't hack it, make the board faster, wider, scalable- doesnt matter. Just make the damn thing work and make it work well.

We have $399 and $499 retail boards from the past years so I don't think the argument against price is valid anymore. A top-end card isn't meant to be mainstream and this market never has been.. except maybe 6-8 months down the road when they hit basement closeout prices for the next product line's release.

Bottom line is- what I've seen on 600mtex/s fillrate and low-bandwidth cards in the past few years was almost playable in lots of things with outstanding AA. I find it hard to believe that now that bandwidth has increased 4x and fillrate is good and high that the same architecture but with faster components can't be fab'd and released.

 

[KimB]

Both should most certainly be used at the same time, in any game. There's just no excuse to have to run without either.

 

[Pete]

I can't believe someone actually commisioned an article on so asinine a topic. I want both, and as video card speeds increase, I'll have them both. But, for now, I'd settle for aniso + high res.

 

[Jerry Cornelius]

You do both at the same time, it's really the same problem, the nature of the triangle causing aliasing. I see no reason for advanced filtering on edge pixels.

Given that hardware hasn't been able to do both (or either in some cases) at any kind of speed untill recently, i really don't see why no one produced quick AA methods. After all it's called Anti Aliasing, not Perfect Reproduction. It's still an approximate science, so why bother with excessive integrety that will never be used.

You take 2 or 3 (bilinear) samples with some degree of anisotropy, maybe from different mip levels based on a crude but effecient algorythm. If you hit an edge, you snag some samples from the framebuffer and blend them using all the information you have at hand. Sure it wouldn't work for this situation or that situation or when this was the case. But it would have removed a lot of aliasing at a predictable speed, hence the term, Anti Aliasing.

Anyhow, I've had a few drinks so...[/i]

 

[KimB]

Which reminds me, I was just thinking of how Matrox' FAA worked, and something hit me.

It is entirely possible for Matrox to do the 16-sample FAA at very high speeds. What it would require is that instead of taking full 16-pixel subsamples, they could just take 16 point-samples. Since all fragment edges are pre-cached, it should be fairly simple to fully-use the texture filtering pipelines, allowing for all 16 samples to be done with just the cost of 4x SS.

I think that the method that Matrox uses will be borne out in the benchmarks when the Parhelia finally ships, but the method does seem more interesting to me now.

 

[Fred]

Guys, im not saying that a tradeoff implies not being able to play the unoptimized version (far from it).


The people who are saying 'well I want both' are avoiding the hard question, and likely the reality at some level (and it may very well be hidden). Witness how changing the LOD slider on the Geforce3 line effects performance. Well, very likely, that is b/c cache configuration is optimized for a specific ratio (something say more geared towards FSAA). This isn't a bad thing necessarily, we're only talkign about a few fps relative difference in that case.

It's just a matter of preference really, and serves to perhaps shed a little nuance on the whole 'my card does better than your card with this feature on, but not the other' rhetoric.

 

[KimB]

Witness how changing the LOD slider on the Geforce3 line effects performance. Well, very likely, that is b/c cache configuration is optimized for a specific ratio (something say more geared towards FSAA).

Anti-aliasing has no effect on texture rendering on a GeForce3/4.

The people who are saying 'well I want both' are avoiding the hard question,

What question is that? There's absolutely no reason to run without both enabled on a GeForce4, let alone next-gen hardware.

 

[Dave Baumann]

Anti-aliasing has no effect on texture rendering on a GeForce3/4.

Unless you are in 4xS mode. And, it will effect texturing at poly egdes, which can have quite a striking effect if you have plenty op poly's.

http://www.beyond3d.com/articles/wildcatiii/index.php?page=page8.inc

 

[KimB]

Even at poly edges, the hardware still deals with the textures in the same way.

And yes, 4xS does affect texturing slightly. The texture LOD is adjusted to compensate for the increased sample coverage.

This still doesn't change the fact that there is little correlation between texture caches and FSAA.

 

[Dave Baumann]

Even at poly edges, the hardware still deals with the textures in the same way.

Multiple texture samples need to be taken at poly edges. i.e. if the mulisample mask has 3 pixels covering one poly then is will use the texture sample from that, however for the one pixel thats from a different poly it will need to determin its colour hence it will need a texture sample.

 

[KimB]

I'm not entirely certain that the hardware does adjust its sampling pattern at polygon edges. Of course, there would definitely be texture clamping problems at polygon edges if they didn't make sure to keep from using texture samples outside the polygon, but those would be hidden by the fact that this only happens at poly edges.

Regardless, if the texture sampling is adjusted at poly edges, it's not going to make much difference.