Interpolation issues ?
by Eric Roberts · in Torque Game Engine · 07/28/2005 (2:05 pm) · 12 replies
Hey all,
I've been recently playing around with trying to impliment a simple AI object derived from ShapeBase. The only recent snag that I've been caught on for the past few days has had me stumped with my debugger, single stepping through, oodles of breakpoints and the like.
When I ask for my simple AI object to move to a certain location, it does so quite obdiently and smoothly (interpolated properly AFAIK) - until it gets to the specified location. It looks like it passes by the specified location just slightly then snaps back to the location. Movement is smooth getting there - just when it decides to stop is the problem. Possibly moving past the object by a single tick - or less? My interpolation system used is very similar to the one used for the player.
Movement is set on the server by setting a velocity vector - and then it's sent to a client. On the server when the server deems it ready it sets the velocity to zero and sends the information to the client (in packUpdate) that we've come to a complete stop.
But this is only for just movement - rotating to a specified degree has the same problem (using the same system above). Just rotates slightly past its position - then snaps back into the correct position.
I suspect it's an interpolation issue - or maybe some data getting out of sync - or both? How? I'm running a single-player server.
How does the AIPlayer deal with this? It doesn't seem to have any of these problems when it comes to moving to a specified location or rotating to a specific orientation? Filling in move structs? It's not a control object is it? So how - or why is it filling in move structs? Is it trying to emulate a sort of control object?
Of course your time is greatly appreciated in advanced,
- Eric
I've been recently playing around with trying to impliment a simple AI object derived from ShapeBase. The only recent snag that I've been caught on for the past few days has had me stumped with my debugger, single stepping through, oodles of breakpoints and the like.
When I ask for my simple AI object to move to a certain location, it does so quite obdiently and smoothly (interpolated properly AFAIK) - until it gets to the specified location. It looks like it passes by the specified location just slightly then snaps back to the location. Movement is smooth getting there - just when it decides to stop is the problem. Possibly moving past the object by a single tick - or less? My interpolation system used is very similar to the one used for the player.
Movement is set on the server by setting a velocity vector - and then it's sent to a client. On the server when the server deems it ready it sets the velocity to zero and sends the information to the client (in packUpdate) that we've come to a complete stop.
But this is only for just movement - rotating to a specified degree has the same problem (using the same system above). Just rotates slightly past its position - then snaps back into the correct position.
I suspect it's an interpolation issue - or maybe some data getting out of sync - or both? How? I'm running a single-player server.
How does the AIPlayer deal with this? It doesn't seem to have any of these problems when it comes to moving to a specified location or rotating to a specific orientation? Filling in move structs? It's not a control object is it? So how - or why is it filling in move structs? Is it trying to emulate a sort of control object?
Of course your time is greatly appreciated in advanced,
- Eric
About the author
#2
I considered that alternative method a while ago but I tried not to give up on the method I was currently working on - I was (and still kind of am) convinced I could get it to work. But your RTS example swayed me to back up my old implimentation and do a re-write of the positioning/movement code by sending the destination point.
This implimentation is completely different then the last implimentation.
Same results.
Did you have to do any checks inside the interpolateTick function to see if the reached the position in RTS?
I don't think you need to... I've set it so when the object gets close enough that his velocity and the tick will carry him past the point of interest - I just set his new position to the destination position sent by the server (and update my StateDelta struct apropriately). But unfortunately he still overshoots just a little (sometimes) and snaps back. Would doing this in ProcessTick (actually in a func called by ProcessTick), which is only called on the 32 ms tick, cause a problem? Even though I checked to see if it would overshoot?
I checked the positions sent by the server - and the ones recieved by the client. They're only different to a thousandth - not enough to explain for the snap.
Also if I open up the map editor and click on the object to see it's box. The box stays perfectly where it's supposed to go, so no snap on the box itself. I'm guessing this should provide a clue (like it works fine on the server?) - but I'm not sure how to interpret it.
Thank you so much for you help,
- Eric
07/28/2005 (8:18 pm)
Thank you Ben for your fast reply.I considered that alternative method a while ago but I tried not to give up on the method I was currently working on - I was (and still kind of am) convinced I could get it to work. But your RTS example swayed me to back up my old implimentation and do a re-write of the positioning/movement code by sending the destination point.
This implimentation is completely different then the last implimentation.
Same results.
Did you have to do any checks inside the interpolateTick function to see if the reached the position in RTS?
I don't think you need to... I've set it so when the object gets close enough that his velocity and the tick will carry him past the point of interest - I just set his new position to the destination position sent by the server (and update my StateDelta struct apropriately). But unfortunately he still overshoots just a little (sometimes) and snaps back. Would doing this in ProcessTick (actually in a func called by ProcessTick), which is only called on the 32 ms tick, cause a problem? Even though I checked to see if it would overshoot?
I checked the positions sent by the server - and the ones recieved by the client. They're only different to a thousandth - not enough to explain for the snap.
Also if I open up the map editor and click on the object to see it's box. The box stays perfectly where it's supposed to go, so no snap on the box itself. I'm guessing this should provide a clue (like it works fine on the server?) - but I'm not sure how to interpret it.
Thank you so much for you help,
- Eric
#3
I believe in the interpolate tick I always interpolated between the previous value and the value I'd calculated for the current tick. So, should not be possible to overstep. What happens if you set $timeScale to 0.2 or so?
07/28/2005 (11:46 pm)
Boxes in the world editor are for the server side objects; the rendered stuff is client side.I believe in the interpolate tick I always interpolated between the previous value and the value I'd calculated for the current tick. So, should not be possible to overstep. What happens if you set $timeScale to 0.2 or so?
#4
So what does that mean? ;)
It seems like its definately a client-side issue - but I don't understand why turning down the timeScale factor would automagically seem to get rid of that 'snapping' issue.
Thanks again,
- Eric
07/29/2005 (8:29 am)
When I set $timeScale to around 0.2 - there's no overshooting. Never goes past it's position and snaps back. The issue vanishes.So what does that mean? ;)
It seems like its definately a client-side issue - but I don't understand why turning down the timeScale factor would automagically seem to get rid of that 'snapping' issue.
Thanks again,
- Eric
#5
07/29/2005 (6:02 pm)
Maybe it's a frame rate dependent problem?
#6
07/29/2005 (10:20 pm)
This sounds like the same problem we have for the player with turning and being snapped back... It could be the same bug.
#7
Alright, well for now I'll move on to other things. I want to get to the prototyping part first!
Simple AI is a necessity for my design so I need it for the prototyping part.
Ah well, I can deal with the snapping for now. Hopefully I'll return to the problem later and find it, or if it's related to the player 'snapping' then hopefully someone else will find the bug before I have to :).
I'll post it here if I find a solution in the mean time.
- Eric
07/30/2005 (10:30 am)
Frame rate dependent? I thought TGE was strictly frame rate independent...Alright, well for now I'll move on to other things. I want to get to the prototyping part first!
Simple AI is a necessity for my design so I need it for the prototyping part.
Ah well, I can deal with the snapping for now. Hopefully I'll return to the problem later and find it, or if it's related to the player 'snapping' then hopefully someone else will find the bug before I have to :).
I'll post it here if I find a solution in the mean time.
- Eric
#8
07/31/2005 (1:03 pm)
TGE is frame rate independent in things that are significant (interpolation won't alter gameplay much if any), but there could be a bug in the interpolateTick code that is causing some things to behave differently depending on framerate (since interpolateTick is called every frame). This would explain why changing the timeScale "fixed" the problem.
#9
It still beats me why timeScale fixed the problem - but at least the current problem is fixed.
The next problem comes from it snapping when I start to move away from it and it tries to follow, it snaps towards me into position for quite a while until I get a farther enough distance away from it. What kills me is now that I've been only having to worry about the setting the velocities correctly - why it should be snapping (into position) at all.
Thanks again for your help.
- Eric
08/01/2005 (7:12 pm)
Just as a small update - I did manage to fix the snap at the END of the AIShape's journey. As I suspected, it was an interpolation issue, but not what I had previously thought. When I implimented collision for the object I basically copied over a large chunk of the code found in player.cc. I knew that all the codeblock needed was a correct velocity - it would take care of setting the StateDelta sturcture properly for me (it's been tried, tested and true). It still snapped ocassionally - but I was finally able to correct this by only focusing on the velocities set (not any of the interpolation code or any of the data in the StateDelta structure). I can't remember the fix exactly, but it was anything far from significant - thank you all.It still beats me why timeScale fixed the problem - but at least the current problem is fixed.
The next problem comes from it snapping when I start to move away from it and it tries to follow, it snaps towards me into position for quite a while until I get a farther enough distance away from it. What kills me is now that I've been only having to worry about the setting the velocities correctly - why it should be snapping (into position) at all.
Thanks again for your help.
- Eric
#10
08/03/2005 (4:34 pm)
$timeScale is an excellent way to make sure that all of your code interpolates properly, has no framerate dependencies, and so forth. We used it extensively when developing the RTSUnit class in the RTS SK; very useful.
#11
I really wish it said somewhere in the docs about the "warp"ing buisness. It seemed to me that warping would only occur when multiplayer was involved, and there was packet loss, etc... (and I was sticking to strictly a singleplayer frame of mind). Early on in development to investigate this "warp"ing buisness, I set a breakpoint in one of the player "warp"ing conditions. As I moved and jumped around - it never broke once. So I didn't think to worry about it when implimenting my simple AIShape - or just simply impliment it later (if I wanted multiplayer).
Boy was I wrong.
I know very little about "warp"ing or why it happens. But realizing that it was related to interpolation somehow and almost as a last attempt at finding a problem I ended up re-investigated the whole thing. "Warp"ing seems to happen quite a bit when it's NOT the control object! As soon as I discovered this today, within 2 hours and some copy and pasting and adjusting here and there from player.cc and all my interpolation problems vanished.
So it works, I'm just really dissapointed that this seeming lack of documentation (and I guess a bad assumption and turn of events on my part) caused far too many days of frustration and complete bewilderment.
And btw - my old velocity implimentation works fine :P. I knew it should've worked! But I'm going to keep the new implimentation anyway.
Thanks again,
- Eric
08/04/2005 (1:05 pm)
Problem resolved (AFAIK).I really wish it said somewhere in the docs about the "warp"ing buisness. It seemed to me that warping would only occur when multiplayer was involved, and there was packet loss, etc... (and I was sticking to strictly a singleplayer frame of mind). Early on in development to investigate this "warp"ing buisness, I set a breakpoint in one of the player "warp"ing conditions. As I moved and jumped around - it never broke once. So I didn't think to worry about it when implimenting my simple AIShape - or just simply impliment it later (if I wanted multiplayer).
Boy was I wrong.
I know very little about "warp"ing or why it happens. But realizing that it was related to interpolation somehow and almost as a last attempt at finding a problem I ended up re-investigated the whole thing. "Warp"ing seems to happen quite a bit when it's NOT the control object! As soon as I discovered this today, within 2 hours and some copy and pasting and adjusting here and there from player.cc and all my interpolation problems vanished.
So it works, I'm just really dissapointed that this seeming lack of documentation (and I guess a bad assumption and turn of events on my part) caused far too many days of frustration and complete bewilderment.
And btw - my old velocity implimentation works fine :P. I knew it should've worked! But I'm going to keep the new implimentation anyway.
Thanks again,
- Eric
#12
But, I'm glad you got it fixed!
And, yeah, there will be info on TDN about this stuff.
08/04/2005 (5:15 pm)
It's not really documented cuz each object implements its own warping/interpolating strategy... So it's not really a central thing that's easily done. :)But, I'm glad you got it fixed!
And, yeah, there will be info on TDN about this stuff.
Associate Kyle Carter
Also, I strongly suggest using setSimulatedNetParams on the GameConnection to simulate 100ms of lag and maybe 20% packet loss - it'll help reveal a LOT of problems you'll otherwise not notice till it ships.