Source code for "Pratical Morphological Anti-Aliasing" is out

#1 Sweet find!

#2 I got the color-based edge detection working. It looks nice but there are a few technicalities that must be solved first:

The MLAA effect relies on some gamma correction setup. I was very lucky because I implemented gamma correction support into my T3D builds, so it integrated nicely. I need to try to implement the MLAA into vanilla T3D to see how it behaves without gamma correction. I really want to release the gamma correction stuff, but it involves a *ton* of source file modifications...

- To keep the performance cost low, the MLAA technique uses stencil to limit processing to edge fragments (the 2nd pass is quite intensive). The problem is that stencil on PostEffects fails if they output to a render target (there's no depth/stencil buffer attached). The correct way to fix this is by adding a "depthStencilTarget" property to PostEffects so one can specify which depth/stencil buffer it will interact with.

Anyway, it is perfectly doable in T3D. =)

#3 Alright, I just took my postFX and shader files, erased the gamma-correction stuff, commented the stencil code and dropped into vanilla T3D 1.1 b3. It works! Deathball looks very nice.

You guys can try it: www.mediafire.com/?358ru4b8eujyjlw
Save the zip file in the same folder as your T3D executable and unzip it there. It should write the MLAA files to the shaders and core postFX folders.

Just remember the stencil is disabled, so the effect is processing all pixels on the screen, taking a much larger hit in performance than it should.

Also, it's meant to be tested in Advanced Lighting. I have no idea what happens if you try to run in BL with it enabled.

#4 Here's a sample:

More screens:
www.abload.de/image.php?img=screenshot_001-00000672s.png
www.abload.de/image.php?img=screenshot_001-00001h7ei.png
www.abload.de/image.php?img=screenshot_001-00002w7lj.png
www.abload.de/image.php?img=screenshot_001-00003r74b.png
www.abload.de/image.php?img=screenshot_001-00004s7oe.png
www.abload.de/image.php?img=screenshot_001-00005y7jk.png

#5 Wow... really nice.
And the impact on the frame rate?

#6 I just tried the code you shared, and i must to say i did not imagine it was so light. In practice, the fps does not have suffered completely... also on an old ATI HD 2600 PRO.

Before and After:

#7 Yeah, it seems to miss some edges depending on which colors are involved. I need to implement the depth-based test to see how it compares. The FPS hit should be much smaller with stenciling on, since it should process at least 75% less pixels.

You can also try playing with the edge detection threshold. You can change it in real-time in the console. I'm using 0.06, but depending on your scene you might want to decrease/increase it.

mlaafx.threshold = 0.06;

#8 The depth based edge-detect does grab some edges the color one misses, but it also misses a lot of edges that the color detection grabs. It does nothing for edges caused by two polygons touching or intersecting since they have the same depth.

I'll try to combine both into a single shader and combine the edges found in both tests.

#9 Alright, it works. Updated version here: www.mediafire.com/?z1izbxtf5idz7ei

I bumped the default threshold to 0.1, since the depth now provides additional edges (and reports flat areas as edges if the threshold is too low). I also increased the red channel weight by 3X in the color edge detection, since it did grab a lot of missing edges on my test scene.

BTW, the article reports MLAA as being faster than MSAA. We really need the stencil optimization. There also something else: the original demo uses A8L8 render targets since only two 8-bit channels are needed, but T3D doesn't support them (I even had to jump through hoops because T3D refused to load the A8L8 lookup texture used by MLAA).

#10 Will this go into 1.1 final ?

#11 @Manoel - That looks pretty cool and your improvements to PostFx to enable it look good at first glance.

I'll do what i can internally to help push at least the PostFx improvements thru.

As for including MLAA into T3D... i want to test your results with the depth check added. The color only tests as seen in your screens above don't seem very good.

Also at GDC i saw a presentation on DLAA (Directionally Localized Anti-Aliasing) which i want to investigate. The slides are here. He reports 2.2ms on the Xbox 360 which is extremely impressive for the results he was showing.

#12 Well, I'm of the opinion that some AA is better than no AA. And this actually passes for (some) AA, unlike the stock EdgeAA that is nothing more than a box blur along the edges ;)

I'm watching the DLAA slides. I like the added softness it adds to the edges, I find it looks more natural (you don't have sharp 1-pixel edges in photographs).

