Alternative AA methods and their comparison with traditional MSAA*

Isn't that just a very easy to make typo - MSAA instead of MLAA when you're typing lots of acronyms and have been using MSAA for years already?
It totally could be that actually, although the context was more MSAA vs MLAA/FXAA in that paragraph. If it was just a typo, all good. Still, the rest of the article is not without issues ;)

Of course, shader aliasing is now a major problem that can make MSAA seem ineffectual, so we need the post process AA since nobody besides me and homerdog gives a damn about SSAA.
You definitely don't need post-process AA to address it. That's like saying you need "post-process" AA instead of mipmaps ;) It should be addressed at the source... screen-space blurring is a last resort! LEAN mapping is a great example of a way to address specular/normal map aliasing (by far the most common type that people see) properly.
 
Isn't that just a very easy to make typo - MSAA instead of MLAA when you're typing lots of acronyms and have been using MSAA for years already? I haven't read the article so maybe it is nonsense, but I'd read that first-and-foremost as a typo and assume the authors aren't completely blind to the benefits of MSAA.

I checked that, its not a typo. He made that argument in paragraph called FXAA vs MSAA in conclusions and below is paragraph called FXAA vs MLAA.
 
LEAN mapping has nothing to do with shader-aliasing. It's about filtering reflectance-textures (like normal-maps) without washing them out.

The whole point of LEAN mapping is to reduce specular aliasing when normal maps are used...
 
The whole point of LEAN mapping is to reduce specular aliasing when normal maps are used...

If you want to attribute every artefact coming out of a shader to the shader itself .... LEAN-mapping specifically attempts to circumvent artefacts from linear filtering of reflectance-textures, that has nothing to do with the shader itself. The only way to fight shader-aliasing are sub-pixel shaders, aka supersampling above it's Nyquist frequency. I'm a bit surprised about the seemingly "redefinition" or "relaxation" of the meaning of shader-aliasing. A shader is not some simply texture-passthrough logic which could be made aliasing free soley through LEAN-mapping (hypothetically saying the LEAN-approach could be generally applied to any texture).

But I guess that's not what you meant.
 
It's semantics. By that reasoning, we can just call almost all of these post-AA/screen-space processes intelligent blur filters (which is true, and it'd be my wish too ;)). But in the context of the thread, we are talking about the purposes of utilization and the end result. The authors themselves specifically mention developing LEAN mapping to reduce specular. So that's that. I don't see what the big fuss is about or the need for arguing such a pointless matter of definition.
 
Semantics is important for the non-savy who believe the new messiah-tech came along. :)
We're currently adding CLEAN-mapping to Oblivion's water, so maybe I felt the urge to hint at what it is, and what not. :p
 
Bilinear filtering is blurring. Trilinear interpolation is blurring between mip map selections. :p On a finer level, what is interpolation between the edge pixels and the pixels outside the poly? You're blurring the values in between and creating a smoother gradation/transition. Were it up to me, "anti-aliasing" would be related purely to dealing with Nyquist issues, so true AA is really increasing sampling rate. All these post-AA's are ultimately single-sample-per-pixel solutions (aside from the ones that involve supersampled normal/depth buffers). Of course, there's the AA definition that is simply removing high frequency components, and blur can do just that for simple edge cases (not shader-related). But... agh... now we're going off-topic!
 
If you want to attribute every artefact coming out of a shader to the shader itself .... LEAN-mapping specifically attempts to circumvent artefacts from linear filtering of reflectance-textures
Sure, but that's *by far* the most common source.

The only way to fight shader-aliasing are sub-pixel shaders, aka supersampling above it's Nyquist frequency.
In general, yes, same with geometric aliasing. However like texture filtering and LEAN the best way is to band limit your signal instead. i.e. address the *source* of the aliasing, not just try and reduce how bad it is.

What - beyond specular, textures and shadows - do you think is a really common source of aliasing in shaders these days then?
 
Andrew made a good point. I would put on that bad-guys list alpha-testing before even starting to worry about exotic shaders.
 
