Does RRF support 3d arcs?

dc42

Let's get some cubic splines now!

Does any slicer actually generate them?

bot

@dc42 Not that I am aware of. Fusion 360 should be able to, but it does not afaik.

By the year 2030 at the latest, I plan to have PrusaSlicer slicing STEP files directly, and outputting fitted bezier curves for all perimeters (that are not perfectly straight nor simple arcs).

So, no rush.

ÖrjanE

From what I have understood, the tricky thing to get right when extruding along Bézier curves is the filament extrusion rate. The G5-command, as it is defined in Marlin, gets the total amount of extrusion for the curve, but to calculate the extrusion rate you also need the length of the curve. The problem is that there, apparently, exists no closed formula for the curve length. The length can be estimated numerically by simulating the move, but this is hard to realize in real time; you can not start the move without knowing the entire curve length.

I have not looked into the Marlin source code recently, so I do not know how they solve this.

bot

@örjane This, among other difficulties, is why the ETA has been pushed to 2030.

Also, offsetting bezier curves is non-trivial, e.g., for the inner perimeters (and the outer perimeter, too, because it must be offset in by half an extrusion width).

I spoke with merill of SuperSlicer once about it, and we agreed that forcing approximations of the correct bezier curve to fit highly-detailed faceted polylines would be the easy/perhaps best approach. Thus, we could steal the length from that prototype high-resolution polyline.

Currently, the mesh limits the polyline resultion. If no mesh were limiting the resolution, then the douglas-peucker algorithm limits the polyline resolution.

We can generate an overly-high-resolution polyline to fit bezier curves to. Basically, the slicing would work as it does now, but using STEP files as input and discretizing the polylines to very high detail. The perimeters would be offset like normal. It is only after we have the properly offset segmented polylines for all perimeters that we then generate and force to fit approximations of the required bezier curve -- they would technically not be the identical to-the-micron bezier curve that the STEP model has on its outer surface, but it would be close.

The purpose of the bezier curves is not to get higher resolution curves: we can already max out the resolution of the mesh and get smooth-as-silk curves.

Instead, the point of bezier curves is to print those smooth curves fast, because hopefully the throughput of processing those splines would be faster than the many g-code moves required to define a high resolution sequence of G1 moves.

ÖrjanE

@bot I looked briefly into the Marlin source code for G5 and, as expected, they do not solve the problem with extrusion rate. They seem to use the t-parameter (that runs from zero to one along a Bézier curve) to linearly control extrusion. That code is actually marked with a "FIXME" comment. For simple arc-like curves, this may be good enough, but for wilder Bézier curves the extrusion rate will vary considerably along the curve.

Since the slicer does not have to work in real time, and, as you say, often already has the curve represented as line segments, it would be good if the slicer had some way of telling the firmware what the curve length is. One obvious solution would be to have the curve length as an extra parameter to G5.

bot

That is interesting info thank you for looking at the marlin source.

One thing I forgot to mention: when merill and I were discussing it, we realized that the beziers would have to be chopped up arbitrarily. As in, there might be multiple fitted "close enough" bezier curves for what would ideally be a single curve. This is because the offset of a bezier curve can, I think, never (or maybe just not always) be represented by a slightly different single curve.

I forget the specifics, I may be misremembering, but the information seemed to be somewhat common knowledge when I was googling it a year or so ago.

MikeS

@bot You might be interested spending 30 minutes watching this: https://youtu.be/aVwxzDHniEw . I enjoyed it a lot!

markz

Well, that came out just great - smooth and all the detail showed up. Thanks. For scale the nearer lizard is about 1.5" long.

alankilian

@markz

That looks awesome!

oliof

This post is deleted!

markz

@alankilian Thanks. The finish is really glossy so it shows the machining ripples well in this light and they're just spot on.

seeul8er

I wrote an experimental slicing script for doing parametric slicing. Computing the offset curves is too hard in my opinion. Instead you should only make the outer perimeter a parametric curve and discretize the inner extrusions as usual.

The framework i use for slicing will also output bezier curves (converted from bsplines) that are of degree 5 etc. As I see it Marlin/GCode Standard only supports degree 2/3 which is quadric/cubic. This means you would need support for higher degree curves as well.

So the best way I currently see is doing some sort of curve fitting inside the slicer or the Duet. Maybe even assisted based on a parametric slice. Modern CNCs can already do this kind of fitting. I think I read something about it on a Siemens control unit.

dc42

@seeul8er perhaps implementing bsplines in RRF would be a better way forward than implementing bezier curves?

ÖrjanE

@dc42 I'm not sure, but I do not think B-splines would be easier to implement or use.

From what I understand, there are two problems with Bézier curves in this context:

The length of the curve is unknown beforehand.
Drawing with an offset from a Bézier curve is not itself following a Bézier curve.

The first causes problems to compute the extrusion rate if only the total extrusion is known. The second causes problems when drawing multiple walls or when the outside of an object should follow a Bézier curve.

