Are Block Instances planned as an input parameter for GH2?

Just curious.

I know there are add-ons (both paid and free) which gets around this limitation in various ways, but I’m interested in a native feature.

1 Like

I’m not really sure how to do it well. A block in Rhino is an instance (plus a transform) of a definition. A definition is a list of identifiers of objects currently in the Rhino document, but kept hidden from the user.

So without a 3dm file which contains the necessary shapes and layers etc. it’s not really possible to have a block. Various solutions present themselves, but I’m not really happy with any of them:

  1. Just keep all the block data in the 3dm file and go in and extract it whenever needed.
  2. Create a completely separate block api which can exist free of any 3dm constraints, and then try and make conversions possible between Grasshopper and Rhino blocks.
  3. Create a Grasshopper type which is just a transform and a block name, then upon baking try and resolve the name. Not sure what should happen if the target block cannot be found.

What are the reasons you use blocks in Rhino? Is it because they keep file-size down? Lower memory impact? Organisational/bookkeeping reasons? Do you want to be able to replace block contents with other shapes? It would be handy to know because it may inform in what way Grasshopper should deal with this.

1 Like

Thank you for the reply!

My specific use case is that I would like to use Grasshopper to place a number of objects in a specific arrangement, and then export it to a .STEP file. Without blocks all those objects become unique parts even though it’s the same part, and with blocks, it’s just one part with many transforms.

So basically, all of the above plus if the objects will need to be modified in a different program, the modifications will cascade to the entire arrangement. :slight_smile:

Almost everything I’ve done with Rhino/Grasshopper so far is to import files from different CAD packages, modified them in some way, and export them out again.

Agreed its kind of murky and hard to get right, as I have seen after heavy use of 3 different approaches by GH plugins - Elefront, Human and Instance Manager (Heteroptera). All do some things well, but only Instance Manager tries to do the native GH approach of having a type component where you can right-click and “set one instance” or “set multiple instances” from Rhino. Human makes you select stuff in Rhino and press a button and Elefront does away with all of that and just lets you reference by name, which is not ideal as it will see all instances as well. So if you use blocks for instancing large amounts of copies of the same item then referencing by name is always bad as it will go through all instances first getting really slow once you have more than a few thousand instances.

Of course the plugins are not really compatible with each other as they create their own datatypes which all contain roughly the same data, but are just called differently. So I think having a common and native datatype in GH would already help to at least have interoperability in GH between different plugins.


VisualARQ apparently also has a “proper” BlockInstance input parameter (even placed in the native Grasshopper parameter menu), but that plugin costs almost as much as Rhino and has tonnes of stuff I’m not interested in.

(I’m also not in architecture, but rather industrial design, so I’m not inclinded to trust that it will work for my use case either.)

Oh okay, maybe it came from that (I had the trial version of VisualARQ). Its kind of weird when plugins place stuff in the standard categories as you have no way to find out where they came from. Hmm… let me see.

Agreed. I mean, GH is so good, say 99% all good. But the alien intruders from “namelessness” plugins should be banned. And severely punished (what are people really thinking when they do that mixing?)

Add to it the anonymous alien intruders craze, the fact that there’s no popup-info, help or hints, disclosing anything about the origin of such alien components (no hint about plugin-name, .gha, path, or anything really).

The principle behind the “general case” reusable “Block” problem has been solved ages ago in business software systems (it’s a typical “product” structure in which a part can be both a selling product on it’s own, or a part in an assembly of parts/products).

Find the holy grail solution to Blocks in those systems. Problem solved. (a basic principle doesn’t change with the context).

// Rolf

in the component toolbar, right-click an icon, choose “component info” to see which .dll or .gha it comes from :nerd_face:

Right now blocks in GH are important for me because they can carry data which GH geometry can’t - texture mapping - this is very important for me.
Also, Unreal Engine 4 understands Rhino Blocks (at least partially) and it makes it possible to do some heavy scattering. UE4 can handle a lot of instances. Treating every exported instance as a unique geometry would absolutely clog this program.


Thanks for the details, that may be helpful when I start trying to figure this out.

Can I ask how you have gotten this to work? By reading a .3dm into Datasmith directly?

We’ve found that the Rhino .fbx export doesn’t weld vertices (even if the option is checked) and the Rhino .obj export flattens the hierarchy, so we can only export using .step (ie, no Rhino tesselation, but that quality is questionable as well, so that doesn’t really matter even if Rhino has a potentially interesting triangle aspect ratio feature that would help with pixel overdraw).

Yes, I import .3dm via Datasmith. I’m not sure how well Rhino blocks are read in UE 4.23 (you can see some funny shading which I experience first time…)

Note that althought the Blocks in Rhino are scaled nonuniformly they are imported as one geometry, so UE4 reads some transformation data.