Hi Ted,
I remember seeing this too. The trick is not to track the
MatrixTransform itself, but to track its child (if there is no unique
child, then reformat your graph by creating a single osg::Group below
the MatrixTransform that contains the MatrixTransform's old children).
For some reason when you setTrackNode(some MatrixTransform) the
transform's matrix is applied twice which is what I think you're seeing.
Actually I just realized that I had made a test case for this. It's
attached.
The program will show a simple scene where a blue sphere rotates around
the world origin, and a green sphere rotates around the blue sphere.
There are also a few stationary cubes just for reference (to see that
there is movement). The camera follows the green sphere with a
NodeTrackerManipulator (unless the --NoNodeTracker argument is given).
The source is commented to explain what is being demonstrated. Note that
the source comments talk about 2 bugs:
* Bug 1 is reproduced by the --TrackTransform argument. When you tell
the NodeTracker to track a transform instead of the child, the
transform's matrix seems to be applied twice, which is what I said
above. The simplest way to see this is to run with --TrackTransform, and
put your finger in the center of your screen. You'll see that the camera
is always centered at 2x the transform from the blue sphere to the green
one (the matrix, which is a translation, is applied with a factor of 2).
Without the --TrackTransform argument, you'll see that the green sphere
always stays right smack in the middle of the screen as it should.
* Bug 2 used to be reproduced by the --DoNotCreateGeometryUnderTransform
argument. When there was no geometry under the tracked node (i.e. the
tracked node has invalid bounds), then the NodeTracker seemed to revert
to looking at the world origin. This seems to have been fixed at some
point, because my test program can't reproduce it anymore.
The program has a few different command line options:
Running without --NoNodeTracker, --TrackTransform and
--DoNotCreateGeometryUnderTransform will lead to the green sphere being
tracked, and this shows normal behavior.
--MT, --PAT, --DOF : select the type of transform node used.
--NoNodeTracker : don't use a NodeTrackerManipulator - this allows you
to see what the scene looks like in general before using the other options.
--TrackTransform : reproduces bug 1 above.
--DoNotCreateGeometryUnderTransform : used to reproduce bug 2 above, but
doesn't anymore.
--AddBSphereCallback : used to be a possible workaround for bug 2...
I never went deep into the OSG code to find a real fix for these
problems, and always assumed that it was our usage of the
NodeTrackerManipulator that was wrong in these cases. I'm not so sure
anymore... Perhaps if you're inclined to debug the issue for bug 1, you
could look into it. We just found workarounds (track children of the
transform instead of the transform itself for bug 1, and the
BSphereCallback for bug 2) and used those instead.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield
*
* This application is open source and may be redistributed and/or modified
* freely and without restriction, both in commericial and non commericial
applications,
* as long as this copyright notice is maintained.
*
* This application is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/
#include osgDB/ReadFile
#include osgUtil/Optimizer
#include osg/CoordinateSystemNode
#include osg/Switch
#include osgText/Text
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/NodeTrackerManipulator
#include osgGA/StateSetManipulator
#include osg/MatrixTransform
#include osg/PositionAttitudeTransform
#include osgSim/DOFTransform
#include osg/ShapeDrawable
#include iostream
// This is a callback that will be attached to a transform which has no
// geometry under it, so that the transform itself has valid bounds (a
// small sphere at the position defined by the transform). Otherwise
// the NodeTrackerManipulator cannot follow the transform.
struct BSphereCallback : public osg::Node::ComputeBoundingSphereCallback
{
virtual osg::BoundingSphere computeBound(const osg::Node node) const
{
// If the node has no parents or if the parent is not a transform,
// return a bounding sphere that will place this node in world
// space / in the same coordinate space as the parent.
if (node.getNumParents() == 0 || node.getParent(0)-asTransform() ==
NULL)
return osg::BoundingSphere(osg::Vec3(0,0,0), .1);
