   Question regarding Skeletal Animation/Skinning
  Hi,I have a question regarding skeletal animation/skinning that confuses me a little bit.In the resources I have read about this it works like this: You have a hierarchy of nodes. To get a pose you start transforming at the root and work your way to all the other nodes, basically accumulating transformations.Than you multiply that matrix with another (static) transformation that every bone has. Now you can use the vertices weights to compute their final position.What I'm not really sure about is that static transformation of every bone. Wouldn't it be possible to incorporate that into the vertex positions and save one transformation-operation? Or do I get a problem because of various weights?I hope I my description makes sense.   
  Yes this is possible, and this is what sometimes was done when there were no vertex shaders yet, to speed up the skinning process.What you can do is not only store say 4 weight and index values, but store those offset 3D vectors for each influence as well. This of course requires a lot more data to be stored per vertex, which makes it less interesting to be used in combination with today's hardware.I wouldn't really use this method when doing skinning on the GPU.How it is generally done these days is to pre-multiply the world space matrix of the given bone with the inverse of the world space matrix in bind pose of that bone. This inverse bind pose matrix is the static transformation you talk about. The bind pose is often the T-pose you see characters in. The artists linked the bones to the vertices in that pose.You use that resulting matrix to perform the skinning deformations per vertex. So that is the matrix you would pass to the vertex shaders as well in case you do skinning on the GPU.   ;  Thanks for the reply! I don't fully understand though.Quote:Original post by BuckshagYou use that resulting matrix to perform the skinning deformations per vertex. So that is the matrix you would pass to the vertex shaders as well in case you do skinning on the GPU.Are you saying that you pass two matrices per bone to the vertex shader? If the inverse bind pose matrix never changes, why would you not want to pre-multiply it? Is there any reason for this?;  No, you multiply them together and pass that resulting matrix to the vertex shader.So you just send over one matrix.You could also send over a quaternion and position vector.Or you can only send over 3x4 instead of 4x4 vectors of the bone matrices.Or a dual quaternion.But those are optimizations.;Quote:Original post by BuckshagNo, you multiply them together and pass that resulting matrix to the vertex shader.Ok, that's what I'm doing right now.Could you explain to me, why the inverse bind pose matrix is not pre-multiplied with the vertices? That's really the thing I can't figure out.;  Because vertices might be affected by multiple bones with different weights. 2 or 3 bones affecting a single vertex are a common practise. And by the way: you don't save any performance by this. You have one matrix multiplication per vertex for each component (position, normal, tangent). Additional matrices included in that transformation do not cause additional computations.   ;Quote:Original post by SchrompfBecause vertices might be affected by multiple bones with different weights. 2 or 3 bones affecting a single vertex are a common practise. And by the way: you don't save any performance by this. You have one matrix multiplication per vertex for each component (position, normal, tangent). Additional matrices included in that transformation do not cause additional computations.So pre-multiplying all affecting bones into the vertex doesn't solve this issue then?In theory it would save me 1 matrix multiplication per bone on the CPU, wouldn't it?   ;Quote:Original post by B_oldSo pre-multiplying all affecting bones into the vertex doesn't solve this issue then?I get the feeling that we miss eachothers topic. What "issue" do you want to solve here? All vertices have their positions, normals and so on given in mesh space. Each bone has a matrix (called offset matrix or inverse bind shape matrix or mesh to bone space matrix) which transforms from mesh space into the bone's local space. There's also a skeleton defined by the hierarchical relations between all bones. All bones have a current transformation with respect to their parent bone. By applying animation data or physics data to all bone's transformations you can make that skeleton move. By concatenating each bone's transformation with their parent's transformation and so on down to the root bone you get each bone's local to mesh space transformation. Note the name: it's exactly the contrary direction to the bind shape matrix. The thing is that the bind shape matrix transforms from mesh to bone space in bind position. That's the position in which the mesh was modelled and rigged. In constrast, the bone to mesh matrix is in the current skeleton's position. It's the difference between those two spaces that makes this process work.So here's what you usually do per mesh in a skeletal animation system:a) Apply animation data to the skeleton nodes. For each bone  a1) Find the appropriate key for the current time in the anim key sequence of that bone  a2) Extract it's value, maybe interpolate with the following key.  a3) Calculate result transform from it (in case there are separate key sequences for scale, rotation, translation, which is usually the case)  a4) The transformation matrix from a3) replaces the bone's current transformation.Now you have a skeleton which moves along with an animation. To make the mesh follow that skeleton you'll do the following:b) Calculate bone matrices. For each bone:  b1) Calculate the bone's current bone-to-mesh transformation by multiplying matrices from child to parent down to the root bone  b2) Multiply bind shape matrix and current bone-to-mesh trafo.  b3) You now have a difference matrix in mesh space that describes how vertices move when the bone moves from its bind position to the current position.c) Apply bone matrices to mesh. That usually means  c1) Upload matrix array to vertex shader.  c2) For each bone affecting the vertex, transform its position, normal, tangent a.s.o. by the bone matrix.  c3) Add up all transformed data weighted by the bone's influence on the vertex.Your mesh should now deform in accordance to the moving skeleton.Quote:In theory it would save me 1 matrix multiplication per bone on the CPU, wouldn't it?Yes, you would save a single matrix multiplication per bone on the CPU. But you can't do this, because each vertex can have more than one bone affecting it, while this pre-multiplication would require that there's only a single bone affecting each and every vertex. And seriously: it's not worth it. Doing a few thousand matrix-vector multiplications upfront to save a few dozen matrix-matrix multiplications each frame... there are much more demanding jobs in an animation system to be optimized before tackling this "issue".;  Thanks for the detailed explanation!Quote:Original post by SchrompfYes, you would save a single matrix multiplication per bone on the CPU. But you can't do this, because each vertex can have more than one bone affecting it, while this pre-multiplication would require that there's only a single bone affecting each and every vertex.It's mainly this, that I wasn't sure about. I thought there might be a way to pre-multiply even though more than one bone can affect a given vertex, which doesn't seem to be the case.Thanks for helping me out!;Quote:It's mainly this, that I wasn't sure about. I thought there might be a way to pre-multiply even though more than one bone can affect a given vertex, which doesn't seem to be the case.You can actually as I tried to explain before.Most people don't know this. But you would end up with <numInfluences> "vertex positions" per vertex rather than just one. So it is not really interesting, but it is possible and has been done before in some older games.