Hi Michael, In fact my approach have the side effect that it could call twice nested callback attached to the UpdateBone. I will use your fix.
Cheers, Cedric - +33 659 598 614 Cedric Pinson mailto:[email protected] http://www.plopbyte.net On Thu, 2009-08-27 at 12:42 +0200, Cedric Pinson wrote: > Hi Michael, > > Another solution could be to run the update of bone in the skeleton > update callback, and in order to avoid twice update of Bone (from the > Skeleton UpdateCallback and by the default UpdateVisitor), it will need > to add a check with a framestamp in UpdateBone update callback. Then it > will be updated once, but called twice. > It's not ideal but could be another solution. > > What do you think ? > > Cheers, > Cedric > > - > +33 659 598 614 Cedric Pinson mailto:[email protected] > http://www.plopbyte.net > > > On Tue, 2009-08-11 at 16:37 +0100, Michael Platings wrote: > > When jumping around in time with a skinned model, I found that the > > model was displaying the transformations from the previous frame. The > > reason for this was UpdateSkeleton would update the bone matrices > > before UpdateBone::update had been called. > > It seems that the intention for this was to ensure the matrices were > > updated before any RigGeometry could be updated. However, it also > > means that the bones will always be in the position for the previous > > frame. > > I looked into trying to force the bones to update first but such an > > approach introduced complexity and opened up the possibility of > > causing other more subtle errors. Instead, I believe the most elegant > > solution is to simply require that bones be ordered before other > > objects within the child list. > > > > I've moved the matrix updating from UpdateSkeleton to UpdateBone. > > UpdateSkeleton now merely checks that Bones appear before other > > children and issues a warning if this isn't the case. > > > > ______________________________________________________________________ > > This email and any files transmitted with it are confidential and > > intended solely for the use of the individual or entity to whom they > > are addressed. If you have received this email in error please notify > > the system manager. > > > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > _______________________________________________ > > osg-submissions mailing list > > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
