After running the script it is populating every object with a bunch of Keys/Values, accourdingly.
One big issue it is the fact that it is recognizing three different panels (09-SIDES & DIVISION PANELS TOP ADD ON’S, in my file below) as being the same, even if I do need to apply sightly different mechanisation to each of this panels.
Unfortunately the script wasn’t upgraded in the last two years and seems that the original developer abandoned this very useful project in GitHub so, (until somebody will want to continue his work) I am trying to develop further his ideea using GH definitions to make-it usable for my needs. Still are some issues I can’t overcome right now, like, for example, the lack of explicit edging, so, for example if I have only one edge aplied on the Length of the piece, I can’t specify in which edge (front or back) will be the edge applied. Also I am mechanizig some pieces like doors with glass inserts who also needs to have edges applied inside, which information I can’t specify right now in Spec.
One big issue still remains regarding to OpenNest: After nesting, I would need to find a way to mark the edges of the pieces that will have edges applied to them as I do need to mark that faces with a marker after cutting the pieces and I need to find a way to create automatically a layer called “Edging” that will have applied a red line on top of each edge of the panel that needs edging. So, when I do print the layout of the nest I can have a birds eye view where the edging will be applied to be able to mark that edges after the CNC cutting process.
I’m not interested in the EasyCut script. My contributions to your threads have been general purpose that others might find useful. I see in the Rhino file you just posted (EasyCut_edges.3dm) that the same list of attributes has been applied to all geometry with values all set to ‘0’.
What I haven’t seen is any identification marks (or Names) being passed to OpenNest, so it’s not clear how you’ll know which pieces are which? That also seems like an important detail?
This it is how looks the Keys/Values after applying some GH definition that reads and matches the information from an .xslx file with numbers of the object names from the Rhino file:
I selected all visible pieces in your EasyCut_edges.3dm file for the OpenNest treatment and immediately saw flaws due to unattached edges in your Rhino file. This image shows one selected but there are many. How did that happen? I could add some clutter to my GH file to ignore those pieces but that’s janitorial work (garbage cleanup).
On closer inspection, they appear to be edge trim pieces with some thickness, not just unattached faces. My code tries to orient the pieces flat for OpenNest but clearly fails with these shapes.
The selected edge piece is named “10-R/H & L/H SHELF EDGING[1]”. Tricky!!
I don’t select all objects from the file to nest. Before nesting I do sort the pieces by material, I do put them on layers, I do select pieces by layer and only after that I do nest. The edges are there only for visual representation.
In this example I do pass in OpenNest only the pieces that are into the “18Black” layer.
As I do explained in my previous post, after cutting the nested objects I do need to mark the edges of the pieces where the edging will be applied into the next step of fabrication.
Maybe there is a way to reassociate this 2mmEdges with the 18Black pieces AFTER the nesting process of the 18Black pieces. This way I can quikly locate that edges on the nested sheet to mark them.
I have two, ColorB assigns colors to each branch, ColorJ assigns colors to each item in a list (or each item in all branches). colors_2022Oct9a.gh (14.7 KB)
It is possible to make the nested parts to match the same colour as the ones displayed on the unit? This will make more easely to identify different parts in the project.
Yes, I could even label each piece with the names.
LATER: The only difficulty is making the labels readable. It doesn’t help that the original drawing is positioned over the OpenNest ‘Sheet’, but that can easily be fixed. The trouble was that there was no contrast between the color of the pieces and the color of the text tags. So I modified my ColorB cluster in two ways:
Added a ‘C’ (Color) output to use for the text tags.
Added an ‘A’ (Alpha) input to make the pieces partially transparent.