After thinking about this for a while, here’s how I’m going to proceed forwards :
There are both pros and cons to using a library like Erik used.
Pros :
- Easier
- Cleaner
- Inherently works well with all current and future curve types, since they are all turned into Poly Lines
Cons :
- Result Curve is always a poly line, which makes the geometry node modifier “apply” operation less useful to users.
- Intersections cannot be calculated at lower resolutions, then scaled back up again for rendering.
- Attributes like radius get lost unless we massively modify the library.
- An external library needs to be approved. It’s small (only ~250kb), but a lot of the code inside is redundant. And getting a patch approved is historically easier without external code.
My node currently has to convert splines to bezier curves, but it always returns easily-editable bezier curves. It doesn’t even support Poly-Lines at the moment, and therefore never even returns them. Useful for users, superfluous if raw evaluated curve data is what you’re after, which 99% of the time you would be.
But taking a step back from the Node itself, all these bezier boolean operations have uses outside of Geometry Nodes. They are in fact a basis on which vector graphic programs like Inkscape work. So even if the final Node uses a simpler Poly Line approach, the code could likely find its way into a set of edit mode operations. Which means my work thus far is likely not going to waste either way. Phew.
So for the time being I’m going to continue the node like before, implementing full bezier boolean operations. After that’s done, I’ll implement Poly Line support, which should use the same internal functions, and therefore be trivial to implement, by hand. A library would be overkill, and would always need to be modified to carry over curve attributes, but the fundamental idea of returning a poly line when that’s all that the following modifiers would use anyways has merit.