MeshBooleanDifference failure with extrusions from GH

I’ve been battling for weeks with a MeshBooleanDifference challenge. I am subtracting out building shapes from a topographic mesh. Some shapes work, some don’t.

After many weeks of debugging and testing I have reduced the problem - I think - to something about extrusions from curves (lightweight Extrusion objects) vs extrusions from surfaces (Polysurfaces). In short, Extrusions work but some polysurfaces don’t (although some do).

Grasshopper extrusions always result in Polysurfaces, even from curves, and most of them don’t boolean with meshes properly (although some do). But even without GH, you can replicate the same failures.

For simplicity, I picked a few examples and deleted everything else from the model, which is attached. The topo mesh has been replaced with a simple mesh box. The original curves and surfaces are on hidden layers.

My GH patch uses the Boundary command (aka PlanarSrf) to combine curves that have internal spaces (i.e. courtyards), and then Extrudes. An example GH patch is attached, but you don’t need it to see the issue.

The orange and red shapes were all extruded by GH, in an identical manner. The ones that fail for MeshBooleanDifference I colored red. I can see no pattern for which fail. You can see one of them has a courtyard, to illustrate the necessity of the boundary command.

I have also included on hidden layers re-extrusions from original curves - which work! - and re-extrusions from surfaces - which don’t.

Interestingly even a curve re-extrusion that works, after being converted to a polysurface (ConvertExtrusion), then doesn’t work! You can see for yourself on the “then converted to polysrf” layer.

Also of note - a non-mesh BooleanDifference with a simple box does work, in all cases. But this doesn’t help me. Converting the mesh to NURB does not work, btw.

Any ideas?

Thank you so much for taking a look!

  • Eric

boolean troubleshooting.3dm (4.6 MB)

boolean (7.4 KB)

use offset mesh instead of extrude (13.0 KB)

Thank you Seghier. I can’t use the NGon OffsetMesh object since I am on a Mac. I tried Weaverbird’s OffsetMesh but it throws an error coming from Boundary, and using MeshSurface in between didn’t work well.

Is there a way to make this work with Weaverbird, or if not, what component would you recommend that is Mac compatible?

Use Weaverbird’s mesh thicken, i don’t use Mac sorry (12.0 KB)


Boundary is a surface, not a mesh. You need to convert to mesh.

Do you have a pure triangular mesh? Are you making holes in your mesh the shape of the extrusion? I am starting to work on a Python script to do this more reliably than Rhino. This afternoon I may get a chance to try in on your case depending upon whether it is compatible with what you are doing.

Convert to mesh does help a lot, thanks. However I am having issues with some curves/surfaces. The curves are generated from GIS building footprint data, then simplified and then offset inwards to approximate removal of wall thickness. I’ve removed all of the GIS stuff for simplicity.

Some of the mesh surfaces produce an error in wbThicken “consecutive edges have the same value.” I can’t manually modify the problematic curves since eventually this will be loading thousands of footprints.

Separate problem - some of the curves don’t offset properly. Using Offset Loose fixes this, but doesn’t work properly when generating surfaces for building with courtyards.

I thought maybe I could do Boundary first, then offset, but due to my beginner level, not sure how to do this.

In the attached files you can see the issues, I have color coded some examples.

@Terry_Chappell The mesh is generated from topo data. Yes the holes will be in the shape of the extrusion. You can see an early version of this project here - (68.6 KB)

boolean troubleshooting 3.3dm (2.9 MB)

I tried trimming your boolean troubleshooting example but the mesh has too few faces. Do you have a triangular mesh with more like 1M faces or so that I could try trimming for you? My trimming script uses a boundary line to define the area to be trimmed (no extrusion needed) and cuts the mesh faces the boundary line crosses. But with no mesh faces being crossed in your example, nothing got cut. I think your real mesh will have lots more faces. Can you sent me a link to it?


Sure, here it is, thanks Terry. I have a much higher res option too if you want it, but it slows things down.

Also of note - in the real file, I have adjusted footprint extrusions to ground elevation and enlarged them to be sure of clean intersections so booleanDiff works properly. The real file is quite complex and convoluted though, I don’t think you want to open that can of worms :slight_smile: .

Regardlesss - the extrusion/thicken issues need to be resolved first.

boolean troubleshooting w topo.3dm (6.0 MB)

I tried trimming the new file. First I had to convert it to all triangles as my trimming script only works on triangular meshes. Then I was able to trim the mesh to a boundary curve I entered. But since the backside has low-density, large mesh faces, only the front part of the mesh got trimmed to the edges of the boundary curve. Several of the back faces were not trimmed as the script was not written to take into account faces larger than the entire boundary curve. Also, there is no joining between the front and back mesh surfaces, is this something you need?

Here is the perspective view of the hole cut in the mesh:

Here is the top view of the hole:

Here is a view of the boundary curve I drew over the mesh.

You could also generate the curve with an equation and use that. Or reuse the same curve multiple times, moving it from one location to another. Or edit the curve between moving and reusing it.

Can you make a version with lots of mesh faces on the back side?


if the mesh is a box why you need use meshes?

The “holes” should have bottoms. They are pockets, in CNC terms.

You can use solid difference but this take long time or you can use this (126.7 KB)

The mesh is a topographical surface converted into a solid. The box was only to provide a simple example. Using meshes per your suggestion. If they are not meshes, I get all the issues in my OP.

I can skip cutting out the bottom of the hole. But then you still need a mesh drawn between the top of the hole and the back, correct? Or can you put that in yourself?

Ok but you need fix some errors; and use join mesh before difference (67.4 KB)

1 Like

Thank you so much. It’s getting closer! I am studying your v4 approach.

v5 - I see the need for your fixes, thanks. I already have a height adjustment for ground elevation and enlargement for clean boolean, as mentioned in my reply to Terry, I omitted it here for clarity. However at least on my system (Rhino 5 for Mac) with your file the majority of shapes still do not thicken, see screenshot.

Your brep/project solution in v4 works well, although yes far more complex.

In either case, I still have the offset issue - I see it can be solved with a smaller number, but I need to retain the 2.5 setting. I am trying to tweak the Simplify tolerance to fix those points before offsetting. Since all of these shapes come from dynamic data (eventually 3,000 shapes), GH has to do the error checking rather than me manually repairing.

  1. Since Offset Loose does handle those problematic footprints okay - should I use this instead of regular Offset, and if so, how to make it offset courtyards correctly like regular Offset does, and how to resolve the PShift error “path shifted out of existence”?

  2. After I figure out the offset issue, do you recommend pursuing the approach in v4 (brep/project/extrude) or v5 (wbMeshThicken)?

you can use this for offset

is the problem with mac version i have no idea you need to contact the developer and you can use which one give you the best and the fast result; if you still have problem with meshes use solids than convert the final result to mesh.
try Pufferfish offset mesh (62.9 KB)

That works, brilliant! Thank you again for all the help. :boom:

I’ll reintegrate with my master file and see if it works with the full dataset and the full topo mesh. Fingers crossed.

I found also using PolylineCollapse helped to optimize geometry further btw.

Just curious, what is the best way to make Clipper Polyline Offset keep the curves on their own planes? It projects them all to on to the same plane (seemingly picked from the median?). Using the Plane input produced unexpected results.

I don’t need to fix this since I can move them after the offset instead of before - first to 0, and then again according to ground elevation from data, but I’d like to learn.