I do need to create some keys/values for some geometries that I do have imported from Rhino into Grasshopper and I do need to sort the list of geometries by prefix number in the order 00, 01, 02 up to the end of the list and grup the items with the same prefix number by branches if there are more geometries sharing same prefix number.
For some reason my version of Elefront didn’t like your component to get the attributes, and even though I was trying to install it it just didn’t want to, so I just replaced it with mine, which seems to work fine as well.
The problem with “Sort List” is it only take numbers as input. Using the “Text Fragment” component it is possible to get the numbers of the layers and everything works fine:
Perhaps this link will help you understand further how the “Sort List” component works. Also, I believe there are other entries in this forum talking about the functioning of this component.
There are three diferent versions of Elefront right now. It is the 5.0 beta, the 4.3 and the 4.2.2, if I remember correctly. On the food4rhino website it is explained the current situation of the plugin. Personally I do have two versions installed on my system.
Dear @Macuso
if you want the geometrie / breps be sortet as well - just pass them as values - and handle the tree with the same “replace paths”…
see attached .gh file
Late to this party because I’m trying to integrate this with the OpenNest work eight days ago but failing so far. OpenNest is hung. OH! 3.3 million pieces, that’s not right!
Here’s what I did for this thread, using Python instead of Elefront to get the names.
import Rhino
import scriptcontext as sc
sc.doc = Rhino.RhinoDoc.ActiveDoc
name = sc.doc.Objects.Find(geo).Name
I need to use the Names of the objects because I do receive them numbered like 01, 02, 03 … and also a cutting list with a bunch of details about each object, like material used, edging, what kind of mechanisation will be applied, etc. and I am using this kind of Grasshopper definition to create a mach between the 3D objects and the information from the cuttinlist to generate the needed Keys/Values for each object.
I am using this after running the EasyCut script, and instead of manually entering all the details, I just run a script that populate all the information for me and sort in layers by material used.
EasyCut, for some reason it is unable to read the names&numbers of the objects, so needs to be entered manually.
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.
OH! 3.3 million pieces, that’s not right!
