I'm attempting to understand something discussed in a Valve article about their multiplayer network algorithms, and have come across a point I don't understand. I wonder if you might be able to explain something to me.

[font="Arial"]The article is titled "[/font][font="Arial"]Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization", and can be found here.

The section that gives me difficulties is labelled "Display of Targets," during a [/font][font="Arial"]discussion of the client-side interpolation used by the Source engine, and the visual artifacts and difficulties encountered with certain objects, such as a bouncing ball.[/font][font="Arial"] It begins in the 7th paragraph of the section:

"[/font]In addition, the above type of interpolation (where the client tracks only the last two updates and is always moving directly toward the most recent update) requires a fixed time interval between server updates. The method also suffers from visual quality issues that are difficult to resolve.... Imagine that the object being interpolated is a bouncing ball .... At the extremes, the ball is either high in the air or hitting the pavement. However, on average, the ball is somewhere in between. If we only interpolate to the last position, it is very likely that this position is not on the ground or at the high point. The bounciness of the ball is "flattened" out and it never seems to hit the ground. This is a classical sampling problem and can be alleviated by sampling the world state more frequently. However, we are still quite likely never actually to have an interpolation target state be at the ground or at the high point and this will still flatten out the position"

The proposed solution: "To avoid the flattening of the bouncing ball problem, we employ a different algorithm for interpolation. In this method, we keep a more complete "position history" for each object that might be interpolated." The article goes on to describe using multiple updates and interpolating between the two that straddle the rendering time.

What I don't understand is - how is this "solution" any different from the "problematic" interpolation algorithm, which also uses two updates to straddle the rendering time?

Are they simply suggesting that the 'update" rate should be as high as possible, to minimize the "flattening of the bouncing ball?" That's not really a different algorithm, and certainly doesn't solve the bouncing ball problem (unless the update frequency is MUCH smaller compared to the frequency of the ball's bounce). Am I missing something?[font="Arial"]
[/font]