jeremiahkellick

Hey, huge thanks for linking that shadertoy example! It made it click for me how you can apply loop and blinn without triangulating.

I'm going to dig into it further, but if I understood at a glance, the triangles are there conceptually, but not as triangles the graphics API sees. You compute your own barycentric coordinates in the pixel shader, which means you can loop over multiple triangles/curves within a single invocation of the shader. Sorry if that should've been obvious, but it's the piece I was missing earlier.

I can now concede most of your original point. This seems like a simpler approach than Slug, if you're willing to supersample. Distance-based anti-aliasing remains an advantage of Slug in my view. I understand the limitations of AAA approaches when compared to supersampling, but it can be a wonderful tradeoff in many situations. If you can't afford many supersamples and the artifacts are rare, it's an easy choice.

But for me personally, I'm writing a 4x supersampled 3D software renderer. I like how the supersampling is simple code that kills two birds with one stone: it anti-aliases triangle edges and the textures mapped within those triangles. I want to add support for vector-graphic textures, so your approach from the shadertoy could fit in very nicely with my current project.

But just one final thought on Slug in case anyone actually makes it this deep in the thread: the paper illustrates 27 cases, but many of those are just illustrating how the edge cases can be handled identically to other cases. The implementation only needs to handle 8 cases, and the code can be simple and branchless because you just use an 8-entry lookup table provided in the paper. You only have to think about all those cases if you're interested in why the lookup table works. It's not as intimidating as it looks. Well, I haven't implemented it, but that's my understanding.

[1] and [2] sound similar to what you are describing. They still involve triangulating the shape, but the triangulation process seems much simpler than the loop and blinn paper. However, if you want to do distance based anti-aliasing rather than supersampling, things are going to get complicated again as you have to expand the shape outline to capture more pixel centers.

I don't see a straightforward way to apply this technique in a pixel shader that includes multiple curves per triangle. I feel like any attempt to do that will approach the complexity of Slug, but maybe it's my own shortcoming that I don't see it. I would love to read more detailed information on that if you have it.

[1] https://medium.com/@evanwallace/easy-scalable-text-rendering... [2] https://web.archive.org/web/20180905215805/http://www.glprog...

Loop and blinn does not compute a winding number using the b) method. It avoids the issue of a winding number by assuming there's only 1 bezier curve per triangle, which requires a complicated triangulation step. It can produce some nasty geometry in more complex cases. With Slug, you can use only 1 quad per glyph if you want.

Also just to clarify regarding this statement:

Slug uses approach a) and that comes with a lot of edge cases (see chart in the post) and numerical precision issues

Slug does not have numerical precision issues. It's the breakdown into different cases that _solves_ those issues, whereas your statement makes it sound like slug has _both_ the case complexity and the precision issues.