Hi All, I was just curious how most people handle bones in models. At the moment I have the bone hierarchy as a member of the mesh class. Mesh is a sub-class of node which can have child nodes, so nodes can be in a hierarchy (the scene graph). I was wondering if people use this approach (ie to keep the bones seperate from the scene graph hierarchy) or if they treat bone as a sub-class of node and continue the node hierarchy down from mesh into the bones. Thanks Rael

Quote:Original post by hplus0603
OGRE treats bones as separate from nodes. However, both are able to be "parents" of nodes, so that you can put a sword in the hand of a character, for example. I think that's a pretty reasonable solution.

Not sure I fully understand how this works. So they inherit from a common root class? A mesh node has a list of child node objects and a seperate list of child bone objects yet the bone objects can contain meshes within them, or is there just one list of children which can be either nodes or bones? Do the bones that are children or grandchildren of a mesh have a reference to the mesh further up the hierarchy that they belong to?

Thanks for any clarification.

Hello Raeldor,

in my engine (http://gregoryjan.free.fr) I m using bones and they are present directly into my scene tree as specific nodes.

I explain:
Scene tree contains 1 root node with several children nodes
each node is an instance of 1 class inherited from the basic node's class

mesh is a specific node inherited from the basic node
bone is a specific node inherited from the basic node

mesh node can be either static or skinned
if mesh is skinned then it contains 1 skeleton and 1 skin
-this skeleton is in fact the root bone's node
-the skin is just additional datas to bind vertices to good bones

so all nodes are animated (by keyframe for example)
when I render 1 skinned mesh then I have just to take animated matrices of each bones nodes of its skeleton to apply it on its skin.

Is it clear ?

Hi grg,

Thanks for the reply. So can a mesh be a child of a bone in your design to attach a weapon to a hand for example?

Thanks

I agree that the mesh shouldn't be part of the scene graph. It may be bound to a node in the graph, but it isn't a node itself. The bones can then also just be specialized graph nodes.

I think I have a solution for this, but I am not sure it's the best way of handling it. The node class has the 'children' property which contains a list of the child nodes. A 'mesh' class is sub-classed from 'node' and has the 'children' property and the additional 'bones' property which holds the hierarchical bones for a skeletel mesh. It also contains an additional 'boneshash' which is a hash table of bones by name for lookup.

Because the bones are not nodes they cannot be part of the scene graph (see my comments later). I then created an 'attachpoint' class sub-classed from node which has a reference to the mesh (it's parent) and also has a 'bonename' property. I can then attach another mesh to this node. When the recursive 'updateworldtransform' is called on the nodes, this method is overridden for the 'attachpoint' class and multiplies the bone matrix with it's parent matrix because passing down recursively to it's children.

Anyways, it seems to work. The bit I am not sure about though, is should I make the bones nodes in the scene graph? The 'updateskinnedmesh' method in my 'mesh' class loops through the bones to update the bone matrices and then loops through the vertices and pulls out the correct bone matrix to transform it by to write it into the new mesh. It seems if the bones were child nodes in the scene graph this would be much harder since I would need to check see what the node type was when recursively updating the matrices and also I would not have the hash table of bone names for lookup.

Any advice on the best course of action would be great.

Thanks

Personally i prefer to distinguish the difference between a Scenegraph ala Maya/Max etc, and a scenegraph used in a game. They are largely two different things, and used for very different purposes. I think for that reason it's worth breaking down the parts into seperate concepts :

The Character Models

* Treat Bones as a single bone hierarchy.
* Store meshes in a seperate list.
* Use an instance structure to bind a mesh, bone and material together. This allows you to instance the same geometry mesh with different parents, and different shaders applied.
* Expose 'Tag' bones from the model to indicate bones for weapon placements, character roots etc. The Scenegraph for your game only really needs to worry about these, not say every bone down to the small toe... ;)
* Treating the mesh as a node is a really bad idea imo. It's far too limiting in my experiance.

As a small aside, I personally make ALL model and animation data loaded constant. This forces you to create a 2nd class to store all data that changes on the model when animating. Ultimately doing this will allow you to create multiple instances of the same character without duplicating vast amounts of data. In general then, I store all loaded models in a flat list.

The World Hierarchy

* Essentially this maintains instances of models
* Transform Hierarchies (ala bone hierarchies) may be useful, but only really for situations where say you have characters in/on a vehicle etc.
* Objects should be able to be attached to the world, or to a tag bone from a model instance (ie, weapon on floor, or a weapon in the hand).

The spatial hierarchy

Whether you use a quad tree, oct-tree or other is largely up to you. Basically you need a way to determine what to render, and what to update. So in a sense this is the structure that helps you to determine what to update within the world hierarchy.