Hey Enger thanx for your exploration of bounding values and their behaviour. while you are correct about the inconsistencies seen, some of these are just a product of the simply calculations available to us to return bounding box values.
in your demo, i am assuming the bounding box is being displayed on the container object rather than the cube itself. bounding boxes on containers are approximated using the bounding spheres of the contained objects, to avoid much more complex calculations. so what you are seeing is entirely correct for the implementation, even though it is approximating. basically, it is safe to assume that a bounding box will always contain the enclosed geometry, but not that it will enclose that geometry precisly. the exception to this is bounding boxes on meshes, in this case, the bounding box values should be exact for the geometry. so looking at your suggested update to bounding calculations, the problem is that this method doesn't take into account the rotation of the child object in calculating the parent bounding values. if we stick to using bounding spheres as approximations, then the rotation of the child objects never comes into consideration, as a bounding sphere will be unaffected by rotation. considering rotation in these calculations would increse the complexity of the maths to produce something that would be a significant performance hit to the engine, hence we stick with the approximation methods we have used. bounding calculations in their approximated form can still be useful, and can sometimes be improved by using centerMeshes() on the object in question to center all pivot values around their contained geometry. this gives the best possible bounding sphere values, which in turn can give the best bounding box calculations for containers. cheers Rob On Wed, Sep 23, 2009 at 7:29 PM, Li <[email protected]> wrote: > Cool, I'll take a look. > -- Rob Bateman Flash Development & Consultancy [email protected] www.infiniteturtles.co.uk www.away3d.com
