Blocks management in Grasshopper

By now, it has become obvious that McNeel will never improve block management in Rhino, but blocks are just completely indispensable when you tackle construction or fabrication processes.

So for some time now, the only resort was to use Grasshopper, but with extra plugins that allow to reference block instances in Grasshopper.
I tried Human, Elefront and Instance Manager from Heteroptera.

First of all, these plugins each have their specific baking components that cater for the way they reference blocks, and manage properties (and user attributes which some put apart from other properties).
Then, although they more or less do the same thing, they all do it in their special way.
For example, one will only reference visible blocks while the other will allow to chose this as an option (but that option is not exposed *$!%#).
One plugin will allow the creation of nested blocks, and not the other.
Some will be generally stable ; the third will crash like a stock-car.
One will count blocks and make a mess of it when the blocks are nested.
Some will get block data from the current file, some from a file based on it’s path.
In general , the baking of multiple blocks will generate short-circuits in the definition and the boolean toggle that triggered the bake will remain “stuck”, generating tons of instance duplicates.

In short : this is a mess !
For the life of me, I haven’t been able to create a proper tool to retrieve, and display information about blocks and even less to change properties, most importantly Keys and Values despite the plethora of tools that claim to make this possible.

Please @DavidRutten, implement block management tools in GH2 !
We really need something legit and rock-solid for this !


Ay up sailor!

If the mountain will not come to Muhammad, then Muhammad must go to the mountain.

Block management is not really one of the core functions of GH, or even one that is so intinsevely used that MUST be updated. Grasshopper community is very big, and altough many of it’s users are architects there are also designers, artists, programmers, naval engineers and so on. GH community is very heterogeneous and the software is very generic to attract the broadest audience possible. In my opinion, I don’t think that McNeel would wan’t to invest resources anytime soon in adding a function that would be used only by a specific segment of its users, although many of us would really love it. That’s why 3rd party plug-ins develop this kind of very specific functions. Maybe today is the day that you start a new journey developing GH plugins for the construction industry, like Muhammad.

I’m an architect and I intensively use GH, but one must understand and cope with the limitations. If you’re looking for a more construction-oriented software I would strongly recommend switching to DYNAMO for this kind of stuff. It’s an analogue software by autodesk, developed entirely for the construction industry.

Best regards,
Sir Ernest Shackleton


Hi mister funny guy,

So you’re an architect, hey ?
The kind that will whip up a magnificent, inspired, erotic/exotic shape with Grasshopper and then let others deal with the petty details related to actually turning my masterpiece into a code-compliant, possible to fabricate, possible to assemble real standing building ?
Well, I’m one of those other guys, and I can tell you that I absolutely need blocks to keep my building data structured, communicate my models with fabricators who need to understand that structure, count the bits and pieces, generate bills of materials, update sub-components and other such trivia.

Since you’re refering to Dynamo, you are actually thinking of Revit, which is absolutely not appealing for me.
Dealing with complex shapes, I enjoy the freedom given by Rhino and would find myself shackled (see what I did there ?) in a dialog-box ridden black box like Revit.

My point is that Rhino could be far superior to Revit, Archicad, and even all the Solidworks bunch, IF ONLY it had a couple of extra features :

Interactive detailing : The switch from Make 2D to a proper 2D-3D interactive detailing system would be a big step, and probably require licensing code from outside which McNeel stubbornly refuses to do.

Better block management : Here, there’s really no excuses. The changes and improvements to make don’t require external licensing or even so much development. McNeel has just been completely deaf to it’s users here, and probably doesn’t understan the needs of the industry, just like you apparently.

Now back to Grasshopper : Many components already exist to alleviate Rhino’s weaknesses in the Block department, and I even think that the C# code behind them is not that hefty (although I’d be incapable of doing it myself with my present coding skills).
The problem, as I tried to convey in my first message, is that none of these tools is sufficiently robust and complete, thus my request.


Can you please explain? I think that I don’t understand how it is used in this sense, because for me it has more cost than benefits. If I see it’s worth it and I can, I’ll include it in the next version of Peacock. Some jewelry plugins use blocks but for me it’s always been something annoying to deal with. Why do you consider them indispensable and I don’t need them to make jewelry?

1 Like


I don’t mean to be rude or anything, but my point is that Grasshopper should have native tools for blocks and attributes (these go together).
We certainly don’t need to add more confusion with yet another plugin referencing exploding, and baking blocks in it’s own way !

I don’t know the jewel industry, and I have no idea if blocks would be useful in there.
Here’s why I think blocks are an absolute must for many industries.

I first started as a big SolidWorks (or SolidEdge, or Inventor, or Pro-eng, …) enthusiast.
Actually, David (yes, THE David) was even on internship in the office at that time, and I introduced him to this type of CAD.
In his subtle way, he got me to understand that what I found so lilberating in SolidWorks (sketch constraints, assembly constraints,…) were actually more…constraining than having a general purpose “Free-form” CAD like Rhino and being able to program it.

But look at it this way : ALL the industries that used SolidWorks or the like, actually need and use blocks.
They are not called blocks, but it’s just the same : they rely on instancing part files in assembly files, and those assemblies are sometimes sub-assemblies in larger ones.
That’s how car, planes, machines and complex structures are designed nowadays !

So basically, good blocks management in Rhino, and a powerful way to make them parametric (GH) is all it takes** for Rhino to be vastly superior to all those big players.

So instead of trying to embed itself in them (Rhino Inside), Rhino could just beat them flat.
McNeel’s lack of ambition makes me kind of angry as you can tell…

** and proper 2D detailing.


I know what they are, but I still don’t know why they’re useful in practice, I’d really like to know. How does it improve your workflow? What does it allow you to do? How does that nested structure help you? Some real example of use case?

Think of how industry has transformed our world since the middle ages.
Not that I don’t have my doubts about the overall positive aspects of all that, but… it’s a fact.
Things are standardized, repeated, made into components.
These components need to be counted, sometimes updated…
I’ll come back to you more in details when I have more time.

Here’s a good illustration found on the internets.

1 Like

Hi Dani,

It is how production lines in manufacture industries function:
They often divide the final product manufacture into groups (engine, suspension, radiatior, facade cladding…), and assign a separate production line or a separate section of the continuous production line. These groups are called assemblies, and the process of manufacturing one such assembly is always the same.
A car may have an engine assembly. Inside this assembly there are more subassemblies or even subsubassemblies. Some of these subassemblies may be the same - they consist of the same parts. Translated to Rhino’s language: their parts are instances of the same block, and they themselves are nested instances of the same subassemblies.

Majority of 3D solid cad modelers posses this assembly feature (also called “semi-product” sometimes).

Rhino’s alternative to the subassemblies and their content are blocks/nested blocks.

As for the other part of osuire’s reply, I think he was reffering to introduction of dynamic blocks into Rhino/Grasshopper. Or maybe I misunderstood?


Imagine you have a building, and that building contains 8 kind of windows that counts 120 windows in total. One day, after you have placed all those pretty windows in your lovely 3D, you receive a call form the windows manufacturer telling you that you have to modify those 8 kind of windows decreasing their with by 5cm. If you have created those windows using blocks, it will take you less than five minutes to modify those 8 master windows. On the contrary if you didn’t use blocks you will have to modify 120 one by one… This kind of changes are pretty common in AEC. One day is a window, another day is a column, another is a sink …and I imagine the same happens with automotive, marine …
Does this clarify why we desperately need a good block system? Every single CAD software I’m aware of uses blocks, and I know a few…


Hi Djordje,

Thanks for helping me out here.
What I mean by “Dynamic” is that Grasshopper can be used as a parametric way to generate, update, and sort the blocks, “Scanning” the whole block structure and display information in a more useful way than Rhino’s Block Manager :

-All Block definitions in the model
-All used instances (instances of block definitions actually existing in the model)
-All sub-blocks (instances used in other blocks, but not necessarily present in the model as standalone instances)
-All blocks defined but with no instances in the model
-The number of occurences of these block definitions
-The attributes (AKA “user texts” ) of the block definitions
-Filter the list of block definition names according to Key/value pairs ; for example, "List me all the blocks with the value “Wood” associated to the Key “Material” , that have a volume over 1m^3.
-Display symbols on the selected block instance names
-Display relevant data on one instance of a block definition
-Generate a BOM from a selection set of blocks, with a user-selectable set of attributes.
-Change the values of certain attributes for a selection set of block definitions
-< Insert your useful block management feature here >


This can be quite trivial to do with static objects, but becomes more difficult with blocks because :

  1. Grasshopper doesn’t natively support blocks
  2. Nested blocks are a pain in the butt

That’s why we need native support of blocks in GH


Hi Osuire,

Then I misunderstood you initially. I thought when you said “parametric” you referred to something as AutoCAD’s dynamic block feature.

Maybe someone else will correct me, but all the listed should be possible to achieve with some custom code in Rhino 6. Even the block attributes are available in current Rhino WIP.

I’m not saying it’s impossible… but it’s a struggle.
I explained a few of them in my first message.

Thus the need of a single, reliable component toolset.


I think that the main reason that block management has not been implemented in Grasshopper yet (a side from the already mentioned like time, resources, priority, audience, etc.) is simply because third party plug-ins already cover most functionality.

Care to develop this a little bit more? What exactly are you trying to achieve and why?
If I remember well, Elefront deals with Keys and Values just fine, where exactly is the limitation?

If I am not mistaken, Elefront was developed internally by Front Inc. during the design of the Morpheus Hotel by Zaha Hadid Architects.

I am sure they had their own custom scripts and stuff to achieve this, but most of it was wrapped into the Elefront plug-in, at least the Rhino/Grasshopper related stuff, and by the looks they did just fine.

Maybe you are getting into more complex stuff than this and the free public generic tools are not enough for you. This could be wake-up call that you could answer in many possible ways: Rethink your workflow, pay someone to code you some custom tools, consider getting into coding to sort these limitations and code custom tools yourself.


Errr… did you actually read my first post ?
Have you ever actually used these third party plugins ?

Anyway, I think it sucks that all Rhino objects can’t be referenced and processed natively in Grasshopper, because, well, this is one of the purposes of Grasshopper.

Elefront created an “Extended Geometry” container which accepts blocks, dimensions**, texts, dots and what not, but then these objects become special classes that will be processed properly only through Elefront components.

And I don’t want to be mean or anything, specialy since Elefront did help me achieve stuff and saved my butt a few times, except this thing crashes like a bee on a clean window.
I use it when I really have no choice, generally because I can’t do what I need to do with Human (Like baking nested blocks).
And even then, baking many blocks with Elefront either generates duplicate (tons of them), or freezes Grasshopper’s interface which forces to close and re-open Rhino.

Then, there’s these silly “update” buttons like on the “Reference blocks by name” which forces to use Metahopper’s “Expire object” if you want to trigger it through Human UI.

Two things that are really handy with Elefront:
-The way it explodes Blocks : “Recursive” or “One level”
-The fact that it can reference them by name and filter “Top level” block (and visible ones too).

One thing that I couldn’t figure is the “Modify Elefront Attributes” ; I was never able to make it change the attributes of a referenced block instance…
Since you seem so learned about Elefront, maybe you can help me out…

** Amusingly, although Grasshopper can not reference dimensions, it can now generate them, but still requires to right-click on the components to bake, making it unsuitable for an environment where it would actually be used : large design firms where dedicated GH programmers make Human UI interfaces for draftsmen.

One thing that I couldn’t figure is the “Modify Elefront Attributes” ; I was never able to make it change the attributes of a referenced block instance…
Since you seem so learned about Elefront, maybe you can help me out…

Elefront is an exceptionally generous plugin and is the primary reason i try and help others understand it when i can – paying it forward ya know?

Like any software workflows can make or cripple a software. If you have the wrong settings in rendering it takes hrs per frame instead of seconds.

I’ve used Elefront in numerous conditions and haven’t found it flaky or “thing crashes like a bee on a clean window” – i would suspect this is more workflow issue.

Complaining about a cutting edge software & open source plugins like they owe you something seems counter to the project. Rhino is many things a variety of trades, granted its better a master of one but with what they are producing for so many its hard to argue they are doing it wrong.

The modify attributes is just like create attributes except you can feed geometry directly into it.

If i’m overwriting key values, layers etc i typically just use the define attributes with modify rhino objects.


Really ? You never had it crash on you ?
It never hung Grasshopper when baking nested blocks ?
Do you use blocks at all ?

Asking Grasshopper to reference blocks natively is perfectly legit and makes a lot of sense since GH helps manage complexity and multiplicity, just as blocks do.
Having a single consolidated, official Bake component would go a long way, instead of mixing a bunch of them from various plugins.

Could you elaborate on this ?
In what case would you use the “Modify attributes” component ?

Here, with my blocks neither work :

1 Like

i support you. i think rhino 7 would be huge disappointment without improved and refined block managment and block functionality in general.

double click on nested block for edit, right click make unique option, show/hide other same blocks, … inspire from sketchup and from other software put it together and just improve it please and include blocks in csv export


Hi All,
in my opinion Blocks are fundamental in Grasshopper for many uses if You are an architect (as me). I don’t think is necessary explain more about the blocks in Rhino (if they was not useful, they was not existing in Rhino too, of course…). I don’t understand why, if someone asking some feature in Rhino /Grasshopper, it start a very stupid discussion about “Why do you need”, “You can use instead the plugin” and so on as Rhino need defenders…or we think Rhino 7 will be the last release because is PERFECT right now?
And just for laughing…why don’t we start to create a Plugin (X) for a Plugin (Elefront) for a Plugin (Grasshopper) for RHINO?
Rhino was not create express for architecture, but we know that after Grasshopper this world is changed. So my 2 cents are to have Blocks directly in Grasshopper as very important feature.



You could visit this page.

There are at least 3 posts with example files that you can download. There is even a link to a video of almost 2 hours long.

One of the two comments below the video reads:

genius. That’s exactly what fabricators need to automate their workflows! I work in Revit and dynamo, there are aswell some issues with prediction of outputs. Sometimes it’s 1 and sometimes it’s 0. I noticed that it all comes down to maths and list management. If you understand how your lists tree structure is made up you can do real powerful things with this kind of software.

That guy seems quite happy. :grin:

It has never crashed for me either, even when using blocks.

Nope. Never happened to me either. I am sure that if you upload the problematic definition people here could help you. It is perfectly reasonably to think it might be a bug, all software have bugs. You could report it here or even reach out to the developer on Food4Rhino. Maybe they answer you, and even answer your questions regarding certain components.

Regarding the “Update” buttons on reference components, that is not a limitation of the plug-in itself but of Grasshopper instead. Expiring certain components and forcing them to recalculate has always required some scripted hack. You decided to go for another plug-in, that’s alright, but don’t blame poor Elefront. It’s not Lunchbox either.

But, hope dies last:

If you right click the component, you can see a “Disable auto update reference objects” option checked by default. Try unchecking it and see if it works like you need it to.

No one is saying it doesn’t. Many things would be great. Wouldn’t it be wonderful if instead of having 20 different software we could have one that did it all? Wouldn’t it be wonderful if a 3D printer could also be a CNC machine? That would be awesome.

Things take time to improve and develop. At least, we should be thankful that it is possible to achieve these tasks with a FREE plug-in. For some other stuff you need to pay, and for some other stuff it is not even possible.


The error message gives some clear hints: It does not work in your case because the geometry you are inputting is not referenced from the active Rhino Document.

Basically it means your geometry needs to be baked into Rhino. Instead, use Modify Elefront Attributes.

Here, from the example files on

You can see the attributes before and after Modify Elefront Attributes. (31.6 KB)