3D Sliced, Depth Map Images: LightBurn Limitations & Behavior

[KungFuJosh (Joshua Peromsik)]

(Sort of) continuing the discussion from 16 bit height map - are more than 256 3d sliced layers useful?:

That previous topic touched on the subject, but I have some more specific questions.

What is the layer limitation (passes) for 3D Sliced image mode in LightBurn?

What is the behavior with which LightBurn handles those additional layers?

How is that affected by using the Preview window to resume a job?

I understand that there are (at least theoretically) some limitations with 3D sliced layers in multiples of 256. Fine. Following that basic theory, 512 is two passes per greyscale shade, 1024 is four passes, etc. Time should also (again, theoretically) increase proportionally (if 256 = 2 hours, then 512 = 4 hours, etc.).

Here’s my situation: No issues doing 256, 512, or even 768 layer stuff for deep engraves on brass. Time seems about right; something a little over 2 hours at 256 takes closer to 4.5 to 5 hours at 512 depending on the settings.

Here’s a brass example with 256 or 512 layers (I forget which lol):

Titanium on the other hand, is more sensitive to heat. In this case, it’s better to use lower power at a higher pass count to get a smooth engrave and still get good depth. Trying to go too high power, on less tedious pass counts yields rough engraves with some bubbling that’s not too pretty.

For my first test, I did 512 passes at 55 or 60W (I don’t recall what the speed was- somewhere between 2800 and 3600mm/s). The smoothness wasn’t terrible (or great), but the depth was lame:

Some people on Facebook laser groups say that good results on titanium take thousands of passes instead of hundreds of passes like brass or other metals (and do Ti with less power). So, for the other side, I’ve decided to try 2560 as the passes count. with 42W at 3200mm/s.

There’s clearly some truth to this theory; here’s the other side of that coin with the higher pass count in progress:

’

The depth is much better (look at the top left edge of the coin), and despite being a work in progress, it’s already smoother.

Here’s the big issue: It’s now over 35 hours in! I won’t run the laser when I’m not around or awake, so I have to stop and restart the process using the preview window and the “start from here” feature.

This behavior is quite strange. First of all, 2560 is 10 times larger than 256, so I would have expected 20 to 25 hours maximum. However, the behavior is weirder than that.

Day 1: I think the laser ran for about 8 hours or so, and get to about 24% completion.

Day 2: The laser ran for at least about 15 hours, and ended at 69% when I stopped the laser for the day.

Day 3 (today): The laser is currently at about 12 hours runtime, and 51%.

I understand that the percentage relates only to completion for the job sent to the laser at that time/day, and not the entire project.

This is odd behavior for two reasons: on 3D depth maps, the later stages usually move faster; and because 15 hours being 69% of the job would imply that the remaining 31% should be less than the 12 hours that have passed so far today.

Another weird observation:

In the layer settings editor, it correctly shows the count at 2560. However, in the cuts/layers window, it says 1000 passes.

Is this the limitation/reason for the weird behavior? Is LightBurn overriding my pass count to 1000 each time I continue the job? So, whatever depth is left tomorrow will get divided into 1000 layers? Or is there some other logic to this madness?

I would think / hope that the total project is divided into 2560 layers, and whatever position I choose in the preview window should continue from that position + layer count.

This also brings me to my biggest complaint about the Preview window: it doesn’t show a percentage or layer count number when using the slider. This would be an excellent feature! For example, if I stopped a job at 56.5%, I could go to that point to start again without guessing. Or if my 3D Sliced image was on layer 500 out of 1000, then I could start there, also without guessing. Or, at least, less guessing. I understand that there will be some minor discrepancy between what LightBurn thinks happened, and what the laser did, but some numbers to get closer would be nice.

Thanks,
Josh

[KungFuJosh (Joshua Peromsik)]

Here’s an alternate theory:

I’m about 64% in now, after 15 hours. I’m counting about 28 or 29 seconds per pass. That’s about 20 hours or so if multiplying against 2560 passes.

Is LightBurn dividing from the later selected starting point by 2560, regardless of where I start in the Preview window??

If that’s the case, it doesn’t make any sense. If I choose 50% as the starting point, LightBurn should start at 50% and divide the remaining job by 50%, thus doing only 1280 passes. Is this not how it works?

Thanks,
Josh

[Finn65 (Finn)]

