Hi Robert I ll try to explain the situation about the cloning problem. Cloning works as long as the animation manager relink target, this operation is done automatically but can be done manually. The problem Michael has encountered is that using collada reader it seems to not possible to setup callback with name suitable for the linker work. It means that without the linker the cloned update callback are not relinked and then are not updated with the result of animation. In order it works the linking operation (manually or automatically) must be executed after a deep copy of a graph. The current operation of the clone operation is to duplicate the update callback like other deep copy of objects. Using a shallow copy for a deep copy will have side effect, like animate two node instead of the copied node.
What is the linker and why ?
The linker is a nodevisitor, and is run from the animation manager (it's
an update callback) this visitor will traverse child and link what is
needed to be linked. It will do this operation if it's tagged 'need
relink', this state are set when a deep copy occur.
The linker will create the link between animation manager and Target in
update callback own by a node or other object. Those target can be
shared between different update callback (eg you can animate an osgText
or a color with the same target).
Once the linker has done its work, node or objects are updated correctly
corresponding to the animation and ready to be updated.
The linker to make its job needs a kind of convention about the update
callback name to be able to link with something eg:
If an animation contains a channel named diffuse, the update callback
that are 'compatible' with this channel will do something like that:
bool UpdateMaterial::link(osgAnimation::Channel* channel)
{
if (channel->getName().find("diffuse") != std::string::npos)
return channel->setTarget(_diffuse.get());
return false;
}
The same principle is used for other type. But if you want to skip this
behaviour and do your link by hand you will have to fix your link by
hand when you do a deep copy to maintain the shared target inside update
callback ...
That's the case of Michael, because the collada reader seems not able to
use the linker.
I hope it will helps to understand better, but if it's not enough clear
dont hesitate to ask. I will try to keep the doc of osgAnimation with
this kind of post in order people can understand how it works.
Cheers,
Cedric
-
+33 659 598 614 Cedric Pinson mailto:[email protected]
http://www.plopbyte.net
On Fri, 2009-09-25 at 16:37 +0100, Robert Osfield wrote:
> HI Michael,
>
> On Fri, Sep 25, 2009 at 4:02 PM, Michael Platings
> <[email protected]> wrote:
> > While working on osgAnimation I've encountered the following problem: if an
> > object is referenced multiple times in a scene graph, and the scene graph is
> > deep cloned, the scene graph clone will contain a different copy of that
> > object for each reference. I think so far this hasn't been a problem because
> > having multiple copies of most objects doesn't matter other than taking up
> > extra memory, but in osgAnimation meshes won't animate correctly if they're
> > not linked to the right bones so this has become an issue.
> >
> > A solution to this could be to add a map of old objects to new objects into
> > CopyOp, and in operator() only call clone() on an object if it hasn't
> > already been cloned. I've implemented this and it works fine, but before I
> > start to rely on this, would such a change be acceptable to you?
>
> This change wouldn't be a clone() method, it'd be a
> shareASingleClone() method which is a totally different thing and in
> the general case would not be safe or appropriate a replacement for
> clone().
>
> It sounds to me like osgAnimation's support for cloning is suspect, as
> one should be able to deep copy a subgraph with an animation and have
> it still work. If it's not possible then a shallow copy should be
> enforced. I'm not familiar with the internals of osgAnimation so l'll
> have to leave this to Cedric to consider.
>
> Cheers,
> Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
