I wasnt able to reproduce this using those classes. The GFUI recognizes whether something is a cut or engrave, but that is based on the stroke or fill for each. âcutâ or âengraveâ or âengrave.vectorâ as class names applied to elements did nothing for me by themselves.
were you able to get something to auto-load as a score?
I was going to suggest the same thing. To test what I was doing, I took the same path and duplicated it in two separate layers (and two separate colors), then applied a different class to each one to make sure that they appeared differently in the GFUI.
Take a single closed path and duplicating it, I assigned one a Graphic Style of â.cutâ and one a Graphic Style of â.engrave.vectorâ and each of them appeared differently in the GFUI.
I think I also figured out how they are defining the order of operations, but I am not sure that can be easily managed in Illustrator using the Graphic Styles. Iâll have to do more testing later tonight or tomorrow.
I did some further testing this evening, but I am getting inconsistent results. So itâs likely that I made some inaccurate assumptions with how the GFUI interprets the SVG. Iâll try to do some more testing tomorrow.
I donât think that is relevant here. We are trying to work out what SVG annotation is used in the catalogue files that allow them to specify score instead of cut and also order the operations. It seems to be style information referenced by class names.
To generalize the discussion slightly, Iâd love to be able to set bitmaps up to which engrave to use (graphic, deep graphic, 3d carve) as well. If all of that can be in Illustrator (or other SVG editor) then itâd really shorten the workflow in GFUI. Hopefully itâs just more Graphic Styles.
This reminds me - didnât Dan talk about making a Glowforge plugin or style guide for Illustrator to allow designers to do things like this? I love the idea of a feature he talked about - drawing slots such that the width of the slot would be parametric and size to the thickness of the material you were cutting. Yeah, not an absolute requirement, but wouldnât it be nice to not have to fiddle all the slots by hand when changing materials? (if using a non-parametric tool, or working from a âflatâ file instead of a CAD file).
I know theyâre trying to be careful and not document anything that they might change in the future. I know Iâd be happy with documentation, fully aware that things work that way now, but could change in the future. Re-tagging elements in a design in the future is easy, especially if agreeing to that means that I can avoid having to manually set engrave/score/cut on everything Iâm doing now.
I think itâs more than that. I think theyâd rather make the easiest stuff so intuitive that no manual is necessary. And the more complicated stuff, I think theyâd rather leave to only those willing to put in the time.
Manuals turn out to be surprisingly expensive to write and to maintain. And when you instrument the online versions of them, you discover that a small minority of your users ever even look at them.
But then again, maybe theyâll surprise me a get it documented later.
If I had to guess, a small number of customers produce GF designs that are intended to be widely shared, but the value of making it easy for designers to produce designs that work nicely on the GF is probably pretty high for GF. That was my impression back when Dan was talking about design guidelines and an Illustrator plugin, etc.
It is also incredibly difficult to keep documentation up to date while the software is undergoing continuous development. In the days of monolithic, slowly changing software releases it was a much different story.
It is not exactly a large app with lots of functions and it doesnât change particularly quickly. It seems more the case they donât want us to know what it does so they can sell catalogue designs and PG.
When I was making 3D printer kits I was milling the same parts day in day out on my CNC mill. The design files get converted to gcode by a CAM program. That CAM program saves as many configurations as you want, so if I changed the design I could remake the gcode and know the settings were correct. Most of the time though I used the same gcode for hundreds of parts. So in the morning I switched the machine on and homed it (which always worked) and then loaded my material and the gcode file for the part and off it goes. The only error I could make was to select the wrong part for the blank.
Now consider how the GF works. Every time you select a design file you have to enter all the settings again. It has assumed the role of a CAM program but doesnât save the configuration or the equivalent of the gcode. It has to be built and download every time because it depends on a height measurement.
My 3D printers measure three points every build but they still run the same gcode over and over again because it doesnât depend on the bed inclination. It gets compensated for by the firmware that reads the gcode and generate the stepper waveforms.
The Glowforge model canât do this because the firmware blindly plays waveforms to the steppers and laser. It canât apply a 3D transform to waveforms.
So GF have come up with a disruptive idea but it only works if you want to make something once. In a production environment where you make the same set of things day in day out you are very likely to make a mistake entering the same settings over and over again and waste time and material. And it is slow to render and download the waveform file for every build. 100MB for 3 hours of 2D engraving.
It took 12 hours on a slow machine but the gcode was only 13MB.
So GF have made a one off job simple but have come up with an architecture that doesnât really scale to production runs because you canât save the CAM configuration and you canât save the CNC file generated by the CAM stage. Saving the settings for a project would be a big help but I donât see how they will get around not being able to repeat a job quickly.