Understanding the Order the GF Cuts

That topic I linked with Dans reply has some good speculation as to why.

Maybe a sort by hex color codes

I googled hex values for colors

The best is cut inside to out. My plotter software automatically orders the cuts that is best for the integrity of the medium. I don’t understand why the Glowforge doesn’t do that

Googled

svg file format

went to wikipedia article and found #22ff00 under the color section as an example, if you sort by that number you would use it as a cutting order.

Color

Colors can be applied to all visible SVG elements, either directly or via fill , stroke , and other properties. Colors are specified in the same way as in CSS2, i.e. using names like black or blue , in hexadecimal such as #2f0 or #22ff00 , in decimal like rgb(255,255,127) , or as percentages of the form rgb(100%,100%,50%) .[32]

Black would be 000000 and the other end of the list above (yellow) would be FFFF00

orange is FFA500 which would go after black but before yellow

sort by hex value and it matches up nicely :slight_smile: I think someone is going to have to do a bunch of cuts with tons on colors and see how it matches up. Or get one of their programmers to pipe up :-D, Python rocks!!! Java sucks!! (there, that will get a programmer’s reaction :smiley: )

1 Like

While nerdy-interesting, since my project was all one color, the color codes wouldn’t apply in this case. (I dig the info, though!)

1 Like

I think since its all one color it calculates fastest cut times and cuts the fastest available paths (thats just a guess of mine though, seems to be that everything is calculated based on top speed possible to make print time less. Thats why some insides and some out sides all out of what would be normal orders we would think would be normal. This is just from what I noticed in all of my projects over time), if you want specific order make all different colors then order manually. I do this with my inside cuts are purple, scores are light blue, and outer cuts are red. Then I put them in that order so i know it will cut that way.

1 Like

Doh! Must have not have had enough coffee sorry :slight_smile:

1 Like

Completely beats me! I programmed the living hinge creator for optimised paths. Works perfectly and saves up to 20% of the cut time. Sometimes…

Other times Gf goes all over the place cutting backwards and forwards and jumping about.

2 Likes

It’s all good! I really appreciate the reply and thinking it through together. I always come out better because of it.

It would be really handy if this was documented. I spend a lot of time reordering layers in the GF UI that could be avoided if I could tell what order they were going to end up in in advance. On a related note, is there any way to put cut/score/engrave settings in the file in advance so they don’t have to be done by hand (and possibly incorrectly) in the UI?

1 Like

Strokes will be automatically identified as cuts (and have to be manually changed to scores). Fills will be automatically identified as engraves.

But no - not a way, that I’ve seen or anyone has discovered, to automatically set up a score. GF does it with catalog files, but I suspect that it involves adding in additional info with a text editor to the SVG files.

1 Like

Everybody knows that unless they just got their Glowforge today and haven’t read the manual. I asked about cut/score/engrave settings. As it stands now, I have to redo the settings by hand every time I bring a file in. I have some pretty complex files and it is easy to forget something. If anybody else has discovered some secret feature that does this, it would be great to know. No text editing would be necessary — you can name elements in Adobe Illustrator and I’ll bet you can in Inkscape and other programs. too. Here’s a file I created in under a minute. See the id= parameters on the elements and groups.

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     width="250px" height="250px" viewBox="0 0 250 250" enable-background="new 0 0 250 250" xml:space="preserve">
<rect id="cut-400-Full-340" x="15" y="15" fill="#FFFFFF" stroke="#231F20" stroke-width="1.0385" stroke-miterlimit="10" width="220" height="220"/>
<g id="score-1000-100-270">
    <circle id="b" fill="#FFFFFF" stroke="#1DFF58" stroke-width="0.7598" stroke-miterlimit="10" cx="75" cy="82.115" r="50"/>
    <circle id="a" fill="#FFFFFF" stroke="#1DFF58" stroke-width="0.6961" stroke-miterlimit="10" cx="175" cy="167.885" r="50"/>
</g>
<g>
    <circle id="engrave-500-50-340_1_" fill="#FF00FF" stroke="#FFFFFF" stroke-width="1.0385" stroke-miterlimit="10" cx="75" cy="175" r="18.5"/> 
    <circle id="engrave-500-50-340_2_" fill="#FF00FF" stroke="#FFFFFF" stroke-width="1.0385" stroke-miterlimit="10" cx="175" cy="75" r="18.5"/>
