BooleanUnion Issue

Can someone please help with the issue in the video.

  • I’ve moved the geometries to the origin.
  • I tried selecting smaller sets at a time but seems to be shifting the ghost problem elsewhere. [quote=“Pascal Golay, post:6, topic:97819, username:pascal”]
    I believe this fails depending on selection order
    [/quote]

I’m stumped. Any advice appreciated.

BooleanUnion.3dm (2.2 MB)

TIA
H

It appears it would work much smoother if you just extracted all the bottom surfaces and then capped things off after, all that overlapping geometry is just begging for trouble. Yes on checking I was able to just extract the pointless bottom surfaces, booleanUnion everything else, then PlanarSrf to make new bottom surfaces, join, 5 closed polysurfaces.

Thanks for your reply @JimCarruthers. BooleanUnion fails when you extract the bottom faces - which makes sense because we no longer have closed surfaces.

I can usually figure out what to change with boolean failures. What’s really weird here is the disappearing geometries.

H

No it works fine here. The objects all intersect fully–in the file you posted anyway–so booleans work fine. It doesn’t actually “care” if your objects are solids or not, ony that they intersect fully. Your problem is those bottom surfaces, a mess of overlapping geometry.

@JimCarruthers interesting… I must be missing a trick then.

Coplanar overlapping surfaces shouldn’t cause an issue with BooleanUnion (Rhinoceros Help)

But what’s really bugging me is that I don’t think the command failed in the first video. Trust me, Rhino is quick to let you know when booleans didn’t work. It’s the disappearing surfaces I can’t understand.

H

Yeah, this is an issue that I’ve noticed for a long while when doing booleans. As far as I can tell, it has something to do with the order that it chooses to do the operations in. If you select the objects in two different orders, you get different results. I’ve never figured out what exactly is going on when the surfaces disappear though. The surface is completely unselectable and invisible, yet it also is a part of the geometry because the polysurface as a whole is still considered closed. If you explode the geometry, the surface doesn’t exist.

My best guess is that somehow the boolean passes some kind of success check within the software and then at a later step when it tries to actually generate the surfaces the surface fails and gets replaced with a null pointer or something.

As far as avoiding the issue goes, yes, coplanar overlapping surfaces shouldn’t cause an issue. But in practice, outside of really elementary cases, they usually do. Keeping your intersections simpler and even batching your booleans into parts will usually dramatically improve success.

1 Like

@jsb.walker thanks for jumping in. Sounds like a good guess as to what’s causing the issue. My non-technical brain was beginning to panic and wonder if it’s something to do with my graphics card. Just wasted half-hour looking into that. :roll_eyes:

I got there in the end, thanks. It was a cat and mouse game of doing the boolean in batches until I got the least offending result - one ghost capsule with at least visible edges - then sorted that set manually - explode, delete, srf, join, trim.

This is by no way a complex set of geometry. What happens if you are working 100s or even 1000s of individual pieces of geometry - a complex facade comes to mind? Another much loved old tool to be shown some tlc development as much as the new kids on the block, maybe?

H

Hello- at the moment it looks like it is these two that break it all:
image
And for these two, the pick order counts.

I’ll put this on the pile…
RH-75349 BU fails at original location

-Pascal

1 Like

Just because they “shouldn’t be an issue” doesn’t mean it’s a good idea to test this capability. Get rid of the bottom surfaces and it’s done in 10 seconds. Of course with this kind of thing I wouldn’t even boolean, I’d trim off the individual cells from the start so that they just join up when arrayed. The thing you’re doing with the outer cylindrical surfaces all coinciding is also problematic, you’re lucky they worked.

@pascal Thanks for looking into it. Should I dare ask how you figured it out or will your reply go straight over my head?

Sounds like a tall pile (75,349). :anguished:

H

Do them in halves and then halve the failing set - repeat…

-Pascal

Yeah. I did them in batches too.

H