Sign in to follow this  

Bones as part of hierarchy, or part of mesh class?

This topic is 4132 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
Im taking this approach:
* An Entity is an implementation of a node in the scene-graph.
* An Entity can reference a Mesh
* A Mesh can therefore be referenced by several Entities and is not a node in the scene-graph.
* An Entity could also reference a Skeleton hierarchy
* A Skeleton hierarchy is separate from a Mesh and from the scene-graph
* A special type of bone is used that can link to scene-graph nodes is used at certain points (like hands, heads, etc) to attach Entities to the skeleton that lie in the scene-graph.

I am still working on this system and the implementation of that last bullet point is unclear at the moment, but that may be of some help.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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. :)

Share this post


Link to post
Share on other sites

This topic is 4132 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this