It's hard to give a lecture on skeletal animation through a forum. But I'll try and explain how it works.

Skeletal animation works by getting a bunch of bone transforms, where the transform of each bone is relative to it's parent's transform. So if you have an 'absolute' transform you want to get rid of that by multiplying the absolute transform of any bone at any frame by the inverse absolute of it's parent. This gives you a local transform for a bone to start with. With this you need to have a bone-hierarchy that lists the parent-child relationships of you skeletal system. Ideally, regardless of any animation, if you twist a spine bone of any character, their 'upper body' and other connected bones that inherit the transform of that spine bone, should rotate/translate relative to that twisting. So you're animation and update step for a skeleton is to compute the 'local' transformation of each bone in the skeleton according to animation, and then to generate an absolute transform for each bone that is the transformation of that bone's parents inherit into it's transformations.

So you need the animation data for each bone for each frame to be in a local context in order to get the correct motion. Once you have that you create the 'world' or 'absolute' transforms for each bone to generate your animation matrix.

Now, before you can render the vertices, you need an inverse bind pose, which is the absolute inverse matrix of each bone at it's starting position. You transform the vertices by the inverse bind pose, then the absolute pose generated from the animation, to move each vertex of the model into the correct position.

As far as quaternions are concerned. Quaternions are just easier to interpolate smoothly compared to matrices. You still need to do the same thing in terms of multiplications by inverses and bind poses etc with quaternions that you would with matrices. The only difference being that with the quaternions a rotation animation will be spherically interpolated. And you do need that spherical interpolation to animate the skeleton correctly.

Following on from this, generally in a skeletal animation system the only actual animation data you need is rotation. Position of bone transforms and scale of bones is optional I guess, I would probably add it to the solution just in case, but I can't guarantee that data will be there in the keyframe data in the md5mesh format. But the position and scale of the bones at the bind pose should at least, because that's part of the mathematical formula to position the vertices correctly.

If you read up and study some quaternion math, you'll see that quaternions aren't that hard. They're just ways of specifying rotation that are more efficient than transform matrices and come with the benefit of interpolating between rotations smoothly. So the things I would look for and do to get a skeletal animation system working would be:

1) Bind Pose

2) Inverse Bind Pose

3) Bone Hierarchy

4) Animation in Local Bone Space

5) Interpolation of local space bone transforms to play back animation

6) Create the pose for the skeleton at the current frame from the local space transforms by transforming by parents

7) Transform the absolute transforms by the inverse bind pose to combine those transformations

8) Send vertex & matrix data to the GPU

9) On the GPU: Calculate the position of the transformed vertex by the bones it's bone indices point to, and then interpolate those results by the bone weights to get the correct vertex position. If using normals, do the same thing, but only apply the inner 3x3 component of the matrices so that you're transforming rotation only.

EDIT: It's been scotch O'clock for the last hour now, so sorry if any of this is incoherent or missing details.

### Show differencesHistory of post edits

### #2Kyall

Posted 16 October 2012 - 02:59 AM

It's hard to give a lecture on skeletal animation through a forum. But I'll try and explain how it works.

Skeletal animation works by getting a bunch of bone transforms, where the transform of each bone is relative to it's parent's transform. So if you have an 'absolute' transform you want to get rid of that by multiplying the absolute transform of any bone at any frame by the inverse absolute of it's parent. This gives you a local transform for a bone to start with. With this you need to have a bone-hierarchy that lists the parent-child relationships of you skeletal system. Ideally, regardless of any animation, if you twist a spine bone of any character, their 'upper body' and other connected bones that inherit the transform of that spine bone, should rotate/translate relative to that twisting. So you're animation and update step for a skeleton is to compute the 'local' transformation of each bone in the skeleton according to animation, and then to generate an absolute transform for each bone that is the transformation of that bone's parents inherit into it's transformations.

So you need the animation data for each bone for each frame to be in a local context in order to get the correct motion. Once you have that you create the 'world' or 'absolute' transforms for each bone to generate your animation matrix.

Now, before you can render the vertices, you need an inverse bind pose, which is the absolute inverse matrix of each bone at it's starting position. You transform the vertices by the inverse bind pose, then the absolute pose generated from the animation, to move each vertex of the model into the correct position.

In any 3D Mesh format that uses skeletal animation you're going to have the following things ( I hope ) because they are the things you need to have a functioning skeletal animation system. You might be missing some things, but those will be the things you can deduce from what you get.

As far as quaternions are concerned. Quaternions are just easier to interpolate smoothly compared to matrices. You still need to do the same thing in terms of multiplications by inverses and bind poses etc with quaternions that you would with matrices. The only difference being that with the quaternions a rotation animation will be spherically interpolated. And you do need that spherical interpolation to animate the skeleton correctly.

Following on from this, generally in a skeletal animation system the only actual animation data you need is rotation. Position of bone transforms and scale of bones is optional I guess, I would probably add it to the solution just in case, but I can't guarantee that data will be there in the keyframe data in the md5mesh format. But the position and scale of the bones at the bind pose should at least, because that's part of the mathematical formula to position the vertices correctly.

