I am looking for some advice on effective block management.
The situation:
I have a file with 12 different moving light fixtures, each defined as a block. Each block is made up of a top level block containing two nested blocks (Group201, Goup202 etc) and a poly surface.
There are 100’s instances of each block, each with a unique name name (EL001, EL002 etc.) resulting in 1000’s of blocks.
The geometry in each lighting fixture is the same, only difference is one element has been rotated.
I am looking to:
A) Set all geometry within the blocks and nested blocks to ByParent.
B) Instead of having a 100 different blocks of the same light, where the only difference is the rotation, have one block with a variable rotation. In the above image, both lights would be a copy of the same block. I am not sure Rhino supports this feature though?
C) Hear how other people manage their blocks?
One solution I can think of is to explode each block and have each fixture as three different blocks. This would result in 12x3 blocks which is preferable to the 1000’s I currently have, but still does not seem like a neat solution.
I have started to look at Elefront and from what I gather I should be able to at least be able to set all geometry to ByParent with Elefront? Is there a workflow within Elefront that could help me with managing the blocks from there as well?
Hello - I think I’d use two blocks for the light assembly - the base and the rotating fixture. make a single block from these and Explode one level on each fixture once it has been placed, and rotate the light relative to the base - so when you insert, you have one block for convenience and then when it’s all done each light is made up of two blocks. Overall there are only three block definitions - base, light and base+light, in the background.
Yes that does makes sense. I was wondering if there were a smarter approach and how other people manage their block collection. I have read a few of the other threads on what functionality people would like to see implemented, so it would be interesting to hear what kinds of workaround they have found.
Was there an answer to this question, i.e. block management? What is best practice for making and maintaining block libraries such that we never have to draw anything twice and blocks are easily accessed for future use.
Might they be kept within templates, such as one for architecture?
It’s important to note that most of what Pascal’s suggestion fixes the problem except for the Light. As far as I’m concerned Lights are still not supported by Blocks. What I would do is what Pascal said except that instead of inserting a Light in a block, which it can’t, I insert a point so that when I use Vray or Human, I can use that point to create a lighting element. Take note it doesn’t have to be a point; for example; rectangular or linear lights can use rectangles or lines. As for management, Elefront is an extremely helpful tool, you can reference blocks directly from file paths; so you can simply create a library in a folder.
That’s the point of elefront, we create each element separately from another file and then reference it in grasshopper. It zooms-out a step. So basically you can model the components of a structure part by part while maintaining a hierarchal structure of attributes. And you can create a library from theses parts i.e. columns, beams, angle bars, flat plates etc.
