Been hacking at this on and off for awhile now, I think it’s finally ready to let out into the wild for testing… The script below attempts to quickly find the minimum volume bounding box of a given object or set of objects. As you well know this is an iterative task which usually involves a lot of testing. My goal was to have a tool which would work quickly and yield a good approximation for most objects. There are a couple of others already out there, but I wanted to write my own.
The method is a typical tree-branch “test and refine” sort of thing, it takes an initial set of samples, finds the “best candidate” and then loops through successively smaller variations around the target to refine it. A reasonably precise solution can thus be arrived at with relatively few iterations. The method I used for determining the initial sample and the refinements may seem a bit quirky though…
Note that with certain complex geometries, this strategy can be “fooled”, there may be a better branch point located somewhere between the initial samples which will not be found, so the method is not completely foolproof - but I wanted a quick one-click tool for most objects, and was willing to sacrifice the small possibility of a wrong answer on certain oddball objects for speed. Otherwise, one can work with Galapagos in Grasshopper for this type of stuff, as it is evolutionary and constantly considers a “pool” of best candidates, not just one.
Instead of hanging a lot of arcane user controls on the script, I ended up hard coding just two easy to understand options: Standard (faster) // Fine (slower) sampling and a Standard / Custom “are we done yet?” tolerance. That tolerance is not a tolerance in the real sense, it’s used to compare successive refinement steps, when the last refinement does not result in something smaller than the previous (within tolerance) the refinement is stopped. The “standard” tolerance is the file tolerance. I also threw some caps on the number of refinement steps for Standard/Fine.
The standard initial sampling setting checks the object at about 9° intervals, resulting in 1680 bounding box calculations. The fine initial sampling lowers that to 3°, making about 9 times that many… Successive refinements have each around 1320 (std) or 2640 (fine) calculations. So the Fine setting will be a lot slower for most objects. The more complex the object is the longer it will take, as Rhino takes longer to calculate each bounding box. A simple object like a box oriented at random in space takes only a second or two.
One trick: To override the artificial cap I set on the number of refinement steps (4 for standard, 9 for fine), set the tolerance to custom, then just accept the tolerance offered on the command line (it will be the file tolerance), the script will run until that tolerance is reached or 25 refinement steps have been done (the absolute cap to keep from a possible endless loop).
Anyway, FWIW - hopefully it’s useful to someone… I will get around to “Pythonizing” it in awhile for my Mac people… Note, it’s NOT been set up for drag and drop…
Edit: fixed version 1 below
QuickMinimum3DBoundingBox.rvb (8.8 KB)