Dumb question: MSAA vs SSAA, what is the big differences?

geo said:
So they introduced the problem and took away the solution in the same DX release? Oops. :p

P.S. Okay, not literally "took away", but as a practical matter it has turned out that way.
I don't understand what you mean. An app has the possibility do to supersampling itself or leave it to the driver/card if the driver is nice enough to expose it.

Murakami said:
Chalnoth said:
The differences you see in the above are due to differences in sample patterns.
How can the sample patterns be different using the same card? Is the sampling grid software controlled on a GeForce 3 :?:
MS and SS aren't implemented the same way.

DeanoC said:
SS is more compatible but still some will fail...
In what way is it more compatible?
 
DeanoC said:
SS is more compatible but still some will fail...
Thanks Deano, I guess it's still a "wait and see" on that one for me then.

Heck, MOST of it is still all a "wait and see" for me on the next gen cards....and to be honest I think I like it this way better than knowing, it's oodles more fun speculating. :)
 
Xmas said:
geo said:
So they introduced the problem and took away the solution in the same DX release? Oops. :p

P.S. Okay, not literally "took away", but as a practical matter it has turned out that way.
I don't understand what you mean. An app has the possibility do to supersampling itself or leave it to the driver/card if the driver is nice enough to expose it.

Ah. Didn't realize the app could do Supersampling. My memory is that all DX8 apps that AA was done in the drivers, and only recently (DX9-era) have apps being doing it in the app instead. I was just finding it ironic that DX8 came out with a method of AA that highly incentivized its use because of performance, but also didn't work when you used the shaders that DX8 also introduced.
 
Xmas said:
DeanoC said:
SS is more compatible but still some will fail...
In what way is it more compatible?

Forcing AA in drivers is really quite hard, there are lots of corner cases that break it (from locking to reusing depth buffers). SSAA tends to work in a few cases where MSAA doesn't, most likely just cause its simplier to work with in the driver...

But in general if ones broke, so is the other...
 
Question: is SSAA working with render-to-texture, for things like motion blur and HDR? Or do you need to render to a larger texture? It seems to me, that MSAA would work better in those cases, although you would probably get artifacts. But I've never tried so far, so I don't know.
 
AFAIK, SSAA (if truly implemented in hardware and not just a driver hack) will always work. You render the image 4 times for 4xSSAA _completely_ and sample than, right? So in which case should it not be working?
 
_xxx_ said:
AFAIK, SSAA (if truly implemented in hardware and not just a driver hack) will always work. You render the image 4 times for 4xSSAA _completely_ and sample than, right? So in which case should it not be working?

Four times, or just once, but twice the resolution on both axis?
 
The best way to do SSAA is to render to a larger texture/surface and than filter it down to the right resolution. This works well on all current chips. The main problem ist the maximum resolution. With 4xOGSSAA you can only go up to 1024 with current ATI chips.

With this solution you can "patch" every game to use SSAA even with Radeons.

But you don't need to do this for R2T AA. DX9 supports a way to this with MSAA, too. But it did not work with ATI chips/driver.
 
DiGuru said:
_xxx_ said:
AFAIK, SSAA (if truly implemented in hardware and not just a driver hack) will always work. You render the image 4 times for 4xSSAA _completely_ and sample than, right? So in which case should it not be working?

Four times, or just once, but twice the resolution on both axis?

I think Voodoo5 SSAA rendered four separate frames in the nominal resolution for 4XAA, with each vertex "nudged" a bit in each, whereas the Geforce 1/2 OGSS rendered to a frame with twice the resolution.
 
This is probably a silly idea, but why not use an accumulation buffer, find the edges, render an extra pixel and give the two outermost pixels a decreasing accumulation mask? With MSAA the hardware knows where the edges are, right? I assume that won't work, but why? Because there is no vertex data for those pixels?
 
DiGuru said:
This is probably a silly idea, but why not use an accumulation buffer, find the edges, render an extra pixel and give the two outermost pixels a decreasing accumulation mask? With MSAA the hardware knows where the edges are, right? I assume that won't work, but why? Because there is no vertex data for those pixels?

I don't know exactly what you mean, but it sounds vaguely like Matrox's "16X" AA-scheme.
 
DiGuru said:
With MSAA the hardware knows where the edges are, right?
No, MSAA has no information about where the edges are. It is effectively edge anti-aliasing for the reason that only one color value is ever calculated per pixel (and thus only when multiple triangles intersect in the same pixel do different color values get calculated).
 
Quite oversimplyfied but up to date implementations:

fragment AA = polygon edge antialiasing

multisampling = polygon edge and polygon intersections antialiasing

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.
 
By the way many of the relevant topics have been discussed here on the boards already in the past:

