Request: Option to Preserve Original Cut Order in LightBurn 2.1+

I’d like to revisit the cut-order optimization changes introduced with LightBurn 2.1.

The original discussion is here:

Unfortunately, that thread is now closed, but the issue is still relevant for me.

My main concern is not simply that the new cut order looks less intuitive. In some of my jobs, the resulting machine runtime is actually longer, and the more erratic travel also makes backlash on my laser noticeably more apparent.

With my intentionally prepared cut sequence, the machine moves in a much more consistent way. So the original object order is not accidental drawing order, but part of the manufacturing process.

What I would like is an optional way to preserve that behavior.

For example, when using “Order by Layer”, I would expect LightBurn to group objects by layer while otherwise keeping the existing order unless another optimization rule requires a change.

Instead, enabling optimization appears to discard the original shape order entirely, even when no proximity optimization is active.

I’m not asking for the new optimizer to be removed. I would simply like an option such as:

“Preserve original shape order where possible”

or

“Legacy cut-order behavior”

That would allow users who benefit from the new optimizer to keep using it, while users with intentionally prepared cut sequences could retain predictable behavior.

Thanks for reading.

This ahold be reviewed before moving on to creating product.

If you turn off all optimizations, it should run in the sequence matching when each part was created.

Thanks, but that is not really the issue I am trying to address.

I know that disabling all optimizations preserves the original creation order.

The problem is that I still need some optimization features, especially “Order by Layer”, without LightBurn completely discarding the existing order within those layers.

My request is therefore not to preserve creation order with all optimizations disabled, but to have an option that preserves the existing shape order wherever the selected optimization rules do not actually require it to be changed.

That was essentially the behavior I relied on before 2.1, and it is important for my workflow because the more erratic travel can increase both machine runtime and backlash.

  1. True → “erratic” travel can increase run time, but not as much as you might think. If you check the numbers, you will see that the rapid moves portion is just a small fraction of the total run time.
  2. Erratic travel does not increase backlash. Software cannot make a mechanical issue worse. It can only make a mechanical issue apparent. One method to hide backlash is to turn off bi-directional scanning when doing images. There is no similar “trick” for vector moves.

LIke I said above, the backlash issue must be investigated and a remedy applied. Otherwise you cannot obtain maximum performance with your machine.