Interpolation problems? (Jumpy players)
by Robert Nall · in Torque Game Engine · 02/19/2004 (1:01 pm) · 122 replies
Bare with me here as I attempt to describe this, heh.
Basically, for any client connected to the game (including the super/server-client) the engine seems to have trouble positioning the other clients in the game. So say you're driving around a track and another racer shows up in your view, they will appear to be spastically warping around their general position. It's as if there were serious lag on the other player, except that nothing else is showing signs of lag. Now if you head over to that other player's screen, you'll see the opposite. His car is moving just fine and the first player's car is all over the place.
I've looked for this in the starter.racing package and not noticed anything. I seem to recall reading somewhere that the speed of an object can affect it's interpolation negatively in the TGE, might that be what's going on here? I'm also using a resource that seperates the camera from the control object, so I suppose that could be causing me problems as well.
So I was basically wondering if anyone else has run into this and knows what it is. If not, I guess I'll have to go test it more throroughly myself, heh. I just have other things on my plate right now and was hoping someone else had already run into and solved this problem before. ^_^
Thanks,
-Rob
Basically, for any client connected to the game (including the super/server-client) the engine seems to have trouble positioning the other clients in the game. So say you're driving around a track and another racer shows up in your view, they will appear to be spastically warping around their general position. It's as if there were serious lag on the other player, except that nothing else is showing signs of lag. Now if you head over to that other player's screen, you'll see the opposite. His car is moving just fine and the first player's car is all over the place.
I've looked for this in the starter.racing package and not noticed anything. I seem to recall reading somewhere that the speed of an object can affect it's interpolation negatively in the TGE, might that be what's going on here? I'm also using a resource that seperates the camera from the control object, so I suppose that could be causing me problems as well.
So I was basically wondering if anyone else has run into this and knows what it is. If not, I guess I'll have to go test it more throroughly myself, heh. I just have other things on my plate right now and was hoping someone else had already run into and solved this problem before. ^_^
Thanks,
-Rob
#82
Make the journals from a HEAD build if at all possible please. We really want to get this stuff solved, but have to know exactly how to reproduce it.
06/02/2004 (3:18 pm)
Can anybody send us a journal of the camera/transform problems? And any other problems, like the particle stuff. We tried reproducing these today, and had no luck.Make the journals from a HEAD build if at all possible please. We really want to get this stuff solved, but have to know exactly how to reproduce it.
#83
I have retested it with Tim's fix, but the problem is still there.
06/02/2004 (3:24 pm)
@Josh: Were you able to reproduce the hopping problem with the build I sent you?I have retested it with Tim's fix, but the problem is still there.
#84
on the other hand, sometimes its almost unnoticeable, sometimes its unplayable... and I'd like to stress I'm positive this isnt my setup, I've tried this on 4 seperate computers, all of which play any other game (including tribes2, and lore) with no problems under the same circumstances
06/02/2004 (3:55 pm)
From what I can tell.. reproducing these problems consists of downloading the head, compiling it and launching it, creating a dedicated server, then connecting with a client and running around... binding a key to turn and holding it down and watching your screen you see your view warp back about 20 degrees, sometimes less about every second...on the other hand, sometimes its almost unnoticeable, sometimes its unplayable... and I'd like to stress I'm positive this isnt my setup, I've tried this on 4 seperate computers, all of which play any other game (including tribes2, and lore) with no problems under the same circumstances
#85
or do you get the problem when you are the client/host in LAN/non-dedicated mode?
or do you get the problem when you connect to a remote dedicated server which isn't the same computer as the client?
06/02/2004 (4:25 pm)
Do you get the problem when you are a client connected to your own dedicated server from the same machine - basically running two copies of Legends from the same folder? (I notice tiny laggyness when I do that)or do you get the problem when you are the client/host in LAN/non-dedicated mode?
or do you get the problem when you connect to a remote dedicated server which isn't the same computer as the client?
#86
06/02/2004 (4:37 pm)
Two copies from the same folder is how I usualy run it but I've tried computer to computer and it was worse lag, however I'm open to the possiblity thats related to something else, ill let you know in a bit when I try again on a few seperates
#87
-Ron
06/02/2004 (4:48 pm)
I have also tried to reproduce the particle issues using a single PC as the dedicated and client as well as a 2-tier aproach (client and server on seperate PC's). In each case I have yet to reproduce the particle issues mentioned.-Ron
#88
06/02/2004 (4:56 pm)
Helk, I just tried to reproduce the problem following your directions with no luck. Can you create a journal for me? That seems like the only way we're going to track this problem. Using the current head, run the game using the "-jSave bug.jrn" command line option. Reproduce the bug a few times, then quit. If you play back the journal "-jPlay bug.jrn" you should see the bug (though the journal will play back faster). If the journal does in deed reproduce the bug, then email it to me: timg@garagegames.com
#89
A small number of changes were made to a clean HEAD (02/05/04) to produce this build:
- added aiWheeledClient.cc and aiWheeledClient.h: These files are based on aiClient, and provide the next move (steering/throttle) for an AI wheeled vehicle.
- modified wheeledVehicle.h and wheeledVehicle.cc to allow aiWheeledClient to access some private members
- added starter.racing/server/scripts/aiRacer.cs to setup and control the bot
- modified car.cs to use the same datablocks we are using
- modified starter.racing/server/scripts/game.cs to create the bot when the mission is loaded
- modified starter.racing/data/missions/racing.mis and racing.ter: added a path for the bot to follow, and flattened the terrain to enable higher speed racing.
I have also included a journal file (aiHopping) that displayed the strange behaviour on my machine. The behaviour is characterised by AI vehicles jerking backwards or hopping into the air. This behaviour does not occur with the human player.
You can find the build here:
http://homepages.paradise.net.nz/chrisr1/temp/hopping.zip
The zip file includes the executable as well as a copy of the starter.racing directory with the new and modified files. Just unzip it over top of a clean HEAD checkout. You will need to add aiWheeledClient.cc to the project to rebuild the executable.
When the mission is loaded, after a few seconds you will be given control of an orbit camera following the AI racer. The bot will follow a circular path until you quit the game.
Thanks to everyone helping out with this problem. :D
06/07/2004 (2:19 pm)
If anyone is interested in recreating the 'hopping' problem, here is the build that I provided to Josh.A small number of changes were made to a clean HEAD (02/05/04) to produce this build:
- added aiWheeledClient.cc and aiWheeledClient.h: These files are based on aiClient, and provide the next move (steering/throttle) for an AI wheeled vehicle.
- modified wheeledVehicle.h and wheeledVehicle.cc to allow aiWheeledClient to access some private members
- added starter.racing/server/scripts/aiRacer.cs to setup and control the bot
- modified car.cs to use the same datablocks we are using
- modified starter.racing/server/scripts/game.cs to create the bot when the mission is loaded
- modified starter.racing/data/missions/racing.mis and racing.ter: added a path for the bot to follow, and flattened the terrain to enable higher speed racing.
I have also included a journal file (aiHopping) that displayed the strange behaviour on my machine. The behaviour is characterised by AI vehicles jerking backwards or hopping into the air. This behaviour does not occur with the human player.
You can find the build here:
http://homepages.paradise.net.nz/chrisr1/temp/hopping.zip
The zip file includes the executable as well as a copy of the starter.racing directory with the new and modified files. Just unzip it over top of a clean HEAD checkout. You will need to add aiWheeledClient.cc to the project to rebuild the executable.
When the mission is loaded, after a few seconds you will be given control of an orbit camera following the AI racer. The bot will follow a circular path until you quit the game.
Thanks to everyone helping out with this problem. :D
#90
06/08/2004 (8:45 am)
No, the center of mass should still work. I'll try out Chris' hopping zip file shortly.
#91
it seems better, there is no more "jumping bean" effect, but sometimes the wheels go through the terrain. Maybe cause of Rigid::resolveCollision()... hope it helps.
06/17/2004 (6:54 am)
Chris : in WheeledVehicle::updateForce(dt), locate the 2 lines with "mCross(r,forceVector,&t);" and add "r.normalize();" just before :// Spring forces act straight up and are applied at the // spring's root position. Point3F t, forceVector = bz * (spring + damping + antiSway); //lily r.normalize(); <-- add this line mCross(r, forceVector, &t); mRigid.torque += t; mRigid.force += forceVector; ... ... // Tire forces act through the tire direction vectors parallel // to the surface and are applied at the wheel hub. forceVector = (tireX * Fx) + (tireY * Fy); pos -= bz * (wheel->spring->length * wheel->extension); mRigid.getOriginVector(pos,&r); //lily r.normalize(); <-- add this line mCross(r, forceVector, &t); mRigid.torque += t; mRigid.force += forceVector; ... ...
it seems better, there is no more "jumping bean" effect, but sometimes the wheels go through the terrain. Maybe cause of Rigid::resolveCollision()... hope it helps.
#92
(I know you weren't actually claiming the change was "correct", only that it improved the situation, just thought it was worth pointing out that it definitely isn't "correct").
06/17/2004 (8:29 am)
Lidwine - it's cool that this helps minimize the problem. I do want to point out, though, that the r vector you are normalizing isn't supposed to be normalized for rigid body mechanics to work accurately. The r vector is the offset from the center of mass, and it's magnitude modulates how much rotation you get when applying a force to a location (pos). If you fix that magnitude at 1, then you get too little rotation when the point is farther than that from the center of mass and too much when closer. That's not to say don't do it -- if it makes the simulation work better for you then it seems like a fine work around (I don't think people have an accurate sense of the amount of rotation created when applying a force to an object, so you won't flaunt any psychological laws by being a little inaccurate here). But the real problem is probably elsewhere.(I know you weren't actually claiming the change was "correct", only that it improved the situation, just thought it was worth pointing out that it definitely isn't "correct").
#93
06/17/2004 (9:27 am)
Sniff... I m not the super debugging girl I thought I was :)
#94
06/17/2004 (9:30 am)
Nah, if it makes it more stable it's good stuff regardless. Just not the final solution.
#95
06/17/2004 (9:41 am)
By the way, the fact that normalizing the r vector fixes the problem might mean that there is an error with the routine that extracts the vector, so I think you are on the right track.
#96
Tim Gift got us most of the way by adding the updateCenterOfMass function to the Rigid class, but it needed to be called in unpackUpdate after the Rigid's world position had changed.
As soon as I read Lidwine's comment about normalising the vector, it suddenly hit me, and this simple fix is the result. Just add this line in vehicle.cc in the unpackUpdate method:
06/17/2004 (7:03 pm)
The hopping is caused when the world position of the vehicle's Rigid element is modified, but it's center of mass is not updated. Calls to mRigid.getOriginVector will then return an incorrect vector. If the change in world position was large enough, the error induces a massive spring force and thus a hop.Tim Gift got us most of the way by adding the updateCenterOfMass function to the Rigid class, but it needed to be called in unpackUpdate after the Rigid's world position had changed.
As soon as I read Lidwine's comment about normalising the vector, it suddenly hit me, and this simple fix is the result. Just add this line in vehicle.cc in the unpackUpdate method:
else {
// Set the vehicle to the server position
mDelta.dt = 0;
mDelta.pos = mRigid.linPosition;
mDelta.posVec.set(0,0,0);
mDelta.rot[1] = mDelta.rot[0] = mRigid.angPosition;
mDelta.warpCount = mDelta.warpTicks = 0;
setPosition(mRigid.linPosition, mRigid.angPosition);
}
mRigid.updateCenterOfMass(); //<- add this line for no more hopping
#97
Yay, glad to have this stuff looking better!
06/17/2004 (8:18 pm)
Rocking. Great work Chris! Nice job Lidwine, and thanks to Clark as well. Yay, glad to have this stuff looking better!
#98
Good catch :) Fixing networking sync bugs is difficult and tricky work.
06/22/2004 (9:34 am)
That's awesome Chris, though now that I think about it... this is the same fix I put in for the controlling object and I should have known that it would also have been a problem for non-controlled objects :(Good catch :) Fixing networking sync bugs is difficult and tricky work.
#99
07/03/2004 (11:43 am)
Hmm... That's very odd.
#100
We have a car that seems to jerk back and forth, and printing the psotions out, it seems to move 1 unit forward / tick for 3 ticks, then 1 back, then hops forward to where it should have been making that jerky feeling even worse.
Considering the amount of time lapsed since Dave's last post and no follow-up, I fear this has fallen by the wayside. Has there been any further efforts made in this area by anyone?
Also, to get around this problem in the mean time, we put in box that looks like a car (car model, but not exported or scripted as a vehicle), and set it to run down a spline like an ai player. At each marker node, it seems to stop, flip direction, drive, flip again, and continue down to the next marker.
Any input for either of these problems would be appreciated, but obviously long-term, the first one is more important.
TIA
- JS
03/25/2005 (1:21 pm)
Using AIWheeledVehicle resource, we seem to be having a similar problem with the AI vehicle as Digital Dave was commenting on back on Jul 03, 2004.We have a car that seems to jerk back and forth, and printing the psotions out, it seems to move 1 unit forward / tick for 3 ticks, then 1 back, then hops forward to where it should have been making that jerky feeling even worse.
Considering the amount of time lapsed since Dave's last post and no follow-up, I fear this has fallen by the wayside. Has there been any further efforts made in this area by anyone?
Also, to get around this problem in the mean time, we put in box that looks like a car (car model, but not exported or scripted as a vehicle), and set it to run down a spline like an ai player. At each marker node, it seems to stop, flip direction, drive, flip again, and continue down to the next marker.
Any input for either of these problems would be appreciated, but obviously long-term, the first one is more important.
TIA
- JS
Associate Ben Garney
You are correct.