Wish for an "Official" Minimal bounding box with multithreading

I find that the search for a minimal bounding has many applications like finding a relevant local reference frame for oddly shaped objects.
There are a few scripts out there, and even a “MinBBox” component which I don’t know who did it because there’s no metadata with this info.

Yet, I find that it should be promoted to an actual “official”, optimized component, with multithreading capabilities because this typically slows my definitions quite a lot.

Is this version fast enough for your usecase? It runs in parallel and is quite “battle tested”. Helvetosaur also have a very good MinBB component (sometimes slightly tighter end result, but only very little) but I use this one for its speed.

minimalboundingbox-csharp_R6.gh (96.7 KB)

// Rolf

We* don’t actually have a 100% reliable algorithm for this. It’s doable for simple shapes with planar convex hulls, but as soon as the hull contains curved regions it becomes a guessing game.

Still, a solution which gets close is probably better than nothing at all.

* Actually I’ll have to ask if anyone else at McNeel has any ideas.

1 Like

Hi Rolf,

Thanks for this.
I notice that you mesh your Brep before the Min. Bbox component.
Rhino bounding boxes are sometimes wrong with Polysurfaces, with large chunks protruding out, and the result is more accurate if the Polysurface is meshed.
Is that why you did that ?

I tested your script against the one I grabbed somewhere, and indeed, yours is faster and more accurate. Thanks a lot !

I see there are other ones out there ; maybe we could organize some kind of competition :wink:

I didn’t make a component - just a script which runs in Rhino without GH. And yes, it’s not the fastest because it’s not multithreaded.

Is this in any way related to the idea of principal axis?


In general the minimal bounding box wouldn’t align with the principal axes, because it is only based on shape, not mass distribution.
For example, attaching a thin spike to a solid like this would significantly alter the minimal bounding box, but the principal axes wouldn’t change much


Well, there goes that idea.

I think the conversion was simply because of the better speed after converting to mesh. I get 83ms for the mesh, while it takes 2.5sec for the brep (on my 6 core / 12 thread machine).

We were playing around with this quite a bit some time ago so there should be several threads left behind where we were trying different things.

The component I posted above was the end result of attempting to make a parallel C# version of a Python component originally created by Ilja Asanovic (credit where credit is due)*. At the end of this looong thread you’ll find the posted MinDB component. I also added quite elaborate comments to the code explaining how it does its thing:

// Rolf

  • Original code by Ilja Asanovic, translated to C# and converted to parallel execution. The info box below can be found if double clicking the component:


Hi all,

I agree, a proper command/GH component would be a great thing!

@DavidRutten: what about this paper: https://pdfs.semanticscholar.org/a76f/7da5f8bae7b1fb4e85a65bd3812920c6d142.pdf

It seems to rely on a preexisting 3D convex hull algorithm, and even then only handles points, not smoothly curved brep faces and edges. Did you see the runtimes? between 1 and 10 seconds per shape, and they’re not even that complicated. Also the links in the paper pointing to source and demo are dead by now.

It may well get us 99% of the way there, hard to tell before implementing it.