Verite V1000 Antialiasing

[Reverend]

Well, it's obvious that Edge AA and today's AA are two different roads to take.

At the risk of stating the obvious :

Edge AA is not Full Scene AA.

As I said, I really like what the 9700 does. I just hope they continue to refine it. AA just makes games look so good, especially as the graphics quality increases. One can hardly see aliasing in Quake 1, but in new games, especially in 'slower' games such as space sims, AA makes a huge difference.

It is my experience that many, many developers choose to use really aggressive LODs for textures/MIPmaps where they think it helps the consumers to go "Gee, this game looks great... very detailed looking". That is both a necessary evil (on the part of the ISVs) as well as a headache (on the part of the IHVs). Don't you just hate the Nyquist rate.

 

[KimB]

Quick example:

Unreal 2 has a default LOD BIAS adjust of -0.5.

The aliasing in some places cleared up dramatically once I set it back to zero...

 

[andypski]

Quick example:

Unreal 2 has a default LOD BIAS adjust of -0.5.

The aliasing in some places cleared up dramatically once I set it back to zero...

As does UT2003. Not sure why they chose this as the default, but it causes aliasing so I set it back to zero. These days I always find myself checking .ini files on games to see if this sort of thing is going on.

 

[Reverend]

EA's racing games are the worst IMO... one of the NFS series (can't remember which one) uses -3.5

There's only so much IHVs can do

 

[andypski]

Quick example:

Unreal 2 has a default LOD BIAS adjust of -0.5.

The aliasing in some places cleared up dramatically once I set it back to zero...

As does UT2003. Not sure why they chose this as the default, but it causes aliasing so I set it back to zero. These days I always find myself checking .ini files on games to see if this sort of thing is going on.

I ought to clarify, before I get misunderstood - I mean I set it to 0 on my machine, not in the driver... :?

 

[Arun]

IMHO:
The future is in Fragment Antialiasing, as defined by nVidia.
And that's not to be confused with what Matrox calls Fragment Antialiasing

nVidia's definition is to use more sample points than colors.
4 colors & 16 ordered samples would certainly give higher quality than 6 colors & 6 rotated samples. And the memory bandwidth cost would likely be lower ( although it could cost very slightly more transistors )


Uttar

 

[arjan de lumens]

More sample points than colors produces glitches if the number of fragments for a pixel exceeds the allowed number of colors for that pixel (which can happen quickly if polygon sizes get too small). Of course, you can merge fragments, but not in a sort-independent manner.

16x ordered grid sounds a bit wasteful - on near horizontal/vertical edges, where aliasing is usually at its most noticeable, it will do a worse job than 6x rotated or sparse grids (3 gradients vs 5). 16x rotated or sparse grids will do a much better job at very little added cost, so why not do that?

 

[Heathen]

As does UT2003. Not sure why they chose this as the default, but it causes aliasing so I set it back to zero. These days I always find myself checking .ini files on games to see if this sort of thing is going on.

So what am I looking for in the ini file?

 

[demalion]

andy: By machine, do you mean ".ini" file? Your second phrasing actually seems more confusing to me than your first.

[completely non serious]
Hmm...I've always wondered if that apparent vowel deficiency might have some side effects...maybe you should research a supplement?
[/completely non serious]

Umm...should I go hide?

 

[KimB]

I hope nVidia finally does away with this ordered-grid stuff.

After all, nearly any sample pattern can be created simply by only rendering specific pixels from a relatively large ordered-grid array. I'm sure it takes a bit more triangle setup engine power, but it can't take that much more.

 

[JF_Aidan_Pryde]

I don't think NVIDIA likes rotate grid very much. They tend to think it is more of a stop gap solution as it only is beneficial for near vertical/hoirzontal lines. NVIDIA seems more interested in more and better 'samples'.

 

[OpenGL guy]

I don't think NVIDIA likes rotate grid very much. They tend to think it is more of a stop gap solution as it only is beneficial for near vertical/hoirzontal lines. NVIDIA seems more interested in more and better 'samples'.

nvidia hasn't show this at all. First, they don't even have gamma correction. Second, I would say that having all of your samples in two rows/columns is a stopgap solution until you can use a programmable grid. See nvidia's 6xS, 8xS and 16xS modes. Don't let the fact that nvidia calls "8xS" "8x" or "16xS" "16x" fool you: These are still mixed super- and multi-sample modes.

