Block Management Tools Need Improvements

I’m referring to that kind of stuff :

You can also look in the old newsgroup and search for rants about blocks, since they are still relevant.


I was just trying to figure out if this post needed a different thread as it was not related to V7 display performance. I understand that BlockEdit could use some work.

could use some priority as well :slight_smile:

please please pretty please even more so than all the fancy new stuff in v7


That was the point I was trying to make.
Framerates will never be high enough, yeah, but these days, I’m working on 2GB+ files with relative ease.
Block management has needed a refresh since Conan the Barbarian’s first tooth.
That remark about nested blocks often coming from SolidWorks etc… sure pulled my trigger !

What you need to understand is that, by definition, people who need blocks in Rhino are the ones working on large, complex projects in which the structuration of the data is what allows you to keep track of stuff and not get lost.
Thanks to Grasshopper, we were able to somehow circumvent the amateurish way Rhino deals with blocks, but it is still very crippling.
When you talk about display speed improvements, you are talking directly to those frustrated people, so just be a bit more carefull how you present it.

1 Like

Boy, do I feel left out… :stuck_out_tongue:

And the only thread that I’ve ever seen getting any traction at all:

The worry now, perhaps, is that the same 5 people are seen posting in all of these, and McNeel thinking that the rest of their customers have no issue with it… though nobody from McNeel has ever given me any satisfactory answers in any of my threads regarding blocks, so I don’t believe that is the case for a second.


@eobet Yo ! Ma man !

Adding my thread to this sad collection.


Yes, yes, please put some love into blocks/blockmanager!
I use inserts/xrefs/reference blocks to be able to work collaboratively on one file and/or to keep large files small and tidy. Thus I have to open the blockmanager often to update/remove etc. blocks. That thing is not on the height of time. We know it, you know it…
An easy thing to add would be to put block functionality in the context menus. Just one of many worthwhile improvements.


Angry crowd of Rhino users with forks and torches : Better block ! Better blocks ! Better blocks !

McNeel : -crickets-


Could this be because the rest of the Rhino users can do what they need to without using blocks even though blocks would make some things much nicer (if properly implemented)? Many of us have tried to use the block system and found it an annoying pain and even hard to comprehend, and just decided it’s useless. Perhaps the persistent beggars are the folks who really can’t even do their jobs without blocks. They have actually used McNeel’s poor excuse for a block system enough to enumerate and describe it’s stinky parts.

I’ll add my voice, for what it’s worth, to this. I don’t use blocks in Rhino. Not because I don’t want to, but because they are a confounding, workflow-wrecking mess.



Could it be a chichen and egg problem ?
McNeel not giving a f- -k because users don’d give a f- -k, the blocks being so f- -ked ?

You got yourselves a nice little theory there fellas.

I think you’ve hit the fking nail on the fking head, Olivier.

1 Like

I want better block management too!

from my pov the problem is double :

  1. block aren’t working well so they’re not really used (eg try to render them)
  2. today majority of the Rhino users are very inexperienced kids and most of them even don’t know what a block is for.

Better block ! Better blocks ! Better blocks !

1 Like

@bobmcneel yes please hire a better block manager


To be fair, though… if I could choose between a better block manager and, say, Solidworks/Alias class robust filleting (and dear god, un-filleting), I’d chose filleting any day. Because although the block manager is an inconvenience for me personally, it’s the filleting in Rhino that’s 100% a showstopper for me to attempt to suggest that anyone else where I work should use Rhino instead of Solidworks/Catia. 2 licenses is the maximum we’re ever getting until filleting is drastically improved… but that’s just us.

Perhaps it’s the reverse in, say, an architecture firm?

Exactly! In architecture design, every repeated element goes into a block by definition. It’s not just for reducing file size, it’s for maintaining your model synchronized and to reduce user errors as much as possible. Imagine you have six different types of columns in your design with a total of 200 columns in your building, and you have to change those profiles, can you imagine going one by one 200 times? And those columns may have several screws (nested blocks), so you would have to update every single screw!!
or just edit those 6 block definitions and be ready to go! Imagine hoy many repeated elements you have in a building…

Blocks are a must have feature in any CAD, 3D and design software and not having a proper block system can be a deal breaker for many users. IMO, McNeel should put everything related to block on top of that famous priority list before adding any new feature to V7.


Seems to me that database-based software is more than necessary along with its reference-instance data model.

I’ve been hinting that to McNeel for years.

I have to agree to that.
What makes me angry is that they don’t even grab the low-lying fruit like sorting the sub-blocks in the “Blockedit” of a nested block.

Back in the day, I fought long and hard to get a sorted list of blocks in the BlockManager.
Imagine that ! The whole shitload of blocks was just listed randomly !
(By the way, you can thank me for that one folks)

I’m no programmer, but how hard can it be to sort a !$#%*! list ?