lag-fighting...

okay, consider this

one player will get the current position of another player... from a half second ago

there isn't a way to reduce that lag, so this client will always either show the position half a second behind [not good], or try to guess where that other player is at the current time [tolerable]. It guesses the current position by showing the player as moving continously, with the same direction and speed. When the client then recieves an update about how wrong it is [the other player isn't moving in a continous straight line are they?], the client then interpolates between the position it is currently showing, and the new guess as to where the current position is [remember, it is late again]. This way the players don't see the other players disappear and show up elsewhere. In order to deal with different players seeing eachother in different positions first person shooters sometimes will register a hit from the view of the one shooting giving good feeback to the players and making the lag even less apparent.

sorry, no charts for you [from me]

Ok, so interpolation means smoothing the movement from the previous "wrong" position to the current "wrong" position. And that imitates the visually "correct" movement if the updates are not too rare... And what about extrapolation ?

Quote:

try to guess where that other player is at the current time [tolerable].

That's the extrapolation, when the client tries to predict a "next" location, from a current location and velocity.

Also look at the game loop page which talks about interpolation and extrapolation in context of game time measurement.

Hmmm... I'm getting confused a little...
Ok, let's say client is tracking a moving unit (a character, or somewhat like that).
It is now time T-1.
At T-1 client has received an update packet from the server. The server told the client, that at (T-2) the unit was at sx(T-2), sy(T-2), sz(T-2) (i won't overcomplicate the situation with such parameters as acceleration, etc..., i suppose the velocity is constant here). Now, the client knows the position of the unit for (T-2) and can make an assumption (relying on the fact, that the velocity is constant and the movement is direct) that at current moment (T-1) the unit's location is at cx(T-1), cy(T-1), cz(T-1). Correct me if i'm mistaking, but i call that an "extrapolated" position (the predicted one).
Now time T comes.
The client receives another update packet, and the newly received packet contains info on the situation that took place in the server-side world at time (T-1). The unit is at sx(T-1), sy(T-1), sz(T-1). And that can be different from what we've tried to guess earlier, sx(T-1) != cx(T-1), sy(T-1) != cy(T-1), sz(T-1) != cz(T-1)... Ofcourse, we could be lucky, and the coordinates could match, but in general we're usually not fortunate :)
How is the client going to correct its mistake without "jittering" the unit?
The client is making another assumption. It supposes that the unit is at cx(T), cy(T), cz(T). And it starts moving the unit from cx(T-1), cy(T-1), cz(T-1) to cx(T), cy(T), cz(T)... Is that what you call the "interpolation" ?But doesn't client take sx(T-1), sy(T-1) and sz(T-1) into consideration ? And does that mean, that client is always rendering the out-of-date world with a L lag (where L is the time it takes for an update packet to reach the client from server)? And if it is, isn't it the issue we were to fight when doing networking? Our goal was to render the actual position of the unit, and we are still rendering one-moment-before, even though we are interpolating and extrapolating... That doesn't make any sense, and i'm totally confused now. Please make it clear anybody!

Case 1: the client actually draws the unit at position T-2 (instead of T-1), so that, when receiving position for T-1 (at time T), the client can draw the unit along the correct path. This leads to a 2*OWTT latency in display updates. This is the vastly easiest thing to do, and is quite sufficient for things like RPGs. This is interpolation.

Case 2: when receiving the position for T-1 at time T, the client estimates a new position for time T, by extrapolating from actual positions at T-2 and T-1. It then starts moving the displayed character towards this position, from the currently displayed position (i e, previously guessed position for T-1). This means that the unit may be drawn in places it's never been, but for units that move mostly straight, it shows a more up-to-date position. This is extrapolation.

So, the client is always late? Client is always rendering an out-of-dated position?

hplus0603, so, in case 1, when time T+1 arrives, the client should "jitter" the unit to its position at time T, without taking into consideration the previous interpolation ? But it whould make the unit "jump" visually, wouldn't it?

No, the client never jitters the unit. In both cases, the drawing position changes smoothly. Read through the algorithms again.

You have the choice of always rendering the unit late, or rendering the unit at an estimated position that may not be correct. Note that you can forward extrapolate the position by more than one T if you need and want to, too.

Interpolation and extrapolation are two fundementally different things. Extrapolation (or prediction) is used primarily in real-time networked games, while interpolation is used in lots of games, regardless of whether/how they are networked.

Here's a very simply example of using interpolation (forget all about networked games for the moment): You design a game that uses a game loop which updates the game logic (or physics) at fixed intervals, say every 100 milliseconds. Without interpolation, the movement in the game would appear very choppy, since you're effectively only rendering at 10 fps. However, let's say that you game logic decides where every object will be 100 ms from the time at which the logic is actually executing. Your rendering code can then "see" one update into the future. If your rendering code know where an object was at time A, and where it will be at time B, then it can render the object smoothly moving between point A and point B instead of jumping from one point to another. The disadvantage of this system is that the rendering code is at most 1 logic update behind the update loop, though the difference is usually insignificant if you're updating sufficiently fast.

Extrapolation, as explained by other posters, is the act of predicting where an object is (or will be) at a particular time. For example, your game recieves an update from the server saying that an object is now at such-and-such a location and has such-and-such a velocity. The client may not recieve any updates for a long time, but it can "predict" very accurately where an object will be at a certain time, assuming that the object does change its course.

Interpolation meets extrapolation when an object DOES change its course. Let's say that the client recieves another update from the server that says the object now has position P and velocity V. Unfortunately, this means that the object's actual location is not where the client predicted it would be. The easy solution is simply to "snap" the object to its new location, but this looks ugly. The good solution is to gradually slide the object from its previously-predicted location to the new, accurate position, which looks much nicer. This is interpolation used in the context of a networked game.

Does that mean, that the client will always render an out-of-date world (with T lag)?
When client receives a packet with data corresponding to server time T, the client begins to interpolate the unit from its current position to the extrapolated position at T+1. But by the time the unit reaches its position at time T+1 on the client, it is already time T+2 at the server. So the client appears to be always late by one T. Is that right?

Quote:

Original post by dummynet Does that mean, that the client will always render an out-of-date world (with T lag)? When client receives a packet with data corresponding to server time T, the client begins to interpolate the unit from its current position to the extrapolated position at T+1. But by the time the unit reaches its position at time T+1 on the client, it is already time T+2 at the server. So the client appears to be always late by one T. Is that right?

This depends on how you do the interpolation towards the server's position. For examply, in my game, the client's position is moved towards the current predicted server's position by 1/4 the distance for every T. This causes the client's position to accelerate towards the server's position such that after a small amount of time it has completely caught up to the server (or where the client thinks the server is). The idea is to make the acceleration brief but unnoticeable, which can be a tricky balancing act.