Thanks for the response Rob. I think I have most of the things you mention in the list implemented now. I have the mesh, bone and animation data loaded into seperate resource classes as you suggest so that they can be used by one or more nodes in the graph without duplicating the data. I am now exposing the bones by creating an 'attachpoint' node underneath the mesh node that contains a pointer to the mesh and bone information.

My world hierarchy (scene graph) is used pretty much to just do an update of the world transforms, and I am using a quadtree for cutting down on object comparisons for rendering and collision detection. Right now the quadtree is rebuilt from the scene graph each frame, but I plan to enhance the quadtree to be dynamic and allow moving of objects from one part of the tree to another.

It sounds like you are advocating not having bones as part of the scene graph, but keeping a reference to them as part of the mesh instance node, am I correct? Then may I ask how you are currently exposing the attach points to allow a child mesh such as a weapon?

I'll have to try and get some kind of diagram together to show the relationships between all these different classes and objects. Is there a standard kind of diagram I should look at for this kind of thing?

Thanks again!

I agree with most everything Rob has to say, with one minor-ish exception: I've found it tremendously useful to be able to treat bones as first-class node citizens, at least in terms of how client code sees them. The ability to traverse the entire scene graph in a game makes it easier to treat more stuff orthogonally.

Just as an easy example, if you wanted a particle effect to be emanating from a character and anything the character is holding (like, say, if you light them on fire or electrocute them), then you can just have your effect code traverse the scene graph from the character root down to the leaf nodes. Otherwise, you'd have to have code that differentiated what you were traversing as you went.

There are other examples, but that one's the easiest to explain. :)