[osg-users] Collision of Spheres
jean-sebastien.guay at cm-labs.com
Thu Sep 4 05:37:16 PDT 2008
> Also after calling getBound, Drawable objects returning a BoundingBox
> (instead of BoundingSphere) object is just a design decision, right?
> Is there anything that prevents us in having a BoundingSphere for
> Drawable objects?
The bounding volumes OSG maintains in every Node and Drawable are there
to facilitate view frustum culling. A bounding box will generally fit
closer to an object than a bounding sphere (one exception being if the
object itself is a sphere :-) ) but also costs more to test for
inclusion within the view frustum.
So the idea is that any Group's bounding sphere includes the bounding
volumes of all its children, and any Geode's bounding sphere includes
the bounding boxes of all its Drawables. While traversing the graph in
the cull traversal, the Nodes (Groups and Geodes in this example) will
be tested for inclusion in the view frustum. Since it's a sphere/frustum
test, it's pretty quick. When the test passes, the children are examined.
Once we get to a Geode and the test still passes, we want to have a
better test to make sure we aren't drawing Drawables for nothing. Since
the drawing cost is relatively high in general, it makes sense to use a
slightly more costly test and potentially avoid the high cost of drawing
the Drawable. So this is where the Drawable's bounding box is tested
against the frustum. If this final test passes, the Drawable will be put
in the render graph to be rendered in the draw traversal.
I hope this explains the general rationale for the presence of bounding
spheres on Nodes and bounding boxes on Drawables. Note that I took some
shortcuts in explaining it, but it should make it clearer.
Please see Paul's followup to my message which gives you a way of
creating a bounding sphere from your Sphere which will be identical to
the original object.
Hope this helps,
Jean-Sebastien Guay jean-sebastien.guay at cm-labs.com
More information about the osg-users