Hacker News Reader

Comment by jeremiahkellick | Hacker News Reader

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

View on HN

> [1] and [2] sound similar to what you are describing. They still involve triangulating the shape, but the triangulation process seems much simpler

Yes, they describe one variation of the angle based method to winding numbers by spanning a triangle fan from an arbitrarily chosen pivot point / vertex.

> if you want to do distance based anti-aliasing rather than supersampling

Particularly when it comes to rendering vector graphics I think of analytic anti-aliasing methods as somewhat cursed and prefer multisampling [0], at least for magnification. For minification mip-mapping remains the go to solution. However, if you only render 2D text on a 2D plane, which is typically overlap free, then these correctness issues don't matter.

> I don't see a straightforward way to apply this technique in a pixel shader that includes multiple curves per triangle

All modern vector renderers I know of avoid triangle rasterization entirely. Like I said, they typically do tiles (screen space partitioned into quads) in a compute shader instead of using the fixed functionality with a fragment / pixel shader. The reason is that nowadays compute is cheap and memory bandwidth is the bottle neck. Thus, it makes sense to load a bunch of overlapping geometry from global memory into workgroup shared memory, render all of it down to pixels in workgroup shared memory, and then only write these pixels back to the framebuffer in global memory.

> I feel like any attempt to do that will approach the complexity of Slug

A highly optimized implementation might very well, yes. Yet, handling the many cases of intersections of the path and the scanline won't be contributing to the complexity, which is what started this discussion.

> I would love to read more detailed information on that if you have it.

I implemented the outdated stencil buffer + triangle fan + implicit curves approach [1] if you want to take a look under the hood. The library is quite complex because it also handles the notoriously hard rational cubic bezier curves analytically, which Slug does not even attempt and just approximates. But the integral quadratic bezier curves are very simple and that is what is comparable to the scope Slug covers. It is just a few lines of code for the vertex shader [2], the fragment shader [3] and the vertex buffer setup [4].

Edit: You can even spin loop & blinn into a scanline method / hybrid: They give you the side of the curve your pixel is on [5], which is typically also the thing scanline methods are interested in. They compute the exact intersection location relative to the pixel, only to throw away most of the information and only keep the sign (side the pixel is on). So, that might be the easiest fragment shader vector renderer possible. Put it together in a shader toy [6] a while back.

[0]: https://news.ycombinator.com/item?id=46473247#46530503 [1]: https://github.com/Lichtso/contrast_renderer [2]: https://github.com/Lichtso/contrast_renderer/blob/main/src/s... [3]: https://github.com/Lichtso/contrast_renderer/blob/main/src/s... [4]: https://github.com/Lichtso/contrast_renderer/blob/main/src/f... [5]: https://news.ycombinator.com/item?id=45626037#45627274 [6]: https://www.shadertoy.com/view/fsXcDj

> All modern vector renderers I know of avoid triangle rasterization entirely.

Well, now you know of a modern renderer that does use triangle rasterization. The reason is simple -- Slug was designed to render text and vector graphics inside a 3D scene. It needs to be able to render with different states for things like blending mode and depth function without having to switch shaders. It also needs to be able to take advantage of hardware optimizations like hierarchical Z culling. And sometimes, you need to clip glyphs against some surface that the text has been applied to. Using the conventional vertex/pixel pipeline makes implementation easier because it works like most other objects in the scene. Having this overall design is one of many reasons why a huge swath of the games industry has licensed Slug.

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.

Reply on news.ycombinator.com