From the shots I've seen, 16xS is barely better than 4x on a rotated grid, but it's still worse than ATi's 4x because of the lack of gamma correction.

 

[Xmas]

From the shots I've seen, 16xS is barely better than 4x on a rotated grid, but it's still worse than ATi's 4x because of the lack of gamma correction.

I wouldn't go that far. Admittedly, 16xS is only slightly better than 8xS (i.e. the 2xRGMS + 2x2 OGMS mode), but IMO this mode is more comparable to ATI's 6x than to 4x.
I know this is very subjective, but my reasons for this are:
- the supersampling part, which improves textures slightly, and takes care of alpha test edges/pixel shader aliasing.
- one often-overlooked aspect when comparing AA is how it looks in motion. When you have slowly 'crawling' edges, the number of samples is a very important factor.
- gamma 'correction'... hm, how correct is it when I set the gamma value in the driver to something different than 1.0? Is it fixed or does it adjust to that?
When I play games, I often set gamma to 1.8 in the driver. A side effect of this is that I get almost linear subsample blending.

 

[Althornin]

I don't think NVIDIA likes rotate grid very much. They tend to think it is more of a stop gap solution as it only is beneficial for near vertical/hoirzontal lines. NVIDIA seems more interested in more and better 'samples'.

"better" samples would be those used more efficiently right?
As in sparse sampling?
As in ATI's 6x AA?

I cant wait for a nice 16x AA (sparse sampled) solution.

 

[Mintmaster]

I cant wait for a nice 16x AA (sparse sampled) solution.

Didn't B3D do an article on 3DLabs' SuperScene AA? That was a very nice looking sparse sampled solution if I remember correctly.

 

[Arun]

More sample points than colors produces glitches if the number of fragments for a pixel exceeds the allowed number of colors for that pixel (which can happen quickly if polygon sizes get too small). Of course, you can merge fragments, but not in a sort-independent manner.

16x ordered grid sounds a bit wasteful - on near horizontal/vertical edges, where aliasing is usually at its most noticeable, it will do a worse job than 6x rotated or sparse grids (3 gradients vs 5). 16x rotated or sparse grids will do a much better job at very little added cost, so why not do that?

Sure, it can produce glitches, but if implemented properly, I don't think it can look worse than traditional 4x.
And it often looks a LOT better.

nVidia's stand on Rotated Grid is very simple.
They don't like it because it's horrible for some rare cases.

Their opinion is that what they call "xS" is better than rotated. xS gives excellent quality in those rare cases, and only slightly worse quality in most cases.

IMO, overall, it's about equal to Rotated.

The problem with nVidia's "xS" is that, so far, they only implemented it by adding supersampling.
If we had the 4xS sampling patterns with true MultiSampling at no performance hit compared to the ordered grid, I believe nVidia would be back in the AA Quality game. That is, as OpenGL Guy said, if they also added Gamma Correction.

Of course, 6xS & 8xS sampling patters are just plain crap. 6xS is not comparable at all with ATI's 6x. But that's another story...


If nVidia implemented Fragment Antialiasing, I'd guess Color Compression would become perfectly useless ( that is, if they aren't already using something like this to do Color Compression ) , and use something fairly different:

3 bits per sample
32 bits per color ( 4 colors per pixel )

As for the value of the per sample bits:
1: 1st color of the pixel
2: 2nd color of the pixel
3: 3rd color of the pixel
4: 4rd color of the pixel

This just an example, maybe you'd have to use 4 bits per sample in order to have something when there's no color or something, not sure.

Anyway, that would result in a memory usage ( color only ) per pixel of:
32*4 + 3*16 = 128 + 48 = 176 bits

That's only 37.5% more than the current methods.

Anyway, as for the location of those samples... I'd be highly surprised if nVidia would use Rotated anytime soon. xS is not out of the question, however, and would certainly be much better than ordered.


Uttar

 

[Colourless]

nVidia's stand on Rotated Grid is very simple.
They don't like it because it's horrible for some rare cases.

This is an alternative to Ordered Grid which is horrible in lots of really common cases?

 

[Arun]

nVidia's stand on Rotated Grid is very simple.
They don't like it because it's horrible for some rare cases.

