Sign in to follow this  

skeletal animation structure

This topic is 2657 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

im currently implementing a skeletal animation system using bones in my engine
currently each bone holds the following information:
-a bunch of keyframes, each holding rotation, length and time
-a list with pointers to child bones
-a list of triangles
-a name

actually i want every bone to have a list of vertices that belong to it, so i can draw triangles that contain vertices from different bones
question 1: is this a good approach?
question 2: if yes, how could i implement it?

Share this post


Link to post
Share on other sites
One thing to keep in mind is that bones typically do not "own" their vertices, except maybe in very simple implementations.

It is very common for a single vertex to be effected by 2 or more bones. You need to do this to smooth the junctions between two bones otherwise your characters will look to be constructed out of rigid cardboard boxes. Each vertex might have bone weights that allow its motion to be a blend of the two bones. Consider your elbow, its not totally a part of the forearm, but it does move with it.

Its up to you if you want to deal with this issue in your implementation. I would consider letting each vertex have pointers and weights to each bone it is affected by.

Share this post


Link to post
Share on other sites
I think about bones as being essentially just a pivot point used in a rotation/translation operation. That's the simple relationship they have with individual vertices - everything else that makes up the way a skeletal structure operates only has to do with how bones interact with one-another. As far as I know, there shouldn't be any direct relationship between bones and the rendering process.

3D programs let you paint skin weights on your mesh, and any decent 3D format in a game engine should contain that information so that when bones are moved or rotated, you know which vertices are affected and how much influence the bone has over them. As karwosts said, vertices HAVE TO take influence from multiple bones or the mesh has no hope of deforming smoothly in any way.

Answer 1: No, I don't believe it is the right approach (although it's only my opinion). I would not think about rendering and bones as an intertwined process. You should always draw every vertex/face of the mesh that the camera can see, regardless of what the bones are doing or even whether any bones exist. Your mesh's skeleton is simply there to transform the locations of vertices in intricate ways.

Every bone could have a vertex list, but only for transformation. And there should be overlap there - bones with vertices in common.

I would think your renderer should be given the entire mesh and run its own abstracted optimizations regardless of anything skeleton related.

Share this post


Link to post
Share on other sites
Quote:
Original post by onfu
As far as I know, there shouldn't be any direct relationship between bones and the rendering process.


That's not always true. You're probably considering a case where all vertices are transformed on CPU and then sent to the renderer as a finished set of vertices. Another option is to upload your bone transformations into a shader and let the vertex shader handle all of the animation.

You can just upload as uniforms all of your bone matrices, let each vertex have an attribute of one or more bone indices, and let the shader do all the matrix magic. I think it should be significantly faster than transforming every vertex on the cpu every frame.

Share this post


Link to post
Share on other sites
Aha.. my bad - thanks for pointing that out :)
I'm still learning open GL, and at that, only open Gl ES in a now dated incarnation. I'm looking forward to making the jump to the magic of shaders and all that lovely optimization.

Share this post


Link to post
Share on other sites
Quote:
Original post by blubberbert
im currently implementing a skeletal animation system using bones in my engine
currently each bone holds the following information:
-a bunch of keyframes, each holding rotation, length and time

Not a good idea. Prevents your joint hierarchy from using multiple animations. Store the keyframe data in an animation class. Make that data refer back to the joints they drive.

Quote:
Original post by blubberbert
-a list with pointers to child bones

Alternatively, a single pointer to it's parent. Which will allow you to store the bones in a flattened array of bones (assuming the parent always appears before its children).

Quote:
Original post by blubberbert
-a list of triangles

Not a good idea. A better idea:

class Mesh
{
Joint* parent;
// and the rest of the mesh data
};



Quote:
Original post by blubberbert
-a name


Could be a unique ID / GUID instead. Text names are only useful for debugging reasons really - but normally you need some way to identify a specific bone to map animation data from cycles to the bones they drive.... A text nam is ok for this, an id is a little bit more efficient (but not enough to worry too much about it).

Quote:
Original post by blubberbert
question 1: is this a good approach?

