Part of this article is completely wrong, and part of it is a bit disingenuous. FXAA is not "inspired" by MLAA. FXAA released 2 years before MLAA released. MSAA is not used in practically any modern renderer, because all modern renderers are deferred renderers and not forward renderers. This article suggests many times that MSAA is some kind of "holy grail" of anti aliasing, when it anything but (and doesn't even really work on modern engines)
Inspiration
FXAA was inspired by the AA work and up-coming work of many others,
“Subpixel Reconstruction Antialiasing”, Matthäus G. Chajdas (Technische
Universität München and NVIDIA), Morgan McGuire
(NVIDIA), David Luebke
(NVIDIA), to appear in i3D Febuary 2011
“Morphological Antialiasing”, Alexander Reshetov (Intel Labs)
http://visual-computing.intel
research.net/publications/papers/2009/mlaa/mlaa.pdf
“Practical Morphological Anti-Aliasing”, Jorge Jimenez, Belen Masia, Jose I.
Echevarria, Fernando Navarro, Diego Gutierrez, to appear in GPU Pro 2
http://www.iryoku.com/mlaa
It seems a bit odd to me that MLAA is listed as an inspiration here, as FXAA and MLAA were essentially developed at the same time. The section you highlighted does also mention that FXAA was inspired by some existing work and some up and coming work, which to me seems to refer to MLAA. I found after more searching that that the Intel MLAA paper did not release until August 2009, which was 7 months after FXAA was released. https://www.researchgate.net/publication/216813593_Morphological_antialiasing.
PowerVR did tile rendering which was a bit different than the rest at the time. I thought they did quads as well, but I might have just merged the two in my head today.
I believe that Matrox is still around in some form or another. My understanding is that they have a useful product in their older GPU models because they uses CPU RAM to hold the framebuffer and remote administration tools shipped by motherboard manufacturers can just tap into that for remote display.
At 1/8th resolution the results don't look perfect. My guess is that that is due to not taking into account the square shape of the pixel. (Of course the actual location of the colors depends on display type, so this is mostly interesting for rendering that has huge pixels on purpose.)
A axis-aligned line cutting through a pixel 1/4 from the center will cut away exactly 1/4 of the area but a line at a 45 degree angle will cut away a (sqrt(2)/2 - 0.25)^2 = 0.2... corner instead. So the error isn't huge, assuming the edges intersecting the pixel are roughly straight.
I looked at the source code and I can't find gamma correction anywhere. Could that be the reason why it looks slightly off?
Very cool, something I’ve wondered about. On first skim though I don’t see any discussion how analytic antialiasing deals with overlapping edges of shapes, which I’ve wondered at
Wow! The amount of work that must've gone into this post is quite astonishing!
A few thoughts:
* It would be nice to be able to pause the early animations, especially to count the number of transparency steps in the first super-sampling example.
* If the circle is not made of geometry, how does the MSAA work?
* SDF pixel size: could you use length(dFdx(uv.x), dFdy(uv.y))?
* Regarding "Don’t use smoothstep()" & "There is no curve to be witnessed here.": That would only be true for rectangular pixels and an axis-aligned edge that passes through that pixel. But neither are pixels little squares, nor are most edges perfectly axis-aligned.
* "Fixing blurring by sharpening, I find this a bit of graphics programming sin.": Couldn't agree more!
> It would be nice to be able to pause the early animations, especially to count the number of transparency steps in the first super-sampling example.
Thought another UI element would be too much, but you are right, I'll insert it.
> If the circle is not made of geometry, how does the MSAA work?
Through the analytical anti aliasing shader and "Alpha to Coverage". MSAA samples against the alpha, that the shader outputs.
> SDF pixel size: could you use length(dFdx(uv.x), dFdy(uv.y))?
Per Syntax, No. In GLSL `vec2()` is required, since `length()` takes only one argument. But regarding `dFdx(uv.x), dFdy(uv.y)`, yes, that also gives pixel size when run through `length()`
> Regarding "Don’t use smoothstep()" & "There is no curve to be witnessed here.": That would only be true for rectangular pixels and an axis-aligned edge that passes through that pixel. But neither are pixels little squares, nor are most edges perfectly axis-aligned.
Ohh, should have clarified that more. I don't mean the curve of the shape, but the function by which opacity is blended by distance. If you use `smoothstep()`, that function doesn't really have a chance to show itself in any meaningful way, no matter the orientation.
ThreeLeggedChimp@reddit
How common even is forward rendering today?
jf908@reddit
Doom Eternal and CS2 are 2 relatively recent yet pretty advanced examples of 3d games which use forward rendering
NuclearVII@reddit
A lot of UI stuff is forward rendered - just makes too much sense to do so.
theeth@reddit
As well as transparency passes for the same reason.
spezdrinkspiss@reddit
Persona 3 Reload being forward-rendered comes to mind
MartinLaSaucisse@reddit
It made a big comeback a few years ago and is now used wildly in many engines including AAA games.
Xxehanort@reddit
Part of this article is completely wrong, and part of it is a bit disingenuous. FXAA is not "inspired" by MLAA. FXAA released 2 years before MLAA released. MSAA is not used in practically any modern renderer, because all modern renderers are deferred renderers and not forward renderers. This article suggests many times that MSAA is some kind of "holy grail" of anti aliasing, when it anything but (and doesn't even really work on modern engines)
R1chterScale@reddit
Makes me cry every time, I miss good AA. Hope that we do see games using clustered forward more as time goes on.
uss_wstar@reddit
MSAA is rubbish though.
It's not even compatible with shadow maps.
badcookies@reddit
https://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf
Xxehanort@reddit
It seems a bit odd to me that MLAA is listed as an inspiration here, as FXAA and MLAA were essentially developed at the same time. The section you highlighted does also mention that FXAA was inspired by some existing work and some up and coming work, which to me seems to refer to MLAA. I found after more searching that that the Intel MLAA paper did not release until August 2009, which was 7 months after FXAA was released. https://www.researchgate.net/publication/216813593_Morphological_antialiasing.
badcookies@reddit
That whitepaper was released in 2011
Xxehanort@reddit
At the top of the paper it reads "February 2009". Which is when it originally released. It was revised over the next 2 years.
badcookies@reddit
Yes and that could be from the template, it says "Initial release" in Jan 2011.
If it was revised often, it would have been updated in that section no?
Can you cite any sources showing it earlier than 2011?
Not to mention its silly, as its clearly inspired by it when it says it was :D
Xxehanort@reddit
Ironic, because you will not admit that you are wrong. It's pretty clear that FXAA was originally released in 2009.
https://ieeexplore.ieee.org/document/9730249
Its okay to admit you were wrong :D
RauBurger@reddit
I think you might have that backwards. MLAA was first published in 2009 as a conference paper: https://dl.acm.org/doi/proceedings/10.1145/1572769#sec5
And NVIDIA didn’t publish the FXAA white paper till 2011: https://developer.download.nvidia.com/assets/gamedev/files/sdk/11/FXAA_WhitePaper.pdf
Hell, the FXAA white paper even directly cites the MLAA paper as an inspiration.
Xxehanort@reddit
FXAA was initially introduced in 2009 by Lottes at Nvidia. It's current, final version was released in 2011.
https://ieeexplore.ieee.org/document/9730249
badcookies@reddit
That version of MLAA was called Jimenez's MLAA as it was different from Intel's version that released years earlier
https://www.realtimerendering.com/blog/morphological-antialiasing/
Blog from 2009 using Intel's code that they had released (urls now dead, but both show 2009 in the url as well)
Xxehanort@reddit
Ahh, that's where I made my mistake when attempting to look this up. I didn't see that Intel released a version in 2009.
RauBurger@reddit
I literately linked the conference proceedings with the MLAA paper right there. I.... what....
RauBurger@reddit
Cool, so not 2 years before MLAA, the same year as MLAA
fix_wu@reddit
https://codepen.io/GrzegorzAndrys/pen/BaXgJag
yea but can you lose line here? antialising bug in 2dcanvas
othermike@reddit
There was also Nvidia's very first card, the NV1, which used quadratic surfaces. (And didn't sell very well.)
BlindTreeFrog@reddit
PowerVR, which was used in the Sega Dreamcast and a few Maxor viedo cards, used Quads as well.
Amaroko@reddit
Never heard of that. Source, please.
BlindTreeFrog@reddit
You might be right.
PowerVR did tile rendering which was a bit different than the rest at the time. I thought they did quads as well, but I might have just merged the two in my head today.
chucker23n@reddit
A lot of SoCs also use PowerVR (instead of, say, Mali).
Do you mean Matrox?
BlindTreeFrog@reddit
I do, I was confusing Matrox and Maxar in my head for some unknown reason.
ggppjj@reddit
I believe that Matrox is still around in some form or another. My understanding is that they have a useful product in their older GPU models because they uses CPU RAM to hold the framebuffer and remote administration tools shipped by motherboard manufacturers can just tap into that for remote display.
HolyPommeDeTerre@reddit
I loved the Sega Saturn !
Not that it has anything to do with the subject
chazzeromus@reddit
the mention of neotokyo is bringing a rush of nostalgia, there's dozens of us!
drekmonger@reddit
Incredible article. Thank you for writing and sharing it.
joonazan@reddit
At 1/8th resolution the results don't look perfect. My guess is that that is due to not taking into account the square shape of the pixel. (Of course the actual location of the colors depends on display type, so this is mostly interesting for rendering that has huge pixels on purpose.)
A axis-aligned line cutting through a pixel 1/4 from the center will cut away exactly 1/4 of the area but a line at a 45 degree angle will cut away a
(sqrt(2)/2 - 0.25)^2 = 0.2...corner instead. So the error isn't huge, assuming the edges intersecting the pixel are roughly straight.I looked at the source code and I can't find gamma correction anywhere. Could that be the reason why it looks slightly off?
SkoomaDentist@reddit
That'd easily explain it. Any anti-aliasing suffers significantly if it ignores gamma.
frenris@reddit
Very cool, something I’ve wondered about. On first skim though I don’t see any discussion how analytic antialiasing deals with overlapping edges of shapes, which I’ve wondered at
HolyPommeDeTerre@reddit
Impressive work. Thank you !
jimanri@reddit
Jesus, this is an incredible source, I wil try out at some time to implement this in godot
Positive_Method3022@reddit
Bro is a genius.
perfecthashbrowns@reddit
Insane post, thank you 🥰Gonna read this a couple times as this is super useful to me.
Full-Spectral@reddit
Very nice work
ZippityZipZapZip@reddit
That's some rare juicy content.
Good_day_to_be_gay@reddit
r/fucktaa
Isogash@reddit
Excellent quality article, thanks for the post!
Kaloffl@reddit
Wow! The amount of work that must've gone into this post is quite astonishing!
A few thoughts: * It would be nice to be able to pause the early animations, especially to count the number of transparency steps in the first super-sampling example. * If the circle is not made of geometry, how does the MSAA work? * SDF pixel size: could you use
length(dFdx(uv.x), dFdy(uv.y))? * Regarding "Don’t usesmoothstep()" & "There is no curve to be witnessed here.": That would only be true for rectangular pixels and an axis-aligned edge that passes through that pixel. But neither are pixels little squares, nor are most edges perfectly axis-aligned. * "Fixing blurring by sharpening, I find this a bit of graphics programming sin.": Couldn't agree more!Frost-Kiwi@reddit (OP)
Thanks for the kind words.
> It would be nice to be able to pause the early animations, especially to count the number of transparency steps in the first super-sampling example.
Thought another UI element would be too much, but you are right, I'll insert it.
> If the circle is not made of geometry, how does the MSAA work?
Through the analytical anti aliasing shader and "Alpha to Coverage". MSAA samples against the alpha, that the shader outputs.
> SDF pixel size: could you use
length(dFdx(uv.x), dFdy(uv.y))?Per Syntax, No. In GLSL `vec2()` is required, since `length()` takes only one argument. But regarding `
dFdx(uv.x), dFdy(uv.y)`, yes, that also gives pixel size when run through `length()`> Regarding "Don’t use
smoothstep()" & "There is no curve to be witnessed here.": That would only be true for rectangular pixels and an axis-aligned edge that passes through that pixel. But neither are pixels little squares, nor are most edges perfectly axis-aligned.Ohh, should have clarified that more. I don't mean the curve of the shape, but the function by which opacity is blended by distance. If you use `smoothstep()`, that function doesn't really have a chance to show itself in any meaningful way, no matter the orientation.
Revolutionary_Ad7262@reddit
Excellent quality