Here’s my thoughts on blocs and how to use them in Rhino.
With blocks, I try to replicate the “Parts/Assembly” logic commonly found in parametric CAD packages such as Solidworks.
I have “part” blocks containing geometry, or other Rhino objects, and “assembly” blocks containing “parts” blocks.
In Rhino, I limit myself to 2 levels, meaning that assemblies always contain parts, and not other assemblies. Let’s not be foolish.
I try to have only assemblies in my models, which means that I sometimes have assemblies containing a single part.
Sounds silly, but it ensures consistency with tools that produce fabrication data (like BOMs) from the blocks.
Given limitations in the way blocks are managed in Rhino, I elected to assign properties to parts on the geometry within the parts.
Since part instances are nested in assembly blocks, it would be problematic to access / change the metadata of the part block instances.
Generally, parts contain one BREP, and that’s it. If they contain more objects, I automatically duplicate the metadata on all objects.
This means that ALL occurences of parts will have exactly the same metadata since it’s embeded in the very definition of the block.
By contrast, the matadata of assemblies is attached to the block instances of these assemblies.
I enforce having the same keys and mostly the same values for all instances, but it is practical to have changing valuies sometimes, like
in the case of project phasing where some of the instances are for phase 1, and others for phase 2.
Lastly, it is important to account for parts or assembly block definitions that have no instance at all in the model ; this is why I sort them at the start of the definition
Looking forward to “official” handling of blocks and metadata in Grasshopper.