Bilinear filtering is blurring. Trilinear interpolation is blurring between mip map selections. :p On a finer level, what is interpolation between the edge pixels and the pixels outside the poly? You're blurring the values in between and creating a smoother gradation/transition. Were it up to me, "anti-aliasing" would be related purely to dealing with Nyquist issues, so true AA is really increasing sampling rate.
what about line drawing algorithms like Wu's, or AA'd text? An antialiased line interpolates points which isn't blurring (not by my definition anyway ;)). These image reconstruction algorithms do similar. Maybe in visual terms, I'd say blurring was interpolation on a scale larger than one pixel, and anything interpolating on the subpixel level would count as AA. No, that's not true, as QAA demonstrates.
 
Non-texture based shading. :p
What term in the shader? You can't just say "oh I put branches in my shader and they alias now aahhhh" - that's not news to anyone. What are you trying to accomplish that you absolutely can't prefilter nicely? We might be able to help :)

But yeah, I think it's pretty fair to say that for the vast majority of common blinn-phong + few tricks shaders, specular is the main culprit of aliasing. Alpha testing is obviously a big one too, but there are various known ways to address that branch as well (Humus' distance fields stuff is a good one).
 
If you want to attribute every artefact coming out of a shader to the shader itself .... LEAN-mapping specifically attempts to circumvent artefacts from linear filtering of reflectance-textures, that has nothing to do with the shader itself. The only way to fight shader-aliasing are sub-pixel shaders, aka supersampling above it's Nyquist frequency. I'm a bit surprised about the seemingly "redefinition" or "relaxation" of the meaning of shader-aliasing. A shader is not some simply texture-passthrough logic which could be made aliasing free soley through LEAN-mapping (hypothetically saying the LEAN-approach could be generally applied to any texture).

But I guess that's not what you meant.

I can't speak for anyone else here, but I've always used the term "shader aliasing" for issues that come about due to fragment shaders being run at an insufficient sampling rate (as opposed to geometry aliasing issues which come from rasterizing at an insufficient sampling rate). Since fragment shaders drive texture sampling, I don't think it's really weird to throw in texture sampling/filtering issues in there as well. So if you get specular aliasing from being unable to sample a normal map at a sufficient frequency, I'd call it shader aliasing. I also don't think it's particularly weird to consider filtering a means of antialiasing, since we've been doing that for years with mipmaps and shadow maps.

But I agree with Alstrong that we're really just discussing semantics here. :p
 
What term in the shader? You can't just say "oh I put branches in my shader and they alias now aahhhh" - that's not news to anyone. What are you trying to accomplish that you absolutely can't prefilter nicely? We might be able to help :)

Let's say I output this:
OUT.Color.rgb = 0.5 * normalize(-cross(ddx(IN.location.xyz), ddy(IN.location.xyz))) + 0.5;

How can I remove aliasing without supersampling? Of course I'd only have problems at the polygon-edges.

Then I have a procedual checker-box generator, or I threshold a texture via a step().

How can I remove aliasing without supersampling? Taking more samples and blending them is ... supersampling, just manually. And it probably is still slightly wrong sampled at the polygon-edges (even with MSAA).

Well, anyway, I don't want to fabricate artificial cases. I believe you when you say it's basically a solved thing. I didn't yet accumulate much experience by broad real-world shader-authoring.
 
Let's say I output this:
OUT.Color.rgb = 0.5 * normalize(-cross(ddx(IN.location.xyz), ddy(IN.location.xyz))) + 0.5;

How can I remove aliasing without supersampling? Of course I'd only have problems at the polygon-edges.

Then I have a procedual checker-box generator, or I threshold a texture via a step().

How can I remove aliasing without supersampling?
In a past life (>20 years ago) when I was working on a ray tracing system, we knew the spread of the rays and so I used interval arithmetic to do a reasonable approximation to AA procedural textures.
 
FXAA for PC mod by some guy

beta version 2! directx 9, x86 only! incompatible with any other form of antialiasing!

What to do: Put all files into directory containing the game executable.

Keys:
Insert : Enable/Disable FXAA
Del : Screenshot
Download


Mass Effect: NoFXAA FXAA
Mass Effect 2: NoAA FXAA
Metro 2033@Dx9: NoAA FXAA
Mafia II: NoAA FXAA
Dirt 2: NoAA FXAA
Dirt 3: NoAA FXAA
Sacred 2: NoFXAA FXAA
Arcania: NoFXAA FXAA

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8862131&postcount=118
 
Last edited by a moderator:
Back
Top