[ODE] Client prediction and asynchronous simulation

[Roar Flølo]

Forget about deterministic behaviour, you'll go mad trying.

This is a good article on networked physics:
http://www.gaffer.org/game-physics/networked-physics/


Roar


On 11/19/06, Eric Lasota <riot at icculus.org> wrote:
>
> Nick Winters wrote:
> > Uhh, you're running client and server physics at different timesteps?
> It's based on Quake 3, which has that setting by default.  I could make
> them run at the same timestep if that compromises stability by itself,
> they'll still need to run out of sync though.  The server will process
> client movement packets as it receives them for the most part, which
> means a client that gets backed up will have no movement for several
> world frames, followed several updates within a single frame.
> > 1) ODE needs a lot of work to be deterministic, floating point math is
> > not deterministic in general, as different compilers, builds, or
> > computers will run things differently.  [Little things like actually
> > having an 80bit float stored in memory, and using it on the next
> > calculation instead of rounding to 64 bit... [32 if you're using
> > singles]] The only effective way I can see to make a deterministic
> > implementation of ODE is to write an integer-based float emulator.
> I don't think this is really going to be a problem.  It may just be run
> in single-precision mode, but even if it's not, minor prediction errors
> are recovered from easily, and objects that will be part of the actual
> physics simulation are few in number.
> > 2) it appears vehicle physics in ut2004 waits for the response before
> > moving/steering... Your look controls and foot controls are responsive
> > [aka: simulated client side so you don't feel the lag] with a ping of
> > 800, but vehicle controls are very lagged.  I think online garry's mod
> > seems to run so poorly is due to the number of or detail of things
> > being updated, but I haven't played around enough to tell.
> Q3's net code is not nearly as elegant when it starts lagging, things
> stutter a lot more than they do in Unreal and that's a lot less
> tolerable when you're driving the thing that's stuttering.  Try doing
> cg_nopredict 1 even on a 23-ping server and it feels really bad,
> supposedly you get the same effect in Garry's.
> > 3) if an object is disabled in ODE, and stays disabled, do you still
> > bounce off of it?
> That's what I'm trying to figure out.  If not, I may have to run 3
> different simulations, which I'm trying to avoid for various reasons.
>
> As I said, right now I'm in the planning phases, so I'm trying to gather
> as much info as I can before I make any major decisions.  However,
> vehicle updates separate from the main simulation is pretty much required.
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://q12.org/pipermail/ode/attachments/20061119/f5f153ca/attachment.htm