Having done a handful of projects-- both explorative and concrete, multi unit, projects-- now, I’m finding that my largest desire from the GFUI is repeatability. Even more so than being able to save off a particular print configuration for future use.
Often, my projects involve repeating a particular item. I need 10 or 12 or more of one particular thing cut out and that thing involves, say, 1 or 2 engraving passes, a score pass, and a couple of cutting passes. As it is, I have to configure each pass individually for each repetition. That’s a lot of repetition and if I forget one, that unit is pretty much a throwaway.
In fact, I’d be happy if I could configure all the cuts for a particular imported item and could then duplicate that set of cuts N times. Bonus points for “pack” features that’d minimize waste material.
Certainly, being able to save off a set of cuts and settings is quite desirable, but I understand the issues of doing so where various parameters may change over time. As a less risky first step, aiding in eliminating the manual steps in repetitive action would be quite welcome.
As an example, this piece is really 12x a single piece. Now, imagine the same with some engravings on it where the proofgrade settings need to be tweaked just a bit.
If I understand you correctly, I accomplish this in two ways.
Take a complete design like the founder’s ruler (Engraves, scores, and cuts). I can set each operation up the way I want (slow the zooms by 10), then ctrl-a to select the whole item, and use ctrl-c & ctrl-v to duplicate the items. As long as I don’t exit the GFUI or move the files, I can repeat those objects as many times as I like.
To accomplish this on a more persistent basis, I build up my design in Ai or AD, using colors to designate each operation. At this point, I can save a sheet full of them, run them through one of the online nesting optimizers, save and upload to the GFUI. Set each color to the desired operation, and you’re good to go. Btw, if I have 77 of something in a file but only need 44, I can delete 33 of the in the GFUI.
This won’t work for all use cases, of course, but it gets the job done for more than 90% of the stuff I’ve made in the past eight months.
Just to clarify the discussion since there are three significant issues addressed here:
Setting up a design file appropriately to distinguish the operations according to cut/score/engrave.
Pre-sets for each of these operations contained in the file itself to avoid having to manually enter settings.
The functionality of saving the setup and layout of a design in the GFUI.
Design setup for indicating discreet operations is fairly robust according to color designations, the ability to embed greyscale images and other design practices. Also with copy and paste, you can repeat things well for any particular session.
Having the presets embedded in the file as the Glowforge design catalog items do, would be a great addition. Being able to save a workspace would offset not having this feature, but if both features were present, that would really enhance productivity.
I wonder how long the design catalog’s monopoly on presets will last. If it is a self-sustaining feature, then we may never get the ability to embed presets in our own custom designs. If the design catalog ends up not generating interest or income, would these features be set free? I’m wondering about target markets here.
There are many who comment that the Glowforge might not be a serious production laser, not just because of speed, size and power, but because there are inefficiencies in workflow that result from locking down presets and saved work spaces.
We’ll all just have to wait to see how the development cycle plays out, the business model matures, and the community adapts and responds to this reality.
it seems like the “app” only saves the first pass (first artwork Square loaded). Any additional are not saved. This is frustrating to me
Additionally, it seems the scale and position of that artwork is reset next time I go into that piece… This is also frustrating…
Would be great to have it remember 1.) the scale/position (all settings), and 2.) all the passes (pieces of art loaded)…
seems like a simple//obvious need. and not that bad to implement. I bet they’re just busy with other stuff and haven’t had time to give this the love it needs. But this is pretty obvious need for improvement in my mind. One of the first things that struck me about this user experience in my first hour of using the forge, which I chalked up to “beta” unfinished status… For switching between different production runs this would be a blocker for sure!
Not long as it all runs in your browser, so you can enter debug mode and get at everything. So it is trivial to see the extensions that GF have added to the SVG and write a program that for example converts shades of grey to scores.
I’ll have to hunt around and see if I can come up with the stylesheet as I’m about to dive into writing my own SVG generators and having markup to somewhat automate the cutting behaviors would be fantastic!
Somewhere in this forum is @scott.wiederhold’s discussion of the style section. Or @takitus or @karaelena. Not sure what they have been able to hack together regrading this. I do not recall a real life example of someone crafting an SVG that loads presets in the GFUI operations space.
By the way, @bbum, love the example you posted regarding just one shape and it becomes the cube.
And we are going to “beyond the manual” in 3, 2, 1… or just shutting this down since it is a feature request.
It would disappoint me greatly if the decision was to only allow embedded presets in Proofgrade. Proofgrade’s advantage will always be in the matching of settings to the material and the material’s integrity. So there’s no need to handicap the user’s ability to put the work into their own optimizations and repeatability.
That “copy and paste” just work is quite the revolution for my workflow. The app-in-a-web-page UI is, for some reason, not firing as “this is really an app” in my head.
Still much work to be done on repeatability, but that helps greatly. I’m very interested in any work that can be done in the SVG itself during generation as I’m going to embark on that path this weekend.
I’m working on some Perl scripts to parse SVGs, identify the colors assigned to paths and other elements, then set the classes on those elements based on the colors. The SVG parsing/rewriting stuff is mostly done, but I still need to deal with all the CSS stuff to find the colors, which is a lot more complicated. I should have it done soon though, assuming I find time to work on it. (Unfortunately my next few weekends are all booked up, so I’ll have to work on it during free moments at work.)
Once I get a command-line script working well enough on my own files I’ll work on finding the time to turn it in to a CGI so other people can use it more easily.
