Mesh Booleans Issues

I’m encountering some robustness issues with Mesh booleans: when booleaning out these meshes (shown in wireframe) from the green mesh,

I get:

The meshes are closed (per the properties panel if I bake them), and welding them makes no difference. Boolean difference with the equivalent Breps yields the correct result: no extra corner, and the two interior holes are created correctly.

I’ve also noticed a (potentially related?) issue with the mesh inclusion component: it is not accurately excluding points that are outside of the mesh, specifically points in the two interior holes of a mesh created from the Brep version of the boolean above:

The Brep inclusion component works fine.

Here’s two internalized GH script containing the respective examples. I’m on the 8.7 SR, and get the same result if I bake the meshes and use the MeshBooleanDifference command. If I instead bake the respective Breps, run the Mesh command with the default settings, and then run MeshBooleanDifference, I get this:

I’ve tried playing with the meshing settings but nothing seems to massage it into working - open to suggestions there. (16.7 KB) (29.0 KB)

Ideally it would work in Grasshopper, but I’m open to any solution using RhinoCommon that can get the mesh result to yield a mesh equivalent to the boolean difference result. Let me know if there’s a better category for this.

Most of the problems are due to coincident faces.


I was just going to mention that…

Sure? That’s not really a solution. The Brep boolean difference works perfectly with the same geometry. I’d expect the mesh boolean to do the same, as the meshes are closed. Is a fix for this possible, or should I not expect this? I’m doing this programmatically, so I’m trying to avoid applying ad-hoc imperceptible translations or scale factors to get meshes to behave as Breps already do, and thought the report and reproduction could be useful.

Coincident faces also doesn’t explain the mesh inclusion issue, since there are no booleans involved there. I know it’s probably because the points are coplanar with some of the mesh faces, but it’s a bug regardless, the points are clearly not in the mesh.

1 Like

Hi @Dan_Cascaval,

I’ve logged issue so we can look into both of these.


– Dale

1 Like

Thank you!