MeshBooleanUnion improvements?

Still some progress to be made… Would be nice if in the file below, MeshBooleanUnion could put the meshes together into closed volumes without destroying everything. The WIP is slightly better than V6, but there is still a good ways to go…

MBU.3dm (482.9 KB)

_MeshBooleanUnion has not changed much from V6 to V7. As explained above, _MeshSplit has changed.

Yeah, guess it was just wishful thinking on my part… :pensive:

May I ask what program or script creates so many adjacent and partially overlapping volumes? I think it could really be improved as a start, and even the old code would have more possibilities of making it. @Helvetosaur

(btw, I moved this particular case to its own thread, and I am adding here a screenshot and in the next message a link to a YouTrack issue)

My last post went to the other thread…

1 Like

Most of these are downloads of 3D building data from various public sources - they may be automatically generated by some program somewhere, but there’s zero hope of getting better data for the moment. This stuff is very typical of what an architectural modelmaker has to deal with when doing site models; often this stuff is massive, many hundreds of buildings and they most likely need to be clean, closed meshes in order to be 3D printed…

Right now you need NetFabb or Magics to fix this stuff, but I’d like to show my students that they could do some simple mesh fixing in Rhino. :confounded:

Yes, first step is fixing for sure. Not running MeshBooleanUnion. If you run the _SelBadObjects command, Rhino WIP recognizes 13 meshes as bad. These need to be fixed. I’ll check one by one what is bad about them, and let you know. Some may be stuff that Rhino can fix today.

EDIT: Even for some of the non-bad meshes, I am seeing that there are degenerate faces and other issues.

The bad meshes were created by the BU. If you try only on the originals (white layer), there are no bad meshes. CullDegenerateMeshFaces on the originals says none found…

1 Like

I wasn’t able to predict this. Thanks for pointing this out.

EDIT: Here is now a link to the correlated issue: RH-56995.