Boolean difference influencing the original shape....outside scope area

I have noticed a weird behavior of boolean difference. After Boolean difference the shape of the original geometry has changed outside of the subtraction area! Is there a remedy for this?
boolean diff20210623.gh (44.5 KB)

I don’t see any problem in R6. By the way, it may be worth mentioning that you have written a Python script to do ‘SDiff’ and ‘SUnion’ instead of using standard GH components.

It is in Rhino 7. The Python script is by Seghier khaled.
Thanks again for him for his solution. It saved my day several times when the standard GH component failed due to the possibility to play with the tolerance.

I am finally able to see the anomaly you are reporting and note that it happens only with the Python code, not the standard GH SDiff component.

SDiff_2021_Jun23a

P.S. Increasing the value of your ‘tol’ (Tolerance) slider to 0.29 seems to fix the problem?
And setting the value to zero (or 0.01?) causes Rhino/GH to freeze for a long time and output ‘<null>’?

P.P.S. Correction: changing tolerance fixes nothing, it only causes ‘<null>’ output. Ugh!

RhinoCommon CreateBooleanDifference() must have a tolerance input - it is not an optional argument. If no value is supplied the method will return None/Null. The same goes for Union, Intersection and Split.

If you want the GH script component to function without a numerical value attached to the tolerance input, in the script you have to detect that and supply a default tolerance - which is what the native GH component does.

The difference you are seeing is because the pointed corner is about 0.045 out of tolerance. Baking the the input components and then trying to do a BooleanDifference with the native Rhino command actually fails - probably also because of the concurrent planar surfaces. If you juggle with the file tolerance you can get it to work, but the result is not clean. GIGO.

thanks for calling my work a garbage. Actually it is geometry I really need to connect two pieces together. In fact it is not two but hundreds of elements. I cannot finetune the tolerance with every element pairs. I cant believe is not possible to make a proper solution for boolean functions.

I understand your frustration but it’s a mistake to take personal offense at the term “GIGO”. Solid Boolean functions are very sensitive to several issues like tolerance, coplanar surfaces, angle of intersections, fragments that taper to a point, etc. When “hundreds of elements” are involved, it sometimes works better to use an Anemone loop to join pieces one at a time.

Sloppy geometry won’t cut it! Get used to it. Python is not a magic bullet.

This is your geometry. It’s not “clean” where this point extends beyond ‘Brep orig’:

gigo

What do you mean by “clean” ?? It is two body which is calculated be previously.
In fact it is a pyramid. Which is I think is pretty clean geometry. The purpose of location of the pyramid is to make sure the the boolean will not fail. The original is starting from the vertex but it is a scaled up version to have more chance that the boolean differnce will work.

I mean that edges and points are not well aligned so they are creating ambiguity for SUnion and SDiff. When they fail, you must try something different. Perhaps create the shapes differently, move them slightly, adjust document tolerance, etc.

What is this thing anyway?

In fact, it is the main larger body that is causing the problem. Your edges are way out of tolerance.

As the intersection between the pyramid object and the larger body crosses the out of tolerance edge, it results in an incomplete intersection loop. That will always cause a trim or boolean operation to fail.

I baked the two input components, then in native Rhino I used Explode/RebuildEdges on the larger one, then Join to try to join it back into a solid. The result is 4 holes, one in each of the 4 inside corners like this one:

Just for a lark, I used Cap to cap the holes in the 4 corners and make the larger body solid within correct tolerances, then I used BD to subtract the pyramid - works perfectly, even without fixing the tip.

Rebuilt.3dm (384.6 KB)

Here is the GH definition with internalized fixed geometry - works with a tolerance set to 0.001

boolean diff_msh.gh (81.6 KB)

Note that in the python script component I added a default value for the tolerance (model abs. tolerance), so you can disconnect that input without it going south.

1 Like

The bigger geometry actually calculated previously by Grasshopper, and the 4 frame pieces are cut along 4 single plane going through the corners. So in theory it should attach each other perfectly by joining them by Solid Union. I am a bit shocked the there is a problem with the method described above… I have to investigate carefully where the failure coming from. Can you tell me where is the zoom -in picture related to the whole geometry?

Four planes? You should need only two. Maybe that’s the problem.

one plane per corner. So two frame pieces is cut by the same plane. like this.

I was on my phone for previous post so was too hasty.

Just trying to say that “planes” extend forever and can produce unintended results when used that way, as opposed to planar surfaces, as the green shapes in your image appear to be?

But if those are already mitered corners(?), you might be better off using Deconstruct Brep to get the faces instead of splitting the brep, potentially missing the miter edges slightly.

P.S. Oh, I see they aren’t mitered corners at all but four separate breps?

I put boxes on the green areas and then I using solid difference to have the four pieces and then I make a solid union to create one joined frame. I can really see where the little strange details coming from.

Boxes, not planar surfaces? Why have any thickness to the cutters?

Yeah, it’s a complex shape so how it is created can make all the difference.

If I have just 0 thickness cutters I have to figure out which part should be join. That is why I am using solid difference. I save one step this way. Or is there any advantage to use just planes as cutters?

I believe that planar surfaces would be the best cutters in this case, not planes or boxes.

Of you scroll up you can see how the frame is created. The cross section of the frame segments is not same but the have common section planes. So these extra brep is always created. It is not by mistake is coming from the nature of the assembly. I dont really see why is it a problem. The frame is correct closed brep anyway. Isn’ it? I dont understand why the program believes it is mistake and moves the edge to a wrong position after rebuilding.