Just some experiments using GF and 3DS Max to generate depth maps to drive 3d engravings. Mostly focusing on how to do bevels. Anyone had any luck doing deep engraves ie greater than 1/8"? I am already up to 6 to 10 passes to get to a a good 1/8" and doing more for deeper cuts does not seem practical for time.
Also GF Support PLEASE PLEASE add some way to markup an SVG so we can add the GF cut/engrave info directly into the file. I want to experiment on using paths to do bevels instead of bitmaps which would seem to be way more efficient and faster, but after generating the paths and bringing them into the GF UI it is not practical to set the values by hand since there are just way to many. I can write a plugin in 3DS Max that takes a 3d bevel and converts it into paths with various settings automatically to test with to see if it is practical but right now there is no practical way to test this.
As for depth, that’ll be a function of material you’re using. I did an engrave in non pg maple last night that was 0.09” deep in one pass, and I was going 600 speed. I had plenty of room to slow it down and go deeper.
As for beveling with paths — if I understand your intent— in theory if you choose a color scheme you will be able to set power by color, but depending on how smooth you want your bevel to be (how many “steps” of depth you’re aiming for), that’ll be a tedious process.
You could get clever with stacking paths (sort of manually doubling or tripling passes to get greater depth) and reduce the number of colors you’d need, but it’ll still be a bit janky.
I did a bit of experimenting with engraving via path here, it might be of interest:
Thanks that is a very interesting idea. I could you use your approach to make one continuous path if the bevel was closed. Then just vary the power once you past your start point every time. That would be the fastest way but just need access to a away to vary power along a path. Grr it is so frustrating not having any sort of SDK or any programmatic access to the settings. There are ton load of tools that the UI needs but no way to create them.
I’m actually glad they didn’t open it. You can very easily end up with all manner of janky half-baked toolsets if you do. Look at the messes that are app stores on IOS and Android… the average app is a piece of junk.
Just because someone has the SDK and ideas doesn’t mean he or she knows how to make a cohesive bulletproof toolset, nor does he or she necessarily have the resources or will to keep it up to date when GF changes their main software.
The worst possible outcome would be to have a ton of features that don’t work well. (Inkscape plugins, I am looking at you)
Edit: I’m not saying that an API or SDK is necessarily a bad thing, I just think it’s got to be implemented very carefully. It’s very difficult to rewind that decision, and especially difficult to do so without revealing your trade secrets. I can see why GF hasn’t done it.
BTW here is the workflow that I used to generate the Depth Mask. It is a bit 3DS Max specific since that is the app I use, but should be similar to other 3d apps like Maya, Blender, etc.
So first you need to create some 3d geometry, for the chains I just created a torus, squashed it a bit and then cloned and rotated each clone 90 and moved it up a bit. Then applied a twist deformer to break up the uniformity. So you get something like this
Then you need to define the view to render the depth map from. In Max you create a Free Camera viewing your object and set it to orthographic so there is no perspective. Set your render output size and file type to render to ( I use png 16bit grey scale), turn alpha on. Then you need to set your render to output the z depth info. For Max you do this with Render Elements by adding a Z Depth element which requires zmin/max values. The zmin is the starting z depth value that will render white and the zmax is the ending value where black will be rendered. You may need to use the tape measure to measure the distance to start and end of your object from the camera to find these values. Then just render and you get a file like below
I don’t believe the SVG file format recognizes gradient strokes along paths and that is likely a limitation GF can not workaround unless the SVG standard gets updated, or they add support for other file formats.
Using a solid color path you would still need 20-30+ paths to produce a smooth bevel just 1/8" wide and even then, the laser is so precise I don’t think the bevel would even be smooth. It would still be somewhat noticeably stair-stepped and have some areas burned deeper (or higher) than it should be simply because of minuscule inconsistencies within the material.
Having the individual paths in the file however presents another issue. The GF app won’t handle that many paths very well.
Edit: Well, I’m surprised the GF app opened this test file with 20 paths even though it’s a pretty simple file, but that’s not to say it would catch all the paths at the time of creating the final motion pathing. I think this file would still look a bit stair-stepped though.
As for stair stepping isn’t this what happens when you have a bevel that runs horizontally when using 3d engrave with a bitmap. It follows the bitmap horizontally at one power in this case. Steps up the power to match next horizontal line value and repeats. The main issue I would think would be hard corners where the GF stops and burns that corner to change direction which could be mitigated some by curving the outer corner.
Yes, ultimately there will always be some stair-stepping so it comes down to how much is acceptable versus the ability for the GF app to read however many paths it takes to create it.
Here’s a thread I posted in July 2017 with some bevel tests.
