Ok… there’s a lot to digest & explain here. I put together a doc to train my team on how Blocks work in Rhino, and I think it might help. I apologize in advance for the length.
First: I’d like to define the sets of layers that we’re dealing with:
- The layer that was active when the block was created/inserted. This is the layer that shows up when you select a block and look at the properties. Let’s call this the “block instance layer”
- The layers that the sub-components of the blocks are on IN THEIR ROOT FILE. This is a key point. Since the whole assembly is a block, that block lives on a SINGLE layer in your current rhino model. However, that block consists of subcomponents (each of the parts in the rhino file that contains the block itself), and each of those subcomponents is on a layer in that file). Let’s call these “block subcomponent layers”
So what does that look like? Lets create a simple block to test how it works. This block is just a bunch of text, assigned to various layers in a tree:
In this file, things work like we’d expect. Turn off the root “block” layer, and everything disappears. Turn off just “1” and you lose the top but keep the bottom half. Etc.
Now, let’s insert that into another model as a block. First, let’s set up a basic layer tree in the new file:
Ok, with Layer 1A active, insert our sample block. Let’s insert it as embedded & linked, since that tells rhino to save the geometry from the block into our current file, but also remember where the root file is stored and check for changes to it. We’re going to insert it as a “block instance.”
First thing you’ll notice, is that you’ve got new layers:
When you insert a block, rhino will automatically add the ENTIRE layer tree from the block file to your current layer tree. (Note: if any of your layer hierarchy in the current file matches that of the block, it won’t duplicate those layers. Rather, it’ll add the block subcomponents to the existing layers. This is a key point, and we’ll get to what that means in a moment).
So, what does our file contain now? One block. If you select all, you’ll get a single item, and it’s on layer 1A.
What happens if you turn off layer 1A? Just like you’d expect, the entire block disappears.
So… what’s the point of bringing in all the layers from the block? What happens if you turn those off? For example “2”. First, try selecting all the objects in layer 2 or sublayers. You’ll get a message that there were no objects added to selection. So turning it off shouldn’t do anything, right?
On the contrary, it hides the subcomponents of the block that were (in their root file) on layer 2 (or sublayers). Even though they aren’t (in this model) on layer 2.
NOTE: WHEN YOU TRY TO DELETE A LAYER THAT IS CONTROLLING THE SUBCOMPONENTS OF A BLOCK, RHINO WILL TELL YOU THERE IS A “BLOCK DEFINITION” LOCATED ON THAT LAYER. THIS HAS LED MANY PEOPLE TO SEARCH DESPARATELY FOR THE “BLOCK DEFINITION LAYER CONTROLLER” SO THEY CAN RESOLVE IT. THIS ERROR IS NOT REFERRING TO THE “DEFINITION” OF THE BLOCK AS AN ITEM. WHAT IT REALLY MEANS IS THAT (AT LEAST) ONE OF THE SUBCOMPONENTS OF THAT BLOCK IS ASSIGNED TO / CONTROLLED BY THAT LAYER. In order to resolve this, you either need to get rid of the block (explodeBlock will remove the block reference and leave you with objects in your current model) or modify the layers in the block definition itself.
Why do you care / why is this a good thing? For a single instance of a block, this is a freaking pain in the butt… you mean I have to deal with TWO different sets of layers to control the visibility of a SINGLE object? That’s ridiculous.
I keep seeing posts saying this makes blocks “unusable” in Rhino. I’d like to propose the opposite… it seems confusing, but it’s the only thing that makes blocks usable in LARGE / COMPLICATED models.
So far, we’ve been looking at a model with a single instance of a single block. Let’s add a bunch more instances.
Ok, now we have 6 instances of the same block (the left three are mirrored). I’ve assigned each “instance” to a layer (as labeled / colored).
Now we get to see the first signs of the usefulness in Rhino’s block management system.
You might have noticed this looks kind of like a tournament bracket. Let’s say that each color/layer is a “division.” Then, inside of each block (division) you have the division quarter-finals, semi-finals, and finals.
If you want to see only Division 1A, you can turn off the other five layers/instances.
That’s pretty simple, and nothing to do with blocks. But what if you only want to see the semi-finals and finals, for ALL divisions? If this was setup in a traditional (non-block) layer tree, that would mean navigating to EACH division and turning off their quarter-final layer. But, because each division is an instance of the same block, you just have to turn off the layers of the core block definition (ABC)
Ok… but who does their tournament brackets in Rhino?
Let’s imagine a different scenario. You’re modeling an entire building… doesn’t even have to be that large. But you want it modeled well / right. The building has 5 floors, and each one has about a dozen rooms. So 60 total rooms. Figure 120 lights, 60 doors, 120 windows, etc.
First you model the general layout / rooms. Assign each floor a layer, then each room a sub-layer. Easy enough. Let’s add doors… Non-block procedure: Model 1 door, then copy it into place 60 times. You either leave all 60 doors on their own “door” layer, or you move them each to the layer of the room they’re in. Ok, same for the windows. And Lights.
You’ve probably got a layer tree that looks like one of these:
Ok… the layer tree on the right is obviously a mess, but at the same time, the layer tree on the left isn’t very effective. If you want to see just the 1st floor, you’d have to do so without the doors/windows/lights (or select and hide other objects). So the tree on the right is the “best” way to do it… but what about when you need more detail? Now your doors get sublayers for handles, hinges, door-jambs, mouldings, etc. Windows get sublayers for the same things. Lights get sub-layers for electrical wiring, trim, etc. Plus all their sublayers for screws / attaching pieces, etc. You get the idea. What would the layer tree on the right have to look like to accommodate all of that for a SINGLE room?
And that’s just for those three components… If there are multiple doors or windows or lights in a room you may need even more layers! And then you have to copy this layer structure for EACH room… now you’re talking about over 1,200 layers for this building, just to include doors / windows / lights… That’s not even remotely practical.
So where do blocks come in? Well, it depends on how well you name your layer structure. But let’s say you planned ahead and built all of your subcomponents to fit the following layer tree.
Now you insert them, as blocks, into the right rooms. What does your layer tree look like now?
Ok, I left off a few of the rooms for the sake of space, but even with ALL of them, you’re looking at only 50 layers. Compared to over 1,200, this is a HUGE reduction in layer count and increase in usability.
By turning off rooms, you still turn off the blocks that are inserted in them (so you can see just the 1st floor without the subcomponents of the other floors in the way). However, you can also turn off all of the doors, or all of the windows, or all of the lights… with a single click. Or you can turn off the screws and other details, and just leave the door panel (to speed up the rendering).
Also, this gets even MORE useful & necessary as the model increases in complexity. If you’re modeling an entire system with many components, and each component has copies of other components nested inside of it, then this system can be a life-saver… IF you set up the layers for your blocks right.
