There are two related pieces of information needed for a print: The artwork (SVG and/or Raster) and the information for power, speed, focus, etc (the Metadata for the print). As I understand it (not having a GF yet) you select the art in the GFUI and then manually enter the metadata.
If you have a complex project with more than a few vector colors, that could get tiresome and error prone. Especially if you want to make changes to a few parameters to tweak the outcome or want to be able to replicate the print later.
Is there a way to, for example, have a spreadsheet where each row is the information for a vector color and the columns have the parameters for doing that part of the job?
One could also create scripts for the various image tools to create this metadata.
I was thinking @karaelena amd @takitus worked on some scripts to auto fill the operations boxes as a work around to the interface not saving your own custom designs. At the moment, it is manual and is error prone. As I design files, I think of how I’m going to process them so they get set up efficiently, but some of them get pretty complicated, like the scrabble board that had multiple layers that I turned on and off and processed for two halves of the board.
Here is hoping that Glowforge implements this or someone understands how a Glowforge designed file gets autoprocessed to defaults.
Ultimately the defaults are not granular enough for all the varieties of materials and use cases. I’m curious as to how that developes with their own in house designs. You will want to color outside the lines very quickly with your own designs and own materials and being able to save those settings will save time. In the end, the time is not the biggest issue as is error free settings entry. Compared to a three hour engrave that I am doing, setting up the file is easy. It’s just remembering which steps go when and where.
I would love to be able to save a file within the UI like I can for my silhouette. With their software, I can import the file, position it, resize it, and choose cut settings, then save it as a silhouette file.
Maybe just simply being able to save settings for particular colors of lines/fills. Something like, if the stroke’s RGB value is 79,139, 232 (a bright and noticeable fuchia) I want the Glowforge to score with these particular power and speed settings every time. If the fills RGB value is… then I want it to engrave with these settings every time.
I suppose they could prescribe colors to different settings to allow for consistency when sharing files and just have the option to save our own. Or a set of prescribed color/setting combos and the rest open for “custom” user settings.
I really feel something in this area could get me to hitting that glowey button faster.
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.)
I did get to see the GFUI in person (thanks again @chevalier_jeanpaul and others (like @marmak3261)!) but I forget how that aspect of it works.
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.
The colors don’t do anything about the depth of engrave/cut, but they do determine the default order of engraving/cutting. (IIRC in the numerical sort order for the RGB number)
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?
