IGES export issue with entity names truncated

Hello to all, this is my first post here, I hope this is the right place.
I have latest Rhino version for Windows
My problem:
We want to export some curves in a IGES file format (the only one accepted by our Polyworks metrology software).
When doing this; the name of the Rhino object is sometimes truncated to 8 characters, but not for all curves.
(se see the uncorrect result when inporting the object in Polyworks or when re-importing in Rhino
Example of a name beeing truncated during export:
TR_TP_J3002-305-F1-1_TES: a long closed curve : truncated to TR_TP_J3
Example of a curve NOT truncated during export:
All objets have same type in IGES file (126), Can’t find why this does not work…TEST_IGES_2 curves.3dm (32.0 KB)

Thanks to anyone for help

TEST_IGES_2_curves.igs (38.8 KB)

Hi Baudry - thanks for the heads-up, we are looking at this.


Hi Baudry,

I looked into this today. I don’t have an answer yet but I do have an idea of what’s going on and I logged myself a bug. https://mcneel.myjetbrains.com/youtrack/issue/RH-38032 I’m hoping I’ll be able to take next week off so I’ll get back into it on the following week. I can’t tell yet if it’s a bug in the reader reading a properly formed iges file or if it’s a but in the writer and the reader gets it wrong because the file isn’t ordered properly. Just curious, does it only occur when you have complicated curves?


Hi Baudry,

Can you try to open this file in Polyworks and see if it A) comes in at all and B) comes in with the right object name?
.TEST_IGES_2 curves_mod.igs (39.2 KB)

If you have any other software that reads IGES, besides Rhino (I’ve already tested that), it would be good to know if it works there too.

Here’s what’s going on. Despite the curve not being planar, we’re still writing out the unit vector for a plane. Of course when it’s not planar, it’s bogus, 0.0,0.0,0.0. This hasn’t impacted a lot of people because usually the entity type 406 doesn’t have anything of value in it anyway. When a curve is set as non planar that vector gets skipped on import so it throws off the count for getting the 406. The file above has the 0.0,0.0,0 surgically removed so the importer, in Rhino, works like it should. We suspect it will continue to work as well or better in other apps but we want users to test and report before we go changing the exporter since it’s worked as is for many users for many years.

Let me know.

Cheers, Tim

RH-38032 is fixed in the latest WIP

Thank you for your very fast action !