At the very least I expect Rhino to either silently move the block definition with the objects, since what I did previous to this error message was to move all objects away from the layer in question, and then I’d also expect Rhino to allow me to delete a nested block instance, and just explode all objects out of that block.
But frankly, what I really expected was this:
hehe… We’re seeing this, don’t worry.
And what you are saying has been said before, by many users - myself included (and my workflow was always the same as what Gustavo does).
At any rate, Pascal put the request in a new tracker item so that we will find this thread when this gets addressed at some point in the future. This is a large project, though. Don’t hold your breath…
-wim
Yep. Blocks (as implemented in Rhino) are just not good for this.
LAYERED FAKE ASSEMBLIES
Imagine pressing a keyboard combination and LMB click which would then select all objects in the layer of that object. That could be a start for mimicking working with “assembly parts” as defined by layers.
Is there a quick and dirty solution for this?
// Rolf
Here are my two:
SelObjLayerTree.py (875 Bytes)
The above selects “down” the layer tree from the selected object - layers that the object(s) are on plus any sublayers below that.
SelEntireObjLayerTree.py (1020 Bytes)
The above selects both up and down the tree.
So how do you currently delete a single nested block definition? Is it possible at all?
Apparently I again got one left over on a layer I moved objects away from, and I suspect there’s like 3-5 levels of nesting, but I can’t be sure since I have no way (that I know of) of viewing that in Rhino.
And yes, this isn’t new… first couple of hits on Google… oldest thread is from 2010 apparently…
http://v5.rhino3d.com/forum/topics/unable-to-delete-not-linked-block-definition-containing-nested
https://www.mecsoft.com/phpbb/viewtopic.php?t=2129
Is nuking the entire thing using the custom script from @pascal in the first link the only option?
EDIT: Also, how do you move a block instance to a different layer? Selecting the instance and then a different layer, and right-clicking to choose “change object layer” does nothing for me.
EDIT 2: Oh, my dear god!! The block instances are now occupying TWO LAYERS AT THE SAME TIME, and neither layer can be deleted! What is going on? How is this in any way usable? 
EDIT 3: Holy shit, just when I thought it couldn’t get any weirder… I now have some objects which will ONLY APPEAR if two specific layers are visible at the same time! Enable either one separately, and it’s as if the objects don’t exist. Why is this even allowed??
The thing is, there is a difference between a block “definition” and a block “instance”.
A block definition is simply the formula for creating the block - i.e. what geometry is in it, where the insertion point is, and any transformations such as scaling etc. It is essentially invisible, and you access it via the block manager.
A block instance is the actual geometry you see in the viewport, based on the definition. A block instance resides on a layer. However, the original objects represented by the instance may have been on other layers originally. Therefore you have a linked parent/child layer structure inside the block - turning off one or more of the layers where the original objects once resided will turn off just those objects in the block instance, but not the others in the same instance. Turning off the layer on which the instance itself resides will turn off the whole thing.
Now, start nesting some blocks inside others. You will quickly see that unless you are extremely careful about how your original objects are organized on layers that it will become a complete mess.
This is why blocks are just not a good tool for organizing assemblies.
It is 100% obvious that this is a pure engineering solution to a problem. The technical decisions behind the implementation might be sound, but from a usability design perspective, the feature might as well not exist because nobody can use this. It’s the same problem that has plagued Blender, and they’re now slowly beginning to turn the ship around…
I nuked all blocks using that old script and began from scratch (I still don’t know how to achieve this without using user land scripts).
They are actually useful, just not as an assembly manager. They are pretty extensively used in architectural projects - also by other software such as ACAD.
I do use linked blocks quite frequently. But I make sure that the file I am linking contains either a unique single layer or a unique master layer with sublayers. Then after inserting I often move the instance to this master layer to keep things organized. Having said this, I do agree that it is very tricky to work with blocks.
IMO a block instance should behave more like a subassembly where the part name becomes a separate unique master layer in Rhino where the block resides on and has the file layers structure as sublayers.
This way it doesn’t mess with existing layers and it is much easier to delete instances by deleting this master layer.
I also try to use Blocks with larger assemblies in Rhino and it’s a bit difficult to be perfectly honest. The error message in the OP can indeed be a bit frustrating - not that it necessarily excuses the tone.
@eobet the main “tool” to fix this error message for me is:
“Select Object Layer” will reveal to you what layers source geometry actually sits on, once you go to all levels of your blocks/nested blocks. To prevent having to do that in the first place, what works okay for me is to keep all source geometry on the same layer tree syntax, including all files linked as blocks. It looks something like this:
0 _ block source geo
< item >
< subitem >
^ sadly this is quite a bit of work sometimes, and not possible work with non 3DM files of course.
I then use a similar syntax for the actual model and instances of blocks:
1 _ model
< item >
< subitem >
…In case you wanted to consider this.
@pascal it would be nice if we could get an organised blocks in rhino discussion going. I know this has been attempted on here before - has it been successful? I actually had high hopes here in regards to Rhino 6, but I’m not sure what has changed in the block manager. My (personal) main problem are the erroneous imports when files are linked as active reference blocks. This usually ends in a layer hotchpotch that cannot be fixed currently.
Hi Duncan - I assume you’ve reported this here or on tech@mcneel.com and we’ve let you know that we understand and/or can reproduce the problems and have made bug track items…? I am not sure with the ongoing stream of messages of all kinds here and my limited brain cells to begin with, that I can remember what it is exactly that you are referring to.
-Pascal
Hi Guys. I did not read all the stuff written on this topic (so the real problem could be somewhere else), but I reall love the Purge tool for cleaning up these things. It might not help with nested block, but it cleans unused blocks, layers and more without any need of the block manager.
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:
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:
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.
Also, @pascal @wim @bobmcneel @stevebaer @brian
One (relatively) simple way to fix the issues people seem to be having - When you insert a block, have an option for nesting all of it’s component layers as sub-layers in the new model (for example, if you insert Block X, have rhino put all of the layers for Block X in the layer tree as sublayers to a new layer titled “Block X Subcomponents”). For those that organize their block layers, they can leave that option off and use the current system.
But for people without a lot of blocks, or just getting started, this would greatly simplify the UI and leave them with a clear understanding of why they can’t delete those layers without deleting the block that creates/depends on them.
Here are the two files I used to illustrate the above post - in case anyone wants them.
Block insertion sample.3dm (79.2 KB) Sample Block.3dm (51.0 KB)
Pascal, I may have fixed the above mentioned issue yesterday when I fixed this YT issue
https://mcneel.myjetbrains.com/youtrack/issue/RH-54300
The fix went into 6.x so users will start seeing it in next week’s V7 WIP and in the SR 19 release candidate that will become available in a few weeks after that.
OK- thanks.
-Pascal
One even easier “fix” would be to change the error message to “a subcomponent of block [name] is located on this layer”
I general feelings are still that ever since 64-Bit, people will want to make larger projects in Rhino–and not export them to some other program.
I suspect that, in the past most people who have used Rhino have made small uncomplicated projects from sophisticated shapes…
…Grasshopper changed that.
I am only a guest here. It’s your company. You set your own goals, but please reconsider giving a little attention to what may not be the sexiest part of Rhino, but the part that will allow user to develop their projects to completion.
