Alternative AA methods and their comparison with traditional MSAA*

[homerdog]

Thanks for the detailed responses.

I'd like to see your technique implemented in a shipping game. Unfortunately the higher quality modes look like they'd only work on PC for now (especially for deferred renderers), and it's not likely that devs will bother to use it on their PC ports no matter how easy it is to add.

 

[IrYoKu]

I'd like to see your technique implemented in a shipping game. Unfortunately the higher quality modes look like they'd only work on PC for now (especially for deferred renderers)

Yes, for the moment they only have a reasonable performance on PC. We think a stripped down version of SMAA T2x could work on the Xbox 360, we are waiting for a devkit to try it.

and it's not likely that devs will bother to use it on their PC ports no matter how easy it is to add.

Unfortunately, that is sometimes the reality. I hope now that the interface allows for an easier integration, more people will be tempted to try it =)

 

[sebbbi]

it's not likely that devs will bother to use it on their PC ports no matter how easy it is to add.

We ordered the GPU Pro 2 as soon as possible because it had the Jimenez MLAA article on it. Thanks for the good article! Developers do care about efficient AA methods that are compatible with deferred rendering. At the end we settled to FXAA on our Xbox 360 game (our modified version runs at 0.9 ms). On a 60 fps game you just cannot spend much more than that on antialiasing. But in the future geometry and shading costs continue to rise, and the post AA solution cost stays pretty much the same. It will be pretty much free.

I am sure we will evaluate the new SMAA filters when we start developing our next PC game or when the next generation consoles get released, whichever happens first . DX11 and compute shaders make MSAA also viable with deferred shading, but the performance hit is still pretty steep, and MSAA doesn't still solve aliasing on alpha clipped surfaces. Skyrim has MSAA + FXAA (to solve transparency antialiasing), but applying post AA filter on top of standard MSAA resolve is just wrong. The AA filter should use the subsamples to improve the edge gradient calculation, not just do two blends on top of each other. If I understand properly SMAA should address this problem?

I personally do like the usage of last frame data. Frames in 60 fps games do not differ that much, and it feels like a huge waste to generate the whole scene again and again with only minor changes. If that data can be used to boost up antialiasing speed and quality, it's a great thing... and if the reprojection step can be combined with things like dynamic ambient occlusion reprojection, it's even better. We need to find more ways to reuse data, as generation of new pixels gets more and more costly all the time.

 

[homerdog]

sebbbi keep in mind, you are one of the good ones . Far too many devs simply couldn't care less about supporting higher quality AA methods on their PC ports. Imagine my surprise when I discovered that Mass Effect 2 didn't support any AA at all!

As for temporal AA, yes at 60Hz things aren't so bad. But we seem to be moving in the direction of 30Hz + high quality motion blur. This makes things interesting since as IrYoKu pointed out, good motion blur can cover up aliasing really well. We could end up with a solution where motion blur covers up the aliasing in motion and temporal AA makes things look nice when they aren't moving. Food for thought anyway.

 

[sebbbi]

We have noticed that post process AA filters work very well for nearby geometry, but as you go further away, the geometric details get smaller and more things start to require subsample precision (our new games has 6 kilometer view distance). Temporal antialiasing however works very well for distant objects, since the perspective gets flattened and the movement is slower (reprojection works better). Combining temporal "subsample" data with post process AA filter is a good idea. But just doing both on top of each other (brute force way) doesn't of course do much good. The algorithm needs to be more intelligent than that. SMAA seems to be the first solution towards that path. I am eagerly waiting for the next step.

 

[SuperCow]

Temporal AA sounds good in theory but in practice it is going to significantly impact the performance of multi-GPU configurations (SLI/Crossfire).

 

[homerdog]

Temporal AA sounds good in theory but in practice it is going to significantly impact the performance of multi-GPU configurations (SLI/Crossfire).

In practice no dev is going to forsake an algorithm because it doesn't work well with AFR.

 

[Frenetic Pony]

Temporal AA sounds good in theory but in practice it is going to significantly impact the performance of multi-GPU configurations (SLI/Crossfire).

