That's awesome! Added this as an addendum to the post.

Neat. Does that mean that every road segment is a separate mesh?

> 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...

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)

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...

Ohh right! I'm sure the must be an Eleventy setting 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)

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...

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...

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.

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.

> 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.

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.

Well, I suppose I'm not the assumed target audience. Back when I was younger I had the time to tweak everything on my computer: my Linux distro, my games (dualbooting windows just for that), and looking things up for that reason. I also could play long gaming sessions.

Nowadays I'm a dad with practically no spare time between raising a toddler and work. Suddenly the question of "does the game overstay its welcome?" has become a thing; I almost exclusively play games that can be played in short bursts of time, and that deliver a great experience as a whole that can be completed in a relatively short playtime. I got a Steam Deck a few years ago for the specific purpose of separating my work computer from my gaming platform, and being able to pick up and play a game and pausing it without problems.

Even with the built-in performance overlay of the Steam Deck (which is very nice) it takes time to assess the quality-vs-performance results of every possible combination of settings. Often more than I would spend on playing a game.

I suspect that people like me either already are or soon will be the bigger segment of the (paying) customers though, so that is something to consider for developers.

And some games do give short explanations of what each type of technique does and how they compare, along with statements like "this usually has a small impact on performance" or "this has a large impact on performance" to guide me, which is already a great help.

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.

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.

https://news.ycombinator.com/item?id=42194175

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.

Now that I am delving into the retro-gaming world, I find it funny that 30 years ago gamers lambasted the Sega Saturn for using dithering patterns instead of proper transparencies, only for the same technique to come back decades later.

This is only a problem if you naively undersample the normal maps in your fragment shader. No AA algorithm can can generate a high quality result from undersampled lighting calculations.

For normal maps specifically, you can preserve lost information from downsampled normal maps as roughness: https://media.steampowered.com/apps/valve/2015/Alex_Vlachos_...

MSAA also doesn't require you to have only one color sample for each pixel but this can be varied per draw call (at least for desktop GPUs) - effectively allowing you to supersample some objects when needed.

DLSS even in Balanced mode is annoying when the camera laterally moves, I start seeing all kinds of artifacts. Strangely enough I prefer FSR 2.0 even though there’s slightly less overall detail.