I would prefer [[xmin,ymin,zmin], [xmax,ymax,zmas]] because it holds per vertex information together. But it would be even more useful to directly move the information to the new builtin Vector class. So [minVector,maxVector] seems the best solution to me.
> Or perhaps, diagonally opposite corners of the bounding box. I am not >sure which is more useful, but then again, I have not been writing collision >detection code.
These two vertices ARE the opposite corners of the bounding box!
>Anyone have any thoughts?
>( we can argue about the name too! I vote for getMinMaxBounds() )[/quote]
This issue came up because I was new to blender and I expected the existent function "Blender.Object.getBoundBox()" to return the MinMax bounds in world space, in fact the BoundingBox coordinates of the object as they are visible in the scene. I found out that the bounding box is drawn the right way, but when asking for its coordinates with Python, those values were pretty different.
I would encourage to move a getBoundBox() to the NMesh class (and any other classes which represent visible objects in a scene; subdivs, etc.) too which can return the untransformed mesh extends in local space - as you get them currently. When you ask its transformation object node for the bounding box you get the two corner vertices as described above with the coordinates as you see them in 3D view.
Currently I'm waiting everyday for the new Python API documentation to come out and the games API docs as well. Maybe then all weapons for effective intersection tasks are already included. I'm very excited about that!