So to sum this up a bit:
Curves:
- Bezier Curves only require the specification of control points
- B-Splines will require an additional Knot-Vector
- NURBS Curves will require the additional Knot-Vector and a vector of point weights
Here is a super convenient way of understanding the differences with all the types of curves. Out of that fact, Bezier curves will require less information in the G-Code file, making them smaller in size. From a computational point of view, I do think that all of the curves are fairly easy to compute and should not cause performance issues on 32bit hardware. While B-Splines and NURBS sure are more complex and allow a more exact fitting of surface points with fewer curves, I think that Bezier curves will do just fine for a first implementation and looking beyond.
Slicing:
I always thought that there is an analytical solution for computing the intersection curve of a plane with a NURBS surface (pretty much all freeform CAD Data is based on NURBS Surfaces). But I am not aware of such an implementation or solution. I did some very basic research on some published papers and couldn't find any in that direction. Usually, they go and find a clever way of determining the area of the NURBS surface that intersects with the plane and then compute and sample intersection points. After that, you do curve-fitting through those points and get the intersection curve as a Bezier, B-Spline or NURBS. Maybe someone else got more info on that.
The script I wrote leaves all the intersection curve computational stuff to a CAD Kernel, so I have no real control over what kind of curve I will receive. That is why I was struggling when receiving bezier curves with an order of 5. If you would write a slicer from scratch you could fit multiple cubic bezier curves instead.
Since the slicing described above is also just an (very accurate) approximation of the surface based on surface points, you could also slice a very detailed STL/3MF the traditional way and then post-process the G-Code in an ArcWelder-Like fashion. That way you could use the robustness of the current slicers, and not have to deal with offsetting parametric curves. Something that I believe is not trivial to get right every time.
Interpreter (RRF):
As stated above: While it is pretty hard to compute the length of those curves analytically, there are numerical solutions that approximate the length. Since RRF needs to linearize (approximate the curve with tiny line segments of a defined length - Marlin uses 1mm by default I think) the curve anyways, one could use that to compute the length of the curve. In that case, you would need to pre-compute the entire move along the curve before actually moving the motors. I am not sure that fits into the current design of RRF.
Get the latest stable release here!
GitHub Repository
Personal Project Page
