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.
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â:
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.
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.
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.
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.