From Kristofer Tingdahl,"we have a bunch of classes that inherit osg::Node, and they...
authorRobert OSFIELD <robert.osfield@gmail.com>
Thu, 23 Jan 2014 16:48:29 +0000 (16:48 +0000)
committerRobert OSFIELD <robert.osfield@gmail.com>
Thu, 23 Jan 2014 16:48:29 +0000 (16:48 +0000)
commitc02fabe615fe4a300b56b89a95e077564133ca3e
treec212d80d73cc3bafe0c90aff904ab4e3bf046c30
parente6f9e65f9185c21be968c230ed20dcfc1526128b
From Kristofer Tingdahl,"we have a bunch of classes that inherit osg::Node, and they create their own, internal geometry which is passed into the render bucket at the cull-traversal. Last week, we realised that these classes are not accounted for when doing an ComputeBoundVisitor- traversal, as there is no specialization in ComputeBoundVisitor for them.

One solution is naturally to create a new class that would inherit the osg::ComputeBoundVisitor, and use that. I don't like that idea as the ComputeBoundVisitor does actually have what I need - it is only hidden in a protected function.

I am therefor suggesting a slight generalization of the ComputeBoundVisitor with the attached patch, which is tested.

The patch has two parts:
we add applyBBox() so that one can use that in a customized traverse-function and add a bbox to the visitor. I considered calling this function expandByBBox(), but I though  applyBBox was better.
The MatrixStack is made available to the outside world. That enables a traverse-function to do whatever it wishes.
I do actually only need one of the two, as I can implement what I wish either way, but adding getMatrixStack() will make more generic expansions possible.
"

From Robert Osfield, changed the name of the new applyBBox(..) method to applyBoundingBox(..) to keep it's naming more consistent with the rest of the OSG.
include/osg/ComputeBoundsVisitor
src/osg/ComputeBoundsVisitor.cpp