Animation threading issue
by Justin Woods · in Torque Game Engine · 03/18/2006 (1:03 pm) · 4 replies
I know similar issues to this have arisen many times, but it doesn't seem that anyone has ever found a viable solution to fix them.
We are having a animation transition problem. When the player loads into the level he plays his root just fine. Then if the player moves forward or plays animations other than his root things start to go wrong. The result is aniamtions that are mixing together.
For example if the player plays an atack animation while runing, then from that point on the players run will be some wierd mix of both the run and atack. This problem exists even after the player dies. The only way to fix it is to restart the level.
Essentialy we are having animations that work fine in the Showtool Pro but when they are played in the game they mix together into 50/50 broken animations. Here is an image sort of showing what happens.
To avoid this problem, most people just adapt their characters to be more similar to the orc. This is not a valid solution for us, as we have characters that are more complicated and interesting.
I have developed two theories as to why this problem may be occuring.
1) The TSShapeInstance class takes in a TSTread. Within TSShapeInstance there are several member functions that catch my eye. They all deal with threads and sequences. These are ::transitionToSequence, ::clearTransition, ::setSequence, ::setBlendEnabled, ::getBlendEnabled, and ::getTime.
However, I have not found a definitive place in the engine source where a TSThread is passing in the required numbers for these functions to work. I think it is partially that I don't understand how that happens. For example, in player.cc I have found several instances of cross multiplication regarding "TSTread" X "thread".
The reason I am facinated by this approach is because it seems that there may be an issue with sequence lengths. If the engine expects an animation to take 1.5 seconds, and it takes 1.2 or 1.7 it could be causing two sequences to collide. This is just a theory, but it seems very reasonable.
2) The other thing I have noticed resides in player.cs. In this file when you create a player datablock you pass in a lot of numbers regarding run speed, etc. Do these numbers perhaps get passed into the engine to determine automatically how long certain sequences should play?
If so, what is the algorithm? This is very confusing to me because I am using the same numbers for all of my characters, yet a couple of my characters have absolutely no blending issues.
Please help in any way possible.
We are having a animation transition problem. When the player loads into the level he plays his root just fine. Then if the player moves forward or plays animations other than his root things start to go wrong. The result is aniamtions that are mixing together.
For example if the player plays an atack animation while runing, then from that point on the players run will be some wierd mix of both the run and atack. This problem exists even after the player dies. The only way to fix it is to restart the level.
Essentialy we are having animations that work fine in the Showtool Pro but when they are played in the game they mix together into 50/50 broken animations. Here is an image sort of showing what happens.
To avoid this problem, most people just adapt their characters to be more similar to the orc. This is not a valid solution for us, as we have characters that are more complicated and interesting.
I have developed two theories as to why this problem may be occuring.
1) The TSShapeInstance class takes in a TSTread. Within TSShapeInstance there are several member functions that catch my eye. They all deal with threads and sequences. These are ::transitionToSequence, ::clearTransition, ::setSequence, ::setBlendEnabled, ::getBlendEnabled, and ::getTime.
However, I have not found a definitive place in the engine source where a TSThread is passing in the required numbers for these functions to work. I think it is partially that I don't understand how that happens. For example, in player.cc I have found several instances of cross multiplication regarding "TSTread" X "thread".
The reason I am facinated by this approach is because it seems that there may be an issue with sequence lengths. If the engine expects an animation to take 1.5 seconds, and it takes 1.2 or 1.7 it could be causing two sequences to collide. This is just a theory, but it seems very reasonable.
2) The other thing I have noticed resides in player.cs. In this file when you create a player datablock you pass in a lot of numbers regarding run speed, etc. Do these numbers perhaps get passed into the engine to determine automatically how long certain sequences should play?
If so, what is the algorithm? This is very confusing to me because I am using the same numbers for all of my characters, yet a couple of my characters have absolutely no blending issues.
Please help in any way possible.
#2
So, I think we maybe talking about different things:
I haven't used "blends" at all. To clarify, I haven't been clicking the "blend" option in the sequence helper.
What Justin was trying to say was, we are having issues with "transitions" - the short segements of time where the engine interpolates between the end of one sequence and the beginning of another.
I'm pretty sure the engine is getting jammed up trying to animate and release various animated nodes.
A possible reason for this:
The transition periods for animations seems WAY too long. I believe Justin is looking for information regarding transition settings/lengths. Numbers seem to be tossed around everywhere - including in the weapon scripting.
To make matters more complicated, we have implemented the melee combat resource.
An Overview in case it helps: the game is third-person, melee combat game. The problem is most of the documentation etc. is based upon the Orc, where the upper body is "fixed" - the only real animation to consider is the legs.
However, i need to animate the entire body in almost every animation. We have ninja style characters who are very agile. Fully body runs, flips, spinning etc. Can you point me to a tutorial or something that talks more about threading and its interactions?
....ugh, I am also pretty sure that my rotations of the bip01 and/or pelvis are causing issues - I have been searching the forums for info regarding any limitations on rotating the bip01/pelvis to no avail.
Anway, I hope this clarified a bit.... We are definately interested in any feedback.
Thanks.
03/18/2006 (10:43 pm)
Hello. I'm doing the animations for this project. This is my first time animating for Torque. I have read the documentation regarding threading etc. It was a little.... less than clear on the topic. So, I think we maybe talking about different things:
I haven't used "blends" at all. To clarify, I haven't been clicking the "blend" option in the sequence helper.
What Justin was trying to say was, we are having issues with "transitions" - the short segements of time where the engine interpolates between the end of one sequence and the beginning of another.
I'm pretty sure the engine is getting jammed up trying to animate and release various animated nodes.
A possible reason for this:
The transition periods for animations seems WAY too long. I believe Justin is looking for information regarding transition settings/lengths. Numbers seem to be tossed around everywhere - including in the weapon scripting.
To make matters more complicated, we have implemented the melee combat resource.
An Overview in case it helps: the game is third-person, melee combat game. The problem is most of the documentation etc. is based upon the Orc, where the upper body is "fixed" - the only real animation to consider is the legs.
However, i need to animate the entire body in almost every animation. We have ninja style characters who are very agile. Fully body runs, flips, spinning etc. Can you point me to a tutorial or something that talks more about threading and its interactions?
....ugh, I am also pretty sure that my rotations of the bip01 and/or pelvis are causing issues - I have been searching the forums for info regarding any limitations on rotating the bip01/pelvis to no avail.
Anway, I hope this clarified a bit.... We are definately interested in any feedback.
Thanks.
#3
I'm not an artist, and I'm waiting/hoping one is going to step in here to confirm and clear up the topic for you, but that right there is most probably what your problem is. Without having your animations able to blend with other animations, they cannot smoothly interact with other transitions which is where the transition time issues are coming up. Again, I am -not- an artist, so it's possible that you can still do what you want with non-blended animations, but doing a programmer's inspection of the orc in showtool, you can see this concept by studying the sequence properties of the animations such as player_forward (which is NOT set to blend, but the other threads blend with this one), player_recoilde , and especially player_dance.
Base Blending and Animation setup tutorial
03/19/2006 (7:45 am)
Quote:
I haven't used "blends" at all. To clarify, I haven't been clicking the "blend" option in the sequence helper.
I'm not an artist, and I'm waiting/hoping one is going to step in here to confirm and clear up the topic for you, but that right there is most probably what your problem is. Without having your animations able to blend with other animations, they cannot smoothly interact with other transitions which is where the transition time issues are coming up. Again, I am -not- an artist, so it's possible that you can still do what you want with non-blended animations, but doing a programmer's inspection of the orc in showtool, you can see this concept by studying the sequence properties of the animations such as player_forward (which is NOT set to blend, but the other threads blend with this one), player_recoilde , and especially player_dance.
Base Blending and Animation setup tutorial
#4
First, there is blending and then there is transtioning. In the TGE, these are two separate things.
Blends allow you to play animations on separate threads on top of each other by additively adding the animation of any bone on top of other bones.
Transitioning is automatic and simply does a linear blend from one animation to the other animation over time on a node by node basis.. the length of the transition is somewhere in code ( I forget where) and it is be default set to about a second. It only works on a single animation thread, and all it does is make it so there is no 'pop' in the animation.
depending on what you are attempting, there are several ways to control it.. you can make sure that only certain nodes are animating in certain animations to manually control node collisions.. you can use blends to add animation on top of other animations. you can use priorities to make sure that if a non blended animation is playing on top of another, that it is the one that takes precedence.
if you are doing full upper body animation along with movement animations, I would use non-blended animations with a differing priority with some manual control over the nodes being exported for that sequence to ensure no node collisions.
as to the problems you are having.. I have never heard of anything like this.. but it really sounds like it is not an engine problem, but more of a misundetstanding of how the animation system works and how you are trying to use it.
transitioning only happens on one thread.. having it go from one sequence to another and have it look like there are two animations fighting makes no sense.. potentially, if a sequence is set to non looping it can get into a situation where the transition never makes it to the end of the next sequence (because the transtion time exceeds the length of the non looping animation), but this does not sound like what is going on here.
I never looked at the melee resource, but from what little I know of it, it works by hi-jacking the arm and look threads from in the player to work for melee attacks.. if this is the case, and you are not using blend animations, then that could account for some of the problems as you would have a few animation threads playing and fighting for control of the same nodes.
For me to be of any assitance here, it would be great to get a description of what it is you are attempting to do.. how you are attempting to do it, and the results of any tests.. screen shots are better, the illustration above does not give me enough to go on.
also, differences of animations in the showtool and the game would be helpful in narrowing it down.
03/19/2006 (12:45 pm)
I can try to help, but some things will need to be clarified, and then a more in depth description of what you are doing needs to be put forth.First, there is blending and then there is transtioning. In the TGE, these are two separate things.
Blends allow you to play animations on separate threads on top of each other by additively adding the animation of any bone on top of other bones.
Transitioning is automatic and simply does a linear blend from one animation to the other animation over time on a node by node basis.. the length of the transition is somewhere in code ( I forget where) and it is be default set to about a second. It only works on a single animation thread, and all it does is make it so there is no 'pop' in the animation.
depending on what you are attempting, there are several ways to control it.. you can make sure that only certain nodes are animating in certain animations to manually control node collisions.. you can use blends to add animation on top of other animations. you can use priorities to make sure that if a non blended animation is playing on top of another, that it is the one that takes precedence.
if you are doing full upper body animation along with movement animations, I would use non-blended animations with a differing priority with some manual control over the nodes being exported for that sequence to ensure no node collisions.
as to the problems you are having.. I have never heard of anything like this.. but it really sounds like it is not an engine problem, but more of a misundetstanding of how the animation system works and how you are trying to use it.
transitioning only happens on one thread.. having it go from one sequence to another and have it look like there are two animations fighting makes no sense.. potentially, if a sequence is set to non looping it can get into a situation where the transition never makes it to the end of the next sequence (because the transtion time exceeds the length of the non looping animation), but this does not sound like what is going on here.
I never looked at the melee resource, but from what little I know of it, it works by hi-jacking the arm and look threads from in the player to work for melee attacks.. if this is the case, and you are not using blend animations, then that could account for some of the problems as you would have a few animation threads playing and fighting for control of the same nodes.
For me to be of any assitance here, it would be great to get a description of what it is you are attempting to do.. how you are attempting to do it, and the results of any tests.. screen shots are better, the illustration above does not give me enough to go on.
also, differences of animations in the showtool and the game would be helpful in narrowing it down.
Torque 3D Owner Stephen Zepp
Many animations in Torque are blended--there are 3 primary animation threads all being phased together simultaneously, and you can't consider them apart from each other and have proper looking animations. Since they are additive blends, all of the initial key frames have to be synchronized properly for proper combination.
You may want to take a very close look at the stock animations themselves while keeping in mind that they add together, and see if a light comes on for your animators, or study the tutorials in TDN and the general documentation to see the theory behind the concept.