Sign in to follow this  

Skeletal Animation: keyframes per joint or per skeleton?

This topic is 2953 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, It's a short question: I'm implementing skeletal animation. I started with a concept that for each joint in skeleton, keyframes are synchronous. This implies that there are same amounts of keyframes per joint, so I can hold the animations in an array of pairs <vector, quaternion> indexed with joint-IDs. Now, while writing a ms3d model loader I noticed, that Milkshape allows different amounts of asynchronous keyframe-lists for each joint. After a while thinking, the second approach seems to me to be more reasonable, as it allows more flexibility (I don't have to store keyframes of non animated bones), but the implementation would be less straightforward. How are you doing it in your projects? Regards, akuda

Share this post


Link to post
Share on other sites
You could store a variable amount of keyframes per joint. Each keyframe should have an associated frame number. When you want to set the skeletal mesh to a specific frame you traverse the hierarchy and interpolate each joint between the two key frames it falls inbetween.

Share this post


Link to post
Share on other sites
I have always done keyframes per skeleton, for no particular reason. The per joint method appears to save on memory. However, it may increase polling time as the list of frames has to be searched... Unless you can provide hints like a frame to start searching at. I think if you want to do more interesting coding and experiment a little, go with the per joint. If you want to just get it implemented and work on other things, go for per skeleton.

Share this post


Link to post
Share on other sites
Quote:
Original post by akuda
Now, while writing a ms3d model loader I noticed, that Milkshape allows different amounts of asynchronous keyframe-lists for each joint.


Keyframes have timestamps, so I would say animation is very synchronous. ;)

Share this post


Link to post
Share on other sites
I prefer to go per joint. I also prefer to associate the state with a timestamp instead of a video frame number. This is also a superset of the other way, although it would consume more memory if used so.

The main advantage is IMHO that animation blending becomes easier. Animations need not be designed to have an effect on all joints at once. E.g. waving may be restricted to an arm and the belonging shoulder, but doesn't has an effect on the legs. So why burden that particular animation with joint states of the legs?

As gzboli has already mentioned, searching the various animation tracks (i.e. one track per joint per animation) can be reduced to a minimum by remembering the last used grid point with each track.

Share this post


Link to post
Share on other sites
I decided to go per joint, and I shall post the result when done.
I will do the search in log(n) time, as the array of keyframes is sorted with beginTime key :).

Share this post


Link to post
Share on other sites
I agree with other posters - go per joint, otherwise you are carrying around a lot of redundant bind position matrices (e.g. previously given - arm and shoulder move remainder of body stays static).

Also as previously mentioned, you can remember the last keyframe index used (per joint) and start a search from there and beat O(log n) in theory

If you have an animation mixer, you should consider how to combine multiple tracks of keyframe data per joint as well before you get started

Share this post


Link to post
Share on other sites
I decided that each animation produces a general "pose" of skeleton (which is complete or not), and these poses are later combined with proper weigths.

So: skeleton holds animations, each animation has function getPoseAt(time t), and AnimationStateSet collects these poses and combines them into a final pose, from which matrices are deduced.

Is that gonna work?

Share this post


Link to post
Share on other sites
Sounds OK, I also forgot to pose the problem of two or more instances of the same skeleton. Can they be at different times in the same animation using your proposed system? Or do they each need a copy of the keyframes? How much data can they share and still perform different animations (or be at different times within the same animation). Just more things to think about.

Share this post


Link to post
Share on other sites

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