Grasshopper Bounding Box differs greatly from Rhino Bounding Box

For some Geometries, the bounding box calculated in Grasshopper differs from the one I get in Rhino. The one in Grasshopper is actually too big and extends past the extents of the geometry in some directions.
See these two pictures:

Bounding Box in Grasshopper

Bounding Box from Rhino

I am sure this is a known phenomenon but couldnt find a discussion about it so far.
What exactly causes the discrepancy and how do I get the accurate bounding box in Grasshopper?

Are you certain you are not referring to more than one geometry in the 2 Geometry components?

Have you tried inputting a plane into the other BoundingBox Input?

Are you certain you are not referring to more than one geometry in the 2 Geometry components?

Very certain.

The input Gemetry:

Adding Planes to the BBox component does not change the output as far as I can tell.

It also seems as though this is also not a bounding box of the Surface points/control points of the Brep

And if you re-orientate the geometry does the resulting Bounding Box still stay the same (i.e. too large)?

Re-orienting the Brep in Rhino still results in an oversized bounding Box

I’m clutching at straws now but what happens if you change the Union Box setting?

Per object and Union Box produce the same output

Here is the GH file with internalised geometry (136.5 KB)

Very strange
I just use Rhinocommon

What you get with legacy component is with accurate set to true.

private void RunScript(GeometryBase geom, bool accurate, ref object A)
    A = geom.GetBoundingBox(accurate);

And when accurate is set to false, it is the control points BoundingBox !!!

MeanWhile I recommand transforming your Brep to a mesh

1 Like

Hi Robin -

For bounding boxes that are too small - RH-31903 Bounding Box in GH is Results not accurate
For bounding boxes that are too big - RH-69696 Grasshopper: BoundingBox is larger than expected

1 Like

Changing the surface seam (to a “int” in the wireframe) a couple of times remove the problem…

This appears to be the best workaround so far even though I dislike the fact that I have to convert between geometry types.

it looks like a similar problem from this discussion (same youtrack log indeed :+1: )

in that discussion there was a polysurface that could be exploded and rejoined (solving the problem)

but here there is a single untrimmed surface, can’t explode and rejoin, so I thought applying a zero-amount transormation could work: (145.9 KB)