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.


I have just used MeshTrim for the first time, and nothing happens.

attached an experiment, (ignore the other parts) and the little tail, on the mesh, I cannot cut it off.


select cutting object, select the ring around it (this was projected to mesh so its a tight fit !)
select mesh, and nothing happens.

Is this the bug or me ?

I have an urgent need to trim something similar on a figure about to be printed, and cannot do so.

is there a nibble away at it tool instead I can use ?

mesh surface editing.3dm (1006.9 KB)

or what ?

I used the line that was used for the project that made the circle on the mesh.
extrude as surface, alter its angle to better suit what I want, then use that as the cutting object and that worked.
Also one can flip the surface dir to achieve cut to side wanted I presume.


I suspect your polyline ring isn’t really a perfect fit to the mesh faces. If you create a surface from the ring (using planar curves option) and scale it up from its centre by a factor of 2 with scale3d, so that it definitely intersects the mesh, then it will happily trim off the tail:


(Or as the line you have drawn is coincident with the ring in the top view, just use the line in that view as the cutting tool)

yep as said, a surface has to do it, no escape for mesh, the ring from projected line in theory was a perfect way but rhino was naughty rhino for me.