WIP: Mesh Booleans updated with improved results

Serengeti (Rhino WIP)
, , ,
1

The ability to Trim, Union, Subtract, and Split mesh geometry is critical when working with imported models. We continue to re-write new mesh commands to work on models that would previously fail.

  • Results of boolean have been greatly improved.
  • Mesh faces keep the same mesh organization as inputs.
  • More mesh models are successful even if not always well structured.

This code is a work in progress. We’re continuing to work on improving the results in hopes you’ll have a chance to test and report examples that work better and those having trouble.

A complex mesh that previously would have failed to boolean.
A complex mesh that previously would have failed to boolean.1766×1125 244 KB

Commands affected by this update include:

MeshSplit a complicated mesh
MeshSplit a complicated mesh881×975 437 KB

Combine these new booleans with the new ShrinkWrap command Rhino 8 WIP to extend what is possible with imported mesh models.

Give this a try and get back to us on a new thread to show how it is working for you.

13 Likes
7

There are new features in the Rhino 8 WIP builds concerning Mesh Booleans.

All 4 MeshBoolean commands (Union, Difference, Intersection and Split) now include:

  1. The ability to quickly cancel the command.
  2. A status meter that shows progress for longer operations.
  3. Improved messaging on the command line to identify problems.

These can be found in the current Rhino WIP

5 Likes
8

Also of note:
it works quite well when combined with quadremesh.

3 Likes
9

Shrinkwrap is also a help here. In some ways these tools are about fixing nightmare meshes.

2 Likes
10

hi @scottd @piac,

I just tested a mesh boolean in today’s updated WIP, something very basic: an open mesh from a loft that is passing right through another close mesh, yet the open mesh has normals clearly define and compatible to create a clean boolean subtraction, it still failed.

capture_gf_103449AM_230515
capture_gf_103449AM_2305151920×1128 100 KB

If I use fillmeshhole in the open blue mesh the boolean it would but that’s unnecessary extra work.

Easy to test, to repeat, and to fix.

Thanks,

G

11

hi Gustavo, I tried replicating it with something similar, but can’t make it fail, can you post that model?

12

Sure, I’ll PM it to you. Thx

G

13

@gustojunk I’ve written up a YT for your file, thanks for sending. The following is currently invisible to public due to your sent file link. RH-74786 MeshBooleanDifference fail

14

Thanks for your great test file, @gustojunk. I’d like to explain why you get this. The code algorithms of Mesh Booleans are now, by design, almost entirely normals-independent. It is still expected, however, that for some cases of open meshes, this might give “wrong” (actually I would rather use the word “unexpected”) results. This is because our brain infers information about what is “inside” from the object itself.

For this reason, we are adding a subset of instructions to conduct some sort of resolution in case of open meshes, using normals this time. This code isn’t ready yet, so it’s only partially enabled.
I’ve made @Gijs’ link public so that you can follow at least some part of the progress.

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

1 Like
15

Hi Giulio, thanks for the update and explanation. In this particular case is almost trivial needing to pay attention to normals since the boolean operand can easily be closed. But for us being able to do booleans in the way we want/expect with open (= half-modeled) operands is a huge time saver. So I really hope that this functionally is not eliminated regardless of the topology type.

thx!

G

1 Like