This is the worst UI part of Rhino.
I mean, why would you do this to a user, and then, in the BlockManager not show any layers?
I bet Block 3 - 9 are also on that layer, but I don’t know.
This and filleting is why Rhino currently is only suitable for small surfacing jobs. 
You have got to be kidding me.
So McNeel is actively trying to dicourage any form of assembly functionality in Rhino? Because that’s the result. Nobody in a serious workplace puts up with this.
It’s good practice to keep Block Definitions in their own layers (whether in the same document or externally) segregated from the layers where Block Instances are to be placed. I think you will find that goes a long way to mitigating the problem…
Regards
Jeremy
It’s also good practice to design a UI that’s actually usable.
I think my current solution to the “problem” is simply to not use Rhino with large assemblies. I seriously don’t know why anyone ever would (maybe @gustojunk would care to share some tips here)?
Hello- it is not clear to me what you’d expect to happen here - would you expect blocks that contain this block to be modified not to include it, or?
-Pascal
Hi @pascal,
It would be good to have a tool that identified all the block definitions hosted on a layer and allowed one to move all, or a selection, to another host.
(Recognising that one can easily move geometry off a layer and then rename and reorganise the layer into a block definition layer structure as a partial workaround. Although I don’t think this would cater for aggregating definitions onto a layer, should one wish to do this.)
It would also be nice, but not essential, to have the option to replace a definition with an instance and rehome the definition.
Regards
Jeremy
A “nested block definition” is of course a block inside a block. If trying to delete such a block - which should be perfectly legit - it implies the user wants to delete the block for the model entirely (and all instances inside other blocks as well). I also can’t see why that shouldn’t be possible.
The layer-problem (containing a block definition) is another “strange thing” before you succumb to it and just accept it, but there’s nothing intuitive about it because there’s no visible prior indication of where the blocks resides. If trying to delete a layer containing a block definition, why not offer an option to move it to another layer instead of just blocking the user from doing what he wants (scrap the layer).
And so on.
I’m already used to this strange behavior (or lack thereof) but I fully understand the frustration for anyone who has not yet given in on the current “strange” block management. Very confusing. It takes a Coursera course to get a grip on it, which indicates that the UI is somewhat lacking… 
At least provide a way to move or get rid of block definitions and layers containing block definitions without any hassle. Allow to just drop them. It should be the user’s choice after giving the user the warning.
// Rolf
Hi all, I added a YT/bug track item to at least get the ball rolling…
https://mcneel.myjetbrains.com/youtrack/issue/RH-54454
-Pascal
We use Rhino with entire car assemblies, thousands of parts, that we trim down to a few hundred for what we need. The trick for us is that we only use layers as our assembly structure. I would not touch blocks for anything more complex that a simple instance of something.
When we import assemblies (native Catia/NX/SW) we do it in Spaceclaim and then we save as .3dm from there. With the option ‘convert assemblies to layers’.
To export back assemblies, we either do the reverse trip: bring that Rhino to Spaceclaim, export from there as a Parasolid.
We have tried also @pascal’s ExplodeBlcoksToLayers upon import of an assembly in Rhino, to get rid of the blocks and turn them into layers. But it does not work well everytime.
Same for his exporter script: ExportAsblocks. It works, but not everytime, on every part.
Every time I try to sit down to try to troubleshoot what’s not working on them, so I can report it, I get lost and confused and I give up.
Rhino should have a properly working assembly manager at some point.
At least it should be able to do a perfect round trip from a perfectly structured/named Step assembly imported-in and layerized. And then exporting that layer structure right back out a s an assembly. Basically what I do with Spaceclaim, but without having to own/use Spaceclaim.
If an engineer colleague sends you Step file for you to change something its reasonable to expect that you can open it, make a modeling change and sent it right back out and everything should be structured the same as it came in.
I’ve been asking for this for a good decade now. At least. Probably an expired wish by now.
G
Thank you for the information!
And here is the answer, straight up.
@pascal @wim @bobmcneel @stevebaer @brian (anyone know any other McNeel people to tag?) are you seeing this? What part of this don’t you understand? You have an entire feature set in Rhino, a core CAD feature set, that’s 100% unworkable in a production environment!
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…
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.
