5 ms·

> 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sendi

> 3. GPUs cannot natively render cubic curves (look at any of the papers on this and you'll find they do CPU-side translation of cubic -> quadratic before sending to the GPU in the best case) which harms perf substantially and makes animation of curves expensive. Plus handling the intersection rules is incredibly complex. Loop-Blinn natively renders cubic curves in the same way as quadratic curves (implicitization), with some preprocessing to classify cubic curves based on number of inflection points (but this is not the same as converting to quadratic). But I don't think the complexity is really worth it when you can just approximate cubic Béziers with quadratic Béziers. > we could literally send a vector graphic model directly to the GPU and have it render (and animate!) at incredible speeds, with easier to understand tools. You can still submit high-level display lists to the GPU with an all-quadratic pipeline. Just add a compute shader step that runs before your pipeline that converts your high-level vector display lists to whatever primitives are easiest for you to render. You may want to look at Raph Levien's piet-gpu, which implements a lot of this idea. Google's Spinel is also a good resource, though the code is impenetrable.

slimsag 5y ago
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. [0] https://imgur.com/a/ferSScN https://imgur.com/a/ferSScN [1] https://imgur.com/a/VHZ8Ers https://imgur.com/a/VHZ8Ers
- pcwalton 5y ago
  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.
  - slimsag 5y ago
    Oh, you're right. I feel a bit of a doofus now :) 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.

slimsag 5y ago

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. [0] https://imgur.com/a/ferSScN https://imgur.com/a/ferSScN [1] https://imgur.com/a/VHZ8Ers https://imgur.com/a/VHZ8Ers

pcwalton 5y ago
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.
- slimsag 5y ago
  Oh, you're right. I feel a bit of a doofus now :) 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.