My understand is that Loop-Blinn performs constrained Delaunay triangulation prior to uploading an actual display list to the GPU, in effect turning its cubic curves into quadratic ones, from the paper:
> The overlap removal and triangulation is a one-time preprocess that takes place on the CPU
All I'm suggesting is merely to ditch that process, ditch the idea that you can have intersecting lines, and instead design tools around convex and concave isolated triangles[0] (quadratic curves) so you end up composing shapes like the ones from the Loop-Blinn paper[1] directly, with your tools aiding you in composing them rather than more complex shapes (cubic curves, intersecting segments, etc.) being in the actual model one needs to render.
I don't think any of this is truly novel from a research POV or anything, it's just a different approach that I think can in practice lead to far better real-world application. It's considering the whole picture from designer -> application instead of the more limited (and much harder) "start with SVGs, how do we render them on GPUs?" question.
The constrained Delaunay triangulation in Loop-Blinn is for tessellating the object so that every fragment belongs to at most one curve (i.e. removing self intersections). It doesn't approximate cubic Béziers with quadratic ones. See section 4 and especially section 4.5 in the paper.
It's been a year since I looked at the Loop-Blinn paper, I had forgotten they did this. That's not a good excuse, I should've shut up or spent the time to actually look it up before commenting :)
Regardless of what they do there, hopefully my general idea comes across clearly from my comment above: create tools that allow users to directly compose/animate convex/concave quadratic curves (which render trivially on a GPU as triangles with a fragment shader), and leave dealing with overlaps to the user + tools.
> The overlap removal and triangulation is a one-time preprocess that takes place on the CPU
All I'm suggesting is merely to ditch that process, ditch the idea that you can have intersecting lines, and instead design tools around convex and concave isolated triangles[0] (quadratic curves) so you end up composing shapes like the ones from the Loop-Blinn paper[1] directly, with your tools aiding you in composing them rather than more complex shapes (cubic curves, intersecting segments, etc.) being in the actual model one needs to render.
I don't think any of this is truly novel from a research POV or anything, it's just a different approach that I think can in practice lead to far better real-world application. It's considering the whole picture from designer -> application instead of the more limited (and much harder) "start with SVGs, how do we render them on GPUs?" question.
[0] https://imgur.com/a/ferSScN
[1] https://imgur.com/a/VHZ8Ers