The output in the command line window is as follow:
Bounding box: -10 to 10, -10 to 10, -10 to 10
Bounding box: -10 to 10, -10 to 10, -5 to 15
Bounding box: -10 to 10, -10 to 10, -10 to 15
As you can see, the bounding box of the resulting brep is in z direction -10 to 15, which is definitely not right! The result in 3D looks as expected. (I moved the 2 spheres afterwards to see the result, which is the red geometry)
Oh… Well, you could, in this specific case, maybe call bool ShrinkSurface( ON_BrepFace& face, int DisableSide=0) on the Brep. But it is not a general solution.
Also, I seem to recall that GetTightBoundingBox is calculated based on the (render?) mesh of the Brep if it is present. It may also be worthwile to see if calling const ON_Mesh* Mesh( ON::mesh_type mesh_type ) with one of the mesh types improves the behavior of GetTightBoundingBox, as it should create a mesh and store it with the Brep object.
The mesh types are below, but I don’t know which type should be used.
Bounding box values are lazily calculated. That is, they are not calculated until they are needed, and then they are cached on the object so they can be retrieved quickly.
For a CRhinoBrepObject, the tight bounding box is based on the object display (render) mesh. If you needed the tight bounding box for any Rhino object, use RhinoGetTightBoundingBox as this function will automatically create the display mesh if needed.
For ON_Brep, a bounding box is never calculated until it is added to the document. Thus, if you need a tight bounding box, then you will need to calculate it on your own.
Here is how you can calculate the tight bounding box for any ON_Brep:
ON_Brep* brep = CreateMyBrep();
const ON_MeshParameters& mp = context.m_doc.Properties().RenderMeshParameters();
const int mesh_count = brep->CreateMesh(mp, meshes );
if (0 != mesh_count)
for (int i = 0; i < mesh_count; i++)
if (0 != meshes[i])
delete meshes[i]; // Don't leak...
my first thought was, that’s crazy!! I’m shocked!
There is no hint in the documentation that the bounding box is absolute useless.
To cache the bounding box information or to calculate it on demand is a good thing, but to give back an invalid result is nothing i would like to have. I think that’s something like the “dirty cow” in rhino - everyone knows it but no one solves it!