Engraving is always a bitmap function, regardless of the source file format. It’s just a question of who’s doing the rasterizing.
If you send your project as a vector, it will be rasterized into a bitmap by the Glowforge cloud software. If you send your project as a bitmap, you have already rasterized it yourself (although it will likely be resampled in the cloud to match your selected LPI).
I keep reading this but not sure if it’s actually true.
Vector engraving forces a single power level for the elements of that same fill color. You can’t convert to dots - you can’t vary power (which I get, because vector gradients aren’t supported). It’s static power.
There is no reason it can’t be taking the SVG syntax for the shape and be filling that in.
Either way - both engrave line by line. Because that’s how engraves are done.
Seems to me your distinction is the right one to make. For some the distinction would be in how the GF is instructed to etch either. The movement/power file that gets sent to the GF doesn’t really make a distinction between engraving an outline and engraving a bitmap, so at that level they are identical, and the execution time would also be identical.
Except, I believe the bitmap will be bounded by the overall image dimensions - so a triangle 3 inches on the bottom and 3 inches in height will cause the head to traverse back & forth over a 3x3 square shape even though the laser only pulses over the actual triangle shape. A vector engrave is bounded by the vector so the head moves in increasingly smaller widths as it goes up towards the narrow point. The head moves less & will be faster.
But nothing we do is quite that simple and complex designs may not see a time saving.
(Or at least that’s how it worked last time I played with engrave optimization before I figured out I was spending more time squeezing seconds out than I was saving )
Nah. If all that’s left is white (no fire) it ends the line and goes on to the next one at an appropriate X coordinate that it can move up and start the next line. Is that how other lasers work or is that good programming? I noticed that on some of the very first engraves that I did - caught me by surprise.
It’s good programming. I hadn’t really looked since the summer, didn’t realize it changed. They also break up long runs - @Jules’ example of two small things on either side of the bed - you’d be surprised how common it is for the laser to traverse the whole freaking thing - the trick was to make it two separate operations by color or layer. The GF is smarter than that.
I had not really thought of it but Autocad has a lot of amazing hatch patterns (and you can write your own) that would work very well for scores but I have not run into that capability in Inkscape. you can create patterns that are essentially a lot more flexible but neither Inkscape or the GFUI can do much with them except to be exported as a bitmap and used that way.
Does anyone know of a Hatch-like vector ability in Inkscape?
It just realized a big difference between bitmaps and vector engraves and that is that if you have several vector engraves in a row you can Boolean them all into one object and engrave them all at once in a single setting. If the engrave is a bitmap, each case will be on its own layer and need separate settings.
If you are just doing one, none of the above will matter.
Yep! You don’t even have to combine the vector engraves, just make them the same Fill color.
Bitmap images are treated separately, because they are generally the same grayscale color range, and there’s no other way to just work on one at a time. (You can combine all of your bitmaps into one image if you want, but if it gets too large, you might run up against the time limit, so it’s a trade-off.)
We’ve got a lot of these things discussed in the tutorials if you ever want to take a look at them. Generally it’s a lot quicker than discovering them on your own. (Maybe not as satisfying.)
My experience was that as the same fill t color they will only engrave all at once if they are the same object. (The GFUI seems to think every thing inside a closed area is an object unless you insist with a Boolean that things outside are part of the same object too. (Or worse something you are moving ends up inside and is very hard to move back out again)
I did have two engraves in an object the same color but still one was engraved and then the other till I Booleaned them together.
Those have different fill colors. They’ll be treated separately.
I think I understand what you are talking about though - you’re trying to circumvent the motion plan that Glowforge uses. There are ways to do it, but generally it doesn’t save that much time to try. There are time savers built into their motion plan that make it very efficient.
For instance, you might think it should engrave right across those two shapes because they’re side-by side, but if they were separated in placement across the width of the bed, it would take a lot longer to engrave them, because the head would have to travel back and forth across the entire width of the bed with each pass, instead of doing short travel back and forth at one end to engrave one shape, and then go to the other end to catch the other one.
They separate the engraving for individual enclosed shapes in the motion plan so that we can place them on leftover bits of material wherever they are available to us. That’s how I use my material - to put small cuts in between other cuts. So the designs I create rarely wind up being placed neatly together when I’m working on leftover material that’s partially cut up.
Here’s the thing though - I’ve seen it change based on placement. If you do have a design that has similar objects placed close together with the same base alignment, and the objects all have the same color - the motion plan will sometimes change and do them all in a row. It changes based on which is the most efficient method for it to use. If any one of the items is out of line though, by even a pixel - it will give it a different treatment and come back to it later.
It’s really quite a work of art. I have no idea how they pulled it off.
in that case the +and its circle were boleaned together and will engrave in the time it takes for the circle to be engraved. the x and circle are not and even as the same color I was seeing them engraved separately taking longer. I was thinking that if all the same colors they would still be 3 operations.
They are not consistent and not always the most effective, When I was making chain links I did a lot of copy/paste in the GFUI and it was interesting to see it jump about so it was sort of the order that I made them. with the originals going clockwise doing the outer and then the inner part, but the pasted ones were cut counterclockwise starting on the inside. very interesting.
So later on I am cutting out the the lamp parts and it starts by cutting out the outside and then doing the inner bits, this allows the wood to warp in the heat messing up the design. So I copy pasted thinking it would reverse and it did not. I reversed it in Inkscape, and still no change. I was going to post it to problems and support but got sidetracked and have not done so yet. or I guess this is it.