That's why I wanted to say that the animation values are relative to the parent and that mostly the x or z axis (in DirectX default coordinates) point toward the child node. So it is not always the Y that you expect to move up and down.
You might want to consider changing your blending into local space rather than world space.
Also I'm not sure if blending matrices is very efficient and if that's even correct.
Next to that you have to store a full matrix per keyframe. That's pretty big. Imagine you are only translating 10 units to the right at constant speed.
You would need only two vector3 keyframes basically, assuming you do not split your position into 3 different tracks.
While now you might need say 30 full matrices.
But yeah, that's a bit off-topic now and if it works for your game and doesn't give you any memory or performance issues, then that's all ok
I'm not entirely sure what you mean with "animation matrix", but I assume this is the matrix that represents the current frame's offset transformation relative to the parent node.
This is also why you will not see an Y value for your calfs etc. Most likely they are in x or z direction, depending on how the hierarchy has been setup. Depending on the art software (and possibly which plugins) used, the x or z axis will probably point to the child/parent node.
The standard way of doing animation is by decomposing those matrices into pos/rot/scale. So a scale vector, rotation quaternion and scale vector for example. You then put those into key tracks and interpolate between them. Then you rebuild the local space matrices (the ones relative to the parent) from those individually interpolated and blend transform components. Once you have the local space matrices you can calculate the world space matrices as I mentioned.
I never did anything with Collada, so I'm not sure what space the animation data is in there. But it is most likely this relative to parent space. The root node has no parent so it will be the full world transform, which is why you would see 85 in Y on the root.
Most likely you know all this already, but I wanted to be sure so that we're on the same page
All you would need to do is find out which nodes you need to follow from the root towards the node you want to calculate the world position of. Then do this for loop with the local * parentWorld matrix and then you can get the translation from that matrix. That will give you the world/global space position.
From what I understand you are already calculating those matrices before multiplying them with the inverse bind pose matrix and passing them to the shader.
If that is the case, it is exactly the same as that.
It doesn't matter how you name those parameters really. It comes down to the same, just like you say
It is just important to keep in mind that your game code will set the parameter values, which the conditions will check.
I would in your case just have one parameter "forward" or so.
And depending on the control scheme in your game you can set that value to either true or false. If you use a game controller check the stick. If you use keyboard, check the cursor up key for example. The state machine doesn't know about the keyboard or game controller, just about the parameter "forward".
Both the outgoing transition condition from idle to shuffle and from jump to lean forward can check the same "forward" parameter.