I do not think this is a true resume of one unchanged 2560 pass job from the JCZ board. LightBurn says Start Here starts the job again from the preview timeline, and LightBurn have said EZCAD boards get streamed data while running. So stopping and restarting a long 3D sliced galvo job is more likely sending a newly generated partial job than continuing from an exact stored slice number. That would help explain the odd percentages after a restart, although it still does not prove whether the 1000 vs 2560 difference is a UI limit, internal chunking, or an actual pass limit.

[KungFuJosh (Joshua Peromsik)]

I don’t see why this would have anything to do with the JCZ board?

The difference in timing and position would be a question of where the JCZ board stopped previously (and what percentage it was actually at when stopped). That’s why it’s essential to match the Preview visual state and slider position with what the current engraving state looks like at the time it is to be resumed (as best as can be visually estimated).

Once the visual matches, LightBurn should do the work to determine the job percentage & number of slices remaining based on the position in the Preview window compared with the total passes count for the image.

That’s entirely on LightBurn to do accurately; the JCZ board will simply take what data is sent to it from LightBurn and continue on. The JCZ board has nothing to do with dividing the image into slices.

Thanks,
Josh

[Finn65 (Finn)]

My point is not that the JCZ board does the slicing. LightBurn does that. The issue is that LightBurn progressively feeds long galvo jobs to the controller, rather than tracking an exact completed slice position on the board. It can manage the buffer and know when it has finished sending and when the controller returns to ready, but the controller does not report back an exact live execution position or completed slice number. Pause and Resume is different because that continues the same active job. But if the job is stopped and later restarted from Preview, I do not think that can be assumed to resume from the exact slice where it left off, because LightBurn does not know the exact execution point the controller had physically reached when the stop occurred. I suspect Preview based restart is a better fit for DSP style controllers, where the job is sent more as a complete planned file, than for galvo controllers that are progressively fed and do not report back an exact live execution position.

I also suspect the remaining time may differ simply because there are fewer passes left, so any error in LightBurn’s galvo time estimate has less chance to accumulate. On a long job, small differences between the commanded speed and the real execution time can add up over many passes. Once you restart from later in the job, LightBurn is only estimating the shorter remaining portion, so those cumulative errors may naturally be smaller.

[KungFuJosh (Joshua Peromsik)]

I think you should read what I wrote again. The JCZ controller is irrelevant, and my statements already account for any difference in position at job stop between the laser controller and the software as it pertains to restarting the project in the future.

Let me put it this way:

If I use the Preview window as I am, and I get the position wrong, so what?

How does that impact this situation in a meaningful way? In truth, it does not. A small variance in layers probably won’t be noticeable on the project, and even if it is noticeable, that’s a separate issue.

The issue I’m discussing here is specifically about how LightBurn handles resuming a project via the Preview window.

The only things that matter are:

