The bit in question is made up of essentially 2 components. There’s a “background” diamond with rounded corners and there are the “foreground” lines forming the Celtic knot shape. In the image below I’ve zoomed in and made the diamond blue to make this more apparent.
I see no reason why this should behave differently depending on the fill setting and grouping. I especially don’t think the print behavior should be different than the edit view.
Can someone help me understand what’s going on here?
Essentially the two side shapes where you have an ambiguous overlap is being evaluated as requiring both the diamond and the partial celtic knot areas to burn independently. This isn’t a problem for the other areas where the knot area is fully enclosed by the diamond.
Then the entire “inner” shape would have been burned. But it wasn’t. Only the ambiguous overlap was burned.
It’s clearly evaluating the overlap and thus not burning the shape “as if it were standalone”.
I’d argue that it should ALWAYS burn just like the view in the editor, regardless of the grouping option in the layer panel. Alternatively, the editor should show the effect of the current burn settings in the layer panel.
It’s very confusing to have it display one way and burn a different way.
The inner shape was evaluated within the context and evaluated as unambiguously negative space. The overlapped portion was ambiguous. I can see an argument where the ambiguous portion should be evaluated holistically. Not sure if bug or feature. In any case, I was just explaining what’s likely happening.
This isn’t so straightforward. What you’re describing is how some laser workflows work. I believe Corel->Epilog works somewhat that way. Essentially I believe it rasterizes everything before burning and reserves a color for cut operations.
But imagine something like this in Fill mode:
But this is what it actually looks like in wireframe mode:
This would double burn the overlapping areas in LightBurn today. Are you saying that you’d prefer LightBurn to use a painter’s algorithm and burn the visible black area with one setting, and then only the blue area with another setting while ignoring the overlapped portion?
That would be a fundamental paradigm shift for LightBurn. One I personally would not welcome but not sure how widespread that idea is.
So the inner shape wasn’t “burned as if it were standalone”. Instead it was burned with reference to the underlying diamond. I’m simply saying the overlap should have been evaluated the same way way - in the context of the underlying diamond. That, unambiguously (at least in the case of the editor) shows that it is negative space in the overlap and burned outside.
Grouping doesn’t change the ambiguity. There is still the same question about whether it’s inside or outside. Grouping should NOT change the interpretation, that’s what the boolean tools are for.
… is, at best, more confusing than doing exactly what the editor shows, unambiguously, about what the overlap produces.
It’s a usability issue (bug, IMHO) that the burn process does radically different things because of relatively obscure and seemingly unrelated settings on the layers panel while showing nothing different in the editor.
Just my $0.02 as a relatively savvy technology user.
[edited to add …]
BTW, your example of the painter’s algorithm is also inconsistent in lightburn. If I group the blue and black squares together and say “burn groups together” then I’d expect the painter’s algorithm to apply, but it doesn’t. It STILL burns them as separate objects.
At the VERY LEAST it should be consistent about this.
I may not have been sufficiently clear. I was not directly comparing that scenario to your original issue. Only addressing your statement that you expect to burn whatever you seen on-screen. I was trying to highlight a scenario where that would fundamentally be counter to how LightBurn works and may not be so straightforward.
It was a pivot. Not a direct explanation for the original issue.
The square and the 3 bottom circles are grouped. In the editor this looks identical to the top, but when burning the burn mode radically alters the behavior. That’s the crux of the issue. It looks one way in the editor and burns randomly depending on some obscure setting.
However, I think everyone understands and expects layers to burn independently. They don’t expect things on the same layer to burn very differently than how they are depicted in the editor.
Perhaps for folks familiar with LightBurn but this trips up a lot of people and I’ve seen Epilog users very much argue for a pure WYSIWIG workflow. I can see the appeal for this being one style of workflow.
What do you mean? The example I showed is quite straight forward. It’s simply two overlapping shapes. There’s no confusion about what’s going on.
The issue is that it doesn’t burn as it’s shown in the editor.
These two circles should burn the same and they don’t depending on grouping and an obscure setting in the layers panel. That’s the problem and it’s a bug in my opinion. They either need to burn the same or there needs to be some visual indication in the editor that they are different.
The original SVG was created by someone using an Epilog laser. Epilog will do a WYSIWYG on poorly created fill patterns. The creator used white fill masks for knockouts. You can’t do that in Lightburn.
The bug comes when you try to burn this. Depending on what is grouped and which “fill …” mode you have selected on the layer, it will burn differently.
In “fill groups together” with everything ungrouped it looks like this:
Note that the two “wings” on either side are burned black rather than knocked out as the other pieces are. You’ll get the same output if you pick “fill shapes individually” no matter how they are grouped.
With “fill all shapes at once” it looks like this:
You’ll get the same results if you group the “ambiguous overlaps” and the base diamond together and select “fill groups together”. This is, in my opinion, how it should burn regardless of how it is grouped or what “fill …” setting is selected in the layer window.
In this rendering the left knot pieces are grouped with the background diamond and “fill groups together” is selected:
I believe one of two things needs to happen. Either the editor display needs to change to match the way it will be burned or the burn process needs to implement the same overlap / interference algorithm that the editor uses.
We’re on different pages. I’m saying there’s likely something going on internally in the application that we’re not privy to that’s deciding draw order or whether or not something is getting negated. It’s likely not easily recognized outside-in.
