I’ve been testing panel layouts across five Blender versions and the thing that kept biting me was bound_box.
Build geometry and then measure it in the same session, and bound_box hands you the shape from before the edit. Below is a default 2m cube run through my plating code at seed 7, 69 plates. The red cage is drawn at the numbers bound_box gave me straight afterwards. Everything crossing that line is geometry it says isn’t there.
It reported 2.0 by 2.0 by 2.0 while the real vertices spanned 2.0978 by 2.1192 by 2.2180. So the object is 10.9 percent taller than its own bounding box says, and the block standing over the lid accounts for 19cm of that. Every gate I had that read bounds was quietly wrong because of it, and none of them complained.
Calling view_layer.update() fixes it. Deriving the bounds from vertex positions doesn’t need fixing at all, since there’s no cache to go stale, and that’s where I ended up.
Worth knowing if you validate scale in a script, or check whether something is sitting on the floor.
There’s a nasty wrinkle as well, and this one cost me an evening. Objects linked with bpy.data.objects.new() recompute their box on demand, while operator-created ones cache. So a regression test can pass against this bug depending on how you built the object in the test. Mine did exactly that. I had a green test, a real defect, and no way to tell them apart until I rebuilt the fixture with primitive_cube_add.
Same figures on 4.5.12, 5.0.1 and 5.2.0, re-run this morning before posting. If you want to see it on your own machine: add a cube, read obj.bound_box[0] once to prime it, edit the mesh, then read the box and the vertex positions and compare.
I’ve run into this kind of Blender issue before, and the confusing part is that the geometry itself can be correct while the value you’re reading is stale.
If obj.bound_box was accessed before the mesh was modified, it looks like the cached bounding box may not be getting refreshed immediately for objects created through operators. That would explain why the reported dimensions stay at 2 × 2 × 2 even though the vertices have moved beyond those limits.
The view_layer.update() workaround makes sense, but I’d still prefer calculating the bounds directly from the evaluated vertex coordinates when the exact geometry matters. That removes the dependency on whether Blender’s cached bounds have been refreshed.
The difference between bpy.data.objects.new() and primitive_cube_add() is especially interesting. I’d definitely include both creation methods in a regression test, otherwise it’s very easy to get a passing test that simply doesn’t reproduce the real-world case.
One correction, and it runs backwards from what you’d guess. My first fixture used bpy.data.objects.new() and it passed with the bug still in, nothing stale to catch. It went red only once I rebuilt it with primitive_cube_add.
Before you lean on the data route: on 3.6.23 it goes stale too, depending on whether anything read a float out of the box first. obj.bound_box[0] is lazy and leaves it current. Add [2], or read the dimensions, and you get 2.0 back while the verts span 2.218. From 4.2.23 up it stays current.
So yes to your vertex loop. It doesn’t depend on who read what first.
