Is there an easy method in Rhino and/or Grasshopper to find the smallest possible bounding box for a solid?
My application is for CNC carving. I’d like to be able to quickly find out the minimum size stock, particularly thickness, needed for objects, often many objects.
Currently I figure this out by manually rotating parts and eyeballing how close they are to being as flat as possible relative to each cplane in each 2d view port.
Surely there’s a better way?
Here’s also a full topic dedicated to different solutions with some nice speed comparisons by @RIL
I have script for orienting brep/solid in such a way that its bounding box has minimum “Z-height” - it is useful for 3D printing (on SolidScape printers) since in most cases this will reduce printing time.
Since you need minimum bounding box (minimum diagonal) I added few lines of code to find position (by rotating it around Z-axis) where resulting box will be minimum.
Result is approximate based on incremental angle (number of steps per 180degree, 180 steps will give us incremental angle of 1 degree)…
MinimumBB.gh (28.7 KB)
Thanks!
Actually, I’d love the original version. Thickness is my primary concern too. I CNC carve stuff out of slabs of foam and wood.
It seems like the other definitions and scripts above tend to produce boxes that find something close to minimum Z thickness, but not exactly and not always.
The script should always return brep oriented in a such way that it has minimum “Z-thickness” (with respect to number of steps by which we dived angle of 180 degree, 180 steps should work ok).
Or you have some solids where the script is not working correctly (not orienting brep in Minimum-Z manner)?
Haven’t tried yours yet. I was talking about links above. One of them has three different GH definitions that produce somewhat variable results. Thickness differences of about 5% between them.
Hi,
Is possible to modify your C# code and replace the Brep entry with a mesh one?
Thanks
Here is version where input object can be any geometry type
MinimumBB-2.gh (13.4 KB)
Nice. I modified a little bit your definition to work also with closed curves.
MinimumBB-3.gh (17.4 KB)
This is really useful! Thanks.
A nice addition would be an output that is the applied Translation, T, so this could be used on other associated objects.
I’ll be trying this out soon. Thanks!
Hello everyone and thank you for all these interesting insights.
Below is my 2cents on this discussion.
𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗜 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗱
My implementation in the ATk MinBBox component uses a multi-strategy approach:
Principal Component Analysis for initial orientation estimates
Special case detection for geometric primitives (triangles, rectangles, trapezoids)
Advanced angle-space optimisation algorithms
Intelligent caching of previous calculations
The results have been validated: when compared to other available components, ATk MinBBox consistently offers an excellent balance between computation speed and minimum volume optimisation.
𝗜𝘀 𝗶𝘁 𝘁𝗵𝗲 𝗯𝗲𝘀𝘁 𝗽𝗼𝘀𝘀𝗶𝗯𝗹𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗲𝘃𝗲𝗿? 𝗠𝗮𝘆𝗯𝗲 𝗻𝗼𝘁 
Computational geometry is a field where perfection is elusive. But for my practical architectural needs, it represents the right compromise between theoretical optimisation and real-world usability.
This new component will be included in the upcoming ATk v1.3.3 release, and I will share more info about it.
Wow - this would be so helpful for UV box / cylinder mapping with Grasshopper - when do you think might this be available Luciano ?
i just tried to compare with pOd minimum bounding box of the same closed curve geometry (circle & one closed random curve)
Cool! but it would be useful to all of us if I could enable profiler to find out any bottlenecks and to test different type of geometries curve (2D/3D) different 3D shapes (eventually also the link to food4rhino) 
I believe in a few weeks (it is a hectic period) …stay tuned!
Hi @Max3,
Currently in Rhino 8 there is a component to compute the 3D Convex Hull.
This can be used to approximate this box.
@RadovanG definition does a great job but if steps is set to 180 it took 16s to compute.
The difference on precision may not be relevant, but I think the attached definition resulting box (bottom right) is better oriented and is faster to compute.
Is also nice that is always the same and the axis on the the resulting box are always sorted by its magnitude, so you should get a box that x is the smaller size of the box and z the largest.
Values at the right are:
On the other size the pure rotating calipers algorithm (the script) may be faster if the convex hull has more faces than (anglesX * anglesY) + anglesZ, maybe not exactly at this point but somewhere near this threshold, but this is hard to predict.
So for a rough approximation with a low value for steps the previous C# script may be faster and the result quite good. But I would say always less precise.
I basically borrowed the idea used in the script, but instead of brute force the steps it uses only the convex hull faces.
thanks, looking forward to trying this version out.
And while I’m here, another type of minimal box that would be useful for fabricators would be to find the flattest box, rather than the one with the smallest volume.
Has anyone attempted that? the box that an object fits in that achieves the smallest possible dimension on one axis?
Hard to resist this classic old chestnut. This uses Galapagos to minimize the diagonal length, though could just as well use minimum volume (BoxProp ‘V’ output). Speed depends on the number of decimal places set for the ‘Azimuth’ and ‘Altitude’ sliders. One decimal place is very quick, though you get slightly different results on each try.
This version tries to do that by using the shortest edge of the BBox… but the results puzzle me? Three example breps (identical copies) have different shortest edge lengths. Does their orientation affect the results? Why? 
Slower than using diagonal length or volume.
Hi @Joseph_Oster,
While doing this exercise I notice that, and is because we have a bug with Breps that we’re never meshed before the box is computed. The resulting box is not accurate in this case.
I pushed a fix for that on 8.21.