If you read up and study some quaternion math, you'll see that quaternions aren't that hard. They're just ways of specifying rotation that are more efficient than transform matrices and come with the benefit of interpolating between rotations smoothly. So the things I would look for and do to get a skeletal animation system working would be:

1) Bind Pose

2) Inverse Bind Pose

3) Bone Hierarchy

4) Animation in Local Bone Space

5) Interpolation of local space bone transforms to play back animation

6) Create the pose for the skeleton at the current frame from the local space transforms by transforming by parents

7) Transform the absolute transforms by the inverse bind pose to combine those transformations

8) Send vertex & matrix data to the GPU

9) On the GPU: Calculate the position of the transformed vertex by the bones it's bone indices point to, and then interpolate those results by the bone weights to get the correct vertex position. If using normals, do the same thing, but only apply the inner 3x3 component of the matrices so that you're transforming rotation only.

EDIT: It's been scotch O'clock for the last hour now, so sorry if any of this is incoherent or missing details.

Skeletal animation works by getting a bunch of bone transforms, where the transform of each bone is relative to it's parent's transform. So if you have an 'absolute' transform you want to get rid of that by multiplying the absolute transform of any bone at any frame by the inverse absolute of it's parent. This gives you a local transform for a bone to start with. With this you need to have a bone-hierarchy that lists the parent-child relationships of you skeletal system. Ideally, regardless of any animation, if you twist a spine bone of any character, their 'upper body' and other connected bones that inherit the transform of that spine bone, should rotate/translate relative to that twisting. So you're animation and update step for a skeleton is to compute the 'local' transformation of each bone in the skeleton according to animation, and then to generate an absolute transform for each bone that is the transformation of that bone's parents inherit into it's transformations.

So you need the animation data for each bone for each frame to be in a local context in order to get the correct motion. Once you have that you create the 'world' or 'absolute' transforms for each bone to generate your animation matrix.

Now, before you can render the vertices, you need an inverse bind pose, which is the absolute inverse matrix of each bone at it's starting position. You transform the vertices by the inverse bind pose, then the absolute pose generated from the animation, to move each vertex of the model into the correct position.

In any 3D Mesh format that uses skeletal animation you're going to have the following things ( I hope ) because they are the things you need to have a functioning skeletal animation system. You might be missing some things, but those will be the things you can deduce from what you get.

As far as quaternions are concerned. Quaternions are just easier to interpolate smoothly compared to matrices. You still need to do the same thing in terms of multiplications by inverses and bind poses etc with quaternions that you would with matrices. The only difference being that with the quaternions a rotation animation will be spherically interpolated. And you do need that spherical interpolation to animate the skeleton correctly.

Following on from this, generally in a skeletal animation system the only actual animation data you need is rotation. Position of bone transforms and scale of bones is optional I guess, I would probably add it to the solution just in case, but I can't guarantee that data will be there in the keyframe data in the md5mesh format. But the position and scale of the bones at the bind pose should at least, because that's part of the mathematical formula to position the vertices correctly.

If you read up and study some quaternion math, you'll see that quaternions aren't that hard. They're just ways of specifying rotation that are more efficient than transform matrices and come with the benefit of interpolating between rotations smoothly. So the things I would look for and do to get a skeletal animation system working would be:

1) Bind Pose

2) Inverse Bind Pose

3) Bone Hierarchy

4) Animation in Local Bone Space

5) Interpolation of local space bone transforms to play back animation

6) Create the pose for the skeleton at the current frame from the local space transforms by transforming by parents

7) Transform the absolute transforms by the inverse bind pose to combine those transformations

8) Send vertex & matrix data to the GPU

9) On the GPU: Calculate the position of the transformed vertex by the bones it's bone indices point to, and then interpolate those results by the bone weights to get the correct vertex position. If using normals, do the same thing, but only apply the inner 3x3 component of the matrices so that you're transforming rotation only.

EDIT: It's been scotch O'clock for the last hour now, so sorry if any of this is incoherent or missing details.

### #1Kyall

Posted 16 October 2012 - 02:59 AM

It's hard to give a lecture on skeletal animation through a forum. But I'll try and explain how it works.

Skeletal animation works by getting a bunch of bone transforms, where the transform of each bone is relative to it's parent's transform. So if you have an 'absolute' transform you want to get rid of that by multiplying the absolute transform of any bone at any frame by the inverse absolute of it's parent. This gives you a local transform for a bone to start with. With this you need to have a bone-hierarchy that lists the parent-child relationships of you skeletal system. Ideally, regardless of any animation, if you twist a spine bone of any character, their 'upper body' and other connected bones that inherit the transform of that spine bone, should rotate/translate relative to that twisting. So you're animation and update step for a skeleton is to compute the 'local' transformation of each bone in the skeleton according to animation, and then to generate an absolute transform for each bone that is the transformation of that bone's parents inherit into it's transformations.

