Depends on what you mean by "mesh". Each road segment is an instanced rectangle that gets extruded and beveled so that it fits tightly against adjacent segments, and then the pixels are shaded using AAA (with a capsule-shaped distance field) so that the result looks like an antialiased wide line with round end caps and joints.
> Do you have advice on linear vs srgb space antialiasing?
Unfortunately, this is completely context dependent. One central point is, whether or not the graphics pipeline is instructed to perform corrections (GL_FRAMEBUFFER_SRGB in OpenGL), as that changes the answer. Another point is, in which context blending is performed. Luckily the developer has full freedom here and can even specify separate blending for alpha and color [1], something that GPU accelerated terminal emulator Alacritty makes use of [2], though it doesn't do MSDF rendering.
One thing I can say though: The alpha, the fading of edge, has to be linear at the end or perceived as such. Or rather if the edge were to be stretched to 10 pixels, each pixel has to be a 0.1 alpha step. (If smoothstep is used, the alpha has to follow that curve at the end) Otherwise the Anti-Aliasing will be strongly diminished. This is something you can always verify at the end. Correct blending of colors is of course a headache and context specific.
> fonts have been tweaked to compensate, so sometimes srgb is better
This should not concern MSDF rendering. These tweaks happened at specific resolutions with monitors popular at that time. Especially when considering HiDPI modes of modern window systems, all bets are off, DPI scaling completely overthrows any of that. MSDF is size independent and the "tweaks" are mainly thickness adjustments, which MSDF has control over. So if the font doesn't match as it looks in another rendering type, MSDF can correct for it.
Great post! Minor nitpick: WebGL does support MSAA since WebGL1, but in WebGL1 only on the canvas, and you don't have any control over the number of samples (can only select antialiasing on/off) - not that it matters much anymore :)
What WebGL2 is still missing is MSAA texture objects (it only supports MSAA render buffers), which makes it impossible to directly load individual samples in a shader (useful for custom-resolve render passes). That's only possible in WebGPU.
Thank you for the excellent writeup, terrific work!
> Whole communities rally around fixing this, like the reddit communities “r/MotionClarity” or the lovingly titled “r/FuckTAA”, all with the understanding, that Anti-Aliasing should not come at the cost of clarity. FXAA creator Timothy Lottes mentioned, that this is solvable to some degree with adjustments to filtering, though even the most modern titles suffer from this.
I certainly agree that the current trend of relying on upscalers has gone too far and results in blurry and artifact riddled AAA game experiences for many. But after seeing this [1] deep dive by Digital foundry I find the arguments he makes quite compelling. There is a level of motion stability and clarity only tech like DLSS can achieve, even outperforming SSAA. So I've shifted my stance from TAA == blurry, TAA + ML when used right == best AA possible currently for 3D games.
Disclaimer: I haven't really played games with high-end graphics on a high-end system in over a decade, and have always had more of a soft spot for games that use beautiful art design to work around the limitations of "underpowered" systems (IMO the graphics in those games hold up much better throughout the decades anyway). And as I mentioned elsewhere I'm generally quite lost when it comes to AA names and abbreviations. It would be disingenuous of me to tell a community I'm not part of what the best solution is for them.
However, on a meta-level I find something like “r/FuckTAA” fundamentally entitled and ungrateful to the people who put years of their lives into making these games. Of course the loudest gamers tend to be smaller subgroup of the entitled toxic ones, so perception is distorted anyway. Plus, I do get it to some degree: if you invest a lot of money and time into powerful hardware to get beautiful graphics, you'd like to actually get beautiful graphics out of it.
Still, every time I read any article on the technical workings of modern graphics, it strikes me as a community full of extremely passionate people who care about squeezing beautiful graphics out of the available hardware. There are nicer ways to say "sorry but this particular technical solution/aesthetic trend doesn't vibe with me".
(Obviously this is not aimed at your nuanced take with a sincere question for discussion. And thank you for the link, will watch, because the tech still is an interesting topic to me even if I don't play these types of games)
I mostly understand your perspective here from a developer point-of-view. I'd like to give you some perspective of /r/FuckTAA and similar views from the gamers' perspective.
What many gamers see in TAA and other anti-aliasing options is higher system requirements and worse image quality. Obviously, this isn't just caused by one factor but it's very noticeable if you compare games now to the games of yesteryear.
Modern graphics are generally less "accurate" in terms of rendering in exchange of way better visual effects like raytracing and better shading. There's a fairly linear progression of rendering quality throughout the history of 3D rendering. Games like Half-Life 2, Halo and the first CoDs had mostly exact forward rendering, the shading was fairly simple but the rendered image did not have spatial or temporal artifacts. Individual pixels could be discerned too. If you increased the resolution, you got a crisp image with crisp UI. These games usually used SSAA, MSAA or CSAA. These methods were very expensive because they effectively rendered at a higher resolution, they could have had double the shading cost.
(I know that MSAA only does it for the edges but I'm keeping the explanation fairly simple)
Next, developers started to switch to framebuffer-based methods (FXAA and SMAA). These introduced blur to the edges of objects which was a downgrade in terms of image clarity. However, these methods are fairly fast and the games didn't exhibit motion-based artifacts.
The shader is relatively fast and the only real cost is an extra framebuffer in memory - which the game already probably had for other post-processing effects.
Developers also started to use deferred rendering and more buffers in general. This led to an explosive growth of VRAM usage, so for optimisation purposes, they started using the console methods of checkerboard rendering and lower-resolution buffers. A good example of this is GTA V where you can see many dithering artifacts in the distance and a generally blurrier picture. These games still didn't have temporal artifacts - looking around did not generally reduce the image quality.
Graphical demands only got more intense, so developers started to "cheat" with forms of temporal anti-aliasing, which (as in the name) introduce temporal artifacts to the image. The stereotypical poster-child for this is Unreal Engine - it's seriously impressive in many aspects but developers just started to slap TAA on everything instead of optimising their shaders and LoDs. TAA is not really one single method - it can really vary in quality based on how many past frames are used, how artifacts are removed, etc.
A while ago, NVIDIA introduced DLSS and (real-time) Ray Tracing, which changed things quite a lot. With these techniques, not even the final framebuffer is at native resolution, but is instead being upscaled from a lower-resolution framebuffer using ML-based methods. Ray tracing also requires denoising because it's infeasible to raytrace every pixel in native resolution. It works surprisingly well, but there's another reduction in clarity. And of course, since the image is effectively being reconstructed (twice!), the temporal effects are horrible, even moving the cursor around can produce nauseating artifacts on more complex objects.
Currently, the gaming industry is at a stage where the massively better GPUs are not used to progressively enhance games but to cut corners and reduce the rendering quality for everyone. Games even use DLSS for their recommended system requirements now instead of being an optional enhancer for weaker GPUs. Currently, if you don't have a top-end GPU (4080 or 4090, basically), you have to make heavy compromises in the newest games in terms of image quality or use DLSS, even without RT. I predict that in the future, even top-end GPUs like the 5090 or 6090 will have to use DLSS to get playable framerates in 1440p with acceptable graphics, not just in 4K.
There is a reason why quite a few people are pissed off. Obviously, they might not know the exact causes of these problems but it's easy to see a correlation of TAA in game - bad rendering quality and choppy FPS, so they scapegoat that. I can't really blame them, I don't think it's realistic to expect gamers to be intimately familiar with the render pipeline.
I have done a few live visualization based blog posts, and they take me ages to do. I kind of think that's the right idea though. There is so much content out there, taking longer to produce less content at a higher quality benefits everyone.
The commit history [1] reveals that, took a while. I don't write professionally, something I do in lunch breaks from time to time. Thanks for the kind words.
One small bit of tecnical feedback for the website itself: it would be nice if the links in the article open in a new tab by default, because reloading the webpage via the back button is a little broken on my mobile browsers. I suspect it has something to do with trying to restore the state of the page while also having WebGL contexts.
Also, forgot to mention that I really enjoyed the article, and I'm not even a gamer! You're totally right in that the graphics community is a lovely one to follow on a technical level, even if you don't play games. Articles like yours are part of the reason for that
Basically no... Analytic AA is a really hard problem for video games, and I know of no general purpose solutions.
For font and 2D vector rendering it's likely, in fact afaik, some solutions, such as Slug already do.
But for 3d rendering I don't know of any solutions.
For an intuition, consider two triangles that intersect the same pixel.
Consider if say one has 20% coverage and the other 30%, does that pixel have 50% coverage, 30% by one, 20% by one and 10% by another, or any other conceivable mix? It's very difficult to say without selecting specific points and sampling directly.
I tried to do this for polygons rendered aliased by computing edge position and reweighting pixel colours. It looks great when polygons are large but it breaks for small polygons (when polygon size is close to pixel size)
Not a question but some unsolicited (sorry) feedback. The intro seems designed to set people up for disappointment. You start off by talking about AA methods used for 3D scenes, and you've picked a very cool way to present them... but the article is actually about antialiased drawing of SDFs, which is not exactly a hard problem and not applicable to 3D scenes. Unless your scene is made up of SDF shapes, but I don't think the method you're presenting would be fast enough on a nontrivial scene as you would need to rely on alpha-blending across seams. (I think Alex Evans' talk on Dreams mentions they tried something similar to get fuzzy shapes but dropped it due to perf and sorting issues.) In any case, it would have been nice for the article's intro to more clearly say what it's about and what the technique is useful for.
True, this is something I struggled with writing and ended up with just a small note commenting that this is not widely applicable. Will clarify more in coming posts. It's all incredibly context specific. The reason for this order, is that you can very much can use all these approaches (SSAA, FXAA, MSAA etc.) for rendering simpler shapes and HUDs. So going through them, where these approaches break down and when it does make sense to go the extra mile with SDFs.
Still, non-standard rendering approaches are very much a thing [1] and I could see setups like [2] be used in scientific particle visualizations.
Great write up, excellent explorables. I skimmed some parts so forgive me if this was covered, but I wonder what happens with overlapping shapes in this approach. For example, a white background with a black disc and then a white disc of the exact same size and position would probably leave a fuzzy gray hairline circle? With regular antialiasing it should be all white.
What happens during overlap, is something you control fully, at every step. (Except when using this with MSAA, as that is implementation defined)
How intersections happen when blending shapes of multiple draw calls or multiple quads is defined by the blending function you set before issuing the draw call. In WebGL the call is blendFunc() [1] and there are a bunch of options.
How to blend multiple shapes on the same quad, within a draw call is shown in the section "Drawing multiple?". There you fully control the intersection with the blending math.
Finally, there is always the gamma question, which is true for all AA solutions. This is not covered in the post, but that might mess with the results, as is true for any kind of blending.
I think the point is that a correct analytical result needs to be computed for all shapes at once. You can't composite overlapping shapes individually, since the alpha value (subpixel coverage), even if analytically correct, is lossy; you lose the information about the exact subpixel geometry, which is needed to do correct compositing (eg. does this shape completely occlude this other one within this pixel?). The standard Porter-Duff blend function assumes the subpixel geometry is a uniform random mist, which is not necessarily a great assumption for AA.
Can you elaborate a bit on the tech-stack used for this blog? I didn't find any hints in the source (but I'm not an expert). Is it some known framework? What does the input look like (Markdown etc).?
The blog is built with eleventy https://www.11ty.dev/ and as the previous reply already mentioned, the source code is on GitHub [2].
All posts are single Markdown file each with HTML inserted where I need it. The javascript for the demos is custom and changes from post to post. The basic style comes from Sakura CSS [3] with a bunch of custom stuff on top.
Yes, that also surprised me and I tested it on multiple mobile Apple devices. It's not really a mistake per se, the implementation is free to do what it wants. Selecting MSAAx2 on these types of mobile GPUs simply has no upside and isn't really supported over MSAAx4 and I guess apple still wanted to make the choice somehow possible, as opposed to Android, where there is only an illusion of choice.
It's just so happens to produce visible artifacts in this case. I suppose for 3D scenes it's mostly fine.
Massive thanks for this! I’m already using my own version of analytical antialiasing but there were some bits I couldn’t get quite right so this is perfect!
Sorry, was most likely funnier in my head then it really is, but I was committed to the bit once I had the idea. I was exited to see Neotokyo mention somewhere popular.
NeoTokyo and Dystopia regulars compete in each others tournaments and are always looking forward to new players :)
Biggest Tournament of the year:
- 5v5 matches of ~4-6 teams
- broadcasted on twitch with
- 1 camera person
- 2-3 casters/commentators
- definitely overproduced
- to an audience of 15-25
Google Maps uses AAA on capsule shapes for all road segments - I wrote it ~10 years ago. :D
Neat. Does that mean that every road segment is a separate mesh?
Depends on what you mean by "mesh". Each road segment is an instanced rectangle that gets extruded and beveled so that it fits tightly against adjacent segments, and then the pixels are shaded using AAA (with a capsule-shaped distance field) so that the result looks like an antialiased wide line with round end caps and joints.
2 replies →
That's awesome! Added this as an addendum to the post.
Fantastic article! I've been trying to figure out antialiasing for MSDF fonts, and have run across some claims:
1. antialiasing should be done in linear rgb space instead of srgb space [1] [2]
2. because of the lack of (1) for decades, fonts have been tweaked to compensate, so sometimes srgb is better [3] [4]
Do you have advice on linear vs srgb space antialiasing?
[1] http://hikogui.org/2022/10/24/the-trouble-with-anti-aliasing...
> Do you have advice on linear vs srgb space antialiasing?
Unfortunately, this is completely context dependent. One central point is, whether or not the graphics pipeline is instructed to perform corrections (GL_FRAMEBUFFER_SRGB in OpenGL), as that changes the answer. Another point is, in which context blending is performed. Luckily the developer has full freedom here and can even specify separate blending for alpha and color [1], something that GPU accelerated terminal emulator Alacritty makes use of [2], though it doesn't do MSDF rendering.
One thing I can say though: The alpha, the fading of edge, has to be linear at the end or perceived as such. Or rather if the edge were to be stretched to 10 pixels, each pixel has to be a 0.1 alpha step. (If smoothstep is used, the alpha has to follow that curve at the end) Otherwise the Anti-Aliasing will be strongly diminished. This is something you can always verify at the end. Correct blending of colors is of course a headache and context specific.
> fonts have been tweaked to compensate, so sometimes srgb is better
This should not concern MSDF rendering. These tweaks happened at specific resolutions with monitors popular at that time. Especially when considering HiDPI modes of modern window systems, all bets are off, DPI scaling completely overthrows any of that. MSDF is size independent and the "tweaks" are mainly thickness adjustments, which MSDF has control over. So if the font doesn't match as it looks in another rendering type, MSDF can correct for it.
[1] https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender...
[2] https://github.com/search?q=repo%3Aalacritty%2Falacritty+ble...
Great post! Minor nitpick: WebGL does support MSAA since WebGL1, but in WebGL1 only on the canvas, and you don't have any control over the number of samples (can only select antialiasing on/off) - not that it matters much anymore :)
What WebGL2 is still missing is MSAA texture objects (it only supports MSAA render buffers), which makes it impossible to directly load individual samples in a shader (useful for custom-resolve render passes). That's only possible in WebGPU.
Thank you for the excellent writeup, terrific work!
> Whole communities rally around fixing this, like the reddit communities “r/MotionClarity” or the lovingly titled “r/FuckTAA”, all with the understanding, that Anti-Aliasing should not come at the cost of clarity. FXAA creator Timothy Lottes mentioned, that this is solvable to some degree with adjustments to filtering, though even the most modern titles suffer from this.
I certainly agree that the current trend of relying on upscalers has gone too far and results in blurry and artifact riddled AAA game experiences for many. But after seeing this [1] deep dive by Digital foundry I find the arguments he makes quite compelling. There is a level of motion stability and clarity only tech like DLSS can achieve, even outperforming SSAA. So I've shifted my stance from TAA == blurry, TAA + ML when used right == best AA possible currently for 3D games.
Thoughts?
[1] https://youtu.be/WG8w9Yg5B3g
Disclaimer: I haven't really played games with high-end graphics on a high-end system in over a decade, and have always had more of a soft spot for games that use beautiful art design to work around the limitations of "underpowered" systems (IMO the graphics in those games hold up much better throughout the decades anyway). And as I mentioned elsewhere I'm generally quite lost when it comes to AA names and abbreviations. It would be disingenuous of me to tell a community I'm not part of what the best solution is for them.
However, on a meta-level I find something like “r/FuckTAA” fundamentally entitled and ungrateful to the people who put years of their lives into making these games. Of course the loudest gamers tend to be smaller subgroup of the entitled toxic ones, so perception is distorted anyway. Plus, I do get it to some degree: if you invest a lot of money and time into powerful hardware to get beautiful graphics, you'd like to actually get beautiful graphics out of it.
Still, every time I read any article on the technical workings of modern graphics, it strikes me as a community full of extremely passionate people who care about squeezing beautiful graphics out of the available hardware. There are nicer ways to say "sorry but this particular technical solution/aesthetic trend doesn't vibe with me".
(Obviously this is not aimed at your nuanced take with a sincere question for discussion. And thank you for the link, will watch, because the tech still is an interesting topic to me even if I don't play these types of games)
I mostly understand your perspective here from a developer point-of-view. I'd like to give you some perspective of /r/FuckTAA and similar views from the gamers' perspective.
What many gamers see in TAA and other anti-aliasing options is higher system requirements and worse image quality. Obviously, this isn't just caused by one factor but it's very noticeable if you compare games now to the games of yesteryear.
Here is a good collection of anti-aliasing methods. https://www.pcgamingwiki.com/wiki/Glossary:Anti-aliasing_(AA...
Modern graphics are generally less "accurate" in terms of rendering in exchange of way better visual effects like raytracing and better shading. There's a fairly linear progression of rendering quality throughout the history of 3D rendering. Games like Half-Life 2, Halo and the first CoDs had mostly exact forward rendering, the shading was fairly simple but the rendered image did not have spatial or temporal artifacts. Individual pixels could be discerned too. If you increased the resolution, you got a crisp image with crisp UI. These games usually used SSAA, MSAA or CSAA. These methods were very expensive because they effectively rendered at a higher resolution, they could have had double the shading cost. (I know that MSAA only does it for the edges but I'm keeping the explanation fairly simple)
Next, developers started to switch to framebuffer-based methods (FXAA and SMAA). These introduced blur to the edges of objects which was a downgrade in terms of image clarity. However, these methods are fairly fast and the games didn't exhibit motion-based artifacts. The shader is relatively fast and the only real cost is an extra framebuffer in memory - which the game already probably had for other post-processing effects.
Developers also started to use deferred rendering and more buffers in general. This led to an explosive growth of VRAM usage, so for optimisation purposes, they started using the console methods of checkerboard rendering and lower-resolution buffers. A good example of this is GTA V where you can see many dithering artifacts in the distance and a generally blurrier picture. These games still didn't have temporal artifacts - looking around did not generally reduce the image quality.
Graphical demands only got more intense, so developers started to "cheat" with forms of temporal anti-aliasing, which (as in the name) introduce temporal artifacts to the image. The stereotypical poster-child for this is Unreal Engine - it's seriously impressive in many aspects but developers just started to slap TAA on everything instead of optimising their shaders and LoDs. TAA is not really one single method - it can really vary in quality based on how many past frames are used, how artifacts are removed, etc.
A while ago, NVIDIA introduced DLSS and (real-time) Ray Tracing, which changed things quite a lot. With these techniques, not even the final framebuffer is at native resolution, but is instead being upscaled from a lower-resolution framebuffer using ML-based methods. Ray tracing also requires denoising because it's infeasible to raytrace every pixel in native resolution. It works surprisingly well, but there's another reduction in clarity. And of course, since the image is effectively being reconstructed (twice!), the temporal effects are horrible, even moving the cursor around can produce nauseating artifacts on more complex objects.
Currently, the gaming industry is at a stage where the massively better GPUs are not used to progressively enhance games but to cut corners and reduce the rendering quality for everyone. Games even use DLSS for their recommended system requirements now instead of being an optional enhancer for weaker GPUs. Currently, if you don't have a top-end GPU (4080 or 4090, basically), you have to make heavy compromises in the newest games in terms of image quality or use DLSS, even without RT. I predict that in the future, even top-end GPUs like the 5090 or 6090 will have to use DLSS to get playable framerates in 1440p with acceptable graphics, not just in 4K.
There is a reason why quite a few people are pissed off. Obviously, they might not know the exact causes of these problems but it's easy to see a correlation of TAA in game - bad rendering quality and choppy FPS, so they scapegoat that. I can't really blame them, I don't think it's realistic to expect gamers to be intimately familiar with the render pipeline.
1 reply →
How long did this take to write?
I have done a few live visualization based blog posts, and they take me ages to do. I kind of think that's the right idea though. There is so much content out there, taking longer to produce less content at a higher quality benefits everyone.
The commit history [1] reveals that, took a while. I don't write professionally, something I do in lunch breaks from time to time. Thanks for the kind words.
[1] https://github.com/FrostKiwi/treasurechest/commits/main/post...
One small bit of tecnical feedback for the website itself: it would be nice if the links in the article open in a new tab by default, because reloading the webpage via the back button is a little broken on my mobile browsers. I suspect it has something to do with trying to restore the state of the page while also having WebGL contexts.
Ohh right! I'm sure the must be an Eleventy setting for that...
Hope it's not too much of a hassle.
Also, forgot to mention that I really enjoyed the article, and I'm not even a gamer! You're totally right in that the graphics community is a lovely one to follow on a technical level, even if you don't play games. Articles like yours are part of the reason for that
As a non-gamedev person but just gamer, I should expect that this will replace TAA anytime soon? Should it replace TAA?
Basically no... Analytic AA is a really hard problem for video games, and I know of no general purpose solutions.
For font and 2D vector rendering it's likely, in fact afaik, some solutions, such as Slug already do.
But for 3d rendering I don't know of any solutions.
For an intuition, consider two triangles that intersect the same pixel.
Consider if say one has 20% coverage and the other 30%, does that pixel have 50% coverage, 30% by one, 20% by one and 10% by another, or any other conceivable mix? It's very difficult to say without selecting specific points and sampling directly.
There're already games fully using SDF rendering, such as Dreams [0]. It even made a SIGGRAPH talk [1].
[0] https://en.wikipedia.org/wiki/Dreams_(video_game)
[1] https://www.youtube.com/watch?v=u9KNtnCZDMI
1 reply →
I tried to do this for polygons rendered aliased by computing edge position and reweighting pixel colours. It looks great when polygons are large but it breaks for small polygons (when polygon size is close to pixel size)
Not a question but some unsolicited (sorry) feedback. The intro seems designed to set people up for disappointment. You start off by talking about AA methods used for 3D scenes, and you've picked a very cool way to present them... but the article is actually about antialiased drawing of SDFs, which is not exactly a hard problem and not applicable to 3D scenes. Unless your scene is made up of SDF shapes, but I don't think the method you're presenting would be fast enough on a nontrivial scene as you would need to rely on alpha-blending across seams. (I think Alex Evans' talk on Dreams mentions they tried something similar to get fuzzy shapes but dropped it due to perf and sorting issues.) In any case, it would have been nice for the article's intro to more clearly say what it's about and what the technique is useful for.
True, this is something I struggled with writing and ended up with just a small note commenting that this is not widely applicable. Will clarify more in coming posts. It's all incredibly context specific. The reason for this order, is that you can very much can use all these approaches (SSAA, FXAA, MSAA etc.) for rendering simpler shapes and HUDs. So going through them, where these approaches break down and when it does make sense to go the extra mile with SDFs.
Still, non-standard rendering approaches are very much a thing [1] and I could see setups like [2] be used in scientific particle visualizations.
[1] https://www.youtube.com/watch?v=9U0XVdvQwAI
[2] https://bgolus.medium.com/rendering-a-sphere-on-a-quad-13c92...
Great write up, excellent explorables. I skimmed some parts so forgive me if this was covered, but I wonder what happens with overlapping shapes in this approach. For example, a white background with a black disc and then a white disc of the exact same size and position would probably leave a fuzzy gray hairline circle? With regular antialiasing it should be all white.
What happens during overlap, is something you control fully, at every step. (Except when using this with MSAA, as that is implementation defined) How intersections happen when blending shapes of multiple draw calls or multiple quads is defined by the blending function you set before issuing the draw call. In WebGL the call is blendFunc() [1] and there are a bunch of options.
How to blend multiple shapes on the same quad, within a draw call is shown in the section "Drawing multiple?". There you fully control the intersection with the blending math.
Finally, there is always the gamma question, which is true for all AA solutions. This is not covered in the post, but that might mess with the results, as is true for any kind of blending.
[1] https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender...
I think the point is that a correct analytical result needs to be computed for all shapes at once. You can't composite overlapping shapes individually, since the alpha value (subpixel coverage), even if analytically correct, is lossy; you lose the information about the exact subpixel geometry, which is needed to do correct compositing (eg. does this shape completely occlude this other one within this pixel?). The standard Porter-Duff blend function assumes the subpixel geometry is a uniform random mist, which is not necessarily a great assumption for AA.
If you fade out the edge pixels like that, won't that create a 1px gap between adjacent squares? What do you do about that?
I think this is the same method Skia uses, and it doesn't work for rendering vectors from SWF files in my experience because of this problem.
Can you elaborate a bit on the tech-stack used for this blog? I didn't find any hints in the source (but I'm not an expert). Is it some known framework? What does the input look like (Markdown etc).?
The blog is built with eleventy https://www.11ty.dev/ and as the previous reply already mentioned, the source code is on GitHub [2]. All posts are single Markdown file each with HTML inserted where I need it. The javascript for the demos is custom and changes from post to post. The basic style comes from Sakura CSS [3] with a bunch of custom stuff on top.
[1] https://www.11ty.dev/
[2] https://github.com/FrostKiwi/treasurechest
[3] https://github.com/oxalorg/sakura
Not the parent, but seems this is the source code for the blog. https://github.com/FrostKiwi/treasurechest
Found it by going to the comments since the comments are GitHub issues the "x comment" is a link to the issues page.
> Mobile chips support exactly MSAAx4 [...] the driver will force 4x anyways
On what GPUs and through what APIs did you see this? This seems fairly weird. I especially wouldn't expect Apple to have problems.
Yes, that also surprised me and I tested it on multiple mobile Apple devices. It's not really a mistake per se, the implementation is free to do what it wants. Selecting MSAAx2 on these types of mobile GPUs simply has no upside and isn't really supported over MSAAx4 and I guess apple still wanted to make the choice somehow possible, as opposed to Android, where there is only an illusion of choice.
It's just so happens to produce visible artifacts in this case. I suppose for 3D scenes it's mostly fine.
I’m definitely seeing similar artifacts when at 2x on an iPhone 15 Pro.
Through Metal or in a web browser? Apple's docs say it's supposed to use the standard 0.75/0.25 sample positions with 2x MSAA: https://developer.apple.com/documentation/metal/mtldevice/28...
1 reply →
Massive thanks for this! I’m already using my own version of analytical antialiasing but there were some bits I couldn’t get quite right so this is perfect!
I would love to connect on some ideas around using antialiasing as a way to extend inference in extracting information from computer vision outputs.
What an absolutely fantastic read.
"A scene from my favorite piece of software in existence: NeoTokyo°."
I am sorry, but may I ask you, do you uphold your duties as a NeoTokyo fan, by promoting both the 2 best (un-)dead Source Mods, NeoTokyo and Dystopia?
https://store.steampowered.com/app/17580/Dystopia/ https://store.steampowered.com/app/244630/NEOTOKYO/
Sorry, was most likely funnier in my head then it really is, but I was committed to the bit once I had the idea. I was exited to see Neotokyo mention somewhere popular. NeoTokyo and Dystopia regulars compete in each others tournaments and are always looking forward to new players :)
Biggest Tournament of the year: - 5v5 matches of ~4-6 teams - broadcasted on twitch with - 1 camera person - 2-3 casters/commentators - definitely overproduced - to an audience of 15-25
Its so much fun ^.^