This is my favorite talk so far, but I’m ENORMOUSLY biased: I work with SVG and vector illustration for a living, and have looked at much of the same literature you listed on GPU optimization. (Enough to know that Slug actually works with quadratic beziers.. isn’t the Slug algo compatible with what you’re doing? It defines shapes as triangles too.) There are not many people who use the even-odd cubic rules to create art (anecdotally I even thought it was a bug when I first learned about them almost two decades ago) so editors that could use your semicircle primitive to regain that curviness without needing to just add more quadratic points would suffice for most artists, and the few who do use even-odd SVG features… I’d love to write an SVG cross-compiler that rewrites the paths as a series of mathematically simpler constructs. I’m excited for your semicircle primitive, because there’s a very little-used feature of SVG to draw circle-based arc segments on paths, but it’s very unintuitive. (Though since SVG does supports them means you could still serialize to SVG… don’t give up on SVG!)
Thanks for pointing to Slug, it seems to be an atleast related thing. Fantastic to have this in Zig also and also introduce people to this technology. Edit: Look at the endcard, he actually referenced Slug!
great talk! i'd agree that it's time we try other approaches like this as supporting bezier curves is really difficult in a renderer would love to see tools to play around with placing these triangle primitives and obviously an exporter from font formats to this format
You raised that "borders are hard to match up": I think that's the real problem with this approach: there's no direct equivalent to just stroking a path (the approach you mention doesn't seem like it would work well to me but you've spent a lot more time on it, of course), you might have to emulate it with a long triangle strip that's very artist unfriendly (due to the lack of a fill rule) It might be a good asset primitive, but I don't know about using it as an authoring interface directly, in other words. The real reason for the use of these complex paths is they're inherited from postscript (and it's proprietary predecessors) that a printer CPU would compute with straightforward line by line raster (just evaluate everything plausible at current y, sort results by x, then apply the fill rule with a counter or bit as you cross each result: extremely cheap and easy for the results you get), where cubics are trivially more effort than quadratics and faster than the multiple quadratics needed to approximate it.
@@Pence128 that might work better than the mentioned "filling the hole" approach, but again I think it means you basically can't author the triangles directly, since they need very exact overlaps. You basically already have this issue with the semi circle, but I think that's solvable by making it a quarter circle that goes right to the edges like the quartic.
I think it’d be very doable to let the tooling do the heavy lifting while still allowing manual editing. Manipulating and rendering triangles is a well understood problem
@@parzival-3141 But if that's true, then you don't really need to worry about how easy it is to edit the primitives. The whole selling point here is that the primitives are easy to understand and edit directly.
@@SimonBuchanNz I agree with that last part, but the first…not really? I see it more as a foundation that’s much simpler to understand and work with. You can use tools that build upon it, but it’s always easy to figure out what’s actually going on and even do it yourself. Think about mesh generation tools in 3D software. Sure you can do complex things, but at the end of the day it’s still all verts/edges/faces.
I like that you try to correct americanisation of your German name. 🙂 Next level could be to look up how to pronounce "ch" in German, could use Google Translate for that. Listen how Words like Mach, Bach or China sound like in German... Hint: You pronounce it like it was "ck" but you know, h and k are two different letters.
I really like this "let's question the fundamental decision of the field" approach of the zig community.
Great talk.
This is my favorite talk so far, but I’m ENORMOUSLY biased: I work with SVG and vector illustration for a living, and have looked at much of the same literature you listed on GPU optimization. (Enough to know that Slug actually works with quadratic beziers.. isn’t the Slug algo compatible with what you’re doing? It defines shapes as triangles too.)
There are not many people who use the even-odd cubic rules to create art (anecdotally I even thought it was a bug when I first learned about them almost two decades ago) so editors that could use your semicircle primitive to regain that curviness without needing to just add more quadratic points would suffice for most artists, and the few who do use even-odd SVG features… I’d love to write an SVG cross-compiler that rewrites the paths as a series of mathematically simpler constructs.
I’m excited for your semicircle primitive, because there’s a very little-used feature of SVG to draw circle-based arc segments on paths, but it’s very unintuitive. (Though since SVG does supports them means you could still serialize to SVG… don’t give up on SVG!)
Thanks for pointing to Slug, it seems to be an atleast related thing. Fantastic to have this in Zig also and also introduce people to this technology.
Edit: Look at the endcard, he actually referenced Slug!
great talk!
i'd agree that it's time we try other approaches like this as supporting bezier curves is really difficult in a renderer
would love to see tools to play around with placing these triangle primitives and obviously an exporter from font formats to this format
🙏🙏 Praise be. Love your work, keep it going
great talk and vision
Damn this is a hidden gem
You know, Bezier is a French name, roughly pronounced bezyay .
nice talk. only issue is questions are not audible.
You raised that "borders are hard to match up": I think that's the real problem with this approach: there's no direct equivalent to just stroking a path (the approach you mention doesn't seem like it would work well to me but you've spent a lot more time on it, of course), you might have to emulate it with a long triangle strip that's very artist unfriendly (due to the lack of a fill rule)
It might be a good asset primitive, but I don't know about using it as an authoring interface directly, in other words.
The real reason for the use of these complex paths is they're inherited from postscript (and it's proprietary predecessors) that a printer CPU would compute with straightforward line by line raster (just evaluate everything plausible at current y, sort results by x, then apply the fill rule with a counter or bit as you cross each result: extremely cheap and easy for the results you get), where cubics are trivially more effort than quadratics and faster than the multiple quadratics needed to approximate it.
I think it's just a matter of making the triangles large enough to draw the outside part of the stroke on them.
@@Pence128 that might work better than the mentioned "filling the hole" approach, but again I think it means you basically can't author the triangles directly, since they need very exact overlaps.
You basically already have this issue with the semi circle, but I think that's solvable by making it a quarter circle that goes right to the edges like the quartic.
I think it’d be very doable to let the tooling do the heavy lifting while still allowing manual editing. Manipulating and rendering triangles is a well understood problem
@@parzival-3141 But if that's true, then you don't really need to worry about how easy it is to edit the primitives. The whole selling point here is that the primitives are easy to understand and edit directly.
@@SimonBuchanNz I agree with that last part, but the first…not really? I see it more as a foundation that’s much simpler to understand and work with. You can use tools that build upon it, but it’s always easy to figure out what’s actually going on and even do it yourself.
Think about mesh generation tools in 3D software. Sure you can do complex things, but at the end of the day it’s still all verts/edges/faces.
Does a font file contain more than just quadratic curves? like for example cubic curves?
Answered in more detail here: github.com/hexops/mach/discussions/608#discussioncomment-4080420
it seems like a bytecode for vector graphics!
I like that you try to correct americanisation of your German name. 🙂 Next level could be to look up how to pronounce "ch" in German, could use Google Translate for that. Listen how Words like Mach, Bach or China sound like in German... Hint: You pronounce it like it was "ck" but you know, h and k are two different letters.
Interesting but unwatchable, filled with ads that won't generate any real amount of money at the cost of bothering the viewers...
get an ad blocker
@@kristoff-it not all devices can get an ad blocker, and there is no reason to have ads.
this dude's speaks at like 30 "um"'s per minute i can barely follow