No. Joint clusters are normally a better approach....


struct VertexWeight
{
int vertex;
float weight;
};
class JointCluster
{
Joint* joint;
VertexWeight vertexWeights[];
};
class SkinnedMesh
{
Vector3 vertices[];
Vector3 normals[];
int vertexIndices[];
JointCluster jointClusters[];
};


Share this post


Link to post
Share on other sites
thx to all of you for helping me out...
Quote:
Prevents your joint hierarchy from using multiple animations.

i just wanted it simple and understand the technique
Quote:
Alternatively, a single pointer to it's parent.

im using this now, in addition to a child list
Quote:
Quote:
Original post by blubberbert
-a list of triangles

Not a good idea.

again simplicity
Quote:
Could be a unique ID / GUID instead.

thats what i meant when i was talkin about a name :D
Quote:
Quote:
Original post by blubberbert
question 1: is this a good approach?

No.

thx for pointing this out i fixed it :D

edit: how do you guys quote with name? :DD

Share this post


Link to post
Share on other sites
Quote:
Original post by blubberbert
thx to all of you for helping me out...
Quote:
Prevents your joint hierarchy from using multiple animations.

i just wanted it simple and understand the technique


Are you writing an engine, or a tutorial?

Quote:
Original post by blubberbert
Quote:
Alternatively, a single pointer to it's parent.

im using this now, in addition to a child list


That structure is useful for an editor, but overkill for a game engine.

Quote:
Original post by blubberbert
Quote:
Quote:
Original post by blubberbert
-a list of triangles

Not a good idea.

again simplicity


I don't follow you. How is:

struct Joint
{
vector<Triangles> tris;
vector<Vertex> verts;
vector<KitchenSink> kitchenSinks;
Joint* parent;
Quatr rot;
Vec3 pos;
Matrix localTM;
Matrix worldTM;
};


simpler than:


struct Joint
{
Joint* parent;
Quatr rot;
Vec3 pos;
Matrix localTM;
Matrix worldTM;
};


??

Quote:
Original post by blubberbert
edit: how do you guys quote with name? :DD


replace the {}'s with square brackets:

{quote}{i}Original post by blubberbert{/i}
{/quote}

Share this post


Link to post
Share on other sites
Quote:
Original post by RobTheBloke
Are you writing an engine, or a tutorial?

simplicity makes maintenance simpler ;) and i like to do small steps rather than big ones that make my code messy ;)

Quote:
Original post by RobTheBloke
That structure is useful for an editor, but overkill for a game engine.

Is the performance hit really that bad? o0

and my classes look completly different so i wont discuss that here (actually i find mine much nicer :P) for example im using a bone-based system, rather than a joint based one :D

Share this post


Link to post
Share on other sites
Quote:
Original post by blubberbert
Quote:
Original post by RobTheBloke
Are you writing an engine, or a tutorial?

simplicity makes maintenance simpler ;) and i like to do small steps rather than big ones that make my code messy ;)

Maintenance comes after you've got the structure right. If you haven't got the structure right, you'll be doing massive refactors. The comments made about code stucture in this thread are the bits of advice you want to pay most attention too ;)

For now, keep everything seperate. i.e. classes for Joints, Skeleton, Animation, Mesh, SkinData (either as vertex index + weight pairs, or joint index + weight pairs). Avoid using composition if possible, at least until you have a clearer idea of how the data 'actually' relates to each other (rather than making those decisions based on guess work). Long term this is the best approach to take to keep the code simple and maintainable.....

Quote:
Original post by blubberbert
Quote:
Original post by RobTheBloke
That structure is useful for an editor, but overkill for a game engine.

Is the performance hit really that bad? o0


Nah. It would be fine.


Quote:
Original post by blubberbertfor example im using a bone-based system, rather than a joint based one :D


There is no difference between a bone or a joint based system. Technically speaking, 'joint' would be a more accurate description..... (It's just a rotation about a pivot point after all)

Share this post


Link to post
Share on other sites

This topic is 2657 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