Bug: Boolean Difference creates weird Boolean Union instead

[Helvetosaur]

@encephalon

CurveBoolean just works without complaining, though the process is a bit more involving due to having to select which parts, which in this case is usually an advantage but one could argue that if the result shown below is wished if it should not also just work like a boolean difference.

You might want to check out PlanarUnion, PlanarDifference and PlanarIntersection.

[davidcockey]

@Helvetosaur

You might want to check out PlanarUnion, PlanarDifference and PlanarIntersection.

Thank you. I did not know these commands existed.

[davidcockey]

New thread started with request to disable Boolean commands working with coplanar surfaces as only input. Coplanar surfaces: Boolean vs Planar for union, difference and intersect

[CD_Lewis]

@davidcockey

Encephalon’s interpretation is consistent with assuming an open surface is the result of shrinking a solid to zero thickness. With this interpretation the results of Boolean operations between a surface and a solid should be the same as limit as the thickness of one solid goes to zero of Boolean operations between two solids.

Encephalon’s interpretation, and expectation, seem to be in alignment with the description of the tools. To underscore that Encephalon is correct about the unexpected nature of the output, I would point out that the same weird behavior can be found in BooleanSplit, which should – at least, based on the description of BooleanSplit and its instructions – not be making a union of anything and yet creates a union anyway. A demonstration shows that using BooleanSplit to split a planar surface so that its two parts fit the interior and exterior edges of a solid doesn’t split the surface at all but unaccountably performs a union operation of the sort noted above:

The two pieces on the left are easy enough to see; when BooleanSplit is issued just identify the planar surface as the target to split and then identify the solid as the cutting object, and by the wizardry of BooleanSplit you are given the figure at right, the union of the two objects (overlapped with the unaltered and unsplit original planar surface). The frightening thing is that one may expect to lose an object one is feeding into a boolean operation as a target and make copies, but there can be a lot of work tied up in a complex shape around which other things must be cut to fit, and one doesn’t expect to lose one’s cutting object to a union operation silently conducted in the background. If one is doing a lot of operations in a row it can be hard to tell where the wheels came off and a lot of time lost to recovering an undamaged cutting object.
Solid and Plane demonstrate BooleanSplit performing union.3dm (3.6 MB)

A specimen file showing the above in a real case is attached. I’ve also observed this when both objects are 3D, which is harder to solve because replacing BooleanSplit with Split leads to open polysurfaces that won’t later be susceptible to BooleanUnion, and an irregular polysurface isn’t a reliable candidate to be closed with Cap so a work flow that must lead to solid objects can’t reliably substitute “split” and “trim” for the boolean operations because they’ll leave you stuck with something that looks okay at a glance but won’t render right (Rhino still makes black splotches when objects share a plane, making it a necessity to union into a single object any object parts you want to render).