14 replies to this topic

[keym]

So I tried to implement vertex skinning using Cg and OGL. I searched the web and most tutorials do it with 4 bones at max, claiming that "you don't need more than 4 bones anyway". I beg to differ. For instance I used "cyberdemon" from Doom3 for testing and it uses up to 7 bones per vertex. And this game is 2004... I know it has nothing to do with that (just tell artist what he can and can't do and problem is solved, right?). But in this topic http://www.gamedev.net/topic/628092-gpu-skinning-4-bones/ MJP said that I can pass as many bone weights per vertex as I want. Currently I'm packing them into TEXCOORD0-7 and I'm hardly getting away with 6 bones - I even sacrificed TBNs and I want to use them too. So the question is what's this trickery that allows me passing more bones without stress?

1. If anyone's curious - I just wanted to implement up to 8 bones just to be safe, also it may come in handy when we start with facial animation.

2. Yes, I know that I can discard least significant weights and then renormalize, but that's "lazy solution", I want to do it right and MJP's post lead me to that direction. Also see above.

3. I'm fairly new to VBOs so I might be missing something about packing vertex attributes.

[C0lumbo]

Currently I'm packing them into TEXCOORD0-7 and I'm hardly getting away with 6 bones

 

I'm guessing your problem is that you're using float2 because that's traditional for texture coordinate UVs?

 

In fact, there's nothing stopping you using a float4 for each TEXCOORD. That would mean that just 4 TEXCOORDs will give you 16 scalar values, which is enough for 8 weights + 8 bone indices.

[keym]

I use float4 and int4 but I also pass 3d vector - weight position - that is part of MD5 format (maybe there is a workaround for this?). That's why it's so crowdy in there... Bones itself are 3d vectors (pos) + 4d vectors (orient).

So just to clarify - there's no way to pass more attributes other than pack them through ATTR0-ATTR15? I'm asking cause MJP's post:

"You should be able to pack as many bones + weights as you want in your vertex."

gave me the impression that I can pass more data and I just don't know the trick.

Edited by keym, 04 February 2013 - 11:27 AM.

[Sik_the_hedgehog]

Let me see if I'm understanding right: you're storing the bones directly in each vertex? Using uniforms would make more sense (then you only need to pass the bone ID and the weight to each vertex).

Edited by Sik_the_hedgehog, 04 February 2013 - 11:33 AM.

[keym]

No, no. The bones are stored as uniform as you say. I store something "extra" that is called "weight position". See here http://tfc.duke.free.fr/coding/md5-specs-en.html and scroll down to

numweights (int) is the number of weights...

[C0lumbo]

I have seen that sort of an approach before (in a CPU skinning context) and I'm not aware of any benefits of it over and above the more common bind pose approach. I think that Max or Maya (or maybe both) tend to make it easier to get the weighting data that way, so perhaps that why it made it's way into the file format, but I'm pretty sure that when it comes to runtime skinning, you're best off processing the skin data to get a single bind pose position per vertex.

Do you know if Doom3 actually used the "weight position" that way in its shaders? I would be a little surprised if it did, but if it did, then I presume there was some good reason that I'm not seeing.

I think if you're keen on supporting >4 vertices, then you probably ought to do bind pose skinning. In fact probably you ought to do bind pose skinning regardless, unless there's some big benefit to doing it the "weight position" way.

Edited by C0lumbo, 04 February 2013 - 12:54 PM.

[keym]

I'm confused. Is was under the impression that in fact this is the "bind pose approach" - these weight positions are provided only in bind pose (scratch that, they are pose independant, they only inform about mesh "volume", combined with bones, bind pose or not, they give the final result) and I also have bind pose skeleton provided. So how do I get rid of these weight positions? What's the usual approach here? Right now I have bind pose skeleton but in fact I don't use it while animating. It's only helpful when "unpacking" animation (skeleton) frames but it looks like there's a reason it's there. I have no idea if Doom3 uses these weight positions in shaders. I just followed mentioned tutorial and ended up here.

Edited by keym, 04 February 2013 - 02:37 PM.

[l0calh05t]

The following link shows how to calculate the bind pose from the info provided in the md5 file:

http://3dgep.com/?p=1356

[jmakitalo]

I'm confused. Is was under the impression that in fact this is the "bind pose approach" - these weight positions are provided only in bind pose (scratch that, they are pose independant, they only inform about mesh "volume", combined with bones, bind pose or not, they give the final result) and I also have bind pose skeleton provided. So how do I get rid of these weight positions? What's the usual approach here? Right now I have bind pose skeleton but in fact I don't use it while animating. It's only helpful when "unpacking" animation (skeleton) frames but it looks like there's a reason it's there. I have no idea if Doom3 uses these weight positions in shaders. I just followed mentioned tutorial and ended up here.

 

I animate MD5 meshes in a way C0lumbo implied. Post multiply your animation pose matrices with the inverse bind pose. Then you can just send the bind posed vertices to the GPU.

 

I'm not sure how animating is done in Doom 3, but maybe it is possible that they did not use GPU skinning, because they needed the transformed vertices for constructing shadow volumes. Then it should be faster to have the vertices in weight space so that post multiplication by inverse bind pose is avoided.

[osmanb]

I'm confused. Is was under the impression that in fact this is the "bind pose approach" - these weight positions are provided only in bind pose (scratch that, they are pose independant, they only inform about mesh "volume", combined with bones, bind pose or not, they give the final result) and I also have bind pose skeleton provided. So how do I get rid of these weight positions? What's the usual approach here? Right now I have bind pose skeleton but in fact I don't use it while animating. It's only helpful when "unpacking" animation (skeleton) frames but it looks like there's a reason it's there. I have no idea if Doom3 uses these weight positions in shaders. I just followed mentioned tutorial and ended up here.

 

I animate MD5 meshes in a way C0lumbo implied. Post multiply your animation pose matrices with the inverse bind pose. Then you can just send the bind posed vertices to the GPU.

 

I'm not sure how animating is done in Doom 3, but maybe it is possible that they did not use GPU skinning, because they needed the transformed vertices for constructing shadow volumes. Then it should be faster to have the vertices in weight space so that post multiplication by inverse bind pose is avoided.

 

Yes, this is how it worked. The PC version did all skinning on the CPU. The resulting meshes were used for collision, shadow volume extrusion, and decal splatting. For the Xbox version, we couldn't afford to do CPU skinning -- so we transformed everything into bind pose to do GPU skinning.

[keym]

I'm confused. Is was under the impression that in fact this is the "bind pose approach" - these weight positions are provided only in bind pose (scratch that, they are pose independant, they only inform about mesh "volume", combined with bones, bind pose or not, they give the final result) and I also have bind pose skeleton provided. So how do I get rid of these weight positions? What's the usual approach here? Right now I have bind pose skeleton but in fact I don't use it while animating. It's only helpful when "unpacking" animation (skeleton) frames but it looks like there's a reason it's there. I have no idea if Doom3 uses these weight positions in shaders. I just followed mentioned tutorial and ended up here.

I animate MD5 meshes in a way C0lumbo implied. Post multiply your animation pose matrices with the inverse bind pose. Then you can just send the bind posed vertices to the GPU.

I'm not sure how animating is done in Doom 3, but maybe it is possible that they did not use GPU skinning, because they needed the transformed vertices for constructing shadow volumes. Then it should be faster to have the vertices in weight space so that post multiplication by inverse bind pose is avoided.

Thank you all for great tips. I'll try to do that but it'll take me some time cause I'm using quaternions so far. So, to sum this up, what I need to do is:

1. Build vertex positions in object space (using bind pose joints) and store them
2. Build bind pose matrices and then inverse bind pose matrices for my bind pose joints (from joint positions and orientations)
3. Build animation pose matrices from joints (like above)
4. Multiply animation pose matrices with inverse bind pose matrices and send them to shader
5. Send bind pose vertices, weight factors and bone indices to shader
7. Compute final matrix from "component" matrices that are weighted
8. Multiply bind pose vertex by final matrix.

Is that correct?

Edited by keym, 05 February 2013 - 11:35 AM.

[keym]

Yep, it works. Just finished implementing my quat to matrix + few helpers. Thank you all!

[keym]

So it turns out that the other day I was bit too optimistic - tested it with bindpose only and I presumed it's allright. What I did - I got the bind pose matrices and then inverted ones, then multiplied bind pose by inverted and then sent it to the shader (silly me, I forgot that multiplying matrix by its inverse gives identity matrix, so no wonder the bind pose object space vertices were ok). Happy to see that it works I assumed that I only need to build animated matrices and replace bind pose matrices by animated ones in multiplication. But sadly this doesn't work. The result is totally messed up. It helps a little if I invert the final matrix but it's still not right.

 

What I already double checked:

1. quat to matrix conversion

2. matrix by matrix multiplication

3. matrix inverse routine

Edited by keym, 07 February 2013 - 01:22 PM.

[keym]

Bump, I'm still stuck.

[keym]

My quaternion to matrix code:

matrix4x4::matrix4x4(quaternion quat)
{
    quat.normalize();
    this->row[0].x = 1 - 2 * quat.y * quat.y - 2 * quat.z * quat.z;
    this->row[0].y = 2 * quat.x * quat.y - 2 * quat.z * quat.w;
    this->row[0].z = 2 * quat.x * quat.z + 2 * quat.y * quat.w;
    this->row[0].w = 0;

    this->row[1].x = 2 * quat.x * quat.y + 2 * quat.z * quat.w;
    this->row[1].y = 1 - 2 * quat.x * quat.x - 2 * quat.z * quat.z;
    this->row[1].z = 2 * quat.y * quat.z - 2 * quat.x * quat.w;
    this->row[1].w = 0;

    this->row[2].x = 2 * quat.x * quat.z - 2 * quat.y * quat.w;
    this->row[2].y = 2 * quat.y * quat.z + 2 * quat.x * quat.w;
    this->row[2].z = 1 - 2 * quat.x * quat.x - 2 * quat.y * quat.y;
    this->row[2].w = 0;

    this->row[3] = vector4d(0,0,0,1);
} 

 

How I build bind pose and inverse bind pose matrices:

    for(int i = 0; i < this->numJoints; i++)
    {
        matrix4x4 matr(this->joints[i].orient);
        matr.row[3] = vector4d(this->joints[i].pos);

        this->bindPoseMatrices[i] = matr;
        this->invBindPoseMatrices[i] = this->bindPoseMatrices[i].getInverse();;
    } 

 

How I build animated matrices:

void md5OBJ::updateSkeleton(int animNum, int frameNum)
{
    for(int i = 0; i < this->numJoints; i++)
    {
        matrix4x4 animMatr(this->animations[animNum].frames[frameNum].joints[i].orient);
        animMatr.row[3] = vector4d(this->animations[animNum].frames[frameNum].joints[i].pos);
        this->animatedMatrices[i] = animMatr * this->invBindPoseMatrices[i];
    }
}
 

 

Matrices are row major.