I stumbled onto bug when doing 3D engraving. The file is svg with 2 raster images for 3D engraving conical holes and vector graphics for cutting. When doing 1-2 copies, everything is fine. When doing something like 10+ copies, one 3D engraved hole is fine. Another gets offset by 1-2 mm. This is not some mechanical issue since all cutting steps which follow are spot on. Also creating another new design replicates the same issue. And the worst part is that I cannot even use svg file filled with many copies since it gets rendered for something like 20 minutes with high CPU load (Chrome). And even after it’s completed everything is so unresponsive that it’s almost impossible to do anything. This happens when number of copies in SVG exceed certain threshold.
3D_eng_cut.zip (10.8 KB)
Are you embedding your raster images into the file? (If it was created in AI that’s a separate step that it’s easy to forget.)
Yes. And everything is engraved/cut perfectly fine. But when I replicate the same thing multiple times (at Glowforge web UI), then offset happens. At web UI there is no visible offset. It only happens when physically engraved. Attached zipped SVG since it gets altered by the website otherwise.3D_eng_cut.zip (10.8 KB)
Ah okay, I think I see what is going on…
When you are copying the engraving and moving it to be where the cut is…are you doing that in the Glowforge interface or in your design software before you save the file?
If you do it in the Glowforge interface, you will have to use Set Focus several times in order to get a correct alignment, because the view changes every time you use it. While the first one will align, the next copy won’t unless you use Set Focus again over the second cut hole. (The reason why is pretty complex to explain, but long story short, when you use Set Focus in a spot, it corrects the fisheye effect at that spot. Everything else is going to “appear” to shift slightly.)
The best thing to do is to copy, align and Embed your engraves in your design software before you save the file as an SVG. Then they are locked into place relative to each other.
If you absolutely can’t do that for some reason, make sure to use the Set Focus in a spot before you place the design in that spot. It temporarily shifts the view there to correct for fisheye effect.
(Or maybe I’m not understanding how you are doing it…if you are copying everything together it should maintain relative distances.)
There is no issue with engraved hole as such, no issue with focus, the issue is with it’s position. It gets offset in X/Y position, not Z. Second countersunk hole nearby it gets engraved without offset just fine. When doing say 10 copies in SVG file, no offset happens. If the same 10 copies are done in Glowforoge web UI, one of the holes position is offset by 1-2mm.
Hmmmm…Okay, I took a look at the file itself…it is opening as aligned in the GFUI, but there might be an issue with it being corrupted because the print preview looks like this before opening it in Illustrator.
Those don’t look aligned to me. When I open it in AI though, it does appear to be aligned, but the artboard is smaller than the design. Try copying your design into a 12" x 20" artboard and reopening it in the GFUI and see if it happens again. I’ve seen weird problems happen in the past if the artboard is smaller than the design.
Glowforge, inkscape and google chrome displays it just fine. And it is produced fine as well, unless I make multiple copies within glowforge web UI. Again they look fine on the screen in Glowforge web UI even when zoomed. The issue only happens when multiple copies of it are physically produced.
I’d still try one, including the copying, with a larger artboard to see if it still happens.
As a data point, because if this is a bug, you aren’t going to get an immediate answer, and a data point will help them find it. (It might have something to do with how rasters and vectors are treated relative to an origin that might be out of range on smaller artboards.)
It’s not smaller. At least in Inkscape. Page size is set to larger dimensions than it’s contents.
I could try it with larger page size. But feel reserved about it. I ruined enough of material with my experiments already.
Using a larger artboard does not use any more material…the design is going to be the same size.
Here’s what it looks like when I open your file in Illustrator. It looks a little funny because I had the original units set to inches and you are using metric.
When I copy that into an artboard (or canvas in Inkscape) that is 508mm x 304.8mm (same as 20" x 12") the results will look like this:
The size of the file itself doesn’t change, it’s just appearing on an artboard that approximates the bed size.
There’s a reason for doing that…based on early testing with different native DPI values for different drawing programs, the Glowforge team developed a workaround to keep files coming in from different drawing programs from being resized incorrectly. That workaround is to always design on a 20" x 12" (or 508 mm x 304.8 mm) artboard.
Once you open it in the GFUI, all you will see is the design and you can move it where you want.
Dunno why it’s shown as such in adobe illustrator but page size is 90 * 50 mm while contents are 82 * 38mm. You can see it on screenshot in my previous post. Increasing it does not take more material. What I’m meaning I need to make something like 10 copies for issue to appear.
Probably has something to do with the default DPI on your version of Inkscape versus Illustrator, so you’re right…might not be causing this issue.
Well, don’t know what else you can try, so just wait till support sees it. It’s been reported. Maybe they can find something.
One other advantage to creating it on the larger artboard…you can duplicate the copies in Inkscape, arrange them to fit on the board (which roughly corresponds to the size of the bed, the cutting area is 19.5 " x 10.9") and you can save the file with the correct number of copies in it, and not have to mess with copying in the GFUI. It’s much faster, and tends to not develop copying problems.
As I said already in the opening post, the issue is that Glowforge does not like rendering too complicated files which I’ve seen reported by other people too. I converted 2 embedded raster images into one and will see how it works.
That’s not nearly as complicated as some of the files I’ve seen…even with ten or more copies. It shouldn’t be causing the raster images to shift or lock up.
It does not like many raster images embedded. If I say make 30 copies in SVG file to fully fill the bed, it renders for 10+ minutes and after that finishes becomes unusably slow. But it renders fine if I remove most of raster images from the file. There is some issue with script running in browser when certain threshold is exceeded. It works OK up to some threshold, add some more and it starts rendering over 10 minutes while fully occupying CPU core. Happens in Chrome and Edge. Did not try Firefox.
I just made a new file with your design, then made 25 copies in the UI workspace. It can be manipulated at will, there is no lag. If I close it, then re-open, it takes 3 seconds before the workspace appears again.
I just doubled it to 50 copies (opened, select-all, copy, paste, close.) It took 7 seconds to “render”…
Chrome on a Macbook.
As I already said, I can make many copies of it within UI of Glowforge just fine. But then offset issue appears when engraving. The problem with rendering only happens if I make a lot of copies within single SVG file (to use it as workaround).
I’m so sorry to hear that you’re running into this snag, but I appreciate you working so closely with our community to attempt to narrow down the trouble.
Just to confirm, if you print the file once, the offset does not occur, and you can do this up to 10 times before you see the offset happening, or is it happening more randomly as you print one version of the file over and over?
Also, are you noticing any other offsets occurring when printing multiple copies of the same design in one print, or only when printing copies of this particular design?