It does and it is. I bet everyone who has one has asked for the “save project with settings” feature.
I expect it wasn’t an initial use case because PG doesn’t need it if you use the stroke vs fill conventions (although even there just saving the color/depth of the engraves or specifying scores vs cuts would be handy).
SVG files allow for arbitrary metadata to be added, which would make saving properties in the same file you import a possibility (and somewhat trivial since GFUI is already parsing them). Most bitmap formats also allow for metadata to be saved internally as well, though not all. It might just be easiest/prudent to save project files as SVG, even bitmaps could be wrapped as SVG, both with the appropriate metadata, a-la InkScape.
Of course the opposite side of this happy scenario is that should GFHQ want to keep all of the settings locked down in whatever they may eventually save projects as, SVG probably isn’t the first choice, at least if they want the files to remain interoperable.
Personally, I’d love to be able to programmatically create SVGs with custom settings embedded and just send it on. But if I could do it, others could do it, and then GF’s “secret sauce” could be considered less valuable.
Does Glowforge not use the color-based approach that other laser machines use? (Where the designer makes all the different types of operation a different color and the machine/CAM software uses those colors to pick the appropriate settings for the machine and material being used.)
Storing the settings in the file sounds like a good idea at first blush, but I think it’s a recipe for making a mess of the files. I wrote up some reasons why I think this, but it was basically a diatribe (I think I have it saved though, if anyone wants I should be able to post it).
That’s true! Though, I think I’ve seen people say things that suggest that the colors are incidental. Like, apparently all vector fills get engraved the same way unless they’re changed individually (in other words, the color doesn’t affect the settings, only selecting the fill and changing it manually will change the power/speed).
Also, I know there some issue with vectors all being the same color somewhere in the UI (in the list on the left maybe) and that causing usabability problems because it’s sometimes difficult to tell similar shapes appart.
yes. It groups objects by color. those groups can then have different operations & settings. Individual components with the same color cannot be separately manipulated - for example 5 boxes colored blue will have the same operation & setting and can only be moved, resized, deleted in the GFUI as a group, you can’t resize, move or delete just one of the 5 blue boxes.
EDIT As @marmak3261 points out below, this is true only if the same colored objects are overlapped or nested and even if they are different colors this is true. It the five squares or whatever are individual and not touching or inside each other same color or different color, you can do the normal copy resize rotate with each individual square.
the UI defaults to objects with a stroke but no fill (or filled - it’s the stroke that controls) as a cut and filled objects without a stroke as an engrave. You can override this.
You might want to recheck this fact. If the same colored objects are overlapped or nested and even if they are different colors this is true. It the five squares or whatever are individual and not touching or inside each other same color or different color, you can do the normal copy resize rotate with each individual square. At least this is what my GFUI does.
The same color just means that all objects with that same fill or same stroke colore are treated as one operation and have the same settings.
Thanks. That’s probably what I found and didn’t have something that wasn’t nested or overlapping.
It’s an example of something that people don’t realize about PRU testing. When doing a definitive test routine on the unit we do an awful lot of near-exhaustive testing scenarios. Otherwise it’s what we see in whatever “oh by the way” testing that occurs as part of other projects as this was in my case.
I edited my original post to reflect this in case someone finds it but doesn’t read the clarification. ️
It sounds like examples 1, 2, 3, and 4 would have 1, 2, 3, and 4 “objects” in them, respectively. Those make perfect sense. Each object can have its own cut settings, can be translated (moved, scaled, rotated), and can be deleted/ignored individually.
It sounds like example 5 would be treated as a single object, even though the design has two individual shapes in it. The fact that the two shapes are nested means the GFUI sees them as a single unit. Is this what you guys mean by “nested”?
… and just like example 5, it seems like example 6 would also be a single object. This time because the two squares are overlapping.
Example 7 is a little more confusing. It sounds like the GFUI will treat these three squares as two objects. It sounds like although the blue square is a different color, the fact that it overlaps one of the red squares means that those two squares are merged into a single object which can be translated, deleted, or have its settings modified; both the overlapping red square and the blue square will be processed as a single unit.
It sounds like example 8 would be a single object, even though it’s very similar to example 4 (which would be treated as four objects) because the new green rectangle joins them all together. A user would not be able to ignore any single shape or color using only the GFUI, they would have to choose to process all the colored rectangles as a single unit, ignore all five of the rectangles, or edit the SVG file.
Close…as long as you have set up different colors in your overlapping groups, you can choose to ignore parts of the group based on color. But you can’t break up the group.
Resizing/moving in the GFUI will affect everything in the group equally.
That used to be handled differently, but it was changed (I believe) because dragging a selection rectangle around an odd shape on a tightly packed artboard without capturing parts of other groups was problematic. (And SHIFT-clicking on individual parts was a real pain, especially for unconnected DXFs that originated in some of the CAD programs.)
Thanks! So, with example 8 you could ignore the lil’ cyan rectangle. That’s cool. And you can’t break up the other rectangles, so no translating the other shapes. Oh darn. How about cut settings? Could you do the magenta square at 100IPM and the other colors/shapes at 150IPM?
Yeah, my impression without knowing how it used to be: it’s all about the selection rectangle. (There’s also a weird thing where you can’t move something with an onscreen drag unless it’s larger than a critical size.)
I can control operations by color with mine but can’t delete or move or resize them in the control software. So this is more than I’ve had before
Once you figure out the nested & overlapping impact it all makes sense.
One trick that I find handy is breaking an object with a miniscule cut. A lot of times I want to do a final cut out of the project - like a square or circle. If I draw one that surrounds it then I can’t manipulate the internal objects individually if I need to (resize or move) even though I can specify different operations. What I do is draw the bounding box and then clip a tiny piece out of the box/circle. That stops it from being a bounding box as it’s an open object. But I can still make it a final cut and the tiny spot won’t stop it from freeing. It’s like leaving a tab to break it out afterwards.