11
\$\begingroup\$

I have many entities on the client side that are simulated (their velocities are added to their positions on a per frame basis) and I let them dead reckon themselves. They send updates about where they were last seen and their velocity changes. This works great and other players see this work find. However, after a while these players begin to desync after some time. This is because of latency.

I'd like to know how I can interpolate between states so they appear to be in the correct position. I know where the player was LAST seen and their current velocity but interpolating to the last seen state causes the player to actually move -backwards-. I could not use velocity at all for other clients and simply 'lerp' them towards the appropriate direction but I feel this would cause jaggy movement. What are the alternatives?

Improve this question
\$\endgroup\$

2 Answers 2

Reset to default
9
\$\begingroup\$

For this reason, you'll find simulations are often run 1 or more frames ahead of what is in fact being rendered at given point in time on a give client. So in other words, what you render might in fact be the second last frame, not the last frame.

Search this article for all instances of the word "ahead" and I think you will start to get the picture better than I may have explained it above.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Okay, so are you implying I really should render the player as they were 300 ms ago and interpolate towards the future? (In a separate state, when a new state arrives; this would switch) \$\endgroup\$
    – Vaughan Hilts
    Dec 19, 2012 at 4:39
  • \$\begingroup\$ @VaughanHilts Again, please read the article and the comments. Gaffer's an expert in that field and he explains it a lot more clearly than I can. But the general idea is that yes, your simulation model is ahead while your rendering is somewhat behind that to account for the effect you described. It not by any means the only place I've seen this technique described. \$\endgroup\$
    – Engineer
    Dec 19, 2012 at 4:41
2
\$\begingroup\$

When you say:

these players begin to desync after some time

it makes me think that your issue may have more to do with your clocks getting out of step than with any latency issues. If it's latency, it should be just as bad at the start than 10 minutes in. If one game clock is running slightly faster than the other, there will be some weird jitter artifacts that will get worse and worse over time. A client could be simulating in the future, when the present packets arrive from the server, it'll pull the client back, causing entities to jump around. Run some more tests to find out.

If out of sync game clocks are indeed an issue, you'll need to look very carefully at your update loop and make sure that every update is based on the amount of game-time passed (either fixed or variable), and that the game-time is advanced using something like the wall-clock (not render time or other variables). Gaffer has some good articles on this, and there's a decent question on here talking about fixed vs variable timesteps. Hope this helps.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ This is not the case, the case is indeed the fact that I dead-reckon too far (a lag spike or something - the packet to 'stop' is not received in time and the client cannot correct itself in time. I know this defintely the case because after the client has stopped I can most DEFINTELAY interpolate back into position. \$\endgroup\$
    – Vaughan Hilts
    Dec 20, 2012 at 5:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .