3D boolean operations bugs

Grasshopper
1

Hi all,

I’m working with solids and I’m having problems with boolean operations.

After some testing and research, I came to understand that the issue occurs when the two solids I’m trying to operate on have coplanar touching faces, meaning the intersection between the two faces is not a curve, and the operation fails.

My goal is to subtract a list of volumes (B) from a starting volume (A). Here’s what I tried:

  • Direct difference between A and list B → fails

  • Union of list B first, then difference from A → fails

  • Iterative loop (built with Anemone) where A(i+1) = A(i) − B(i), subtracting B one item at a time starting from A(0) = A → fails whenever B(i) is coplanar with A(i)

I tried both with Breps (ensuring they are closed) and with Meshes (ensuring they are closed and have unified normals pointing outward). The problem persists in both cases.

I also tried the Dendro plugin, which handles these cases more consistently, but unfortunately it doesn’t suit my needs: Dendro converts everything to a voxel-based volume and re-approximates the entire geometry, not just the areas affected by the boolean operation, but the whole shape. This means I lose the exact edges and faces everywhere, even in regions that should be untouched. I need precise shapes with exact edges that remain as such.

I’m aware of a workaround that involves slightly offsetting the solids in B to prevent coplanar touching faces, but I’m not satisfied with it: moving in a given direction may fix one coplanarity issue while creating new ones or leaving others unresolved.

I’m attaching an example file covering all the cases listed above. It uses the Anemone and Dendro plugins; if you don’t have them installed, simply ignore the branches related to those specific cases, the rest of the file will open and work fine regardless. For each case, I also included a variant applying the workaround mentioned above. As you can see, none of the cases work consistently this way either. The only one that shows some promise is the iterative mesh subtraction, but it still doesn’t give me enough reliability to consider it a solid solution (the displacement must be high enough to avoid coplanar issues, but depending on the case it may still not be sufficient, or it may be too large for my tolerance); also, it could look promising just in this specific case and turn out to be equally unreliable as the other approaches in different scenarios.

Does anyone have ideas on how to solve this? I’ve run out of options.

Thank you for reading, and have a great day!

BooleanBugs.gh (48.6 KB)

2

A couple of notes:

  1. Your object is too big for the units you’re using, not sure what scale you had originally, but having an object that’s 150,000 units in size is asking for trouble - so consider how different the calculation will be if you’re working out the same area in m (1x1x1) or in mm (1000x1000x1000)
  2. Your object is quite far from the origin, it doesn’t look like it because it’s so huge, but bring it back to 0,0,0 - you’d be surprised by how many operations fail when you’re trying to do them 100 miles away from the origin.
  3. Combine your B Meshes into one object, the fact that they’re overlapping will 100% be contributing to your failures

See if that improves it at all

3

Thank you for the answer.

It looks like it’s improving a little bit, but I need to test more.

Meanwhile, I’d like to ask about your points 1 and 2: the file I posted is just a piece of a larger model, working in millimeters, already centered at the origin, with extensions on the order of magnitude of kilometers (so around 10^6 units). The trick of scaling everything down depends on the absolute dimensions alone, or on the dimensions relative to the document tolerances used for boolean operations?