Matrox FAA:

http://www.beyond3d.com/forum/viewt...r=asc&highlight=coverage+mask&start=0

Multisampling:

http://www.beyond3d.com/forum/viewt...r=asc&highlight=coverage+mask&start=0

Multisampling can be performed in several ways.

In the case of tilers, the pixel color can be computed once and applied to the visible samples in the pixel based on the sample's z values. When the tile is done, the filter can be applied to the tile and the results written to the frame buffer.

On IMRs multisampling is best done using some version of the A buffer. In this case, triangle fragments (those portions of a triangle within a pixel) set the bits of a coverage mask with one bit per sample. A single color and z value is stored for the fragment. Since there are usually only one or two fragments in a pixel, this allows significant compression of the color and z data. For 8x AA it allows up to 4 to 1 compression without loss for two fragments.

It does assume, however, that the z values are the same for each sample, which is usually not the case. Z3 handles this by including the z slopes along with the z value at the center. Other problems occur when the number of fragments exceeds what is allocated (usually two are allocated since most pixels have one or two fragments).

There are a number of sample patterns.

Ordered grids - standard row-column pattern
Staggered grids - every other row offset half a column (close packed)
Rotated grids - ordered grid rotated by a fixed angle
Sparsely sampled grids - NxN grid for N samples, one sample per row and one sample per column
Jittered grids - a uniform grid with each sample randomly jittered in +/- x and y up to half a sample step. Requires a large number of samples to work well. Similar to Poisson distribution.
Poisson pattern - a uniformly sampled random pattern. Requires a large number of samples to work well. Difficult to implement in hardware.
Others

The important aspects of a good sample pattern are:

For small numbers of samples ( say <32) a pattern that provides approximately the same number of intensity gradations as the number of samples is of primary importance. Ideally this would be true for edges at all angles, but this is especially true for near horizontal and near vertical edges. Sparsely sampled grids is best, followed by rotated grids.

The next most important factor (especially for a small number of samples) is uniform sampling. This prevents pixel popping. Care must be taken with all the above patterns to make sure the samples are fairly uniform in their coverage of the pixel and do not aggregate in clumps or along characteristic lines.

To break up aliasing across pixels, a pattern library is often used. These patterns are interleaved across several pixels (say 4x4 pixels). To avoid pixel popping, care must be taken that the pattern boundaries do not cause non-uniform sampling. Ideally, the whole 4x4 pattern looks like one uniform pattern much like seamless texture tiles.

Of course it goes without saying the more samples the better. For IMRs coverage mask (A buffer) techniques easily allow 8x, 16x, or even 32x AA without much extra memory bandwidth since it simply requires a larger bit mask. Tilers can also easily increase the samples without incurring extra bandwidth.
 
Ailuros said:
Quite oversimplyfied but up to date implementations:

fragment AA = polygon edge antialiasing

multisampling = polygon edge and polygon intersections antialiasing

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.
Simple, but correct.
 
Ailuros said:
Quite oversimplyfied but up to date implementations:

fragment AA = polygon edge antialiasing

multisampling = polygon edge and polygon intersections antialiasing

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.
Sort of. Think of fragment AA as only antialiasing the borders of objects. It could work with a stencil test, but Matrox' method wasn't designed with that in mind, as it would have been too much of a performance hit (Matrox' fragment AA depended upon a very small portion of the scene being made up of object borders).
 
Chalnoth said:
Ailuros said:
Quite oversimplyfied but up to date implementations:

fragment AA = polygon edge antialiasing

multisampling = polygon edge and polygon intersections antialiasing

If my memory serves me well Matrox's FAA wouldn't work with stenciling also, albeit I'd figure it would be possible with FAA with a few workarounds.
Sort of. Think of fragment AA as only antialiasing the borders of objects. It could work with a stencil test, but Matrox' method wasn't designed with that in mind, as it would have been too much of a performance hit (Matrox' fragment AA depended upon a very small portion of the scene being made up of object borders).

A simple cliff note helps usually understanding; for more details there's a link to a thread for Matrox's FAA above and since there might be more relevant threads to be found, all it would take any interested fellow user is to use the search machine either with "fragment AA" or "Matrox FAA" to search for more detailed explanations.
 
DiGuru said:
_xxx_ said:
AFAIK, SSAA (if truly implemented in hardware and not just a driver hack) will always work. You render the image 4 times for 4xSSAA _completely_ and sample than, right? So in which case should it not be working?

Four times, or just once, but twice the resolution on both axis?

The question remains: in which case is SSAA incompatible to anything? The blending happens _after_ the whole image is rendered (be it 4 frames or double the res). Right?
 
Back
Top