I’m working on some laser cutting layouts and using Human to bake geometry to layers. In some instances the “blue” (which is engraving) ends up on top of the “red” (which is cutting). I couldn’t figure out how to adjust DisplayOrder with GH so I end up doing it manually at the end of the process, its the only step that isn’t automated.
Is it possible to use GH to grab everything from the “blue” and send it backward after I’ve baked it all to layers? Or vice-versa would be fine too.
It could be I’m doing this kinda wrong too, any help is appreciated. Thanks
I do not know how to do.
However, I’m surprised that the cut order is usually configured in the lazer cutter interface and the display order is purely visual and useful only to us humans.
Personally, I do not define the colors on the curves/lines. I create blue, red, purple, black layers, … (interior, exterior cut, engraving, half-cut, …) and I put curve without attribute in the right layer. Rhino DXF and AI exporters respect this layer order.
You know what, you’re completely right. The laser cutter completely ignored the order of lines. Thanks @kitjmv. The reason I’m using PDF’s is that I couldn’t find a way to automate the export of layout views, however @dharman made a great python script/gh component that does this by printing PDFs.
Some of these topos are 100’s of sheets and I depend on OpenNest to help ease the pain and minimize waste.
Still though, now I’m curious if its possible to adjust the DisplayOrder in the Rhino viewport via GH.
May I allow myself one last piece of advice.
You should never have cutouts on an engraving. Except in very special cases. Or if the engraving has a large offset (to obtain a width of 0.5 mm for example.)
The reason is that you will be cutting a pre-cut material (by engraving) at the same power as other full thickness cuts.
It is true that it is not important for hard and thin materials (like 1mm PMMA).
But with thick and greasy materials (like 10mm chipboard, which is only made of glue) This damages the machines and above all it can be dangerous.
It is therefore good to have the habit of not overlapping the lines except in the impossible cases.
Yeah, your totally right. My GH definition removes most of the overlaps, but sometimes there is the odd location where there it fails and leaves an overlap. The definition puts the roads, the sheet above and the contour cut all on the same sheet so it gets a little complicated.
I’m cutting MDF and the engravings are pretty shallow, but it also wastes cutting time when we have tons of sheets to cut.
I’m glad you pointed this out, gives the needed motivation to improve my definition and eliminate these overlapping curves…maybe this DisplayOrder thing is a Rhino 8/GH 2 problem
Assuming that you have some ordered (in the example shown: by Area descending meaning that the “inner”/smaller ones should appear “on top”) GeometryBase stuff on hand (done with GH or sampled in a List/Tree/etc into some parameter) bake and set DisplayOrder as follows:
No worries, thanks for the reply. I ‘just’ need to learn C# when I see all the solutions you make on the forum. It solves a lot of problems GH can’t solve. If I just had more time and a bigger brain.
