Odd result with booleans on closed polysurfaces

Hello all,

I cannot get past this odd problem with booleans and closed polysurfaces, and hope you could point me in a new direction.

I have two closed polysurfaces. I would like to subtract the one on the right of the image from the other.

I have checked for bad objects, invalid surfaces and non-manifold edges, to no avail.

I have checked the intersection of the two solids, and it seems good to go.

BooleanUnion yields expected result.

BooleanSplit and BooleanDifference yield the following: the polysurface I am trying to subtract from is marked as a closed polysurface, but there is definitely something wrong there.

And the polysurface I am trying to subtract with now has a naked edge (still no bad objects or non-manifold edges though).

Does this ring a bell for anybody? I am at a loss for what to look for next, and online searching has not been fruitful.

Thanks in advance!
Alexia

Hi Alexia- a Rhino file is worth a thousand pictures in a case like this - can you post a file with the objects?

-Pascal

Hello Pascal,

Thanks for your reply. Here the accused file!

AK

GRAF_maquette_copy.3dm (11.2 MB)

Hi Alexia -the Boolean is correct as far as I can see- the naked edges are on an extra surface that is conicident with the bottom face of the smaller object.

-Pascal

Hmm, I see. Thank you for pointing that out.

I have hidden that surface and made sure to select the two polysurfaces in question when calling that command, but I am still getting an abnormal result: do you have any idea what else could be going on?

AK

Yeah, I see the shading is incorrect - that means the surfaces are incorectly oriented - still poking…

You can ‘fix’ it by exploding the the thing and rejoining, but I don’t yet see what is causing this.
Ah - it is very far from the origin… @ak_epfl move the inputs to the World origin before the Boolean - that should look better.

-Pascal

Interesting. Just out of curiosity, what is the logic behind this? Can you explain why this happens when it’s far from the origin?

This has to do with the way that Rhino 5 creates display meshes. Rhino 5 uses single-precision floating point numbers for these - Rhino 6 uses double-precision.

A lot has been written here on the topic. A few links:

1 Like

Pascal: yay, it worked!

Thank you, never would I have found that on my own.

Best,
AK