Jump to content
  • Advertisement
Sign in to follow this  
socrates200X

Backwards matrix multiplication

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

Correct my thinking on this if I'm wrong:
/// 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();

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?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
I don't think you need to lock and unlock buffers around UpdateSkinnedMesh(), the function does this internally.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!