Which frame do blends use for their start?
by Jason Gossiaux · in Artist Corner · 08/18/2008 (8:53 pm) · 7 replies
When exporting blended animations in MS3D, is the first frame the first frame, or is the model's unanimated pose the first frame?
I am finding that if I say, export an animation from frame 144-200, when viewed in showtool the first frame is not the keyframe at 144, but rather the model's unanimated pose. Is this normal?
I am finding that if I say, export an animation from frame 144-200, when viewed in showtool the first frame is not the keyframe at 144, but rather the model's unanimated pose. Is this normal?
About the author
#2
First of all, it looks like "export animations" became re-checked at some point. So I wasn't using DSQs like I thought I was.
So now if I try and use DSQs my non blended run and walk animations are all screwed up like you wouldn't believe. * EDIT - looks like this is caused by using framerates other than 30 when exporting those animations. Does a fix for this exist?
My blended animations use 30fps so they are not corrupted, however they appear to be ignoring the reference frame no matter if I am using DSQs, or not...
08/18/2008 (9:30 pm)
Well now I'm all confused again :P First of all, it looks like "export animations" became re-checked at some point. So I wasn't using DSQs like I thought I was.
So now if I try and use DSQs my non blended run and walk animations are all screwed up like you wouldn't believe. * EDIT - looks like this is caused by using framerates other than 30 when exporting those animations. Does a fix for this exist?
My blended animations use 30fps so they are not corrupted, however they appear to be ignoring the reference frame no matter if I am using DSQs, or not...
#3
I wouldn't have thought a different frame rate would mess anything up => do your non-blended run and walk animations work ok if you export them with a 30fps framerate?
I'm not aware of any bugs with the blend exporting - though that doesn't mean there aren't any! Is it possible for you to send me the model that you are having trouble with, along with a step-by-step of what you are doing?
08/18/2008 (10:52 pm)
Quote:So now if I try and use DSQs my non blended run and walk animations are all screwed up like you wouldn't believe. * EDIT - looks like this is caused by using framerates other than 30 when exporting those animations. Does a fix for this exist?
I wouldn't have thought a different frame rate would mess anything up => do your non-blended run and walk animations work ok if you export them with a 30fps framerate?
Quote:My blended animations use 30fps so they are not corrupted, however they appear to be ignoring the reference frame no matter if I am using DSQs, or not...
I'm not aware of any bugs with the blend exporting - though that doesn't mean there aren't any! Is it possible for you to send me the model that you are having trouble with, along with a step-by-step of what you are doing?
#4
Yes they work as expected with a 30fps export. If I change it to 40 or 42 or 36 (other values I tried) the model gets all mangled in showtool and in game. This is with a non blended run animation.
I'll be sending out the ms3d file in an email here shortly with instructions. Thank you for looking into this for me!
08/19/2008 (7:21 am)
Quote:
I wouldn't have thought a different frame rate would mess anything up => do your non-blended run and walk animations work ok if you export them with a 30fps framerate?
Yes they work as expected with a 30fps export. If I change it to 40 or 42 or 36 (other values I tried) the model gets all mangled in showtool and in game. This is with a non blended run animation.
I'll be sending out the ms3d file in an email here shortly with instructions. Thank you for looking into this for me!
#5
As far as I can tell, blend animations are working just fine, but there might be some confusion about how they are supposed to work.
The 'reference' frame has the node pointing at 9oclock, the first frame of the blend animation is pointing halfway between 10 and 11. A normal (non-blend) animation would store the first frame at that absolute position (between 10 and 11), but a blend animation stores the difference between the frame and the reference frame => in this case, a clockwise rotation of 45 degrees.
This means that when the blend animation is played, the first frame will cause the node to rotate clockwise 45 degress from whatever its current orientation is. This is very different to a non-blend animation that would force the node to the absolute position (between 10 and 11).
The last 2 frames show this in action: the base pose has the node pointing at 6oclock, and when we apply the blend animation, there is a clockwise 45 degree rotation around to between 7 and 8. Note that this is a completely different absolute position to the first blend frame in our modeling app, but this is exactly how blends are supposed to work!
To tie this back to your model: the 'reference' frame and the first frame of your blend are the same (frame 144), so the blend transform for the first frame is exactly 0. ie. the first frame of your blend will have exactly zero effect when applied (the subsequent frames of course will move the arm as expected).
When you load your model in the showtool, it's base pose has the arms outstretched, and as expected, when the blend animation is played on top, the first frame has zero effect (arms still outstretched instead of at sides like in the modeling app).
08/19/2008 (1:43 pm)
Thanks for the model, Jason. I'm posting results here for prosperity.As far as I can tell, blend animations are working just fine, but there might be some confusion about how they are supposed to work.
The 'reference' frame has the node pointing at 9oclock, the first frame of the blend animation is pointing halfway between 10 and 11. A normal (non-blend) animation would store the first frame at that absolute position (between 10 and 11), but a blend animation stores the difference between the frame and the reference frame => in this case, a clockwise rotation of 45 degrees.
This means that when the blend animation is played, the first frame will cause the node to rotate clockwise 45 degress from whatever its current orientation is. This is very different to a non-blend animation that would force the node to the absolute position (between 10 and 11).
The last 2 frames show this in action: the base pose has the node pointing at 6oclock, and when we apply the blend animation, there is a clockwise 45 degree rotation around to between 7 and 8. Note that this is a completely different absolute position to the first blend frame in our modeling app, but this is exactly how blends are supposed to work!
To tie this back to your model: the 'reference' frame and the first frame of your blend are the same (frame 144), so the blend transform for the first frame is exactly 0. ie. the first frame of your blend will have exactly zero effect when applied (the subsequent frames of course will move the arm as expected).
When you load your model in the showtool, it's base pose has the arms outstretched, and as expected, when the blend animation is played on top, the first frame has zero effect (arms still outstretched instead of at sides like in the modeling app).
#6
08/19/2008 (1:45 pm)
On a different note, it does appear the node transforms are distorted if the 'fps' value is set to anything greater than 30. Values less than 30 seem to work ok. That looks to be a genuine bug (not yet sure if in Torque or the exporter).
#7
For example if you are running a cyclic non blend thread, and call playthread, the current frame of the cyclic thread is used for the blend. This is why my blend sequences always look correct when played in this manner - but playthread sucks for player animation.
So I was using setactionthread which is where my blend animation problems began. setactionthread does NOT apparently use the current cyclic frame to blend from. It blends directly from the root pose. Therfore my animations were not blending correctly. To fix this I setup my models with the root pose as the reference frame. My only nagging problem is they momentarily go back to the rootpose near the end of the animation. But eh, its not a milkshape problem.
Thanks again for the example. That's the most concise set of pictures and explaination on the topic I've seen yet :P
08/19/2008 (3:00 pm)
EDIT - Ehh... ok I think I understand the concept now. Thanks a ton. The Torque engine has several ways of handing blend animations apparently.For example if you are running a cyclic non blend thread, and call playthread, the current frame of the cyclic thread is used for the blend. This is why my blend sequences always look correct when played in this manner - but playthread sucks for player animation.
So I was using setactionthread which is where my blend animation problems began. setactionthread does NOT apparently use the current cyclic frame to blend from. It blends directly from the root pose. Therfore my animations were not blending correctly. To fix this I setup my models with the root pose as the reference frame. My only nagging problem is they momentarily go back to the rootpose near the end of the animation. But eh, its not a milkshape problem.
Thanks again for the example. That's the most concise set of pictures and explaination on the topic I've seen yet :P
Associate Chris Robertson