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?
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 extractSrf or pointsOn)
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?
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
