I’m trying to hone in on why and when this happens. Sometimes, I’ll have an image in LightBurn that looks fine.
So I export it and the thumbnail is off:
Drag it back into LB and get this:
Usually, deleting the stray nodes at the bottom (in this case) and re-exporting it fixes the file. I can say with certainty that this occurs when exporting “the file” (with nothing selected). I will start exporting “selected” and see if it happens. I usually “select all” before exporting to ensure no stray pieces sneak in.
This is the file with the image as originally exported as well as the re-imported version.
owl-1.lbrn2 (73.8 KB)
It did it again, sort of, this time exporting selected objects.
But this time, when re-importing the exported file, it still looks fine in LB.
Apparently it’s not possible to fool the server into just uploading the svg files. Changing the file type didn’t make a difference.
I suspect, in this case, it has to do with the open shapes since it is a line drawing. Offsetting and fattening the lines seems to have cured it.
Those are still SVGs, they’re just rendered so you can see them. (I’ve never verified if the content is fully intact)
I’ll have a look at the files and see if I can figure out what’s going on.
If I “shatter and re-assemble” your owl file, using Alt-B (break apart) then Alt-J (auto-join), it exports and imports correctly.
I haven’t gone through the file content in enough detail to understand what’s busted yet, but I’m guessing you edited this a lot in node editing, and something went sideways in the process. Was this completely done with the 1.3.00 update, or created with a prior version?
Alright, I think I know what’s happening, and it’s a genuine bug - haven’t seen this before, but some of the shapes in your file have only a single point in them, like this one:
The two control handles for that point make the line go in different directions, and loop back to the start. I think this is confusing the heck out of my export code, and possibly the code that sorts shapes into inside / outside shapes to decide what goes where.
I’ll go figure out why this breaks it.
Ok, owl works now:
Will look at the other file to make sure that one works as well.
This one is borked because you exported it set to Fill, but almost all of this is single stroke lines that won’t fill. Change the appropriate shapes to a Line layer and re-export, and it works as expected.
Some time ago I had a different issue which might be considered somewhat related:
I had an issue with single point curves where the enclosed area wasn’t being filled. The vectors had been imported from CorelDraw clipart. I fixed it by adding an extra node and LB then recognised it as an enclosed area and filled it accordingly.
Yeah it doesn’t look like they automatically join either - the auto-join code likely ignores anything with only one node, so I might need to handle this case specially.
The “Fill” code now allows for shapes that are “sealed” but not closed - IE, if the starting point and ending point have the same numeric coordinates, but are stored as different nodes, it still fills the shape, so those old files likely work now.
Beta builds are updated with this fix.
This started as an SVG file found on the interwebz. I’m trying to build a library of “LightBurn certified” vector graphics. I did no editing to this particular file. Import into LB, if it looks right export to library. Something happened in the export…
Ok, so the import handled it properly, but the export messed it up. That’s fixed now.
This makes my brain hurt.
I’ve written millions of lines of code. Mostly process control stuff for running custom machinery and refrigeration systems. Lots of it was assembly language, lots of it was C. I’ve done a huge amount of programming in LabVIEW also. It’s been a few years now since I left your world.
Since the last update I downloaded (12/4) I have not had one bad svg file saved with “flying nodes”. I think we won this round.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.