Great article. Re: font rendering: didn't Sebastian Lague do a video demonstrating real-time bezier font rendering? He didn't invent the concept but, IIRC, you can use a per-glyph acceleration structure to compute per-pixel distance to only relevant bezier curves on a given scanline, meaning something like a handful of tests per pixel rather than iterating through every curve in the glyph.
Also, combining CSAA for small glyphs and MSDFs for large glyphs might be worth investigating.
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.
Blog posts are considerably less trustworthy sources than IEEE conference papers. Not to mention the actual whitepaper itself, with the fucking 2009 date at the top. Not to mention every other mention of 2009 as the date when the first version released. You just keep cherry picking random blog posts and version updates as "evidence" and ignoring all actual evidence. It's pretty tiring
Perhaps you are thinking of how Doom Eternal moved away from megatextures which was a significant change. There's two very nice graphical breakdowns for Doom 2016 and Doom Eternal which detail how forward rendering is used for opaque objects.
I am not a graphics programmer and I did not understand 100% of that but I found the read incredibly enjoyable and the demos and tone added well to the experience. Thanking for writing / sharing it.
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.
The PowerVR Series 1 and 2 was inherently triangle based.
Like most GPUs (even today) it does accept a quad primitive type, in additional to triangles. But this quad primitive is only meant to be used planar (flat) quads. Most GPUs implement this quad "support" with the simple hack of internally splitting quads into two triangles right before rasterization. It's more of a primitive compression format then anything else. If you try to render a non-planer quad, you get a visible fold along one of the diagonals.
But because of PowerVR's Tile-Based Deferred Rendering, it's handling of these out-of-spec non-planer quads is different. It only calculates surface equations based on only the first three vertices, discarding the depth, UV and color of the forth vertex. Instead of the fold down the diagonal, any inaccuracy would get worse the closer you got to that forth vertex, and could end up with very visible texture/color seams along two of the edges.
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.
dmgard@reddit
Great article. Re: font rendering: didn't Sebastian Lague do a video demonstrating real-time bezier font rendering? He didn't invent the concept but, IIRC, you can use a per-glyph acceleration structure to compute per-pixel distance to only relevant bezier curves on a given scanline, meaning something like a handful of tests per pixel rather than iterating through every curve in the glyph.
Also, combining CSAA for small glyphs and MSDFs for large glyphs might be worth investigating.
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)
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
badcookies@reddit
Ah yes, your source with a date of 07-09 January 2022
The only source is that it referenced the Feb 2009 from the whitepaper title lol
Xxehanort@reddit
Blog posts are considerably less trustworthy sources than IEEE conference papers. Not to mention the actual whitepaper itself, with the fucking 2009 date at the top. Not to mention every other mention of 2009 as the date when the first version released. You just keep cherry picking random blog posts and version updates as "evidence" and ignoring all actual evidence. It's pretty tiring
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.
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
chazzeromus@reddit
the mention of neotokyo is bringing a rush of nostalgia, there's dozens of us!
jezek_2@reddit
Yep, and the more amazing thing is that is still actively played. Every Friday night (sometimes also on Saturdays/Sundays).
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
dustarma@reddit
I thought Doom Eternal moved to a deferred pipeline.
jf908@reddit
Perhaps you are thinking of how Doom Eternal moved away from megatextures which was a significant change. There's two very nice graphical breakdowns for Doom 2016 and Doom Eternal which detail how forward rendering is used for opaque objects.
dustarma@reddit
I stand corrected then, thank you!
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.
AustinYQM@reddit
I am not a graphics programmer and I did not understand 100% of that but I found the read incredibly enjoyable and the demos and tone added well to the experience. Thanking for writing / sharing it.
MintPaw@reddit
If you fade out the edge pixels like that, won't that create a 1px gap between adjacent squares?
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.
phire@reddit
Ok, I looked into this, and it's interesting.
The PowerVR Series 1 and 2 was inherently triangle based.
Like most GPUs (even today) it does accept a quad primitive type, in additional to triangles. But this quad primitive is only meant to be used planar (flat) quads. Most GPUs implement this quad "support" with the simple hack of internally splitting quads into two triangles right before rasterization. It's more of a primitive compression format then anything else. If you try to render a non-planer quad, you get a visible fold along one of the diagonals.
But because of PowerVR's Tile-Based Deferred Rendering, it's handling of these out-of-spec non-planer quads is different. It only calculates surface equations based on only the first three vertices, discarding the depth, UV and color of the forth vertex. Instead of the fold down the diagonal, any inaccuracy would get worse the closer you got to that forth vertex, and could end up with very visible texture/color seams along two of the edges.
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
fix_wu@reddit
https://codepen.io/GrzegorzAndrys/pen/BaXgJag
yea but can you lose line here? antialising bug in 2dcanvas
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