1. What position is the job in? (Percentage and/or Pass count # - both should be visible for review)
2. How does LightBurn handle generating the remaining passes for the job to continue?
3. What is the number of passes limitation, and how does LightBurn handle high numbers?

I tested it differently, and LightBurn certainly has less trouble understanding 1000 passes compared to 2560 or higher.

To your concern about resuming, look how simple this is to be close enough:

So, as I said, the JCZ controller isn’t relevant since we’re comparing the visuals.

My point about layer counts and percentages being visible in Preview is a simple matter of knowing what LightBurn determines to send to the laser controller when I click Start here. Why is this important? Well, if LightBurn shows the amount of layers to be executed, then you know ahead of time what’s happening. If the layer count in the main settings is 2560, and I put the preview window exactly at 50%, then it should say 1280 to be executed. However, it seems that is not the behavior, at least not with higher layer counts/passes.

Consider this: time is usually tapered to some degree IME. Meaning, the final layers are smaller and pass much faster than the earlier/larger layers. Now compare my previous statement about job completion percentages, and time spent on each section. The numbers don’t add up.

The amount of wasted hours and materials that could save users is immeasurable.

Thanks,
Josh

[Finn65 (Finn)]

You are on 2.0.05, so this is still 8 bit 3D Slice. At 2560 passes, LightBurn is not generating 2560 unique depth layers. It is reusing the same 256 threshold states about 10 times. That is why your timing, percentage, and eyeballed restart logic stop making sense at those counts. Time per slice is not constant, because scan efficiency changes with the shape and continuity of the active regions, not just with how much area remains. The 1000 behaviour is with the 8 bit version, not the 16 bit version of LightBurn.

[jkwilborn (Jack Wilborn)]

@Finn65

16 bit version of LightBurn

Is there a 16 bit version?

[Finn65 (Finn)]

Its supported in LightBurn-v2.1.00-RC

[MikeyH (Mike Hembrey)]

@Finn65

8 bit version, not the 16 bit version of LightBurn

Did you mean 16 bit and 32 bit? Or 32 and 64 bit?

I have not seen 8-bit since I retired my Z80 processor.

[Moza (Greg)]

He was actually referring to the 8 bit vs. 16 bit depth map (bit depth of the image) for 3D engraving, not the software architecture.

While LightBurn runs as a 64 bit application, the distinction between 8 bit and 16 bit image files is crucial for avoiding “stepping” in relief gradients. 8 bit only offers 256 levels of gray, while 16 bit provides 65,536 for much smoother transitions.

[jkwilborn (Jack Wilborn)]

@Finn65

supported in LightBurn-v2.1.00-RC

Probably why I haven’t seen it. I’m still using Linux…

---

Does that mean I have to make 65,536 passes to get it to use all the information?

256 passes takes a couple of hours, the whole operation is 256 times 2 hour passes… Don’t know how how long this would take…

[Finn65 (Finn)]

No, I am referring to greyscale depth maps, as that is what the topic is discussing.

[Finn65 (Finn)]

I am not sure what your referring as I can’t any other post here you have made for some reason.

But yes the topic we are discussing is greyscale depth maps for 3d engraving.

[Finn65 (Finn)]

Not really. A 16 bit depth map gives LightBurn up to 65,536 tonal levels to work with, but that does not mean you need to do 65,536 passes to get a benefit from it, though you could if you really wanted to.

What it means is that, unlike 8 bit, once you go above 256 passes LightBurn can keep using new threshold steps instead of just repeating the same ones over and over.

So with 8 bit, 512 passes is basically two passes per threshold on average.

With 16 bit, 512 passes can still be 512 different threshold steps, which should give smoother 3D curves with less visible stepping. The downside is still the same though: more passes means more runtime.

In the discussion, Josh was trying to do 2560 passes using 8 bit greyscale, so he was basically engraving the same layer about 10 times on average.

[Finn65 (Finn)]

I just checked LightBurn-v2.1.00-RC and it only allows 5000 passes as maximum.

I dare say the 1000 and 5000 limit was a developer choice is so the program runs smoothly without crashing as those files could get pretty large.

[KungFuJosh (Joshua Peromsik)]

@Finn65

In the discussion, Josh was trying to do 2560 passes using 8 bit greyscale, so he was basically engraving the same layer about 10 times on average.

That’s correct, and intentional. The issue is that Titanium is a whiny bastard when it comes to power, and requires lower heat and more passes to get any depth. Otherwise, it comes out bubbly and/or rough.

You can see on C3PO that it’s shallow, and still a tiny bit rough despite being moderate power at 512 passes.

R2D2 has thousands of passes at lower power, with significantly better results. Over 2mm depth on the engrave on that side.

I’m hoping 16bit image map support will resolve this. The behavior currently is buggy at best; but to be fair, it’s pushing the function well beyond what was probably expected.

Thanks,
Josh

[Finn65 (Finn)]

@KungFuJosh

That’s correct, and intentional. The issue is that Titanium is a whiny bastard when it comes to power, and requires lower heat and more passes to get any depth. Otherwise, it comes out bubbly and/or rough.

Have you tried shortening your pulse width and adjusting your kHz first to address the heat and finish issue directly?

[KungFuJosh (Joshua Peromsik)]

Not extensively, but isn’t the result roughly the same? Extended time to get similar results?

I could sacrifice a coin to screw around more with that- do you have suggestions for a starting point?

Thanks,
Josh

[Finn65 (Finn)]

I do not know what laser source you are using, but pulse width and frequency change the pulse interaction itself, not just the runtime. In general, a shorter pulse width tends to give more ablation and less melt, though it still needs to be tested on the actual machine and material because the response is laser dependent. I would probably start by testing around 150 ns and your lower usable kHz range, then raise power as needed. This really does need to be tested on your machine and material, because it is very machine and material dependent.