The badness of Meshtrim

We badly need some improvements with MeshTrim, MeshSplit and all the MeshBooleans as it causes the same issues in V6 as in V5.

Here’s an example. Try to use MeshTrim and trim away the areas between the curves.
Also try to extrude the curves into surfaces and use MeshSplit.

MeshTrim Badness.3dm (149.6 KB)



@Holo, i know this is cold comfort, but the green mesh is really a bad one:

Mesh has 2 degenerate faces.
Mesh has 180 non manifold edges.
Mesh has 77 duplicate faces.
Mesh has 603 pairs of faces that intersect each other. 

After removing the duplicated mesh faces and exploding into parts i was able to use _MeshTrim for all parts, except the vertical faces. They where done using _MeshSplit, all in Top viewport.

MeshTrim Badness_cg.3dm (309.4 KB)

+1 for mesh related improvements though, especially for finding intersecting faces.


Hi Clement, yeah, bad meshes are part of the industry, these came from Revit. And in my opinion Rhino has to deal with it like other software does, at least meshsplit and meshtrim should be able to handle the mesh on a per-face level and thus ignore duplicate faces. What I do in a pinch is to isolate the objects, unweld at degree 0, explode, trim each face individually and then join the stuff I want to keep.

They are and Rhino should be able to deal with it. It seems like other platforms have figured it out and there is even the possibility of interfacing with these platforms. McNeel is really dragging their feet on this one.


A first necessary step would be that Rhino handles valid 2-manifold meshes correctly. I agree that bad meshes are part of the industry but having written lots of meshing algorithmic code myself, I’m willing to settle for correct behavior on valid meshes. Invalid meshes need to be pre-processed in order to make them valid (and yes, some improvements could also help on this).

All the algorithms in a mesh library are based on a few basic building blocs like edge splitting, edge collapsing, triangle-triangle intersection, etc. If you have a guarantee (an actual algorithmic proof with corresponding implementation like in the CGAL library) that each of these operations preserve the validity of a valid mesh, you can use them to compose arbitrary complex operations on meshes. That’s this guarantee that is missing from Rhino meshing code.

For example, many people reported very bad splitting problems on valid meshes.

As long as those are not fixed in a systematic way as I just described, I don’t see much hope for robust mesh processing in Rhino, even on perfectly valid meshes.