Robert,
Nevermind, I found it. :) Would you consider accepting a patch that
introduces the option to disable this feature via some method:
myTrackManip->setContinuousUpdate()
...and perhaps other options for applying modifiers to the amount of
transformation taking place; i.e.:
myTrackManip->setTransformSensitivity()
Perhaps these belong in MatrixManipulator instead, so that all of them
could benefit? I'd be willing to try this, after I finish the
AnimationRecordPath thing... :)
On Fri, 2007-06-08 at 11:47 -0400, Jeremy L. Moles wrote:
> On Fri, 2007-06-08 at 16:27 +0100, Robert Osfield wrote:
> > Hi Jeremy,
> >
> > All of manipulators will work with all of the osgViewer, they aren't
> > platform specific. The request* methods are really just hints to the
> > viewer. Most games will being running a frame loop and won't be event
> > driven so you won't ever be turning on/off the rendering, this means
> > that such viewers will just ignore the request as the frame will be
> > updated anyway. You'll see the vast majority of examples work with a
> > frame loop.
>
> Is there a way, then, to disable the continuous "trajectory" (for lack
> of a better descriptive term) feature of the TrackballManipulator then?
> Or does this go against what it's meant to do in the first place? I'd
> like to leverage the existing code for sure, but perhaps this is a job
> for a different manipulator?
>
> > Robert.
> >
> > On 6/8/07, Jeremy L. Moles <[EMAIL PROTECTED]> wrote:
> > > I'm trying to put together a standard "3rd Person" camera setup, and it
> > > appears that the NodeTrackerManipulator demonstrated in osgsimulation is
> > > a great place to begin.
> > >
> > > Am I correct in my assumption that this Manipulator can be made to
> > > instruct a Camera to follow whatever Node it is attched to as the object
> > > is translated? I haven't had a chance to test this out yet, and I'm not
> > > sure if the planet is spinning or the cessna is moving in
> > > osgsimulation. :)
> > >
> > > My main question, however, is a request for any existing solutions to
> > > this before I being reinventing the wheel--as educational as that may
> > > be. :) I guess it's a tough thing to answer, since the Manipulator
> > > classes seem to be quite dependent on the windowing system/viewer in
> > > question (in my case, SDL). However, any advice or success stories would
> > > be helpful. The one thing in particular I'll be interested in doing is
> > > disabling the requestContinuousUpdate() feature of the
> > > TrackballManipulator (which the NodeTrackerManipulator appears to use
> > > internally) so that it behaves as close to modern "game cameras" as
> > > possible...
> > >
> > > _______________________________________________
> > > osg-users mailing list
> > > osg-users@openscenegraph.net
> > > http://openscenegraph.net/mailman/listinfo/osg-users
> > > http://www.openscenegraph.org/
> > >
> > _______________________________________________
> > osg-users mailing list
> > osg-users@openscenegraph.net
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
>
> _______________________________________________
> osg-users mailing list
> osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
