Blocks management in Grasshopper

Here we go again…

I’m an industrial designer. I guess that makes me the only target audience according to you.
I don’t need BIM. I need decent block management in both rhino and grasshopper. Every day I need to create vector based drawings that update with my geometry!

I need these features!

To assume that the target market doesn’t need these things because you don’t need them is ignorant.

Maybe when you cool down and see through your blind love for this half baked program you’ll understand the real issues here… Maybe.

Also, paint is not simple and nice. Its junk for toddlers to play with.


Never said that.

I guess McNeel is ignorant then! Paradoxically they are the ones with the most access to data!

I need to cool down? Btw, I use Paint. NET every day to make quick crops out of screenshots and mark stuff on images. Thanks for the compliment Mr Cool guy.

Ok, folks… Let’s cool down a bit, shall we ?
Did you notice who is NOT stating his point of view here ? McNeel people.
I’d like to hear some honest statement like : “blocks would require a complete reboot and that would generate compatibility issues ; sorry, we’re stuck with this crap”.
Or maybe : “we don’t wish to compete with BIM software, BIM is no fun, and we rather focus on fun stuff like modeling kouglehopf cake molds”.
The only McNeelie who gave his opinion on this was David, in the old GH forum.
He said " blocks in Rhino are a convoluted mess".
Same goes for “Make 2d” : people will rip their guts apart on this subject with the same rhetorics as in this thread :
“Even free CAD has gotten interactive 2d/3d since Bush father was president and we are stuck with friggin Make 2D” vs. " How dare you attempt to distract McNeel from it’s saint endeavor to revolutionize the modeling of pretzels with your petty request for proper drafting ?"

But do they tell us exactly WHY ? Nope.
Silence -> frustration -> anger


Hot tip - Windows+Shift+S

Please banish paint from your life.

1 Like

@osuire very true, it would be awesome to hear something from McNeel :pray: :pray:

Who the f… are these people anyways? They get secluded indoors and they just start spreading their rage all over the internet. You are not even part of this community pal. Those are rookie numbers. Coming in here thinking you can bash everyone because you are bored staying at home. Leave me alone clown.

4 hours you only read this discourse. And look how much toxicity. Your ratio must be off the charts.


  1. Assembly/Component design mentality geared to feature driven modelling geared to a proper bottom to top approach geared to object meta data management is the only way to go in the MCAD PLM and the AEC BIM world. Anyone denying this is simply an amateur.
  2. This means dealing with nested hierarchies (“blocks” in R) in ways far and away from what R can do or would ever do. “Dealing” means a lot of things: visualizing on screen things (for instance see the famous CATIA transparent GUI), managing relations on the fly, creating scenariors on a per file or files basis, managing selective un-instancing (critical) and lot’s of other mysterious things.
  3. Bentley Systems has he most complete suite to deal with AEC matters. Plus the core app (Microstation Connect) is using a common 3d engine with Siemens NX (the top MCAD thingy these days). I remind you that Rhino is a surface modeller. Find a friend expert in Microstation and ask him to explain what the Models are (and what Cells are). Then ask him to explain what the Dynamic Views are (and what sort of animals can you display on them).

All in all this is NOT a topic that Rhino users can deal with: is kinda attempting to tune a Golf GTI: a good car BUT not a sports missile by any means.

Remember: Parametric is a thingy used in the very early design stage(s) despite the fanfare. Is highly questionable if would survive in the post Covid19 world (at least the part of it that most people understand).

Note: Imagine any building. Then imagine 500++ drawings of that type:

Update: Let’s forget big stuff and very complex assemblies and things that most non pros outside our trade can’t understand - even in a million years. Let’s talk about a friend of mine who got a very small loft (60m2, ~640 sft) and asked an indicative solution (obviously gratis: what to charge for 1 hour job?). Using the latest Adode Reader (3D PDF can’t translate Model/Node relations so you should imagine the hierarchy) play the 1M dollar mind game: what could be a valid parent/child structure for the objects shown?

302_PLoft_Ambatzis_V1A-CONCEPT_DRAFT-001.pdf (2.1 MB)


I’m not sure… what are you trying to say here Peter?


Any design is the sum of his parts. Be that a small loft defined mostly via equipment objects or a big building with a zillion components or a plant with a gazillion of things. These form hierarcies that are not static (and should been as “flexible” - on the fly - as possible). Componets may come from live Libraries (like the cabinets in the loft or the WC items etc) or be “isolated” entities within a given file (this is a stupid way to cut the mustard because you create things on a per design/file basis meaning that you rediscover the wheel ever time … blah, blah).

Imagine an engine and focus to the “main” moving parts: crank, rods, pistons and rings (forget valves, cams and spings for the moment). So a crank is a void node that contains the child crank parts while every piston is a void node containing one rod (for simplicity) one pin two wrist pins one piston and several rings (2 to 4). Obviously the “same” things are instance definitions (meaning that the nodes are nested instance definitions). Parts come either from Libraries of parts or are custom (defining new Libraries).

So in fact we are talking about managing hierarcies of instance definitions (forget for the moment the smart objects as used in several AEC BIM aps).

Now in some design phases you work by isolating some things (either on a node basis or via multiple clip planes) exactly “like” (kinda) the model tree in the Adobe Reader (that part is done by Ray Bentley of Bentley Systems). Imagine a racing piston version B: while displaying the piston version A in some View (or many) you should work on the active part (and maybe reduce the rings and the sides for even less friction etc etc) and see all the related things (or not): portion of the cases (via custom clips on a per View basis), the head (ditto), the valves (ditto) etc etc.

