Hi, here is a collection of simple objects that fail to boolean difference away a box.
Setting tolerance to 10x higher does the trick, but I expect the software to solve this with out us users having to fiddle with the tolerances. It should simply try this by it self if it fails.
Here’s the file:
simple boolean fail.3dm (829.3 KB)
Hi Holo, The software does exactly what you suggest. It tries your tolerance, 0.01, which fails. It then tries 0.001, which also fails. When you change to 0.001, it tries that, which fails, and then 0.0001, which works.
Your model has a very small surface that is causing the problem. I think I can fix it without messing with the tolerance. I’ll put it on the list.
Thanks for the report.
Thanks for the reply and for taking a look Chuck!
It sounds to me that boolean maybe should test for both 10x and 100x tolerance automatically, and maybe even more by asking the user, as tolerances for boolean are a bit strange from a user point of view. Tolerance makes sense when joining something, but not when stuff like booleans, intersections and splitting fails. (it makes sense from my programmer point of view of course).
From my user point of view the reason for using Nurbs is that it is “floating point accurate” (yeah, I used that wrong intentionally to illustrate how logic for my user side of the brain differs from my scripting/programming side) 
And also boolean fails on all objects if one object fails, and it doesn’t give any indication on what object that is, which is one of the reasons I made a python script to handle cases like this.
(the red objects were created by Grasshopper by the way, so they should be nice and clean)
I’m looking forward to hear how you plan on fixing it with out messing with tolerances!
I don’t like the idea of upping the tolerance more than once. It rarely helps, and it can take a long time for nothing. In most cases, when a boolean fails at a loose tolerance but works at a tighter one, it is because to surfaces are nearly tangent or overlapping, but not quite. At the loose tolerance, the overlap or tangent code gets called, and since the surfaces aren’t really overlapping or tangent something fails. At the tighter tolerance, the intersector finds transverse intersections and the boolean succeeds. Since the surfaces were nearly overlapping or tangent, most likely the user thinks that they really are, and the boolean result, while successful, is not all that desirable.
Your case is different, and I think I can make it work because the intersection is right along an edge, but since the surface is so narrow, intersection events are found along other edges as well as the correct one. I should be able to detect that this is the case and only use the correct intersection. There is already code to handle the case. It probably just needs to be adjusted.
I agree that there should be a way for the user to know which objects cause the problem. That’s on my list, and I started looking into it a while back. It’s fairly high priority, but there are other things I have to take care of first.