/// For each bone, compute final matrix by computing first by bone offset,
/// then by the bone's combined transformation matrix
for (unsigned int uiBoneCt = 0; uiBoneCt < uiNumBones; ++uiBoneCt)
{
D3DXMatrixMultiply(&m_pBoneMatrices[uiBoneCt],
&pMesh->pBoneOffsets[uiBoneCt],
pMesh->m_ppFrameMatrices[uiBoneCt]);
}
/// Update mesh with new animation transforms
void *SrcPtr, *DestPtr;
pMesh->MeshData.pMesh->LockVertexBuffer(D3DLOCK_READONLY, (void**)&SrcPtr);
pMesh->m_pSkinMesh->LockVertexBuffer(0, (void**)&DestPtr);
pMesh->pSkinInfo->UpdateSkinnedMesh(m_pBoneMatrices, NULL, SrcPtr, DestPtr);
pMesh->m_pSkinMesh->UnlockVertexBuffer();
pMesh->MeshData.pMesh->UnlockVertexBuffer();
Backwards matrix multiplication
Correct my thinking on this if I'm wrong:
This is part of an implementation of a skinned mesh animation project. As the theory goes, the bone offset matrix for a bone transforms vertices from the original "bind space" to bone space, then the combined transform takes the vertices from bone space to character space, rotating / translating based on any local animations.
Now, this means that if B is the bone offset matrix and C is the combined local bone transform, then the correct matrix multiplication order would be CBv, since matricies multiply from right to left. But, as the code shows, the multiplication is BCv, which seems false. Changing the order messes up my model. Is there some weird way DirectX handles matricies?
The D3D convention is to use row vectors not column vectors, and as a result of this to combine transforms you need to premultiply the matrices not postmultiply. This is reversed from the typical math/engineering convention. So in your example the calculation is actually vBC (where v is a row vector) which matches the "order" you expect but simply in a reversed notation.
I don't think you need to lock and unlock buffers around UpdateSkinnedMesh(), the function does this internally.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement