I have a brep geometry that is aligned to the world XY axis and is generated from boolean operations with other breps.
When I want to calculate the Box of that object using a reference plane that is oriented along the YX axis, the dimensions of the box do not match the brep anymore. See the image below.
The issue is solved when I explode the brep and join it again in Rhino. But I would like to understand a bit better what the problem is and how I can avoid it in the future. Is there a way to guarantee that this does not occur after boolean operations or would I always have to explode and re-join?
See below the rhino and the grasshopper file.
Thanks in advance for the response
this is unexpected. I’ve not experienced this before. The problem is not in your c# code, this happens in grasshopper as well. I extracted some of your trimmed surfaces and i found that the untrimmed surface of this one is 10mm wider than the trimmed surface. (you can see this by using
The bounding box should ignore this underlying surface. I think this is a strange quirk maybe something is strange about the part, or it might be a bug? it appears the dimension of the parts you’re using upstream in your boolean operations are invisibly affecting the bounding box of the part.
Thanks @dharman for your response and for looking into it. I am very surprised that this can happen. Ideally I would not need to explode and re-join every geometry that I generate in order to guarantee the box is created from the correct surfaces. @mcneelsoftware is this a bug or is there another way to avoid this issue? Or is there a way to detect which breps have the issue and need to be “repaired” and which ones not?
Hi Lukas -
Thanks for that example. I’ve put it on the list for a closer look - RH-69696.
it looks like the Brep is still in a transitional state until is exploded and joined, applying further booleans operations does not change GH’s perception of the Brep