Hi All,
One of the items I've been working towards over the last week has been
to add interactive volume region editing, my plan was to use the tab
box manipulator from osgManipulator to allow me to adjust the
osgVolume::VolumeTile's Locator matrix. Alas digging into
osgManipulator I found it was tied to just updating the
osgManipulator::Selection node, and wasn't extensible to handle any
other transform node types let alone a specialist osgVolume::Locator.
Other issues I came across was the osgManipulator required the
application to have it's own event handling that does the dragger
picking and passing of events to the dragger, and the coordination of
the updates from draggers to the selection nodes via a global
osgManager::ComandManager. Both these elements meant that one
couldn't just add a node to the scene graph and have a dragger - the
application itself would have to have lots of hardwiring to be able to
use the draggers.
So this week I rather than just hack a bit of extensibility into
Dragger to allow me to observer changes to the Dragger, I took the
opportunity to refactor osgManipulator to make it simpler to use, more
encapsulated, easier to use with conventional nodes and more
extensible. These changes are now checked into OSG svn/trunk, these
do change the API a bit so does break the strict API compatibility
with previous rev's of osgManipulator, but to enable better backwards
compatibility I've kept around two now redundant classes
(CommandManager and Selection.)
For current users of osgManipulator the key differences are:
1) osgManipulator::Dragger now has it's own ability to catch mouse
events, so there is no need to have your own event handler
to do intersection testing and passing of events to the
draggers. To enable a Dragger to set actively consuming events you
do dragger->setHandleEvents(true) - you can use this method to
toggle on/off the event handling as you wish.
2) osgManipulator::Dragger now maintains a list of Constaints and
DraggerCallbacks, replacing the maps previously held in
CommandManager.
3) osgManipulator::Dragger now can pass updates via new
DraggerCallback interface to 3rd party code, so osgManipulator is no
longer tied to only updating a osgManipulator specialist node
(which was osgManipulator::Selection node.)
4) osgManipulator::Dragger now can update MatrixTransform nodes
directly, so the CommmandManager is no longer required, and
since it now can work on MatrixTransform nodes it also makes
Selection node redundant.
5) osgManipulator::Selection has now become just a typedef
osg::MatrixTransform, and is only kept around for backwards
compatibility. It's now official deprecated.
6) osgManipulator::CommandManager has now just become a shell class
that maintains most of the old public interface but stores no
data locally, instead just attaching Constraints and Selection
nodes directly to the Dragger. In user code it's best now just to
just set up your draggers and transform nodes directly, but
I've just kep this CommandManager class around to help out with
porting.
To illustrate the new set of draggers have a review of one of the key
funcitons in the osgmanipulator.cpp example, the new code looks like,
note the only custom node is the Dragger itself:
osg::Node* addDraggerToScene(osg::Node* scene, const std::string& name)
{
scene->getOrCreateStateSet()->setMode(GL_NORMALIZE,
osg::StateAttribute::ON);
osg::MatrixTransform* selection = new osg::MatrixTransform;
selection->addChild(scene);
osgManipulator::Dragger* dragger = createDragger(name);
dragger->setHandleEvents(true);
osg::Group* root = new osg::Group;
root->addChild(dragger);
root->addChild(selection);
float scale = scene->getBound().radius() * 1.6;
dragger->setMatrix(osg::Matrix::scale(scale, scale, scale) *
osg::Matrix::translate(scene->getBound().center()));
dragger->addTransformUpdating(selection);
return root;
}
Where as the previous incarnation of osgmanipulator looked like (note
the now redundant Selection and CommandManager usage):
osg::Node* addDraggerToScene(osg::Node* scene,
osgManipulator::CommandManager* cmdMgr, const std::string& name)
{
scene->getOrCreateStateSet()->setMode(GL_NORMALIZE,
osg::StateAttribute::ON);
osgManipulator::Selection* selection = new osgManipulator::Selection;
selection->addChild(scene);
osgManipulator::Dragger* dragger = createDragger(name);
osg::Group* root = new osg::Group;
root->addChild(dragger);
root->addChild(selection);
root->addChild(createHUD());
float scale = scene->getBound().radius() * 1.6;
dragger->setMatrix(osg::Matrix::scale(scale, scale, scale) *
osg::Matrix::translate(scene->getBound().center()));
cmdMgr->connect(*dragger, *selection);
return root;
}
Not too many lines of code different, but crucially no global objects
like CommandManager, and now specialist classes to do the transform
tracking. The other big change is that you don't need to custom event
handler. The new osgmanipulator is now just 303 lines long, while the
previously it took 439 lines of code.
I would very much appreciate some testing and feedback from existing
osgManipulator users. I'd also like feedback on whether we should
remove the headers and class definitions for Selection and
CommandManager - I'm in two minds as these classes are now redundant
and potentially confusing for new users of osgManipulator, vs making
it a bit easier to existing users to key there existing apps compiling
with svn/trunk and 2.10. There is a chance that my to
CommandManager/Selection changes won't compile with existing users
though and if this is the case then keeping them around doesn't help
any. All in all, I need some directly testing and feedback.
Cheers
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
