Transfering IGES from cimatron to rhino - naked edges and bad surfaces

Hi everyone.

I work very closely with our company engineer, he works with Cimatron to prepare the files for CNC milling.

When I transfer file in IGES format there is no problem the files open with no problem in Cimatron, all the surfaces are good and joined. But when I receive files from him ,even if it is the same file I sent him (he only saves it again in Cimatron), the surfaces are many time broken ( their edges are not well defined and i need to rebuild them) and i am unable to join them ( the edges move and the surfaces are not touching each other).

We tried to use STEP format to transfer the files but that didnt work the files were even worst.

Does anyone have experience with this problem?
Is their a better way to transfer the files?

hope i was clear and not to long

Roi Ramot

Hi Roi, for the joining problem this might be a tolerance issue. Check if the absolute tolerance in Cimatron is smaller compared to the one used in Rhino. I get various IGES files, eg. from ProE or Solidworks where joining results in many naked edges until i lower my tolerance in Rhino from 0.001mm to 0.01mm. Bad or missing trim curves are common too.

For the bad objects problem, it might help to tinker with IGES prefs (or flavours) in Cimatron, i´m not shure what kind of settings it has to offer. Alternatively, is there the possibility to try out VDA format ?


have a read of these two McNeel papers:

thanks for the quick reply.

i will check the settings in Cimatron.
also the papers were very helpful

Quoting from step 5 in the Guidelines for Repairing IGES Files

“5 Check for bad surfaces.
The Check and SelBadObjects commands will determine if some of the
surfaces in the model have problems in their definitions. They may have stacked
control points, bad edge curves, or a variety of other problems.”

This article was apparently written back in The Rhino2 days. That was when Rhino had good error checking That functionality is no longer present.

I knew something was wrong recently but I couldn’t put my finger on it. During the Beta phase of Rhino 5 I could swear that I could use selbadobjects and it would select the one in the example below… and now it doesn’t. Notice the contours are not continuous across the middle of the object where there are stacked control points.

Hey, someone else may actually LIKE your bad object and we wouldn’t want to have one of those nasty warning messages showing up now, would we…?


All fun aside :smile:
The functionality Jim refers to disappeared with RH 2, not during the v5 cycle…

Why is the object above not classified as bad anymore?

It clearly does not work as you cannot perform standard Rhino Commands on it like sectioning.

plus I was impressed by the improvement of selbadobjects over Version 4… but now I am not. I was singing its praises to the other offices in my group as they would send me files to check for issues and v4 didn’t identify them but v5 did. These were IGES files from Maxsurf

This is just my guess right now, but I think, in theory, Rhino was supposed to handle stacked control points better so these were not considered bad any more. It clearly does not handle them fully yet. We get surfaces with stacked points from hull building programs, where stacking points internally, so to speak, is commonly used to make chines, so we do want to handle them better… OK, I see you’re getting surfaces from MaxSurf.

Can you send me the surface that behaves badly in your example?

@GregArden, am I correct that intersecting surfaces with stacked points was supposed to ‘just work’ in V5, or did I make that up?


Hi Pascal,

Whilst I’m glad you are making inroads to allowing Rhino to handle stacked CPs better, there are programs that don’t.

We use openCascade in or in-house software for sectioning the IGES hull forms to calculate displacement. The maths goes awry if there are stacked CPs. Rhino was used to correct these models supplied to us from Third parties and selbadobjects was useful to identify at first glance which surfaces were using them and then applying the smooth command to separate them.

It was just a basic example above created by:

  1. create a plane surface
  2. Rebuild 5x5
  3. select the 3 middle columns of CPs
  4. SetPt X click in the middle
  5. ExtrudeSrf (Solid = yes)
    StackedCPs.3dm (155.3 KB) ,

Exactly the reasons that Rhino should have a user-configurable “bad object” warning…


This is the sort of stunt pulled by Maxsurf:
The disappearing/reappearing surface

It might not be considered a “Bad Object” now, but it is certainly bad practice. But as a consequence, if you extrude these three surfaces to solids then you try and Boolean Union them, it will fail. ~Unsurprisingly

StackedCPsBooleanFail.3dm (246.3 KB)

EDIT: Apologies all round for the hijacking of this thread

Maybe they can add a SelDubiousObjects :smile:

1 Like

GrasslandPlugins.rhp (7 KB)

Adds the command “SelStackedVerts”, which should select all curves and Breps that contain stacked vertices. Could have scripted that but wanted to try the plugin approach. Might add a event watcher later, like CheckNewObjects, to execute the checks when objects are added to the document…



First of all, Stacked control points is not the only type of degenerate geometry that causes Rhino commands to fail. In the “Don’t have a solid fillet” thread we had two examples in one small model.

Second, the problem is that often it is not the users fault. Frequently, bad geometry is created by bugs in Rhino. The reason Rhino development proceeds at such a glacial pace is in part because it can take years of users stumbling over bad geometry to find these bugs. That is because nobody can tell at what point the bad geometry was created… If Rhino had good error checking the bugs would be found and eliminated quickly.

The solid tools in particular could use a good dose of error checking. They tend to be lousy tools that breed degenerate geometry because they have never been deloused.


Surfaces with collapsed spans should get called out in some kind of check function. But they should also work for simple trim and split operations. For more complicated operations like booleans they may never work, which is why we need the check function.

Thanks, Danny, I’ve added a couple of examples for Greg to take a look at on our bug tracker -

These are not available to the public, yet.


Thanks Pascal,

I keep getting the:

New user registration is disabled. Please contact your system administrator

Whenever I try to sign into those links with Google

Yes, despite the links, the system is not public yet, nobody outside McNeel has access…