Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 30 May 2006
Offline Last Active Apr 20 2015 10:02 PM

Posts I've Made

In Topic: Finding skeleton joints in world or object space

07 October 2014 - 03:45 PM

Ah sorry I misunderstood about the blending then, you are right you also mentioned the convert, I was a bit sleepy :)

Let us know how it goes! :)

In Topic: Finding skeleton joints in world or object space

07 October 2014 - 11:47 AM

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 :)

In Topic: Finding skeleton joints in world or object space

06 October 2014 - 04:54 PM

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.

In Topic: Finding skeleton joints in world or object space

06 October 2014 - 02:20 PM

You need to just calculate the world/global space matrices and get the position from those.

If this is what you tried but it doesn't seem to work then you have a bug in your code somewhere smile.png

Maybe your local space matrices are not up to date yet?


You do not need the inverse bind pose matrices, but just the forward kinematics loop.


worldMatrix = localMatrix * parentWorldMatrix;   (or other multiplication order, depending on your matrix implementation)


So just the same as how you calculate your world space matrices already (before multiplying with inverse bind pose matrix).


Alternatively you can use your local space transformations (the separate pos/rot/scale) to calculate the world space values, without needing matrices. But that works basically the same.

In Topic: Animation states and blend trees

10 September 2014 - 10:04 PM

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.