Questions about GetBoundingBox(bool)

I’m encountering some behavior in GetBoundingBox I don’t understand. I have a Brep (it’s a simple rectangular prism) for which GetBoundingBox(true) produces this reasonable bbox (truncated for clarity):

Max: (17.40, 32.70, 3.96)
Min: (-14.86, 0, 0)

but GetBoundingBox(false) produces this substantially different one:

Max: (17.40, 32.70, 11.44)
Min: (-14.86, 0, 0)

All that extra Z distance seems to be propagated to the Brep’s faces, even for accurate bboxes. Here’s Faces[2].GetBoundingBox(true):

Max: (0, 13.38, 11.44)
Min: (-14.86, 0, 0)

Faces[2].GetBoundingBox(false) yields the same thing. I’m not sure exactly how the Brep was created (it was given to me by a user), but I know that it spent some time waaaaaay far away from the world origin. I know that this often causes numerics to break down, but I’ve moved it back to the world origin, and the behavior persists. New objects drawn near the origin don’t do this, and the bboxes generated by the BoundingBox command always look fine.

Is there a reason for this other than that it was originally drawn so far away? And either way, is there a way to “fix” the Brep?

Hi Cody,

If you post some sample geometry, we might be able to provide a more accurate answer.

But in a nutshell, an accurate bounding box for a Brep is generated from the Brep’s render meshes. An inaccurate bounding box from a Brep includes control point locations. There is a reason for using each option.

– Dale

Here’s a document with the object in question: bbox.3dm (228.3 KB)

The Breps in this case are approximate models of buildings; we’re generating bounding boxes to find their heights, from which we calculate their floor counts, which we in turn use to generate previews of the buildings’ windows. Since it’s just for giving users a rough visual representation, they never needed to be too accurate, so I was using the inaccurate versions. (If there’s a way to do this that doesn’t use bounding boxes that would be totally fine, but I figured a fast bounding box would be a good way to get what we need.)

I think Faces[2].GetBoundingBox(true) uses the function of the underlying surface of the BRepFace, there is no special implementation for a trimmed face. You can extract the face, thereby converting it to a BRep of its own, then use the function with the correct result.

Is this still true? I recall writing some C++ code way back in Seattle that used only vertices, edges and trim-aware iso-curves.

While investigating @menno’s suggestion above, I learned that this isn’t just about the bounding box - if you convert one of the faces to its own Brep using BrepFace.ToBrep, and use Intersection.BrepPlane to check it for intersection with a plane above the Brep (in the region between the top of the accurate bounding box and the top of the inaccurate bounding box), there will be a hit, even though Rhino doesn’t draw anything there. But if you create the face Brep using Brep.CreateFromOffsetFace (with an offset of 0), the accurate bounding box is accurate, and there is no intersection, so I’ll just do that.

Don’t use ToBrep, use ExtractFace.

See below for a better answer…

Hi rosecodym

BrepFace.ToBrep(self: Surface) -> Brep
    Converts the surface into a Brep.

To duplicate the face with all it’s trims use:

BrepFace.DuplicateFace(self: BrepFace, duplicateMeshes: bool) -> Brep
    Duplicate a face from the brep to create new single face brep.
    duplicateMeshes: If true, shading meshes will be copied as well.
    Returns: A new single-face brep synonymous with the current Face.


Thanks, @Willem, that seems to be working great!

1 Like