Also, i think the 2nd and 3rd passes are based on edges, or at least are optimized to a degree for non-edges. But I'm not very familiar with graphics programming.
The implementation for Mesa is in TGSI here: http://lists.freedesktop.org/archive...st/010629.html
which is based on the Jimenez MLAA code, which you can view in a more readable DX10 version here: https://github.com/iryoku/jimenez-ml...haders/MLAA.fx
Maybe someone smarter than me can make more sense out of it.
The second pass is what makes it so much better in quality than many of the other implementations; instead of a constant blur, it depends on the type of aliasing. I recommend the fxaa vs mlaa article @ digitalfoundry, you can see how much more fxaa blurs.
As a gamer on nvidia hardware (under Windows) I've found that MSAA and CSAA fall short while FXAA and MLAA really nail it..
The major problem with MSAA & CSAA is that it doesn't anti-alias shaders very well (if at all)... So you have these very bright pixels on the edges of objects that are caused by shiny objects but the bright pixels aren't anti-aliased properly because the shaders are at a different level than MSAA/CSAA.. So at decent resolutions (1080p) and very high texture & lightning details you can see some course grainy pixels on the texture caused by the bright reflective lighting on the edges of shiny objects (like wet steps).. MLAA and FXAA fixes that while you can crank MSAA and CSAA to the max all day long and it will do nothing to fix those annoying coarse white pixels along the edges of very shiny objects (which can really detract from the realism, IMO).
Last edited by Sidicas; 08-18-2011 at 07:53 AM.
Thanks, will do.The second pass is what makes it so much better in quality than many of the other implementations; instead of a constant blur, it depends on the type of aliasing. I recommend the fxaa vs mlaa article @ digitalfoundry, you can see how much more fxaa blurs.
Edit: I missed the part where this is written in TGSI rather than GLSL. But still, the hardware limitations should be identical. Need to think about this some more.
Since pass 1 calls discard for non-edge pixels, the stencil is not marked for those. Early-Z isn't lost this way. This is quite a smart optimization, my jaw dropped too when I first saw it.glClear(GL_STENCIL_BUFFER_BIT);
glStencilFunc(GL_ALWAYS, 1, ~0);
glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
// pass 1 here