Errors in meshes created from non-native Rhino geometry

Rhino
, , ,
1

Hi all,

When importing NURBS geometry from other CAD software such as Siemens NX, SolidWorks, CATIA, Creo, or Fusion 360 (via STEP, IGES, or similar formats) and converting it to meshes in Rhino, the results are often problematic. The internal structure of these NURBS surfaces does not appear to be interpreted correctly by the Rhino _Mesh command. As a result, the generated meshes frequently contain issues such as degenerate faces or self-intersecting geometry, typically visible as irregular clusters of vertices and polygons along surface edges.

Vertex Cluster
Vertex Cluster723×503 47 KB

Notably, these surfaces do not have naked edges or non-manifold edges, so the errors seem unrelated to standard topology or tolerance conditions. This appears to be a long-standing issue, present even in older Rhino versions, although mostly affecting some specific workflows.

For context, I work with the ExactFlat plug-in (and for ExactFlat as well), which relies on meshes to generate 2D patterns from 3D geometry. During the flattening process, meshes are remeshed into a more suitable topology. However, this remeshing step is often disrupted by the aforementioned mesh defects, as degenerate faces and similar issues are not properly handled by the remeshing tools. This forces us to manually repair each mesh, which is extremely time-consuming. I imagine this could also affect other mesh-based workflows.

*Unfortunately, tools like _QuadRemesh do not fully resolve the issue. While they can improve overall mesh quality, the resulting faces are processed independently and their vertices are not properly stitched along shared edges. In some cases, the quad-remeshed geometry inherits the issues stated before, resulting in missing polygons or similar artifacts.

_ShrinkWrap won’t fix the issue either, as it doesn’t keep the mesh faces as open, sewn meshes (it makes everything thick and watertight).*

I’ve attached a couple example files (imported from Fusion 360, SolidWorks and Creo) that consistently produce these types of errors when meshed in Rhino. See “Named Views” to zoom into the problematic areas.

My mesh settings are as follows, but different mesh settings still lead to the same outcomes.

Mesh Settings
Mesh Settings482×567 13.6 KB

Mesh Error Creo.3dm (8.7 MB)

Mesh Error Fusion 360.3dm (3.8 MB)

Mesh Error SW.3dm (19.3 MB)

Rhino Version 8 SR28
(8.28.26041.11001, 2026-02-10)

Please let me know if you have any questions.

Best Regards,
Gonzalo.

2

Hmm, looking at the Creo one, and the seat back in particular(I guess that’s what it is?) the weird points do seem to correspond to where the edge curves are doing slightly wonky things, like abrupt changes in direction(some of which are inherent to the surfaces but there are lots of extra ones.)

Using RebuildEdges does help, and it helps more the bigger the tolerance, but there’s a limit to how much just doing that helps.

Manually re-creating the splits in the seat back with clean geometry seems to be your nuclear option. (Top in attached image)

Further, those areas where the surfaces change direction instantly made me try DivideAlongCreases to break them up at those points, and that plus RebuildEdges would seem to be the quickest sort-of fix.

image
image1920×1080 614 KB

3

I exploded your Solidworks example and where you put the red circle, two edges end and there are three control points within a very short distance.

image
image1318×1023 9.3 KB

I moved the edge on the right down so I see to which edge the control points belong.

image
image1454×1487 41.3 KB

Looks like the edge to the left has two control points within 0.000007 mm

The other selection here also contains three control points. These are 0.000018 mm apart. I scaled the ‘duplicate’ points 1000 times so Rhino displays the value in the command line.

image
image1723×684 6.64 KB

Boundary Error SW Rhino 8.3dm (19.7 MB)

Boundary Error SW.3dm (19.7 MB)

What tolerance was used when the Solidworks file was imported into Rhino?

4

Thank you for your response. I hadn’t tried _RebuildEdges before, and it seems to do a great job of consistently repairing the surfaces across all the files I shared.

As for _DivideAlongCreases, when used in combination with _RebuildEdges it tends to generate invalid surfaces, so I wouldn’t include it as part of a standardized workflow.

5

Hi Martin,

When importing files into Rhino, there are no tolerance settings available. I also don’t have control over the export settings in the source software, as I simply receive the files as they are.

However, once the file is opened in Rhino, even with tolerances set to 0.01 mm, exploding and rejoining the surfaces before using the _Mesh command does not resolve the issue.

Jim’s solution using the _RebuildEdges command appears to be the best option.

6

I think in some situations the tolerance setting would have to go much lower than the usual 0.001 units, something like 0.000001 units or so but even then you often don’t know what the previous software tolerance was… It can be a pain…

Where do you think the duplicate points I mentioned come from? Maybe they’re a very tiny distance apart, shouldn’t that be avoided?

7

I believe the issue is likely caused by a knitting operation -either as a native feature in the original software or introduced during the conversion to STEP or IGES- that modifies the edge shapes to meet document tolerances. Unfortunately, the Rhino _Mesh tool does not overlook the issues introduced during this process, resulting in these noisy artifacts.

A lower tolerance would likely make the issue worse, as Rhino becomes more sensitive to these defects rather than ignoring them.

8

You can export just a part of the original shape where the errors occur and look at a *.step export but I guess you’d have to export from where the object was created.

9

Unfortunately, I don’t have control over how these files are created, and the sample set is too large and diverse to attribute the issue to a single native command, or even to the source software itself. It is more likely related to how Rhino interprets the files.

10

I exported a dense mesh from Rhino and then remeshed it using Isotropic Remesher in Open Flipper. (free). I arbitrarily set the mesh edge length to 2mm in OpenFlipper but it could be set to suit your need. The mesh from Rhino is attached for comparison with the remeshed version.

image
image1885×932 530 KB

Mesh Error SW remeshed.stl (1.8 MB)

Mesh Error SW STL.zip (5.6 MB)

11

It seems this mesh has some more dense zones where the original had duplicate control points.

12

Yeah, but is it usable for the application …

13

Would be super interesting to see the source of the files

14

I just recalled there is a grasshopper tool for isotropic meshing, if that topology can work Introducing TriRemesh - high quality triangular and hexagonal remeshing and shrink wrapping

15

Hi cdordoni,

Thanks for sharing that remesher. Unfortunately, the resulting mesh is full of degenarate faces at the mesh boundaries. See how the control points are not followed by (visible) mesh edges.

image
image1337×781 41.6 KB

16

I think I misunderstood, I thought the control points are part of the problem. I don’t know what your tolerence is … are you indicating it is so tight that the small difference would be an issue? I can’t imagine the end result requires that kind of precision.

I should have checked for degenerate faces.

17

Which file are you using as input here? I’d like to take a look and see if it can be improved

18

Look at the Solidworks file