Grasshopper Bounding Box differs greatly from Rhino Bounding Box

[rodwyll (robin_gdwl)]

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?

[martynjhogg]

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?

[rodwyll (robin_gdwl)]

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

[martynjhogg]

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

[rodwyll (robin_gdwl)]

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

[martynjhogg]

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

[rodwyll (robin_gdwl)]

Per object and Union Box produce the same output

[rodwyll (robin_gdwl)]

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

[laurent_delrieu]

Very strange
I just use Rhinocommon

GeometryBase.GetBoundingBox Method (Boolean)

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

[wim (Wim Dekeyser)]

Hi Robin -

@rodwyll

For some Geometries, the bounding box calculated in Grasshopper differs from the one I get in Rhino.

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
-wim

[maje90 (Riccardo Majewski)]

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

[rodwyll (robin_gdwl)]

@laurent_delrieu

MeanWhile I recommand transforming your Brep to a mesh

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

[inno]

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

Box generation for Brep returns unaccurate Box object

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. [image] 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 …

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:

BoundingBoxTest_Re.gh (145.9 KB)