client-side physics

[daniel miller]

in case anyone missed it, Ryan posted something I emailed about
client-side physics:

http://www.rexdeveloper.org/wiki/index.php?title=Client-side_Physics

The basic idea is to use a physics engine on the client to predict
what the server is going to do with prims and avatars, rather than
relying simply on interpolation.

The more I look into this problem, the more I become convinced that
the issue of timing is going to be important. The present SL protocol
(AFAIK) lacks any kind of time-stamp mechanism to know when a network
packet was sent. The problem is that this introduces jitter and
uncertainty with respect to synchronizing the client's view of the
world with the server's.

The "right" answer would be to add timestamps to each time-critical
message (particularly object updates). This way, the client can keep
track of the varying lag time, and attempt to run its own simulation
with a precise delay, such that the majority of server messages are
received "before" they are due to be instantiated. Late messages can
then be analyzed to see if they should be skipped, or in specific
cases (major changes in motion) the client can 'roll back' its
simulation, or otherwise incorporate the late message retoactively to
resync with the server.

Without this sort of facility, client-side prediction is much less
useful, as the benefits are overwhelmed by the effects of jitter and
lag.

-dan