STEP Import Leaves Instance Definition Geometry on Default Layer

Hi,

I am encountering an issue while importing STEP files into Rhino.

When I load a STEP file, all imported objects initially come under the Default layer. After the import, I programmatically move the objects to their respective mapped layers.

However, I am observing unexpected behavior related to block/instance definition geometry.

Issue Details

  1. During STEP import, the importer sets Default as the active layer.

  2. Because of this, definition geometry for instances is created on the Default layer.

  3. After the import, only the instance objects are moved to their mapped layers.

  4. The definition geometry remains on the Default layer.

  5. As a result, Rhino displays elements appearing in both the mapped layer and the Default layer, which creates confusion in layer organization.

! _ExplodeBlock _AllBlocks _GroupOutput=Yes _Enter
_ExplodeBlock _AllBlocks _GroupOutput=Yes _Enter
_Purge _BlockDefinitions=Yes _Enter

Hi @lander,
Thanks for the suggestion. However, exploding blocks changes object IDs and removes instance structure, which is important for our workflow.

Is there a way to update the layer of instance definition geometry directly (via API or import settings) without exploding the blocks?

To change attributes, e.g., layers, of objects in block definitions while retaining the objects’ GUIDs:

  • Via UI, sub-object select (Ctrl+Shift+click/window) the objects in the block, then modify their attributes in the Properties panel. Objects, excluding the instance objects themselves, in nested instances can also be selected this way.
  • Programmatically

Some scripts to do this can be found in the thread, Change layer of block definition?

Hi Manav -

In a quick test here, that statement proves to be wrong.

Apart from that, it’s not clear to me what you are trying to do.
Perhaps you could post files that illustrate the issue?

In Rhino, a block has its definition and its instance. When dealing with blocks, it’s useful to keep those two concepts very much apart.
-wim