[ODE] Accelerations

[Simon Thoresen]

Hi.

An itermediate solution I will be using is simply to allow each client to be
out of sync. Only the most critical of entities will be sync'ed, while
others are simulated indepedently on each client.

Say for example that a rocket is launched. By simulating it on the server,
we will know if the rocket will affect anything within the game. If it
doesnt; simply run the simulation locally without applying any effect. If
the server determines that something actually blows up, alert the clients.
Since the differences between each client will (hopefully) be minimal, no
serious artefacts should occur.

Of course, this technique requires that your game allows a little slack.

HTH,
Simon Thoresen

----- Original Message -----
From: "Adam Moravanszky" <amoravanszky@dplanet.ch>
To: <ode@q12.org>
Sent: Monday, December 03, 2001 5:01 PM
Subject: [ODE] Accelerations


> Hello,
>
> another problem.  I am using ODE in a networked environment: the usual
game
> client-server scenario.  Since ODE is for games, and games are usually
> multiplayer, I expect the following to be an important ODE relevant issue.
>
> In such games, the server usually does the simulation, and then tells the
> clients all about the result.  Because of various properties of a network
> I'm sure you are aware of, the bandwidth of the connection is usually
> insufficient to provide the client with a high frequency update of all
> bodies' positions and orientations.  The client has to be made more clever
> by guessing how the server's objects move when it doesn't happen to
receive
> updates.
>
> What games with simple 'physics' usually do, is to simulate these simple
> physics laws on the client as well.  These simple physics involve
collision
> detection, collision handling with either velocity clamping or bouncing,
and
> acceleration due to gravity.  Since these interactions were usually
between
> a single object and a static environment, the client had no problem
applying
> these same rules of movement on its partial view of the world (the client
> doesn't have all world objects locally, only the for it 'relevant' ones).
> Thus, updates from the server to the client are only sent if the client
> simulation for some reason becomes out of sync with the server.
>
> The question now, obviously, is how this carries over to more
sophisticated
> physics with joints and resting contact ala ODE.
>
> Until now, I have been doing ODE simulation on the server only, while the
> client did a simple simulation of collision detection-less motion with a
> constant velocity (the velocity sent by the server at the last update.)
> This works almost well enough to use, but only almost.  When an object
> accelerates due to gravity on the server, the visible movement on the
client
> is discontinuous.  When objects move slowly on the server as stuff slides
or
> interacts in various ways, the client pose drifts away from the server,
only
> to be 'popped' back to the right place.  Such pops are very visible, even
> though the pop distance is but a centimeter or less than three degrees
> orientation. (The current tolerance levels.)
>
> The first fix I am considering is to simulate the accelerations on the
> client as well.  Unfortunately, that would make it necessary to receive
> acceleration infos from ODE, which it doesn't currently provide.  I have
> looked at the ODE code, and seen that it doesn't use an acceleration value
> internally either.  But you have something like this:
>
> v[i] + stepsize*vnew[i];
>
> Here, vnew could be considered as the acceleration.  Russ, what would
speak
> against making this value queriable?
>
>
> The second fix would be full ODE simulation on clients as well.  I was
> hoping I could avoid this, because it not only means a larger load for the
> client, but I also need to code up some way on the server to detect if the
> client has fallen out of sync, which is now much more difficult.  I also
> need to find all objects which are needed to insure a correct world-subset
> simulation on the client, somehow...  Lots of extra work for me, so I
don't
> like it at all.
>
> Perhaps there are further intermediate solutions on the client, like doing
> collision detection to prevent interpenetrations, but no proper collision
> handling/resting contact.
>
> Help!
>
> --Adam
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode