Characters are not animating
by Jason MacWilliams · in Artist Corner · 04/01/2008 (11:07 am) · 4 replies
We have been having lots of troubles lately with our characters not animating and we cannot find a solution. We are using 3dsmax 9 with exporter 0.900r(dtsv1.24) and TGE 1.5.2. We have 6 different skeletons on our characters: 2 of them are 3dsmax bipeds, while 4 are custom skeletons renamed using the biped naming convention with some extra bones added and some bones removed (depending on the character). We had to implement a fix from 216.116.32.49/mg/forums/result.thread.php?qt=16831 to get the custom skeletons to not crash.
The problem we are seeing seems to be isolated to the non-biped characters (even though they've been renamed). All of the biped characters are animating correctly in all cases but the non-biped characters do not. We have the client and some aiplayers using biped skeletons and they all work fine. But there are some aiplayers that use our non-biped skeletons and they do not animate properly. We've looked at such fixes as 216.116.32.49/index.php?sec=mg&mod=resource&page=view&qid=11218, but they have been unable to fix the problem.
When the aiplayers try to animate, some of their bones (not all) are moving but not through every frame in the sequence (so arms are lifting part way up and such). The degree to which the bones animate (or refuse to animate) is model dependent, so some models will play more of their animations, while in some cases they will play nothing. **BUT BIG PROBLEM** sometimes (rarely), one of these problem models will play an entire sequence properly when asked (using setactionthread, or playthread - both of which yield the same results).
Considering this problem with the aiplayers we replaced the client's model with one of these problem models and the new client worked correctly in all tests. And putting the client in the game world right next to the same model aiplayer, the aiplayer still does not animate where the client does. We have never had this issue on the client's character, only on aiplayers (and inconsistently). To restate the ***BIG PROBLEM*** from above, the aiplayers still can (rarely) work correctly.
We checked the animation problem with showtool and showtool pro and those two programs both showed the models animating correctly, but they still fail in-game. We've read up on the numerous threads that talk of this behaviour and found nothing.
So a couple of concluding points/questions:
1) AIPlayers are not animating correctly, but sometimes (rarely) will play a single sequence right.
2) AIPlayers will never play any animation twice in a row, so if you play the "wave" animation, you have to play some other sequence before you can play "wave" again.
3) All of the animation tests we've performed are with the console functions setActionThread("...") or playThread(0, "..."), none of them are ever being invoked by the engine.
4) Is there a bone per character limit that could be causing the problem?
5) Is there a keyframe per sequence that could be causing the problem?
The problem we are seeing seems to be isolated to the non-biped characters (even though they've been renamed). All of the biped characters are animating correctly in all cases but the non-biped characters do not. We have the client and some aiplayers using biped skeletons and they all work fine. But there are some aiplayers that use our non-biped skeletons and they do not animate properly. We've looked at such fixes as 216.116.32.49/index.php?sec=mg&mod=resource&page=view&qid=11218, but they have been unable to fix the problem.
When the aiplayers try to animate, some of their bones (not all) are moving but not through every frame in the sequence (so arms are lifting part way up and such). The degree to which the bones animate (or refuse to animate) is model dependent, so some models will play more of their animations, while in some cases they will play nothing. **BUT BIG PROBLEM** sometimes (rarely), one of these problem models will play an entire sequence properly when asked (using setactionthread, or playthread - both of which yield the same results).
Considering this problem with the aiplayers we replaced the client's model with one of these problem models and the new client worked correctly in all tests. And putting the client in the game world right next to the same model aiplayer, the aiplayer still does not animate where the client does. We have never had this issue on the client's character, only on aiplayers (and inconsistently). To restate the ***BIG PROBLEM*** from above, the aiplayers still can (rarely) work correctly.
We checked the animation problem with showtool and showtool pro and those two programs both showed the models animating correctly, but they still fail in-game. We've read up on the numerous threads that talk of this behaviour and found nothing.
So a couple of concluding points/questions:
1) AIPlayers are not animating correctly, but sometimes (rarely) will play a single sequence right.
2) AIPlayers will never play any animation twice in a row, so if you play the "wave" animation, you have to play some other sequence before you can play "wave" again.
3) All of the animation tests we've performed are with the console functions setActionThread("...") or playThread(0, "..."), none of them are ever being invoked by the engine.
4) Is there a bone per character limit that could be causing the problem?
5) Is there a keyframe per sequence that could be causing the problem?
#2
We have found 1 thing strange, we exported one of our broken characters with the animations in a separate dsq (instead of internal to the dts) so we could remove the skin/model data and keep only the skeleton data in the sequence and it generated different behaviour than when we exported the entire model and sequence in a single dts.
04/02/2008 (6:35 am)
So, it could very well be a programming issue but it's also an animation problem so I wanted to see if anyone here knew anything about it. I saw that lots of people on the art forums had similar problems, but nobody posted a solution (or even a partial solution). So, I'm curious how many other people have encountered these particular symptoms and if they discovered anything about them?We have found 1 thing strange, we exported one of our broken characters with the animations in a separate dsq (instead of internal to the dts) so we could remove the skin/model data and keep only the skeleton data in the sequence and it generated different behaviour than when we exported the entire model and sequence in a single dts.
#3
04/02/2008 (12:16 pm)
Jason, this is strange, you shoudn't have any problem separating to dts/dsq's. You didn't say how you test the exported animations. Since you use "-show" or TST your problem is an export issue. In situation like yours it's quite difficult to tell where the problem exactly is. One assumption is that you haven't keyed some of the bones in animation begin/end frames (the sequence begin/end frames). A good decision is to add a minor animation to the bones in the begin/end of the sequence. Another assumption is that you haven't set up properly the *.cfg file.
#4
On a whim I was pointed to a change we made in the animation system (supposed to make life easier) where we multithreaded the animations in-game so we could swap out upper body weapon poses (like holding a pistol vs. a machinegun) and blend them onto the move animations so we didn't need hundreds of sequences and specialty code to select them. So, certain models were not using the additional threads (no weapon poses - just full body anims) and that caused a problem, and TSTPro agreed when we added more threads in the thread control.
Anyway, there were blending problems (I guess blending null animations or something), so we exported all the animations for the broken characters with blend enabled and now they're all playing properly.
Thanks for the help.
04/03/2008 (10:18 am)
FIXEDOn a whim I was pointed to a change we made in the animation system (supposed to make life easier) where we multithreaded the animations in-game so we could swap out upper body weapon poses (like holding a pistol vs. a machinegun) and blend them onto the move animations so we didn't need hundreds of sequences and specialty code to select them. So, certain models were not using the additional threads (no weapon poses - just full body anims) and that caused a problem, and TSTPro agreed when we added more threads in the thread control.
Anyway, there were blending problems (I guess blending null animations or something), so we exported all the animations for the broken characters with blend enabled and now they're all playing properly.
Thanks for the help.
Torque Owner Ivan Mandzhukov
Liman3D