Proposal: Importing STEP assemblies as nested layers, not nested blocks

Yes, as Eric (@ejolley) said, if there was a tree-view like panel just for the nested blocks and if there was a bit more methods in the api to manipulate the objects inside the blocks I would have never had the need to create a script to translate the blocks into layers.

Hi @brian, do you know when we will be able to see this in a WIP build? thx.

1 Like

@brian wish/proposal:
why not having a block editor that is integrated with the layer structure?
block and layer could be used in the same ways and mostly they both need the same options and capabilities.
makes sense?

They have to be separate.
Assemblies from solid-modellers also have layers that should be kept.




I just posted this question:

…so I hope that any future implementation of blocks to layers will take this into account and never produce a layer with only one object in it (it could be an option, I guess, for those who want a nightmare of a file to manage, hehe).

Btw, is there any chance of a solution regarding instanced objects with layers? Can’t remember if this was discussed or not.

(PS. I now found a script by @Pascal that enables me to move BlockDefinitions which was the root cause of all of this, so yeah… if the editing/managing of Blocks in Rhino would have been modernized, as suggested here in 2015, this whole ordeal could have been avoided.)

Hi @brian, I wanted to check in this, we are most 3 years later and this is still a major plain point for us.

More of a paint than 3 years ago as we do more work in engineering and final part design for tooling. I think it will be fine to have mirrored objects as unique, not blocks for now. The rest of what you describe here, I think it’s exactly what’s we need. I’d love to test something.

Any chance this can make it as part of V8, or at least a plug-in/script we can test and perfect, and then you can decide later if it makes in into a shipping product, if ever. If we have a plugin solution we’ll be just as happy.



1 Like

Nope, none of this is going to make it into V8 - plug-in or otherwise. We’re wrapping up the feature set for Rhino 8 now.


Old thread, and I don’t know if this has been solved, but here’s my 2 cents on Import/export of blocks in assemblies from other CAD formatsd.

To me it seems that the problem of reconstructing blocks for, say, STEP-export could be solved with an extra attribute on the exploded RhinoObjects (@gustojunk suggested exploding blocks into regular RhinoObjects). Starting from there:

  1. EXPLODE BLOCKS – Import blocks and explode all instances into RhinoObjects.

  2. PSEUDO-BLOCK-ID – If multiple block Instances exist in import data, then, before exploding them, create a new (novel) “PseudoBlockID” and this ID as an extra attribute to all instances being exploded into RhinoObjects.

  3. Keep a table with these new PseudoBlockIDs.

  4. EDIT & LOCK ! – If ANY of the RhinoObjects having this extra “PseudoBlockID”, say RhinoObject A, B and C, if any of the three are edited, say RhinoObject B, then LOCK the OTHER RhinoObjects with the SAME PseudoBlockID! (You’re already guessing where I’m going with this).

  5. UPDATE PSEUDO-BLOCKS – When done editing a RhinoObject which has this “PseudoBlockID”, simply replace all other RhinoObjects in the file having the same PseudoBlockID (of that’s “too much” to handle, handle the modified (pseudo)Block on export instead).

  6. PREPARE EXPORT - RECONSTRUCT ORIGINAL BLOCK – Since we know which RhinoObjects were originally instances of the same block (via the PseudoBlockID) we can now recreate a single block out of all these “pseudo-blocks”, and then export also all the other pseudo-blocks, but now as true instances of the one RhinoObject we have chosen as the “BlockDefinition”.

  7. “BLOCK DEFINITION” – The one RhinoObject which we chose as the “BlockDefinition” must of course be the one we Edited, since all the other exploded copies where Locked and thus could not become a “definition” (unless of course all the psudo-block-instances (RhinoObjects with the same PseudoBlockID) where updated directly after editing.)


The above approach would ADD an attribute (but only on demand) plus some logic for updating pseudo-instances and reconstructing the original block configuration for export. It would not require MODIFYING current logic for handling blocks in Rhino.

The above approach would keep track of the original block structure while residing inside Rhino as exploded “regular RhinoObjects”, and via the PseudoBlockID all exploded copies would always be ready for reconstructing back into the original block configuration on export.

The exploded RhinoObject/PseudoBlock-copies can be spread out in any layer configuration thinkable (although requiring the extra space) and still be updated like if they had been Rhino blocks, plus composed back into the original block configuration on export.

Hopefully it makes sense.


Hi Rolf, this approach makes a lot of sense. I don’t remember if this was discussed here in the forum or I talked about it in person with Brian, but he had subjected a similar (or same?) approach as a way to freely work/edit in Rhino but always maintaining assembly information to then put it back in the bottle before exporting again.

I’d love to see this built into Rhino someway. Could this be scripted? Or has to be a built/in feature?


This could probably be done with the Grasshopper Rhino components…

The only thing I’d be worried about is filesize when there are a lot of detailed instances.


I think it was discussed in the former thread that was so long that Brian creatad this new thread.

I think the part after import and before export could be scripted. I don’t know if the import/export code would have to be modified, or if all the processing could be done after import and before export.

Adding extra attributes (like a PseudoBockID) is supported out of the box.

Triggering Events to make Rhino update all the RhinoObjects (exploded copies) having the same PseudoBlockID would require hooking into some already existing event, but I currently have no insight into Rhino events.

If update after editing a PseudoBlock Instance is not automatically triggered (by an internal event), the user would have to explicitly invoke a command like “UpdatePseudoBlocks” efter editing, to ensure that all pseudo “instances” are updated.

After updating all PseudoBlock instances, they could all be unlocked again so that further editing could begin again, even on any of the PseudoBlock instances (otherwise they would have to remain locked from editing until being updated just before export, or whenever).


This problem could be limited, and in some cases even eliminated by initially creating only, let’s call them “ObjectLocators”, meaning small structs which only contains their ID’s but no or very little geometry (perhaps only a box as a “place holder” or the alike). The geometry would then be fully instantiated only if the PseudoBlock instances are actually displayed, or even so reluctant to be fully (lazily) created that they’d resist creating until being explicitly demanded by the user to finalize its creation.

In this way - so called Lazy Evaluation - the concept could allow for zillions of pseudo instances to not even have to be drawn at all, except for one or few instances which you force into display in order to edit one of them.

Lazy Evaluation is a fairly standard trick in modern programming (I’m actually hacking together a C# framework with derived (C# & Rhino) C# class attributes, with lazy evaluation, as we speak. This very light-footed framework will be used in a C#/Rhino project I have going).

My slogan is “There’s always a solution”. Remains only to find the solution(s). :wink:

This would be an interesting project to look into when I’m done with my current project, but it’s many months away.


– “There’s always a solution” – me.

1 Like