This means that managing hierarcies/relations is only a portion of the problem: is useless without a proper way to display on screen the things that you want to see. Meaning that each View should display different things (and Views should be as many as you want).

But the big thing in real-life is the dollar question: during the design you should increase the accuracy of the cost pre-estimation (i.e. part cost + assembly cost): if we are talking about standard parts this is more or less easy … but if is a new one (like a new piston or a new cabinet or a new complex facade combo in a twisted tower) … well … you should get some pre-offers/estimations for that by people who do similar things. But if the engine (or the building) is complex this means that you should communicate with lot’s and lot’s of sources, get their feedback and maybe replace parts on the fly and the Specs Articles (even at final study level). This means auto - updating a zillion annotations/marks as well: a rather impossible task (that does Microstation Connect).

1M question: if a part belongs to an assembly … what portion of the design you should expose to some maker in order to get a realistic cost pre-estimation?

Back to the small loft: having all the above in mind … draw in a piece of paper the ideal hierarchy/strategy for the objects present … and then mastermind a policy for a cost estimation. I mean a real-life policy for the real world (where the parametric hype means absolutely nothing).

If all that appear … er … outer space stuff … just find a practice designing a contemporary plant with CATIA and ask for a demo (or better: contact Frank Gerhy).

BTW: imagine designing a retractable dinner table for … er … cyborgs (meaning a freaky collection of freaky parts with cyborg compatible aesthetics). What is the hierarchy required? Anwers: The Lord, District 666, North Pole.

CF45_FalconDinnerTable_030.pdf (992.9 KB)


i am laughing out loud :grinning::grinning:

Only you could start a reply with “Simple:” and finish it with 10 paragraphs :sunglasses:

1 Like

Did that table just transform into a harpoon launcher before my eyes? That’s an awesome cyborg table.

PS: NEVER use WD40 on that (deployment freaky squeak noise etc).

PS: The fact that cyborgs don’t eat is rather irrelevant.

Cautiously wading into the conversation here…

I hesitate to get mixed up in the broader topics discussed here, but I can offer how we’re using Elefront here at Front to manage attributes within nested blocks, in the context of large architectural models being worked on by teams in multiple offices in different geographic locations.

In our case, we also use blocks to manage the propagation of small-scale geometries (like gussets, brackets, bolts, etc). across a large model, with those components carrying attributes along with them. Typically, we would define those blocks in an algorithmic way. That is, if we have the same bracket with 14 different lengths, we’d use a script to generate those, and use the Define Linked Block component, which would create the fourteen .3dm files of those blocks with their attributes. This could include blocks nested within it**.

If those pieces are assembled into another block, and we realize we need to add or change an attribute to the sub-block, we would go back to the original script, make the change there, and re-generate them through the same Define Linked Block component, thereby overwriting the sub-blocks.

If you are using the Import Linked Block component, click update or re-running the component will pick up those changes since it is newly reading in the information. Especially to achieve the functionality described by the OP, I highly recommend Linked Blocks to provide that continuity.

A quick note about that: Point taken regarding consistent filepaths. Our offices are distributed geographically, so we’ve implemented an IT approach that features consistent filepaths across our offices. Perhaps other options there would be something like symbolic links, or some other way to at least simulate filepath consistency. Worst case… Dropbox? Not sure. But if you can work that out, using Linked Blocks we’re able to have someone in Hong Kong modifying dozens of individual parts while someone in New York is combining them into assemblies and someone in London instantiates them across the global model.

Regarding the nested blocks, it’s true that you can’t go modify a sub-block within the active document, because that is a Rhino limitation. Indeed it would be nice to have that functionality. I suppose it would be possible to do the defining of your blocks, and the nesting thereof, within a single Rhino session, which would then keep your blocks live in the active document. We prefer to work in a more piecemeal, distributed way, because I could see that getting quite unwieldy when you have hundreds of block-types.

**An important note about nested Blocks and the current version of Elefront. Right now, when you use Import Linked Block, it does, as the name would suggest, create a Linked block. However, if you are doing this to create a block, which will then be nested, only the information about the block instance itself will be passed. For example:

  • I have a single fastener block with some attributes and a Brep representing the fastener
  • I assemble those into another block representing a bracket, using the Import Linked Block component
  • I then propagate my bracket blocks in a larger model, assuming the fastener will also pass through.

With the default functionality, the fastener block’s geometry (and its attributes) will not pass through. The block instance will pass through, as well as the attributes applied to the fastener block instance. That’s because in the bracket model, it only contains information about the fastener instances, not the geometry within. To get around that, in top-level block (the bracket in this example) the sub-block (fastener) need to be changed to “Embedded and Linked” in order to get the geometry to pass through.

In the next version of Elefront, we will expose a toggle on the Import Linked Block component to give you the option between “Embedded and Linked” and just plain ol’ “Linked”.

Of course much of the discussion on this post is more philosophical, and I’m going to favor my pragmatic side by sidestepping that a bit – I think it’s valuable discussion, but I am simply offering what I hope is some useful information until the smarter folks figure out something else.


Hi Keyan,

This was both elegantly exposed and informative.
I will try to overcome my aversion to linked blocks and give your suggestions a try…

Any ETA for that update ?

Thanks for sharing Elefront. I does really make our life easier.

1 Like


I just created an account to answer you.
I would like to say a huge AMEN.

If only Rhino had those type of features, it would surely be a revolution in the industry.

Please MCneel, consider these, i personally would be happy to participate in a crowfunding campaign to help rhino become a more architecture friendly working environment. With better layout management, block management, detailing etc …