[HN Gopher] AAA - Analytical Anti-Aliasing
       ___________________________________________________________________
        
       AAA - Analytical Anti-Aliasing
        
       Author : todsacerdoti
       Score  : 416 points
       Date   : 2024-11-20 08:03 UTC (14 hours ago)
        
 (HTM) web link (blog.frost.kiwi)
 (TXT) w3m dump (blog.frost.kiwi)
        
       | FrostKiwi wrote:
       | Thanks for sharing! Author here, happy to answer any questions.
        
         | Moosturm wrote:
         | What an absolutely fantastic read.
        
         | flohofwoe wrote:
         | 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.
        
         | ferbivore wrote:
         | > 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.
        
           | mastax wrote:
           | I'm definitely seeing similar artifacts when at 2x on an
           | iPhone 15 Pro.
        
             | ferbivore wrote:
             | 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/met
             | al/mtldevice/28...
        
         | ferbivore wrote:
         | 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.
        
         | amitp wrote:
         | 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] https://www.puredevsoftware.com/blog/2019/01/22/sub-pixel-
         | ga...
         | 
         | [2] http://hikogui.org/2022/10/24/the-trouble-with-anti-
         | aliasing...
         | 
         | [3] https://news.ycombinator.com/item?id=12023985
         | 
         | [4] http://hikogui.org/2022/10/24/the-trouble-with-anti-
         | aliasing...
        
         | enbugger wrote:
         | As a non-gamedev person but just gamer, I should expect that
         | this will replace TAA anytime soon? Should it replace TAA?
        
         | Lerc wrote:
         | 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.
        
         | tobr wrote:
         | 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.
        
         | vanderZwan wrote:
         | 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.
        
         | meta-level wrote:
         | 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).?
        
           | Cieric wrote:
           | 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.
        
         | aappleby wrote:
         | Google Maps uses AAA on capsule shapes for all road segments -
         | I wrote it ~10 years ago. :D
        
           | delusional wrote:
           | Neat. Does that mean that every road segment is a separate
           | mesh?
        
             | aappleby wrote:
             | 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.
        
         | tomrod wrote:
         | I would love to connect on some ideas around using antialiasing
         | as a way to extend inference in extracting information from
         | computer vision outputs.
        
         | zadler wrote:
         | 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!
        
       | rootext wrote:
       | Awesome article.
       | 
       | SDF(or mSDF) isn't the future. It's already "good enough"
       | classic.
       | 
       | > This works, but performance tanks hard, as we solve every >
       | bezier curve segment per pixel
       | 
       | This is "the future" or even present as used in Slug and
       | DirectWrite with great performance
       | 
       | https://sluglibrary.com/ https://learn.microsoft.com/en-
       | us/windows/win32/directwrite/...
        
         | Asooka wrote:
         | I may be remembering totally wrong, but isn't the algorithm
         | used in Slug patented?
        
           | qingcharles wrote:
           | https://news.ycombinator.com/item?id=42194175
        
         | Lichtso wrote:
         | Don't forget about implicit curve rendering [0]. The patent
         | will expire soon [1].
         | 
         | [0]: https://www.microsoft.com/en-us/research/wp-
         | content/uploads/... [1]:
         | https://patents.google.com/patent/US20070097123A1/en
        
         | aappleby wrote:
         | I wrote an implementation of the Loop/Blinn paper for Microsoft
         | Game Studios ~20 years ago, I wonder if they're still using it.
         | 
         | Had to do a _lot_ of work to make it production-ready, as their
         | voronoi-based tesselation goes pathological on a lot of Asian
         | glyphs.
        
       | hoseja wrote:
       | What's the catch?
        
         | armada651 wrote:
         | The catch is the alpha-blending, which is something modern
         | games avoid doing as much as possible which is why so many
         | games use that dither-pattern transparency you may have seen
         | before.
         | 
         | To do alpha blending correctly you need to blend with what's
         | behind the object. But what if you haven't rendered what's
         | behind the object? You won't have anything to blend with!
         | 
         | This means you first have to sort all the objects you're
         | rendering and render them in-order. It also means you can't use
         | a depth pre-pass because you need to draw what's behind the
         | object even for the parts you already know will be covered by
         | the object in front of it. There's a bunch of more reasons to
         | avoid it, but those are some of the basic ones.
         | 
         | An alternative is to draw only a few pixels of what's behind
         | the object you're rendering at the edges of the object that's
         | in front and then alpha blend those extra samples together,
         | which seems to be the solution proposed in the article for
         | actual 3D games. So then the catch is that you're doing MSAA,
         | just with high-quality blending rather than the standard
         | averaging of the samples.
        
       | Lichtso wrote:
       | Great write-up!
       | 
       | Though a little caveat from my side, as I have written both 2D
       | and 3D rendering engines. Let me tell you, they could not be more
       | different. It is not just another dimension but completely
       | different goals, use-cases and expectations.
       | 
       | So instead of:
       | 
       | > Everything we talked about extends to the 3D case as well.
       | 
       | I would say the entire post is mostly about 3D, not 2D rendering.
       | If you are curious about this topic being approached for 2D
       | rendering here is a nice write-up I found about that:
       | https://ciechanow.ski/alpha-compositing/
       | 
       | One particular criteria for AA techniques that no one cares about
       | in 3D but is very relevant in 2D is correctness and bias. AAA for
       | example is heavily biased and thus incorrect. Drawing the exact
       | same shape multiple times in the same place will make it more
       | opaque / darker. The same thing does not happen with MSAA which
       | has a bounded error and is unbiased.
        
         | lagrange77 wrote:
         | Hey, i'm brainstorming for a 3d vector renderer in WebGPU on
         | JS/TS and stumbled on your project [0] yesterday.
         | 
         | (Thick) line drawing is especially interesting to me, since
         | it's hard [1].
         | 
         | I also stumbled upon this [2] recently and then wondered if i
         | could use that technique for every shape, by converting it to
         | quadratic bezier curve segments.
         | 
         | Do you think that's a path to follow?
         | 
         | [0] https://github.com/Lichtso/contrast_renderer
         | 
         | [1] https://mattdesl.svbtle.com/drawing-lines-is-hard
         | 
         | [2] https://scribe.rip/@evanwallace/easy-scalable-text-
         | rendering...
        
           | Lichtso wrote:
           | My implementation does:
           | 
           | - Implicit Curve Rendering (Loop-Blinn) and stencil geometry
           | (tessellation-less) for filling
           | 
           | - Polygonization (with tangent space parameter distribution)
           | of offset curves for stroking
           | 
           | > by converting it to quadratic bezier curve segments
           | 
           | Mathematically, the offset curve of a bezier curve is not a
           | bezier curve of the same degree in the general case
           | (exceptions are trivial cases like straight lines, circles
           | and ellipses). Instead you get terrible high degree
           | polynomials. You will have to approximate the offset curve
           | anyway. I choose to use polygons (straight line segments),
           | but you could also use splines (bezier segments), it is just
           | overtly complex for little to no benefit IMO.
           | 
           | BTW, distance fields and offset curves are very similar. In
           | fact the distance field is the set of all possible offsets of
           | offset curves and the offset curves are the isolines on the
           | distance field.
           | 
           | Here is a good summary of all the edge cases to think about
           | in 2D rendering:
           | https://www.slideshare.net/slideshow/22pathrender/12494534
           | 
           | About subpixel AA: Don't bother, LCDs are on the down trend.
        
             | lagrange77 wrote:
             | Thank you very much for the hints! This rabbit hole gets
             | deeper every day. :D
        
             | wtallis wrote:
             | > About subpixel AA: Don't bother, LCDs are on the down
             | trend.
             | 
             | OLEDs have subpixels, too. The real problem is the growing
             | diversity in subpixel arrangements, making it impractical
             | to have a good subpixel AA method for every display type on
             | the market. And mobile platforms have it worse, because
             | screen rotation means you need to be able to change AA
             | methods on the fly.
        
         | kookamamie wrote:
         | I don't think the article generalizes trivially to 3D, though.
         | 
         | The solution presented relies on signed distance fields, yet
         | skims over the important part - a distance to what? In 2D it is
         | obvious, we are measuring distance to an edge between the
         | object and its background, to a silhouette.
         | 
         | In 3D, when objects may rotate producing self-occlusions,
         | things get more complicated - what are we measuring the SDF
         | against? The silhouette of a 3D object's 2D projection is ever-
         | changing and cannot be trivially precomputed.
        
       | amjoshuamichael wrote:
       | Graphics programming analysis done using examples written in
       | WebGL-genius. Hypertext that takes full advantage of the medium.
       | This reminds me of something I'd see on https://pudding.cool/,
       | but it goes _far_ more in depth than anything there. Absolutely
       | fantastic article.
       | 
       | I've been using MSAAx4 in my rendering engine for some time and
       | only recently have considered switching to a FXAA / TAA
       | implementation. I'm actually not sure I'm going to go through
       | with that now. I definitely learned a lot here, and will probably
       | use the analytical approach for UI items, I hadn't heard about
       | that anywhere.
       | 
       | Not often you see graphics-programming stuff on HN. For anyone
       | interested in more graphics write-ups, this list of frame
       | breakdowns is one of my favorite resources:
       | 
       | https://www.adriancourreges.com/blog/
        
         | art0rz wrote:
         | I really dislike TAA, especially on lower framerates. There's
         | too much ghosting. I often switch it to a slower algorithm just
         | so I don't get ghosting.
        
           | kridsdale1 wrote:
           | It's very strange. I had a vivid dream, only about 5 hours
           | ago, where I was debating the drawbacks of TAA with some
           | scientists in a lab (likely because Half Life has been in the
           | news this week). I think I dream about rendering algorithms
           | once every several years.
           | 
           | And now today there's this post and your comment here in the
           | front page.
        
             | Nevermark wrote:
             | As randomly connected graphs fill in, they quickly _must_
             | produce patterns. The patterns are non-random (thus they
             | are a pattern!), but essentially  "chosen" from all
             | possible patterns randomly.
             | 
             | Which is another way of saying: a proof of God would be
             | going through life without a constant stream of
             | surprisingly meaningful coincidences.
             | 
             | Unbiased reality is inherently a blind but inventive
             | "Creator".
        
           | Waterluvian wrote:
           | My feeling is if I can render at 4K I can just not do AA at
           | all. It really looks quite fine without, at least for me.
        
             | amjoshuamichael wrote:
             | I tried that initially, but I found that it still wasn't
             | quite satisfactory. My game's art style has a lot of
             | straight edges, to be fair.
        
             | kbolino wrote:
             | No AA on 4K/high-DPI has been _almost_ perfect for me, but
             | I still occasionally notice thin edges flickering and
             | objects getting dithered when fading in or out. It 's
             | definitely better than TAA though, which just ends up
             | smearing everything that moves.
        
         | TimTheTinker wrote:
         | Steve Wittens also does a lot of these kinds of articles (math
         | with WebGL-infused illustrations, etc.) at https://acko.net/
         | 
         | One of my favorites: https://acko.net/blog/how-to-fold-a-julia-
         | fractal/. This helped me understand the relationship between
         | trigonometric functions and complex numbers like nothing else
         | I've ever seen.
        
       | theandrewbailey wrote:
       | I've been so used to screen space techniques that I initially
       | read SSAA as "screen space antialiasing", not "super sampled
       | antialiasing".
        
         | rahkiin wrote:
         | My favorite is stil SSSSS, or screen space sub surface
         | scattering.
        
       | serf wrote:
       | scrolling thru the post the NeoTokyo screenshot struck me
       | instantly, I ran through the hallway thousands of times - I ran a
       | server for that mod for some years and had great fun with a small
       | community of good/capable people.
        
       | apexalpha wrote:
       | Those frames with the circle and zoomed bit are a fantastic way
       | to convey this message, well done the whole article reads great.
        
       | vanderZwan wrote:
       | Tangent: my biggest problem with AA is something adjacent to it,
       | which is that almost none of my games bother explain what the
       | differences are between the different abbreviations available in
       | the settings, half of which are completely unknown to me. Like,
       | sure, I can look them up but a _little_ bit of user-friendliness
       | would be appreciated.
       | 
       | This article will probably help for future reference though!
        
         | ndileas wrote:
         | Games/graphics are one of those domains with a lot of jargon
         | for sure. If you don't want to be a wizard you can just mess
         | with it and see what happens. I like how dolphin approaches
         | this with extensive tooltips in the settings, but there's
         | always going to be some implicit knowledge.
         | 
         | On a meta level - I feel like I've seen anti-acronym sentiment
         | a lot recently. I feel like it's never been easier to look
         | these things up. There's definitely levels of acronyms which
         | are anti-learning or a kind of protectionism, but to my mind
         | there are appropriate levels of it to use because you have to
         | label concepts at a useful level to accomplish things, and
         | graphics settings of a game definitely are on the reasonable
         | side.
        
           | kridsdale1 wrote:
           | The PS4 Pro introduced the gaming world to the simplification
           | of settings from dozens of acronyms that were common to PC
           | Gamers, down to "Performance" and "Quality".
           | 
           | I wouldn't be surprised if there's now a market demand for
           | that to spread back to PC land.
        
             | armada651 wrote:
             | PC games have had Low, Medium, High presets for graphics
             | settings for decades. I don't think reducing that from 3
             | choices to 2 is going to be a big win for user
             | friendliness. And I certainly think it's user-hostile if it
             | means taking the customization away and only letting users
             | choose between two presets.
             | 
             | PlayStation does have shining examples of user-friendly
             | settings UI though, namely in their PC ports. Look at this
             | UI in Ratchet and Clank:
             | 
             | https://x.com/digitalfoundry/status/1684221473819447298
             | 
             | Extensive tooltips for each option and any time you change
             | a setting it is applied immediately to the paused game
             | while you're still in the settings menu allowing you to
             | immediately compare the effects.
        
               | whywhywhywhy wrote:
               | > I don't think reducing that from 3 choices to 2 is
               | going to be a big win for user friendliness
               | 
               | It's nowhere near as simple as 3 settings now there are
               | different antialiasing techniques, path tracing lighting
               | or reflections, upscaling (multiple algorithms) etc.
               | 
               | Nothing is all just fully positive and each has tradeoffs
        
               | ferbivore wrote:
               | Nixxes are very enthusiastic about every PC port having
               | proper settings and exclusive options. I hope the
               | C-levels at Sony continue to not notice.
        
           | GuB-42 wrote:
           | > just mess with it and see what happens
           | 
           | And even if you know every detail, that's still the best
           | course of action, I think. Which kind of antialiasing you
           | prefer, and how it trades with performance and resolution is
           | highly subjective, and it can be "none".
           | 
           | There are 3 components to rescaling/rendering pixels:
           | aliasing, sharpness and locality. Aliasing is, well,
           | aliasing, sharpness is the opposite of blurriness, and
           | locality is about these "ringing" artefacts you often see in
           | highly compressed images and videos. You can't be perfect on
           | all three. Disabling antialiasing gives you the sharpest
           | image with no ringing artefacts, but you get these ugly
           | staircase effects. Typical antialiasing trades this for
           | blurriness, in fact, FXAA is literally a (selective) blur,
           | that's why some people don't like it. More advanced
           | algorithms can give you both antialiasing and sharpness, but
           | you will get these ringing artefacts. The best of course is
           | to increase resolution until none of these effects become
           | noticeable, but you need the hardware.
           | 
           | The best algorithms attempt to find a good looking balance
           | between all these factors and performance, but "good looking"
           | is subjective, that's why your best bet is to try for
           | yourself. Or just keep the defaults, as it is likely to be
           | set to what the majority of the people prefer.
        
       | polytely wrote:
       | amazing blog, both in content and presentation. Love it when
       | articles give you controls to play with. Gives me hope for the
       | future of the web. the NeoTokyo mention reveals great taste.
        
       | SirMaster wrote:
       | I really miss MSAA. I still dislike DLSS personally. I realize
       | many people seem to like it, but it just does not look that good
       | to me. Or as good as things used to look or I believe could look.
       | 
       | Sure it's better than TAA, but come on, this can't be the
       | ultimate end for gaming graphics... At least I hope it isn't.
        
         | mavamaarten wrote:
         | Same here. I can't put my finger on what exactly it is, but it
         | just never feels and looks as good as lower quality at full
         | resolution.
        
         | OCASMv2 wrote:
         | The problem with MSAA is that it only handles aliasing from
         | geometry edges. It's pretty much useless against shader
         | aliasing, which became a massive problem after normal mapping
         | and HDR lighting became standard in the PS3 era.
        
       | bredren wrote:
       | Appreciated that link out to Captain Disillusion. I had not heard
       | of that guy. Incredible work, here's a direct link for those
       | interested in video effects:
       | https://www.youtube.com/@CaptainDisillusion
        
       | globular-toast wrote:
       | > Mobile chips support exactly MSAAx4 and things are weird.
       | Android will let you pick 2x, but the driver will force 4x
       | anyways.
       | 
       | Hmm... On my Android phone I definitely see a difference between
       | 2x and 4x, but it's not "rounded" like the iPhone one.
        
       | wizzard0 wrote:
       | those buttery smooth gradients are soooo pleasing to watch <3
        
       ___________________________________________________________________
       (page generated 2024-11-20 23:00 UTC)