Step File dropping block on export

So I have a Rhino file with blocks and when I export to a step file some of the blocks aren’t coming across as parts. They are just getting sent across breps.

Hi DjNelson,

That could very well be due to that block being Mirrored.
I guess (but someone from McNeel should confirm that @pascal )that the STEP exporter can or will not handle mirrored or otherwise transformed blocks.

I have a script here that (should) find mirrored blocks:

MirroredBlocks_SC.rvb (2.3 KB)


Yep your right those are mirrored. And the script worked slick, thanks. Does it look for negative values in the transformation matrix?

That is correct. We explode geometry out of a block when the transformation is not a uniform scale, translation, rotation or combination of the those. As far as I can tell, there is no accepted way to represent any other transformation in a STEP file. There is an entity that looks like it might be intended to represent a generic transformation, but I’ve never seen a STEP file containing one and all other products that I have checked also explode blocks in these cases. Because of this I assume that the other products would not read the entity anyway, so it would be counterproductive to change the current behavior.

Chuck Welsh
Robert McNeel and Associates

@chuck Thanks. Although I think the biggest case for mirror parts/blocks is to easily create left and right handed parts without having to two separate files. In a solidedge assembly you can mirror parts and it creates a new mirror part that is linked back to the original. Which after thinking about it you could set up something similar with a few more steps in Rhino. If you have Part A, you could insert that mirrored into “Part A Mirror”. That way the two are linked to together and when you export it, the Part A gets exploded leaving you with just Part A Mirror. If that makes any sense. Here is a test file. If interested.

Thanks. We’ll take a look.

Hi Dennis- thanks, I am looking at this…


Has there been any thoughts on changing this?

I have a situation where i wanted to rescale a model with blocks from MM to IN and then export parts. However, I am running into the same issue of the exports are just polysurfaces that are joined.

Hello - uniform scaling should not get in the way - are the blocks still intact after scaling, before the export?


Hi - yes, the blocks are still intact. these screenshots are before and after changing the units. A few addition notes: the block is nested, it originated in another program that exported them to STEP files.

Before scale : MM

After scale: INCH

So… if you export without scaling, is the result different from exporting after scaling? I think the scaling part is not what matters, it’s the export, right?.. what format?


sorry, yes you are correct. I am exporting using STEP file format using the ‘AP214AutomotiveDesign’ scheme.

The point where i find the issue is when i reopen these files. The one that was exported and kept the mm units opens again as a nested blocks, but the one where i changed the units opens as a polysurfaces.

Hello - I can repeat this… so scaling does matter - judging from Chuck’s comments above, I would say this is not expected, i.e. a bug - thanks for the report.


Sorry, looks like I misspoke 4 years ago. I don’t see a way to represent scaling in a STEP file besides scaling the object directly (rather than putting a scale tranformation in a block). If there were a way to do it, and other products used it, then we would have bug reports of Rhino reading STEP files with objects the wrong size. We have no such unsolved bugs. If there is a method, but not used by other exporters, it’s a safe assumption that the importers from those products would not know how to process the scale method.