Odd result with booleans on closed polysurfaces

polysurface
boolean
rhino5

#1

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


(Pascal Golay) #2

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

-Pascal


#3

Hello Pascal,

Thanks for your reply. Here the accused file!

AK

GRAF_maquette_copy.3dm (11.2 MB)


(Pascal Golay) #4

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


#5

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


(Pascal Golay) #6

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


#7

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


Why so slow?
(Wim Dekeyser) #8

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:


Why so slow?
#9

Pascal: yay, it worked!

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

Best,
AK