I find it amuzing that it looks a lot like my own experiments in post-processing AA, down to using Photoshop to prototype things instead of trying to come up with fancy algorithms.

#13 Also i notice in the video on the iryoku.com site that the trees in the background shimmer badly even with MLAA. Thats a case that so far nothing but multisampled techniques seem to do very well. Even then i think that has more to do with mipmaps than real aliasing.

Anyway... we're testing your MLAA implementation now. THREED-1529

#14 AFAIK it's impossible for any post-processing AA to eliminate temporal shimmering: if the aliasing changes too drastically with subtle movements (example: very intricate alpha-tested geometry without mipmaps or large AF values), the post-processed AA result will also change drastically and still shimmer.

After all, all these post-processes AA techniques are nothing more than very clever blur effects, blending samples from other locations to emulate the visual results of multisampling.

#15 Right... also like you can see in that video even 8x MSAA shows some shimmer on alpha test. For this reason alpha test just isn't part of the criteria for post-processed AA quality.

First and most importaint... the GG art team loves the quality of this MLAA.

Testing performance... on a Core 2 Duo and a 4 year old 8800GT running the deferred renderer at 1600x900... we got results between 2ms and 4ms. This is pretty damn good for that huge resolution on that old card... for sure faster than 8x MSAA would be.

Assuming your good with it Manoel i think we're gonna try to get this into 1.1 final. I'll be merging your PostFx and DDS fixes so that we can use those additional optimizations. I expect we'll get the same < 1ms results as the article.

If later we get time to implement DLAA... great... it doesn't hurt to have options.

#16 Getting it into 1.1 final was the plan all along anyway :)

BTW, MSAA simply does nothing on alpha tested geometry, which is sad when you have lots of it. There is CSAA (coverage sampling AA), which helps a little bit but doesn't quite look like AA. It can be enabled by some D3D9 hacks, but since it's not standard in DX9 it looks different in NVidia and AMD cards (I prefer the AMD look, since NVidia uses dithering which looks horrible IMO).

BTW, the luminance texture support (which allowed me to use the original DDS files from the MLAA site) didn't provide any measurable changes in performance (actually, I think it worked slightly slower in my HD 4850), so I don't think it's worth it.

#17

Quote:BTW, MSAA simply does nothing on alpha tested geometry

Yea... i think the improvement i was seeing was "alpha to coverage" support in Unigine.

For lots of alpha test trees we need to use tricks like rendering twice to get alpha blend edges or the stencil mask technique from Black Rock Studios. Both require drawing the meshes twice... but BlackRocks' technique (also in GPU Pro "Alpha Blending as a Post-Process") allows you to disable color writes on the stencil pass.

But really the solution to alpha is what its always been... we need to store all the layers of transparency per-pixel. The DX11 linked list techniques give me hope.

Quote:the luminance texture support didn't provide any measurable changes in performance

Makes sense... i figured the big win would be the stencil.

#18 AFAIK enabling "alpha to coverage" is very easy: check the GPU vendor ID and set a special value to a render state depending if it's NVIdia or AMD. About 6 lines of code at most. But it only works for true MSAA, so it's useless for deferred rendering/lighting.

The DX11 linked list stuff is indeed the most robust solution. It simply does the right thing: opens up the blending black box to the game without nonsense like having having one entire render target for each layer, stippling, etc. It looks very similar to the way old PowerVR cards dealt with transparency (I remember seeing Dreamcast games where alpha blended polygons intersected properly at pixel level).

Ah! Only now I read that page about rendering stuff twice! Damn, so clever and works perfectly! Why didn't I ever think about that? For moderate amounts of alpha-tested geometry it sounds like a very simple and practical solution, specially if it can be enabled/disabled per material.

#19 The render twice technique is very old... i think the first time i saw it was like the 90s. It does leave some incorrectly sorted halos around you alpha test if you get too close to it... but its better now with higher resolution textures than it was back then with 256s.

If i get some time i may experiment with adding a per-material flag for doing the dual render trick. My big concern is that since we're deferred the edges won't be shadowed correctly.

#20 Yeah, for deferred it would be bad since the alpha-tested pass would be deferred-lit while the alpha-blended pass would be forward-lit.