This is an alternative to Ordered Grid which is horrible in lots of really common cases?

LOL, good point.
As I said, nVidia thinks their "xS" is better, because it's *never* "horrible".
But, in most cases, it's worse than rotated.

The real question is when they'll introduce it with true multisampling...


Uttar

 

[arjan de lumens]

Sure, it can produce glitches, but if implemented properly, I don't think it can look worse than traditional 4x.
And it often looks a LOT better.

Hmmm. Consider a polygon mesh with a moderately large polygon count. On average, each interior vertex is shared between 6 polygons. If such a vertex ends up in the middle of a pixel, you may end up in the situation where 6 fragments from different polygons, with different colors, contribute to the color of the pixel (in addition to whatever color the pixel had before applying the 6 fragments). This case isn't that uncommon. Now, how do you handle this case so that you don't e.g. get the background color shining through or any other artifacts?

nVidia's stand on Rotated Grid is very simple.
They don't like it because it's horrible for some rare cases.

Doesn't make very much sense. The worst case for rotated grid is when you have a polygon edge nearly aligned with the grid. Rotated grid stll handles this case much better than ordered grid handles near-horizontal/vertical edges. And for higher degrees of AA than 4x, there are grids, such as the sparse grids posted by SA some time ago, that are still much better than rotated grid.

If nVidia implemented Fragment Antialiasing, I'd guess Color Compression would become perfectly useless ( that is, if they aren't already using something like this to do Color Compression ) , and use something fairly different:

It will not make Color Compression redundant at all. For the majority of the pixels on the screen (~80-95%, dependent on polygon size), you will need only 1 or 2 color values, and storing 4 color values per pixel in this common case is incredibly wasteful wrt memory bandwidth. Rather, for the 1 color case, you store the color and a code to indicate that the pixel only has 1 color (about 33-35 bits total) and for 2 colors, you store the 2 colors and a bitmap of which samples are covered by each color (about 80-83 bits total).

 

[Arun]

Sure, it can produce glitches, but if implemented properly, I don't think it can look worse than traditional 4x.
And it often looks a LOT better.

Hmmm. Consider a polygon mesh with a moderately large polygon count. On average, each interior vertex is shared between 6 polygons. If such a vertex ends up in the middle of a pixel, you may end up in the situation where 6 fragments from different polygons, with different colors, contribute to the color of the pixel (in addition to whatever color the pixel had before applying the 6 fragments). This case isn't that uncommon. Now, how do you handle this case so that you don't e.g. get the background color shining through or any other artifacts?

Here's a possible solution:
Use the same color as one nearby sample.

Sure, it degrades quality. But as I said before, it shouldn't give worse quality than traditional 4x AA.

The real problem with the whole method is that it's hard to implement.

nVidia's stand on Rotated Grid is very simple.
They don't like it because it's horrible for some rare cases.

Doesn't make very much sense. The worst case for rotated grid is when you have a polygon edge nearly aligned with the grid. Rotated grid stll handles this case much better than ordered grid handles near-horizontal/vertical edges. And for higher degrees of AA than 4x, there are grids, such as the sparse grids posted by SA some time ago, that are still much better than rotated grid.

Agreed, Rotated Grid is on overall better than Ordered.
But it seems nVidia really want to use a perfect sampling pattern the next time they change their sampling patterns.
Too bad there's no such thing

If nVidia implemented Fragment Antialiasing, I'd guess Color Compression would become perfectly useless ( that is, if they aren't already using something like this to do Color Compression ) , and use something fairly different:

It will not make Color Compression redundant at all. For the majority of the pixels on the screen (~80-95%, dependent on polygon size), you will need only 1 or 2 color values, and storing 4 color values per pixel in this common case is incredibly wasteful wrt memory bandwidth. Rather, for the 1 color case, you store the color and a code to indicate that the pixel only has 1 color (about 33-35 bits total) and for 2 colors, you store the 2 colors and a bitmap of which samples are covered by each color (about 80-83 bits total).

What did you mean here, exactly?
What prevents you from only writing one color value when there's only one color value per pixel, when using Fragment Antialiasing?
It just seems to me that the Color Compression methods used today are a special case of a Fragment Antialiasing algorithm.
Or anyway, they could be, depending on how it's implemented.


Uttar