Rhino 8 Feature: Build Blocks Better using Grasshopper

Grasshopper 1 now supports Blocks

Grasshopper 1 for Rhino 8 WIP now has several new components for creating and/or editing block definitions and instances.

With the click of a few buttons, you can create Block Definitions which can be baked (with object attributes) into your current Rhino document. Or if you prefer, simply use the new Import Block Definition to use geometry from an existing Rhino file to define a new block.

Blocks definitions can also be nested inside other definitions according to your specifications and workflow preferences. Additionally, all object attributes are maintained inside your block definitions and passed along to each of your block instances.

Check out our previous post to learn about how to assign attributes to geometric objects.

Creating a Block Instance is as easy as telling the component which block definition to use and where in your scene to put it. With these new block components, you’ll be able to optimize your workflow in no time.



It’s so exciting to get these new features.
I have tried and it seems temporarily not support the nested block definition creating and editing.
Will they be another exciting adding in the near future? :grin:

It should support nested blocks. I’ll post another example tomorrow which shows how to do this.

1 Like

Nothing less than fantastic! Thank you.

1 Like

@weekenlwk I have just uploaded a new example file showing how to create a nested block for a door assembly. Check out the Examples Section in the original post up above. Let me know if you have any follow up questions.

Making the Human plugin useless are we?.. :wink:

Its very interesting with the whole flow-through components.
I have a couple of thoughts but this is all from a Human user (and the extensions that can be built on that)…

1: Not sure I’m a fan of having to right-click to bake before the Block Definitions are added to the file.
2: Love being able to import blocks!
3: Blocks is kind of missing as a Param for Inputs.
4: Would be really cool if its possible to use dimension and leaders when defining Block Definitions.

Great to see progress on a more native way to work with blocks!

A new Bake component is on our roadmap so that you don’t have to right-click to bake it into the scene… so that is coming (at some point). Also, we have plans to implement annotation objects like dimensions, leaders, text entities etc… so that is also coming soon. Can you expand about what the use case would be for a blocks param? This actually already exists it’s just not exposed on the Grasshopper toolbar.


@AndyPayne Really appreciate for the quick response.
I have check your sharing, and that’s an so great workflow for creating nested block in the grasshopper.
And I compare to what I have done, finally find out it seems that something is going wrong as following if I using the referenced nested block.:

1, referenced nested block seems some missing in the preview dispay;
2, referenced nested block in the gh progress can not be bake anyway, and will throw exceptions below

I also upload the rhino and grasshopper document to help you quickly rebuild the issue.

Please kindly recheck this. Thanks!

Nested Blocks-test for referenced nested block.gh (12.0 KB)
Nested Blocks-test for referenced nested block.3dm (150.5 KB)

Great to hear most of it is already in the pipe-line!

The Blocks param would just be a quick way to set one block instance as an input. I’ve used that as a way to reference geometry in with a known, local reference plane (the blocks ref plane), as it means 1 input replaces several. I’ve done it using the Guid param and then converting it to ref object in code:

InsObj = Rhino.RhinoDoc.ActiveDoc.Objects.Find(guid);

It would also make my “Menu-runner” work with it :wink:

1 Like

@molu I see. Have you tried using the Query Model Objects component? I think this would do what you want. Basically, it’s very similar to the Geometry Pipeline component. It will references all geometry in the Rhino document. By default, there’s only a single output called Objects… but if you want to break the objects out by type, then right-click on the component and select Show All Parameters. Now all of the geometry (that is currently supported in Grasshopper) is broken out by type (including Block Instances). You can use the Name and/or Layer filters to select only those objects. It might be a few more clicks than a single parameter, but if you’re referencing several instances then I think this component is more useful.

Also, you can simply right-click on the Block Instance parameter (Bi) of the Model Block Instance component and select “Set one Block Instance” and select an instance that way too. The referenced block instance will then be passed out of the Bi output and you can pass it along to whatever you wanted.


Yes saw the Query Model Objects, that’s very powerful as its parametric by nature, just like the Dynamic Geometry Pipeline :wink:

Ahh yes that’s all the functionality I need, also for setting specific Block Definitions. Will test if my Menu-runner can catch it.

Very cool to see Grasshopper 1 still being developed. Its just a bit sad we have to wait for the a Rhino 8 final release to get this functionality (running WIP stuff on “production” projects never ends well). ¯\_(ツ)_/¯

:eyes: :eyes: :eyes: This is beautiful. Thanks for this.

It would be good to have an auto-update enabled/ disabled and a manual update button in case the component gets bogged down (or you’d like to manually specify when the script computes downstream).


sorry I have just tested the definition that should produce nested blocks. I have referenced two Rhino files and when I do the right click and bake I get only 4 blocks and under “Door Assembly” only Brep is contained. Can you please explain is this expected results because I was expecting that the other blocks to be contained inside “Door Assembly”

Thanks for checking on this… You’re right… for some reason some of the wire connections were lost (perhaps when we updated some of our components it cause the connections to disappear). Anyway, I have fixed the example file and replaced it in the link above. Can you try to download this file and try again? Thanks for reporting this.

thanks for the fast replay, now it’s working as expected.

Hi, will they will be some components that can give Attribute User Text to the object, and then when the geometry is baked, attribute stays stored as information


This should be available in next week’s WIP release :slight_smile:


thanks a lot, that is really good news :slight_smile:

I tried it today to feed a python script. My script used rs.Command("-ShrinkWrap… on a selection of meshes with preset parameters. The Query Model Objects component seems to feed a Data Dam constantly which caused my script to loop a few times. I’m wondering if that’s really the way it is supposed to work or if I’m missing something?

Attached is a simple definition without the Python script. I initially used eleFront 4.2.2 to reference geometry in Grasshopper Rhino 8 and the script worked sort of ok.

Anyway, I think it would be better if the Query Model Objects component would not push the output non-stop and I’d prefer a behaviour like the Geometry Pipeline or eleFront Reference by Layer component.

rhino_8_query_model_objects_data_dam_problem.gh (7.9 KB)
rhino_8_query_model_objects_data_dam_problem.3dm (159.6 KB)