Hi,
I was wondering how Rhino and grasshopper deals with layers.
I’m using a the pachyderm plugin and it references grasshopper generated geometry with acoustic materials settings that are set in Rhino to each layer.
Pachyderm requires the LayerID (integer) of the relevant rhino layer to associate with the grasshopper geometry.
I can extract the true LayerID of a rhino layer within grasshopper using the Human plugin, but it generates a hexadecimal number as per below.
Does the layerID (integer) correspond to the numerical order that the layer appears (starting with index 0?)? or is it something else completely?
I wrote this years ago, so hard to remember exactly, but getting the layer by integer ID was the simplest way I could find using the rhino API at the time. It generally works according to the order they appear in the layer list in rhino (zero based, I think, but could be wrong).
I took a look at the tutorial videos in great detail. The part that talks about this particular topic doesn’t confirm if it is the order, or if it starts with a 0 or 1. I think this is also as the tutorials are really getting you up and running in the software and use arbitrary material acoustic data.
I had assumed it was the order starting with 0 in previous experiments, but I’m now in a situation where I’m using WallaceiX to cycle through a number of different material option in order to optimise room acoustics - so the specifics in this case are important.
@Arthur if you could confirm one way or the other it would be great. Pachyderm is a great plugin and coupled with some interesting thinking around how a design problem can be setup in it in conjunction with an evolutionary solver is proving to be pretty interesting - albeit a very slow solver process with 5000 generations :)) Thankfully I’m using the results as indicative so I don’t need to go crazy with number of rays or convergence for each generation.
So Pachyderm accesses the layers through Rhino.RhinoDoc.ActiveDoc.Layers[LayerIndex]. The Layers property is indexed as an array, which means it ought to be zero-based. My notes in the code seem to indicate that I was aware that it was zero-based when I wrote it, so most likely, it is zero based.
The order corresponds to the order it appears in the rhino layer list. That said, I don’t know how it does nested layers, and I don’t know if there are any exceptions. To be on the safe side, try not to change the order of the layers in your model. If you must, at least save it, and then close Rhino, and open it again.
I’m not sure how Human is accessing layers. It doesn’t surprise me that layers in Rhino have GUIDs, much as everything does in Rhino. I don’t see any value to Pachyderm referencing layers this way, but if you can think of a good reason to do it, maybe I can set up Pachyderm to accept layers this way as well.
Hi Arthur,
Fantastic, thanks for the confirmation.
I had noticed that if I moved layers around in rhino they didn’t always update in pachyderm properly until I restarted - I figured it was an update issue. I don’t have any nested layers in this setup as I wanted to keep the file super clean.
I don’t think there is any need to set up the layers based on Human extracted GUID’s - it would mean that another plugin has to be relied upon. Also layer order, indexed from 0 is pretty straight forward. I managed to use my own logic and come to the same conclusion. I think it is pretty apparent given the brief overview in the tutorial videos and the fact that anyone delving into this aspect of the plugin will know their way around grasshopper pretty well.
As an aside there is one thing that pachyderm does that bugs the hell out of me. The pachy_RT component has a right-click option to do the calculation based on rays, rather than convergence. I’m using rays as it helps me control the calculation times with the evolutionary solver much better. Every time I open the file the component defaults back to convergence and usually crashes when I try to ESC out of the process as it automatically starts the calculation. My work around is to ensure that the component is disabled prior to saving and exiting, or locking the solver before opening the file. The number of times I’ve had to force crash rhino and reopen is getting into triple figures currently. It is a small things, but I kick myself every time
Thanks for the help and great plugin, I will send you some info on the project i’m working on once it complete. It is part of my PhD so I should really wait until it is submitted.
