Converting unfilled, unclosed paths from Cut to Engrave fills them

[alexbbrown]

In this image of my render, the top and bottom layers are unclosed, unfilled lines/paths (like circuit traces). I converted one of these path sets to ProofGrade engrave to see how it looks, and it has changed it to the equivalent filled, closed path.

When I printed it, it did engrave the inside of path (so it’s not just a UI issue).

Curiously, it didn’t fill it where even numbers of these shapes overlapped (there might be some fun to be had there)

Expected: unfilled unclosed paths should not be filled when converted to engrave - the engrave should just rasterise the path itself.

---

I guess the obvious workaround is: don’t do that. Or, convert to outlines first.

[marmak3261]

You have experienced a basic feature of how Glowforge treats vectors. There have been some lively discussions about how the GFUI handles these cases:

Engraving vector lines?

I had that in my original design and it rendered in the ui as two right triangles when set to engrave… [image]

Using vector for engraving instead of raster

Ive noticed in several threads the mentioning of using vector for cutting and raster for engraving. Most of the artwork I use for my current engravings is vector and so are my cut lines. Is it necessary with the GF to convert all engravings to raster? In some very detailed illustrations, wouldnt users lose some of the detail when converting? Jake

Bug: Open paths in SVG are closed by in app.glowforge.com

I have a neat SVG of the Escher lizard. It has a couple of curvy lines on its back. Cool! The problem is that the app renders said curvy lines as closed paths; it connects the end to the beginning. If I’m scoring, it cuts through the material along with path without closing. For engrave, though, it closes the path by drawing a straight-line from beginning to end.

[alexbbrown]

Thanks @marmak3261. I understand what’s going on now, and I have updated my expectations to align with reality again.

[marmak3261]

A few folks with laser experience had to unlearn some things about this. I was starting from scratch so I was able to learn the basics. Even after a year of forum activity and lots of file dissection, I still had a few cases where I didn’t quite get if figured out. Your example is superb though and something that folks can learn from. Thanks for posting.

[bbum]

Neat! So, the overlapping fills that resulted in alternating fills of burn are demonstrative of the even/odd fill rule oft used in graphics algorithms, it seems! Or, in this case, the GFUI is filling based on the # of closed paths that are stacked. Which is a bit weird, but reasonable.

Tangentially related:

Even–odd rule

Potentially more directly related. May be fallout from the way the SVG rendering engine is implemented. Interesting.

Understanding the SVG fill-rule Property — SitePoint

[johnse]

Also note that at this time Glowforge only understands fill-rule:nonzero, not fill-rule:evenodd

[alexbbrown]

Well that’s kind of odd, because the result I got looks very much like the effect of evenodd.

I have replaced the result in my post with a better version so it can be seen more clearly.

[bbum]

This doesn’t appear to be a continuous path, though, but overlapping paths?

I don’t know how the SVG fill rules apply across multiple paths.

[vee]

I’m so sorry for the late reply. Thanks everyone for the great help! @alexbbrown, I’ve passed your report on to the team.

Were you able to get the print you wanted after following the suggestions in this thread?

[Rita]

It’s been a little while since I’ve seen any replies on this thread so I’m going to close it. If you still need help with this please either start a new thread or email support@glowforge.com.