Idle animation "twitches" when viewed externally

#1 Its because the player is under no control. I.e it is not the clients control object anymore.

#2 @Westy: Okay, but why doesn't the Orc guy exhibit the same behavior? When I detach the camera from him, I just see him standing there, looping his idle animation. That's the expected behavior... There should be no movement input at all if I am detached.

#3 I get the same problem - Orc works fine, my own player twitches

Looks very dumb, and I would love to know a fix

I use it a lot when popping up GUI windows with information that the player needs to press. I detach the control object and reattach when the GUI window closes. But meanwhile the player is sitting in the background and twitching

#4 @Thomas, yeah, exact same thing I see. I'm curious, what 3D program/exporter did you use to get your model into Torque? I wonder if this is either something related to the exporter or (more likely, I think) a mis-configured model.

#5 3ds max 6 with a exporter that was fixed regarding multires (even if we still havent had the chance to test that part yet - sorry). Alex from GG released it some month ago for testing.

The root animation is our own - made with character studio in Max 6

(I dont do the modelling, so I cant tell more than that)

What about you?

#6 I'm using Lightwave 8.0 with the latest beta of GnomeTech's DTS exporter.

The model is entirely self-made, here, too. Like I said, everything looks great -- as long as the camera is attached to the model.

I'm just curious but are you using ground transforms? I wonder if this is related to it. To me, it looks like the player is trying to walk, either forward or sideways. It seems to depend on where its standing; Sometimes the "side" animation will play, other times the "run" animation.

#7 Our model is totally made from scratch too. Currently its not using ground transforms or triggers for foot prints (on the todo list). So thats not it unfortunally.

We didnt mess too much with datablock settings. Mostly jump force and removing the energy counter.

Really weird

#8 We have the same problem, and we use Maya 5 with Maya 5 DTS exporter.

As stated before, really wierd.

#9 Interesting... I'm using foot triggers, and those work fine, but I was seeing this issue before I added those.

Okay, if a Maya user and a Max user are having this problem, along with a Lightwave user -- Then I don't think this is related to the exporters at all.

It must be something with how our models are constructed, or some other issue. I guess it's time to go do some code digging and debug tracing!

#10 I dont have access to the sources at the moment, but I have disected the vehicle classes once to create my rigid shape resource.

I remember there being an "at rest" check in the collision detection if I remember correctly, where there are some buffer values for speed, energy or whatever. If they are below the threshold values, then motion will stop. Else it will try to bleed off energy.

(This is all from memory and several month ago, so dont shoot me if some details are wrong)

Maybe the player class has something similar? And maybe some conditional is set when the player is connected to the control object while its unset if the control object is detached. Maybe the "threshold" is calculated on the control object and not the player.

Just some wild ideas

#11 Buzz - anyone had any luck in looking at this?

#12 Sorry Thomas; I was on vacation all of last week.

I will try to take a look at this tonight or tomorrow. I think you are on to something with the at-rest code.

#13 Welcome back ;-)

I'm also taking a shot at the code right at this moment. Seeing if there are some obvious problems when you detach the control object.

BTW - you did see my little fix regarding the collision code for the Rigid Shape, right?

#14 OK, small update - tried to comment out the player setActionThread, updateActionThread to see if its some action animation problem. But the player is still twitching back and forth as if there is player movement.

But I think I found something in updatePos(). If you stick in a
Con::printf("**** speed %f", speed);
in the for loop
for (; count < sMoveRetryCount; count++) {
F32 speed = mVelocity.len();

, then its non-zero when you detach the camera/control object/control client.

Maybe we should take this on IRC, eh? "Man_of_Ice" is my nick on there. In the meantime I'll keep posted on progress and findings here

#15 More updates

OK - its definitely something with the scripts/mission and not the engine that triggers this. Not saying that its not a resource or anything that does this when called from script.

The same engine build exhibits this behaviour:

My own player in my game = he twitches
I tried putting the orc into my game = he twitches
I put my player into the starter.fps = no twitching
Orc in starter.fps = no twitching

The orc twitching is not easily seen - go up close and look at him and you can see he twitches.

To narrow this down, here is a list of my resources implemented into the engine:

Movie like camera system
Advanced Camera
Message routing
Rigid Shape

Using a Separate Camera Object
Adding Reactive Mission Regions
Air Control
Fixed water repeat problem
guiObjectView - Mountable Animated DTS Viewer
Synapse Lighting Pack - all but volume lighting changes


My mission has a lot of shape replicators, a few bots (tried to remove them - no change) and my terrain squaresize is changed from 8 to 4.

I also tried creating a brand new mission without anything in it, and twitching is still there

Is there any correlation between my list and the ones you implemented?

#16 Hi guys,

"Synapse Lighting Pack" nice, I'm fond of that one. :)

I don't know if this is the same issues, but a while back I noticed that my AI would twitch while idle (straight TGE 1.2). Turns out that under certain conditions AIPlayer::getMoveData (name? not near code) was being called from the client, this was causing major animation conflicts between client/server. Something similar may be happening in Player::getMoveData (name?).

I'll try to provide more info when I get home.

-John

#17 OK - thx to Paul Dana for a little sparring.

I dumped in a Con::printf in the Player::interpolateTick() to print out the delta.posVec and look whats happening:

Pos 0.000000 0.000000 0.000000
Pos 0.000000 0.000000 0.000000
Pos 0.000000 0.000000 0.000000
Pos 0.000000 0.000000 0.000000
Mapping string: dropCameraAtPlayer to index: 4
Pos -0.011951 -0.011963 -0.000038
Pos 0.007023 0.006531 0.000019
Pos -0.006004 -0.006012 -0.000019
Pos 0.011933 0.011943 0.000038

The moment I press F8 to go into observer mode, then the player is moved back and forth.

But I cant find the offender. Giving up for today now, but the above might help you narrow it down further

#18 @Thomas: I poked around with it a bit tonight, and you're on the right track. This looks like there's something wonky with the server prediction code. It keeps bumping the un-controlled player's delta vector up just a few hundreds of a point.

However, right now I am dead tired and just can't wrap my head around the delta code in player, so I will check this out again tomorrow.

Update: I saw some code in the player move routines that pertained to server-side prediction and uncontrolled objects. I suspect that's where the problem lies. But I'm at work now and can't test it out.

#19 Ahhh - I found it!!!!!

There is something wrong when you set your runForce low. I have had a hard time tracking this sucker down, but I can reproduce the problem in a clean HEAD.

The default player runForce is set to 48*90, and I lowered this in my scripts to 20*90. If I set the runForce to 20*90 in a default head player.cs it also twitches. Setting it lower seems to worsen the effect.

I'll see if I can figure out whats wrong in the player.cc code, but if you could try this and confirm?

Edit:

the "magic" number seems to be the switch from 28*90->27*90 (at least in my game). At that point things start to go wrong with visible twitching.

It might be that the twitching is present all the time, but not "large" enough to make a difference. Maybe some division by another factor that then escalates into twitching.

Edit2:

ok - it seems as if this line is part of the problem:
F32 maxAcc = (mDataBlock->runForce / mMass) * TickSec;
(player.cc line 1524)

I dumped it into excel and once maxAcc dips below a value of 1, then the twitching starts. I can adjust the mass/runForce ratio based on the excel sheet and stop the twitching.

I still have to find the offender in regards of starting the "twitch" animation. But it seems this is (part of) the reason

#20 That's right Thomas. If you want to see some real twitching, try setting the mass of the player really high. The twitching is definitely in the engine.