Rhino attributes are probably one of the most exciting and powerful functions I have discovered recently, all thanks to the minds behind the Elefront library for GH, and the webinar I attended early last year. I was introduced the their existence and to common use cases, but it was only recently, through my own work, that I discovered what I think is the strongest application yet.
Let's start from the beginning. Attributes in Rhino are user added information stored as key/value pairs (think of the key as the variable, and the value as... the value) within a given Rhino object. This functionality alone is what allows Rhino to act as a lightweight BIM-model. You could easily imagine attributes that are recognizable from Revit, such as reference line justification, end connection types, section type, element type, material, etc. What's neat is that this information can be read in the transfer to Revit, allowing you to pre-assign this information to your geometry in Revit. RhinoInside is already an enormous enabler for getting complex geometry into Revit, and this is simply another benefit to save time in Revit once the import is conducted. But it's not my main point.
You'll notice in the image above that the object I selected has two attributes: Path and BakeName. Starting from the back, BakeName can be understood as a tag given to every object in a bake instance, which serves as a identifier for that specific bake component. As long as you use the same bakename, the component will overwrite existing geometry with that same bakename every time it bakes, i.e. it will only allow one instance of a bake, for each bakename. I find this incredibly helpful for ensuring my Rhino model is clean with no duplicates, keeping the file size to the bare minimum. Of course, whenever I do want multiple instances of a given bake, I can change the bakename to allow it - I just prefer that the default is set to overwrite old geometry. This is neat, but still not my main point - the Path attribute is.
The path attribute is simply encoding in the Rhino object the relative DataTree path it had in Grasshopper. While extremely simple, the power of this move is exceptional. Typical bake operations will squash your carefully conserved data structure, making it unattractive to bake to Rhino until you are finished with all operations on that given geometry set. You can think of the path attribute as a fossil of the GH data tree, with just enough information for the digital archeologist in you to use it to find out what the living object was and restore it. This opens a lot of doors. Most importantly, it allows you to break your enormous grasshopper scripts into bitesize pieces, which each communicate and transfer data between them using the Rhino model as the go-between, and using the Path attribute to keep the data structure intact. Your scripts are now smaller (less computation), clearer (each function can be it's own independent script) and more modular (with a bit of attention directed to keeping the output format identical, anyone can change the script's function to suit their purpose, without any risk to subsequent operations). Additional, it allows you to set up your now multiple scripts in a MUCH more user friendly way - especially for novice GH users.
