With enabled Arc Fitting:
Disabled Arc Fitting which results in Curve Planning to be used instead (at least that’s what bambu studio tells us):
Looks like sparse infill alone takes +3 hours.
Is the print quality really that much better with curve planning? Also, how can we confirm whether it’s actually being used and that the printer isn’t still handling arcs the old linear way?
Arc fitting enabled is the faster setting, right? I would assume that it is both faster and better quality than curves being interpolated by short straight lines. The printer can execute curves as one smooth movement at constant speed. That should be beneficial for both speed and quality.
Do you have gyroid infill enabled, a very curve heavy sparse infill? Perhaps thats part of the puzzle.
Yeah - it’s faster with Arc Fitting enabled.
The thing is that bambu studio automatically disables it and informs the user that printer supports curve planning and to use it instead:
Indeed - gyroid 30% infill
Just something I’ve noticed on one of my prints. I used a negative part (torus) to cut out a piece of a model and it created a low poly cut out but when I printed it, it was smooth. I’ll have to try the same thing with arc fitting enabled to see if it does the same thing or if it prints low poly like the slicer showed.
Is it really impossible to turn this off? Holy crap so we got an X2D firmware upgrade that makes the printer … checks notes … slower?!
Edit, seems I can re-slice after this intrusive change of settings. Why does it do it on its own though?
Yeah - it’s not forced, but enabled by default.
Seems that from bambu perspective - curve planning is “just better” and doesn’t matter if much slower…
I just got this on my H2C as well with the new beta firmware. I can’t really find much about it on the wiki. Could anyone explain what exactly the difference is and why bambu seems to be making it the default?
Btw to be clear, even if you use Arc fitting, curve planning is still active (afaik). Although it may or may not affect g2/g3 curve gcodes.
I believe the thinking behind this is that Arc fitting is just done for gcode compression, and is effectively lossy. The printer can handle raw line data and doesn’t need it. However, I wonder if we have the the controls to steer it.
You should play around with the “resolution” setting too. It has a huge impact on how both lines and arcs are generated in the slicer. I wonder now if that value is sent to the printer for use in curve planning… I think that would be ideal - samples straight lines generated in the slicer, and the printer is aware of the resolution. But I think the value of resolution is actually much too high for fine prints. You can see the difference on smooth curved surfaces.
Also to adress the slowness directly, have you tried adjusting the acceleration values? These may enter into both modes, in different ways.