So you need the animation data for each bone for each frame to be in a local context in order to get the correct motion. Once you have that you create the 'world' or 'absolute' transforms for each bone to generate your animation matrix.

Now, before you can render the vertices, you need an inverse bind pose, which is the absolute inverse matrix of each bone at it's starting position. You transform the vertices by the inverse bind pose, then the absolute pose generated from the animation, to move each vertex of the model into the correct position.

In any 3D Mesh format that uses skeletal animation you're going to have the following things ( I hope ) because they are the things you need to have a functioning skeletal animation system. You might be missing some things, but those will be the things you can deduce from what you get.

As far as quaternions are concerned. Quaternions are just easier to interpolate smoothly compared to matrices. You still need to do the same thing in terms of multiplications by inverses and bind poses etc with quaternions that you would with matrices. The only difference being that with the quaternions a rotation animation will be spherically interpolated. And you do need that spherical interpolation to animate the skeleton correctly.

Following on from this, generally in a skeletal animation system the only actual animation data you need is rotation. Position of bone transforms and scale of bones is optional I guess, I would probably add it to the solution just in case, but I can't guarantee that data will be there in the keyframe data in the md5mesh format. But the position and scale of the bones at the bind pose should at least, because that's part of the mathematical formula to position the vertices correctly.

If you read up and study some quaternion math, you'll see that quaternions aren't that hard. They're just ways of specifying rotation that are more efficient than transform matrices and come with the benefit of interpolating between rotations smoothly. So the things I would look for and do to get a skeletal animation system working would be:

1) Bind Pose

2) Inverse Bind Pose

3) Bone Hierarchy

4) Animation in Local Bone Space

5) Interpolation of local space bone transforms to play back animation

6) Create the pose for the skeleton at the current frame from the local space transforms by transforming by parents

7) Transform the absolute transforms by the inverse bind pose to combine those transformations

8) Send vertex & matrix data to the GPU

9) On the GPU: Calculate the position of the transformed vertex by the bones it's bone indices point to, and then interpolate those results by the bone weights to get the correct vertex position. If using normals, do the same thing, but only apply the inner 3x3 component of the matrices so that you're transforming rotation only.

Skeletal animation works by getting a bunch of bone transforms, where the transform of each bone is relative to it's parent's transform. So if you have an 'absolute' transform you want to get rid of that by multiplying the absolute transform of any bone at any frame by the inverse absolute of it's parent. This gives you a local transform for a bone to start with. With this you need to have a bone-hierarchy that lists the parent-child relationships of you skeletal system. Ideally, regardless of any animation, if you twist a spine bone of any character, their 'upper body' and other connected bones that inherit the transform of that spine bone, should rotate/translate relative to that twisting. So you're animation and update step for a skeleton is to compute the 'local' transformation of each bone in the skeleton according to animation, and then to generate an absolute transform for each bone that is the transformation of that bone's parents inherit into it's transformations.

So you need the animation data for each bone for each frame to be in a local context in order to get the correct motion. Once you have that you create the 'world' or 'absolute' transforms for each bone to generate your animation matrix.

Now, before you can render the vertices, you need an inverse bind pose, which is the absolute inverse matrix of each bone at it's starting position. You transform the vertices by the inverse bind pose, then the absolute pose generated from the animation, to move each vertex of the model into the correct position.

In any 3D Mesh format that uses skeletal animation you're going to have the following things ( I hope ) because they are the things you need to have a functioning skeletal animation system. You might be missing some things, but those will be the things you can deduce from what you get.

As far as quaternions are concerned. Quaternions are just easier to interpolate smoothly compared to matrices. You still need to do the same thing in terms of multiplications by inverses and bind poses etc with quaternions that you would with matrices. The only difference being that with the quaternions a rotation animation will be spherically interpolated. And you do need that spherical interpolation to animate the skeleton correctly.

Following on from this, generally in a skeletal animation system the only actual animation data you need is rotation. Position of bone transforms and scale of bones is optional I guess, I would probably add it to the solution just in case, but I can't guarantee that data will be there in the keyframe data in the md5mesh format. But the position and scale of the bones at the bind pose should at least, because that's part of the mathematical formula to position the vertices correctly.

If you read up and study some quaternion math, you'll see that quaternions aren't that hard. They're just ways of specifying rotation that are more efficient than transform matrices and come with the benefit of interpolating between rotations smoothly. So the things I would look for and do to get a skeletal animation system working would be:

1) Bind Pose

2) Inverse Bind Pose

3) Bone Hierarchy

4) Animation in Local Bone Space

5) Interpolation of local space bone transforms to play back animation

6) Create the pose for the skeleton at the current frame from the local space transforms by transforming by parents

7) Transform the absolute transforms by the inverse bind pose to combine those transformations

8) Send vertex & matrix data to the GPU

9) On the GPU: Calculate the position of the transformed vertex by the bones it's bone indices point to, and then interpolate those results by the bone weights to get the correct vertex position. If using normals, do the same thing, but only apply the inner 3x3 component of the matrices so that you're transforming rotation only.