[osg-users] Animating articulated osg models

[Mike Metcalf]

(NOTE: I posted this question directly to the forum some time ago, but my messages sit under moderation for too long to be useful. I decided to attempt to post via the mailing list)

We are developing an osg-based application which requires the use of various vehicle models, which we have modeled at several levels-of-detail.

The highest level of detail for each of these vehicle models include articulated parts such as turrets that move in azimuth and guns that move in elevation (e.g. tanks).

Because the osg file is somewhat substantial, we do not want to load the same osg file for each entity in our simulation. If we had ten tanks to render, loading ten duplicate osg files wouldn't be so bad, but we need to support rendering dozens of different vehicle types with hundreds upon hundreds of vehicles of each type.

Therefore we took the advice found in the OpenSceneGraph beginners guide (page 101 and 102) and have implemented a system whereby one detailed osg model is made the shared child of dozens or hundreds of parents (each of which is an osg::MatrixTransformation). During execution, we simply update the rotate/translation or these MatrixTransformation nodes and our single model is displayed in dozens or hundreds of unique locations and orientations.

But we also need this single model to be *posed* in a different way for each of the represented entities: Tank1's turret and gun are at different angles than Tank2's turret and gun, etc.

So I have attempted to implement UpdateCallbacks in order to *pose* my tank model each time it needs to be rendered for a given entity.

On the matrixTransform for each entity, I call setUserData with some entity-specific data, then call setUpdateCallback with a callback object descended from NodeCallback:

class articulatedIconCallback : public osg::NodeCallback

{

  public:

   // called every time a player's matrixTransform node is updated during update traversal

   virtual void operator()(osg::Node* n, osg::NodeVisitor* nv)

   {

      osg::ref_ptr<articulatedIconDataType> iconData = dynamic_cast<articulatedIconDataType*> ( n->getUserData() );

      if (iconData)

      {

         iconData->updateIcon();

      }

      traverse(n,nv);

   }

};

In my implementation of UpdateIcon(), the code retrieves the entity-specific data (MatrixTransformation->getUserData) in order to determine the turret and gun angles for that unique player, then proceeds to descend into the node hierarchy of the osg model, looking for nodes with specific names which mark them as the articulation point. For instance we look for a matrix transform node (internal to the osg model hierarchy) with the name "TURRET_AZIMUTH". If we find it, we set the matrix accordingly. We carry on and do the same for gun elevation and other articulated parts.

The problem is that this appears to not be working. All the player models are positioned and oriented correctly, but each and every player which shares an osg model shares the same turret/gun angles, as if the last player processed is applying his data to all the players.

In general, am I correct in expecting setUpdateCallback to behave this way? Is there something specific I need to do to in order for this approach to work? Any help will be greatly appreciated!

-Mike

[Aurelien Albert]

Hi,

> In general, am I correct in expecting setUpdateCallback to behave this way?

=> yes

In the situation you describe, the osg model is shared against multiple parent, event if there is a specific matrix transform :

Common parent
|
|-> Matrix_1 -> Osg_Model
|
|-> Matrix_2 -> Osg_Model
|
|-> Matrix_3 -> Osg_Model
|
|-> Matrix_n -> Osg_Model

the "Osg_Model" node is displayed n times in your scene

All "Matrix_1" to "Matrix_n" nodes allow to draw the multiples "Osg_Model" at different places, but there is only one "Osg_Model" instance in memory, so if your update callback update a node which is below "Osg_Model" in the hierarchy, all update callbacks edit the same node.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=51756#51756





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Martin Scheffler]

Hi Mike,

to allow articulated parts on instanced models you can use bone deformation instead of DOF transforms. This changes the way the tanks have to be modelled, but it allows you to render all tanks in one draw call. You can use osgAnimation or osgCal to do the bone deformation.

Cheers,
Martin

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=51757#51757

[Paweł Księżopolski]

Hi Mike,

As Aurelien said, you are sharing the same nodes between instances,
so when you update one turret rotation - you update all of them
( for the same type of tank ).

You need to make a copy of the osg file, but this copy
should share statesets, textures and geometries
( only osg nodes should be deep copied ).

In our system for each type of the vehicle we use
a model prototype - the file loaded from osg file.
When we need to create an instance, we do :

osg::Node* modelInstance = dynamic_cast<osg::Node*>( modelPrototype->clone(osg::CopyOp::DEEP_COPY_NODES) );

The nodes are cloned ( deep copy ), but drawables and statesets are the same.
Now you can connect update callbacks to nodes.

Paweł Księżopolski

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=51759#51759

[Mike Metcalf]

(I had attempted to send this response via the mailing list but it appears I've done something incorrectly. I'll post it here, but because I am moderated, you quite likely won't see my thanks for quite a while.)

Aurelien,

Thank you for your feedback. I have a better understanding of why my approach was not working.

---

Martin,

I will try the bone deformation approach soon, but I will likely have to retool much of my osg model-handling code to make it work. It sounds like a good approach for when we implement animated lifeforms. I appreciate your suggestion.

---

Pawel,

With this information, I should be able to get my original code working like I intended.

Dziękuję bardzo!

------------------
Read this topic online here:

http://forum.openscenegraph.org/viewtopic.php?p=51763#51763