</g>
</svg>

I’m sure this is already on the suggestion list. Would be nice to see it sooner rather than later.

On the other question, any @glowforge people want to let us know if there is any official documentation on whether there is an ordering by color and, if so, what that ordering is?

Not a Glowforge person nor is it officially documented other than threads on this forum but here is the color ordering. It’s based on Web hexadecimal values and the GFUI orders them such that colors towards the left are last and colors towards the right are first.

Based on what I have seen, the algorithm that defines the order does not necessarily choose the same order for the same project every time. It could run a different order each time you run the same job.

1 Like

This doesn’t make sense.

First there is no standard thing called “WebHex” colors (best I can tell it’s the name of one of the default palettes in Inkscape, which I’ve never used). There isn’t even really a think called “hex colors”. There are 24-bit RGB colors which can be represented in hex, which is how you specify colors on the web. But they can also be represented in other ways such as rgb(0,102,51) a nice evergreenish color, also rgb(0%,40%,20%). There are 2^24 24-bit colors or about 16.8 million of them and that’s not counting 256 levels of opacity. Colors outside the 24-bit range can be specified with rgb() but let’s ignore that.

Second, there is no canonical order of colors, not surprising since RGB colors occupy a 3-dimensional space. There isn’t even a canonical order of the 216 “web safe” colors that are almost completely irrelevant these days — for example, these pages present the web safe palette in three different orders (Color Chart — HTML Color Codes, websafecolors.info, Web colors - Wikipedia). Also, since the 216 web safe colors all have names, some sites present them in alphabetical order.

I find it hard to believe that Glowforge would implement an algorithm that only works for the 216 web safe colors or relies on the colors in a particular “WebHex” palette in a particular application.

I could believe one of these:

  • It’s random (seems pretty unlikely to me)
  • It’s based on colors as first encountered in the file
  • It’s sorted by intensity (e.g., R + G + B maybe + A)
  • It’s sorted by R, then G, then B (etc.)

Has anyone done a large enough test to know for sure or does anybody from @glowforge want to enlighten us? Thanks.

I believe I’ve seen this too. Given that the Glowforge people are pretty smart and have done a lot of things right, I can’t believe it’s random. Perhaps another variable is head speed? Or material?

There are multiple threads on this forum regarding setting up custom color pallets for Inkscape, CorelDRAW, Illustrator and Affinity Designer specifically for controlling the order of operations that the GFUI loads… even already mentioned in this very thread with a direct link.

And I’ve been using these colors daily for over a year. It’s well tested. I know it works. Multiple other long time users know it works.

2 Likes

My bad.

Not sure what your point is as far as naming elements in AI. That’s a gimme. Is that how you propose Glowforge should allow you to define the settings? If that’s what you really want, you should post the suggestion in #problems-and-support.

I can see a lot of inherent problems with that with the way Glowforge defines operations (by color).

1 Like

I’m adding this comment here mainly for anyone else who comes across this thread. See the other thread I have linked to.

The named colors above was not useful as “dark blue” (e.g.) is not well defined. There are many dark blues. However, I did find this post which I had missed earlier (when I found this one): Custom Inkscape, Illustrator, CorelDraw and Affinity Designer Color Palettes for ordering operations in GFUI and it contains hex and numerical values for the colors listed above. Based on that, it looks like my guess that sorting could be by R, then G, then B, is correct. This can also be looked at as sorting by the entire hex value, if you have that value available. Given this, I don’t need a palette.

Names/ids are not ideal but I think it may be the best solution given that GF doesn’t control all the various illustration products.

For engrave vs. cut, GF has done what every other laser cutter does — differentiate fill vs. stroke. Currently, score is manual.

For order of operations, they really only have two choices: 1) order in file (back-to-front or front-to-back) or 2) color. I actually like color better because it is easier to control. My only complaint is that it’s not documented anywhere.

For manual override settings, I can only think of two things that would be internal to the file: 1) names/ids, 2) a special visible text block that contains instructions and is ignored for cutting purposes. That might be cool but would be pretty hard.