[ODE] Accelerations

[Anselm Hook]

So you have an ability to specify where logic gets executed - in some
cases you migrate control of the execution of logic from one machine to
another?  Other machines just listen to displacement events (or possibly
do some speculative simulation that can be overridden I suppose).

Sounds like a typical database in some ways - you want to commit atomic
events and reasonably guarantee event ordering (so that if you break the
bottle and drink the bottle then only one of the two events happens).

But you still have other parties or entities that will want to
communicate with that object...  some simple scheme will be needed to make
sure your requests are routed to the right place (instead of being routed
to a 'ghost' instance that will later have its state overwritten).

A rocket has deterministic behavior, better example might be an avatar
whose behavior is more difficult to speculate.  You might have a case
where you have to migrate control for the avatar to the server - for
example your avatar steps onto an elevator, or two avatars collide.  In
that case your high level inputs have to be re-routed to the authoritative
instance for that object - this whole idea of 'talking' to an object could
be generalized so that your high level logic isn't aware of the network...

   class myavatar {
        ODEDynamicsBody body;
        public deal_with_msg( style, value ) {
           if( style == move && locally_authoritative ) {
               body.addForce( value );
           }
           else if( style == move && !locally_authoritative ) {
               send_msg_to_authoritative( style, value );
           }
        }
   }

Seems like a good idea for things that are not connected by joints.

Seems like you can get performance improvements by using the highest level
events possible (such as 'drink the milk' rather than low level dynamics
events such as 'move arm left')...

I've noticed in the past that message handlers strewn through-out code can
be a mess, especially for debugging networking.  I tend to aggregate
networking related code in one block - despite the fact that it isn't very
object oriented.  In this way the actual objects are solely concerned with
heavy lifting, and the requests for object behaviors is external - it's a
separation of concerns:

        class myavatar extends ODEDynamicsBody {
            public void addForce();
            public void drink_milk();
        }

        message_resolver( target, style, value ) {
           if( target.locally_authoritative == false ) {
               send_msg_to_authoritative( target,style,value);
           }
           else {
               if( style == move ) {
                  target.addForce( value );
               }
               else if( style == drink_milk ) {
                  target.drink_milk(value);
               }
           }
       }

That reminds me that I once heard somebody talking about an idea of a
'network contact' or 'network constraint' - that would be instantiated as
a bridge over a network and would be apply to propagate forces - such an
idea could be directly wired into ODE for transparent networking of the
dynamics.

-a



On Mon, 3 Dec 2001, Simon Thoresen wrote:

> 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
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>