I think it would be better if it was made optional, or at least have
it explicitly switchable in a constructor. eg something like
AnimationPathCallback(AnimationPath* ap,double timeOffset=0.0,double
timeMultiplier=1.0,bool autoInitStartTime=false):
Something that would be really useful for my current project that you
may want to think about while you're working on the viewer code is to
allow a frameStamp to passed in to the viewer in the main event loop
and for it to be the one that is handed down to the Node callbacks for
the update traversal, as well as any other things that are being
evaluated like AnimationPathManipulators. osgProducer::Viewer seems to
want to keep everything internal to itself. I need to be able to sync
everything in my scene to a source of time that is external to the
scenegraph and viewer, specifically current the position of a sound
stream that may be paused or scrubbed back and forth.
Both these issues remind me of the second principal from the "Zen of Python" :-)
python -c "import this"
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
-Drew
ps Merry X-Mas
On 12/20/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Drew,
The initialize of the animation path callback the first time its
called is a deliberate attempt at making sure that the animation
starts at the beginning on the first frame.
Perhaps this reset feature needs to be made optional.
FYI, I am considering placing a start tick into osg::Timer, and
therefore the osg::Timer::instance() to help make it easier to get
time consistently across the app. I need to ponder on this issue
further before I make any changes though. I'll ping you if I do.
Robert.
On 12/20/06, Drew Whitehouse <[EMAIL PROTECTED]> wrote:
> Well I found a fix that works around my problem, it doesn't really clean
> up the behaviour that I noted in the posts above but does do what I
> want. The problem was to do with osg::AnimationPathCallback which
> calculates it values relative to the first time it's evaluated. So when
> the window was first realized the time was already > 0.0. Hence the
> _firstTime member variable was set to a number > 0.0 meaning it isn't
> evaluated at the framestamp's time for that particular frame. I get
> around it by overriding the operator() and zeroing out _firstTime;
>
> Possibly a bug ?
>
> -Drew
>
> class MyAnimationPathCallback : public osg::AnimationPathCallback
> {
>
> public:
>
> MyAnimationPathCallback(osg::AnimationPath* ap,double
> timeOffset=0.0,double timeMultiplier=1.0) :
> osg::AnimationPathCallback(ap,timeOffset,timeMultiplier) {}
>
> void operator()(osg::Node* node, osg::NodeVisitor* nv)
> {
> if (_animationPath.valid() &&
> nv->getVisitorType()==osg::NodeVisitor::UPDATE_VISITOR &&
> nv->getFrameStamp())
> {
> double time = nv->getFrameStamp()->getReferenceTime();
> _latestTime = time;
>
> if (!_pause)
> {
> // Only update _firstTime the first time, when its value
> is still DBL_MAX
> if (_firstTime==DBL_MAX) _firstTime = 0.0; //
> <<<<<<----------------------- force it to be 0.0 instead of time
> update(*node);
> }
> }
>
> // must call any nested node callbacks and continue subgraph
> traversal.
> NodeCallback::traverse(node,nv);
> }
> };
>
>
> >
> > _______________________________________________
> > osg-users mailing list
> > [email protected]
> > http://openscenegraph.net/mailman/listinfo/osg-users
> > http://www.openscenegraph.org/
> >
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
--
Drew Whitehouse
ANU Supercomputer Facility Vizlab
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
