[ODE] Re: ODE on multiplayer games

Geoff Carlton gcarlton at iinet.net.au
Sat Mar 26 11:12:32 MST 2005


This seems to be discussing the merits of having a local simulation to 
predict entities in between proper server updates?  I'm curious if 
anybody has ever tried this and got it working, or whether this is 
purely a theoretical discussion.

If the server is doing all the proper simulation and this is a client 
prediction scheme, it seems a lot more flaky than just interpolating 
each object's pos/vel from the last few updates.  If an object isn't 
hitting anything, then the standard interpolation/extrapolation will 
work ok, and if the object is involved in a collision then who knows 
where it will end up - most likely it will be a totally different 
direction to what the server has decided, since the objects will be in 
slightly different orientations on the two simulations.

Geoff


Megan Fox wrote:

>Trouble is, then how do you detect the case of two pool balls?
>
>... that is, pool ball A is rolling (extremely quickly) towards pool
>ball B.  Pool ball B, when struck, should fly off at similarly high
>speeds.  If the contact forces are clamped such that correction
>velocities can't exceed 1m/s, wouldn't pool ball B eat most of the
>velocity up without any result at all?
>
>In a general penalty system, how do you tell "bad" penalty (unwanted
>interpenetration) from "good" penalty (somewhat high speed collisions
>resulting in temporary penetration)?
>
>-Megan Fox
>
>On Fri, 25 Mar 2005 18:23:42 +0100, Alen Ladavac <alenl-ml at croteam.com> wrote:
>  
>
>>>>gradually, what's to stop the case where you update box A (but not box
>>>>B), where box A's updated position interpenetrates with box B's local
>>>>position, causing a local physics explosion, then you update box B,
>>>>        
>>>>
>>>You know the position and velocity of box A at the time of the update.
>>>You can, if you want to, make it immune to other interactions for a brief
>>>while after getting the update. Especially if you know objects are at
>>>rest (disabled) on the server, you can make that quite sticky in the
>>>distribution, so if it interpenetrates with B, B will go flying, but not
>>>A.
>>>      
>>>
>>IMO, velocity used to resolve interpenetration in the contact joint should
>>be clamped to some reasonable velocity (like 1m/s) in general. This keeps
>>explosions caused by interpenetration to minimum, in this case and in
>>various others.
>>
>>JMTC,
>>Alen
>>
>>
>>    
>>
>_______________________________________________
>ODE mailing list
>ODE at q12.org
>http://q12.org/mailman/listinfo/ode
>
>
>
>  
>




More information about the ODE mailing list