Not so sure this is really practical concern.

Regardless, I've always wanted to see a depth biased MLAA implementation. Just let the effect falloff as distance increases depending on whatever settings look good. And as has been stated temporal AA looks better the less movement, and thus usually further away, geometry is.

So some form of mlaa for the near field and temporal AA for the far should work well without any truly noticeable artifacts. And that's really what matters, going after something that looks good should always beat "accurate". Especially when the thing technique that looks good is a lot cheaper too.

On an off note, I'd always wondered if anyone's tried some form of mlaa on shadow maps. Maybe not too useful as MSAA'd shadow maps are a lot cheaper than the full color sample and etc. that you need for your frame, but it just sounds like an interesting experiment. I bring it up mainly because of Skyrim's horrible aliased shadows, not even changing them to x4096 myself has truly solved the problem.

 

[Andrew Lauritzen]

IMHO temporal AA is, if properly implemented, not that bad in motion. Notice that our movie shows motion in every scene, and there is still a noticeable improvement in subpixel features rendering. I recommend downloading our demo to see the real thing. Temporal SSAA is not as robust as MSAA, but still does the job.

Agreed, I didn't mean to imply it was bad, just that it's a bit finicky. I tend to prefer optimizing for the worst case in games and while you could argue that MSAA becomes SSAA in the worst case, that case really doesn't happen unless constructed. In contrast, very fast motion *does* happen in games (especially first person shooters) and temporal AA breaks down in this case. It's true that motion blur helps in these cases, but it's not a perfect solution. Furthermore there are still valid small motion scenarios that break under reprojection caching like high frequency foreground geometry (blinds, foliage, etc) that occludes very different fragments each frame even if the camera/objects are moving relatively slowly.

Anyways as I said, definitely looking forward to a demo of the MSAA + MLAA technique, ideally with a few semi-real scenes in there - at least as much as you can get ahold of.

 

[Ethatron]

At the end we settled to FXAA on our Xbox 360 game (our modified version runs at 0.9 ms).

MLAA is quicker than FXAA when you use stenciling, FXAAs bandwidth-requirement is much higher in that case. That is on a 5870, don't know if the XBOX-architecture is so "bad" that it doesn't help. What stops the use of MLAA is the occasional non-existant depth-buffer.

You are probably aware already from a few pages back (were I posted all the shots) that you can try them AAs all out in OBGE and even get accurate timing-graphs. My optimizations (if there are any) are always public domain as part of it.

 

[sebbbi]

MLAA is quicker than FXAA when you use stenciling, FXAAs bandwidth-requirement is much higher in that case.

In your comparison, are both MLAA and FXAA stenciled in the same way (processing same amount of pixels), or did you use stenciling only for the MLAA?

FXAA comes in many forms. MLAA is close in performance to the high quality PC FXAA preset. However the FXAA console preset is many times faster than the high quality PC preset. The quality if of course slightly lower, but the performance makes it pretty much the only AA method usable in 60 fps console games (if you use deferred lighting).

 

[reptile]

... and MSAA doesn't still solve aliasing on alpha clipped surfaces.

Yes, it does, with alpha to coverage. I don't really understand why this "technique" gets a lot of hate... i keep bringing it up in forums as an example, but im yet to receive a proper answer explaining whats so "wrong" with it. Most people tend to point towards examples which all turn out to be asset problems. Granted, it doesn't work with the post-process techniques, but as an approximation of coverage, it works very well in MSAA4x scenarios - almost as good as alpha blending without the associated problems.

Also, using the ability to set the output coverage mask manually, and with a bit of precalculation for the texture, you could simulate a supersampled version of the alpha texture, which would solve the remaining "dithered-guesswork" artifacts of standard alpha to coverage.

 

[Andrew Lauritzen]

I agree alpha to coverage is pretty decent, but I will content that it looks "almost as good as alpha blending at 4x". That's really not true until you get at least 16 samples per pixel, even with a good sample pattern (i.e. not the current hardware ones). Stochasic stuff is just far too noisy for 4 samples to produce a clean image. Of course it does fine for close-up foliage but even FXAA/MLAA does fine for that.

 

