What does amArmAnimation do?
by Huan Li · in Torque 3D Professional · 05/26/2009 (8:56 pm) · 14 replies
In player class source file, there's :
what does this do?
struct ArmAnimation {
U32 action;
TSThread* thread;
} mArmAnimation;
TSThread* mArmThread;what does this do?
#2
Thanks,
So , i think the arm thread may be a nearly static animation, just a weapon-carring animation, right?
05/26/2009 (10:52 pm)
@MichealThanks,
So , i think the arm thread may be a nearly static animation, just a weapon-carring animation, right?
#3
05/26/2009 (11:07 pm)
Pretty much, from my own understanding of it anyway. It may have another use, but that's what I've used it for. 
#4
That control is an additional control,do not confuse with the main animation thread.
You can add a lot of threads,that they control a lot of body parts.
For example if you play run animation and if pass nearby enemy.
Then you may want your player to watch the enemy while running.
That is impossible to do in a single thread,because you can advance only a single sequence on it,not both of them.
You need to create a thread for the head and play an animation for it.
The main thread controls the rest of the body in its lower priority.
Every additional thread is programmed depending on its own functionality.
05/27/2009 (2:01 am)
There is added an extra thread,that controls a body part.That control is an additional control,do not confuse with the main animation thread.
You can add a lot of threads,that they control a lot of body parts.
For example if you play run animation and if pass nearby enemy.
Then you may want your player to watch the enemy while running.
That is impossible to do in a single thread,because you can advance only a single sequence on it,not both of them.
You need to create a thread for the head and play an animation for it.
The main thread controls the rest of the body in its lower priority.
Every additional thread is programmed depending on its own functionality.
#5
The sequence also needs a higher priority than the other body animations so it can override the motion for bones it animates.
05/27/2009 (7:56 am)
In Player::updateLookAnimation() you can see how the arm animation is used: it's static, and the Player sets its position based on the vertical look angle. So, the arm sequence should contain the character aiming down at the start, aiming forward at the middle and aiming up at the end.The sequence also needs a higher priority than the other body animations so it can override the motion for bones it animates.
#6
So, just so i am sure about what was explained here, using this i could have a character's legs play a walk animation while the upper torso/arms/legs play a talk animation where the character waves hands around to enphasize what he says - while actually having those two animations set up separatly (one walk + one talk instead of one walk + one talk + one talk while walking)???
05/28/2009 (11:14 am)
Nice - was wondering how to get around to do something like that.So, just so i am sure about what was explained here, using this i could have a character's legs play a walk animation while the upper torso/arms/legs play a talk animation where the character waves hands around to enphasize what he says - while actually having those two animations set up separatly (one walk + one talk instead of one walk + one talk + one talk while walking)???
#7
For players talking, you want to use the ShapeBase PlayThread(), which runs in parallel to the player's movement animations. With them you can play animations on top of the current movement animation. If your talk animation only moves the upper torso joints, and has a higher priority than root, run, etc, it will allow the legs to keep moving while the arms and head do the talk animation.
Beware that there's no way to destroy a thread via script, so when you're done talking you can use a empty animation with priority lower than all others to "clean" a thread channel.
05/28/2009 (12:49 pm)
@Luis: Not quite. The arm animation is static, it doesn't play over time, the animation "time" is set based on the vertical aiming angle. If the player is looking forward, the animation is at it's middle, if the player is looking up, the animation is set to its end, etc.For players talking, you want to use the ShapeBase PlayThread(), which runs in parallel to the player's movement animations. With them you can play animations on top of the current movement animation. If your talk animation only moves the upper torso joints, and has a higher priority than root, run, etc, it will allow the legs to keep moving while the arms and head do the talk animation.
Beware that there's no way to destroy a thread via script, so when you're done talking you can use a empty animation with priority lower than all others to "clean" a thread channel.
#8
But you miss one thing - when using a lot of sequences on various threads, he will need a transition.
ShapeBase doesn't have that option.
Yes,there is a resource,but when controlling a new thread,you will need an extra control over it (when various runtime circumstances happened).
This is the thing,that made my way to use the c++ transition.
You need also something,that ticks.
The advancetime() only advances the animation (as a time generator),but it doesn't know where to stop or where to do the transition.
I made a precise timer and used it on.
And there is something,that you miss too.
When using different prioritys,there is something,that you'll need for the control return.
But i won't tell you,i am sure you will guess it.
My player is controlled by 3 threads all the time with no problem.
And i think to extend it to 5,i want to add new sequences like 'talk'.
As i said,every additional thread is programmed depending on its own functionality.
05/28/2009 (1:12 pm)
Playlore,you are right.But you miss one thing - when using a lot of sequences on various threads, he will need a transition.
ShapeBase doesn't have that option.
Yes,there is a resource,but when controlling a new thread,you will need an extra control over it (when various runtime circumstances happened).
This is the thing,that made my way to use the c++ transition.
You need also something,that ticks.
The advancetime() only advances the animation (as a time generator),but it doesn't know where to stop or where to do the transition.
I made a precise timer and used it on.
And there is something,that you miss too.
When using different prioritys,there is something,that you'll need for the control return.
But i won't tell you,i am sure you will guess it.
My player is controlled by 3 threads all the time with no problem.
And i think to extend it to 5,i want to add new sequences like 'talk'.
As i said,every additional thread is programmed depending on its own functionality.
#9
05/29/2009 (4:30 am)
Ok - thank you both for the info - will look into that then
#10
05/29/2009 (6:20 am)
Picasso, you're right. The PlayThread() doesn't transitions (but it's trivial to make it do so by replacing one line of code), and for 100% control adding a custom talk/torso thread directly to Player is ideal. 
#11
06/11/2009 (7:56 pm)
This may be best suited for a new post, but I have a question about how SetArmThread() is used now in Torque 3D script. With TGEA I had incorperated the simple melee system into both the source code and the script. Most of the melee animations were called with a setArmThreadPlayOnce(%attack.seqName) command wich called a version of setArmThread in the player.cc. Now I have started a fresh build of the source code without any of the melee code and have simply tried calling a function in the script such as setarmthread("swing"); As soon as the function executes the game crashes on me. If I use SetActionThread("swing") the animation performs, but obviously without the blend which makes it useless for what I need. Is SetArmThread() no longer supported in script(as I see it is still in the source code)? If it is, is there a new synthax for it?
#12
If it is 0(NULL),try this at the beginning of setArmThread:
When you have only a look animation, it is initialized to 0.
06/12/2009 (1:30 am)
Send mArmAnimation.thread to the console.If it is 0(NULL),try this at the beginning of setArmThread:
if(mArmAnimation.thread == NULL) mArmAnimation.thread = mShapeInstance->addThread();
When you have only a look animation, it is initialized to 0.
#13
Second, even if you have a "look" animation your swing animation will not play. That's not how armThread works. ArmThread works exactly like the "head" and "headside" animations: it does not play over time, the playback position is attached to the player's vertical looking angle. See for yourself, that's how the player updates the arm thread, in Player::updateLookanimation():
06/12/2009 (6:00 am)
First, you *need* a sequence called "look" in order to create mArmAnimation.thread, otherwise its null and any call to setArmThread() will promptly crash the engine.Second, even if you have a "look" animation your swing animation will not play. That's not how armThread works. ArmThread works exactly like the "head" and "headside" animations: it does not play over time, the playback position is attached to the player's vertical looking angle. See for yourself, that's how the player updates the arm thread, in Player::updateLookanimation():
if (mArmAnimation.thread)
{
// TG: Adjust arm position to avoid collision.
F32 tp = mControlObject? 0.5:
(renderHead.x - mArmRange.min) / mArmRange.delta;
mShapeInstance->setPos(mArmAnimation.thread,mClampF(tp,0,1));
}
#14
06/12/2009 (7:00 am)
Actually you're right.const char *lookName = StringTable->insert("look");
for (int c = 0; c < actionCount; c++,dp++)
if (dp->name == lookName)
lookAction = c; 
Associate Michael Hall
Distracted...