Both these things can be avoided by defining the G-code somewhat differently from how Marlin has done it. If the extrusion rate (mm filament per mm movement) is given as a parameter, instead of the extrusion length, this would solve the first issue. The second could be handled by an optional offset parameter to move the tool with an offset (along the normal) to the curve. Both these things would be fairly straightforward to implement (I think...), and potentially useful for a slicer.

bot

@örjane I'm not sure I understand the difficulty in tracking the extrusion amount for the curve. If we specify that the curve have a constant height and width, and we follow the centerline, the extrusion should be a linear function of the length travelled, right?

Maybe I'm not thinking about it enough.

@seeul8er thank you very much for chiming in! It sounds like you have already done some interesting work. I had the same thought of only "curving" the external perimeter, but for a number of reasons I want at least two curved perimeters. I figured that, since we would already stumble on not having higher-order curves, we will be approximating the external perimeter anyway, so why not do the same for internal perimeters? Is it just that difficult to get an approximated offset, even if we output a different/larger number of curves for the inner perimeters? I thought that there should certainly be a (larger) number of close-enough curves that could fit into what would otherwise be the offset of a single ideal single b-spline. I'm not an expert with this math or concept at all, so please ignore me if you wish.

If, however, we have to begin splitting the curves into a larger and larger number of curves to get the offset, then we run into the same problem as polylines: too many moves slowing things down.

I would want to at least get two perimeters in curves/splines. A single perimeter, in my experience, is not sufficient to hide the crimes of the perimeter immediately interior to it. Zig-zag infill needs at least two perimeters to hide. So, the faceted inner segmentation would reveal itself at spots through a single curved perimeter.

ÖrjanE

@bot The problem with extrusion amount is that in the G5 command (as implemented in Marlin) it is specified as the total amount that should be extruded until you reach the end of the move. Since you do not know (and can't easily compute) the length of the curve, you do not know how fast you should extrude.

Regarding the need for curved perimeters, my wild idea was to let the firmware handle the offset. The slicer would then generate gcode commands for the same curve for each perimeter, but specify different offset for each perimeter. Then there would be no need to calculate any approximate curve(s) for the inner perimeters. Since the normal of a Bézier curve is simple to compute, it would not be hard for the firmware to move the tool along the offset path.

bot

@örjane I understand now, thank you. I was forgetting that the firmware needs to calculate the move length itself to determine the extrusion rate. So, yes I think the responsible slicer will provide a length.

As for the normal of the bezier being used to automatically offset: that is a great idea. I don't see why that wouldn't work. I'm not sure how I got into thinking that the inner perimeters needed to be discrete curves.

I suppose the problem becomes self-intersection, and cases where the requested number of perimeters don't fit. It's worth experimenting with on (digital) pen and paper. I might play around with some CAD software and see how splines and curves behave more intimately.

ÖrjanE

@bot Many of the problems seem to come from how the interface between the slicer and the firmware is defined. The extrusion rate is known by the slicer but it is forced to communicate it to the firmware via the E-parameter which is the total extruded amount instead of the rate. When I think about it, this also applies to G1,2,3 moves; the slicer internally translates rate to amount and the firmware translates back to rate. I guess that for most prints, the extrusion rate stays constant over many (hundreds of) G1 moves, so there would be a potential for saving gcode file size here by only sending the rate number when it changes. Well, changing G1 would probably be too disruptive to be realistic.

To somewhat bring this back to the original topic of this thread, perhaps we should also consider Bézier curves in 3D, not only planar ones. The question about offset then becomes a bit more complicated, but not unsolvable (cross products come to mind).

As you point out, self intersections may occur if offsets are used in tight bends, but I would consider that to be the slicers responsibility to detect (when it matters). We should also note that movement along an offset curve will affect the speed and hence (again) the extrusion. Those things (acceleration, jerk, PA, input shaping) are all under the control of the firmware, so this would hopefully be handled by the existing machinery.

bot

@örjane Very good thoughts, thank you. I can confidently say that you've progressed my understanding of the problem forward. Maybe we can move the ETA to 2029 from 2030! I'm still in no position to know where to start coding this, but PrusaSlicer already deals with beziers for SVG, though, so...

ÖrjanE

@bot I'm happy if these scattered ideas can be of some use; looking forward to 2029.

It is indeed a bit of a chicken-and-egg problem where to start coding; both firmware(s) and slicer(s) need to support this to be useful. One approach could be to have a converter inbetween, in the same spirit as ArcWelder, which can convert back and/or forth between polylines and Béziers.

I did not know that PrusaSlicer already supports Béziers in SVG. Interesting. Supporting Béziers in the input to the slicer is probably quite different, perhaps even independent, from using Béziers in the output (GCode). Circular holes where the axis is tilted from Z, for example, will become ellipses in the XY plane which are not well captured by circular arcs (G2/G3). I expect that Béziers could be well suited for such situations if the slicer would be able to detect them.