[reptile]

Okay, not almost as good, but - in my experience - as good as it (currently) gets without resorting to alpha blending. For mid-far range foliage it is noisy, but still much better than without it. I can't stress enough how important it is to author the textures with atoc in mind, i saw a lot of games trying to get away with autogen mipmaps for atoc foliage only to get a screendoor noise because lower miplevels had a lot of grey in their alphas.

Screen space AA usually - and again, in my experience - does a pretty terrible job at foliage, even close-range, because crawling gradients tend to be much more noticable when you're dealing with a more irregularly shaped contour. Then again, anything is better than no AA, as evidenced by a recent
big title. That game is just pushing too much geometry for too few pixels, making some of the later levels a pain to look at. Shame, because otherwise it's probably one of the best looking games ever.

 

[MJP]

You don't even need to do traditional A2C to get higher quality alpha-tested edges with MSAA. In D3D10.1 and D3D11 you can output a custom MSAA coverage mask from the pixel shader, which means you can run the alpha test per subsample (rather than per pixel) and use the results as your coverage mask.

Not that I have a problem with A2C...I agree that it doesn't get enough love.

 

[Ethatron]

In your comparison, are both MLAA and FXAA stenciled in the same way (processing same amount of pixels), or did you use stenciling only for the MLAA?

I don't think you can do that for FXAA. Or you rewrite it, because it's
one-pass, it'll brute-force scan the framebuffer such that you read something like 6-8 times that much pixels.

The detection of edges in MLAA can be done with the one channel depth-buffer, if you put some effort into it MLAA consumes 1/4th or less of the memory-bandwidth of FXAA. In my experience only a 10-20% end up being marked as edges. Which makes the blending-code complexity not very important.

I'm just saying the framework of MLAA/SMAA and FXAA is totally different, the former is more flexible and you can use the tricks-box and hunt very very low times with MLAA/SMAA, and make it possible.

 

[sebbbi]

The detection of edges in MLAA can be done with the one channel depth-buffer, if you put some effort into it MLAA consumes 1/4th or less of the memory-bandwidth of FXAA. In my experience only a 10-20% end up being marked as edges. Which makes the blending-code complexity not very important.

I'm just saying the framework of MLAA/SMAA and FXAA is totally different, the former is more flexible and you can use the tricks-box and hunt very very low times with MLAA/SMAA, and make it possible.

Yes, but with a certain console, you cannot directly use rendertarget as a texture. You have to resolve the contents first to main memory. 720p full screen resolves are not cheap. A few of them, and you already have 1 ms spent.

With FXAA you of course have to do a separate edge detect pass, if you want to use the stencil culling. But many engines have multiple existing full screen passes (tiled deferred lighting for example) that can easily be modified to do the edge detection in addition to their usual work. For example if you integrate the edge detection to the full screen (tiled) lighting pass, you already have the depth sampled (for position calculation), and only need to sample the neighbors' depth (that are fortunately in texture cache). So the edge detect become really inexpensive.

 

[Ruskie]

Anyone knows type of PPAA used in AC Revelations? DF said its some of the best they've seen on consoles. Very smooth, no blurring and crawling/sub pixel problems are not as pronounced as in other types of post process AA techniques.
http://images.eurogamer.net/2011/articles//a/1/4/2/2/2/4/4/360_046.jpg.jpg
http://images.eurogamer.net/2011/articles//a/1/4/2/2/3/0/0/360_aa1.bmp.jpg
http://images.eurogamer.net/2011/articles//a/1/4/2/2/2/4/4/360_015.jpg.jpg
http://images.eurogamer.net/2011/articles//a/1/4/2/2/3/0/0/360_aa2.bmp.jpg

 

[homerdog]

Are those contact hardening shadows I see? Looks very good.

 

[Andrew Lauritzen]

Have they compared it with other AA methods on the same art, or are they also implicitly comparing AC Revelations to other games here?