[vos-d] Physics Braindump

[Ken Taylor]

Peter Amstutz wrote:
> On Tue, Feb 27, 2007 at 10:14:51PM +0100, Benjamin Mesing wrote:
> > On Tue, 2007-02-27 at 11:03 -0500, Peter Amstutz wrote:
> > > On Tue, Feb 27, 2007 at 09:03:44AM -0500, Reed Hedges wrote:
> > >
> > > > Each object should be internally responsible for deciding how it
> > > > responds to physical forces (messages requesting movement), I think.
> > > > This would be ideal, at least.  It allows you to distribute physics
> > > > computation load by just distributing objects on different sites
> > > > (servers).    Will this work?   Will it work when an object a on
Site
> A
> > > > is moved, detects its collision with object b on site B, sends it a
> > > > force message, etc.?
> > >
> > > There's two problems with that: [..] the second is basic
> > > Newtonian physics, that for each action there is an opposite reaction,
> > > so if I push on a box, the box also "pushes back"
> >
> > I do not see the problem here. Reed was saying, that the object should
> > decide how it *responds* to force. If e.g. a humanoid object wants to
> > push a box, it sends a force message to itself and the object.
>
> The problem is network lag between when I start to push on the box and
> it actually responds.  Is a "force" message an instantaneous impulse, or
> a force vector applied over time?  If it's an instantaneous impulse then
> I'm going to bump objects along rather than pushing them smoothly, but
> if it's applied over time, then you might find that lag has caused you
> to push that box right over a cliff.

I think the problem can be worse than that... let's say there's two balls,
each one owned by a different node, and they're on a collision course. Each
node sees a lagged version of the other ball, and so they will each
calculate a different point of collision, each thinking their own ball is
further along than the other side.

In other words, at the pont of collision, Node A might see this:
-->-->-->AB<--<--

While node B sees:
-->-->AB<--<--<--

Now, what happens? Let's forget about the "force" thing for now, and just
have each node send out the state of each of its objects (position,
momentum).

A sends out "I'm at position 5"
B sends out "I'm at position 3"

... oops, they just went right through each other.  If your timestep is
smaller, they might instead get stuck in each other, or your collision
response algorithm on each side might send them flying apart at a humongous
velocity. None of those three are very good outcomes, but I can see them
being all too common in a distributed simulation like this.

Though.... it still might be worth hacking together a test case to see what
happens :)  But only after server-synchronized physics is working properly
in the first place.

-Ken


>
> What *might* work is publishing the position, velocity and mass of each
> object and doing full collision detection and resolution on each site,
> but only actually committing changes to local objects.  So rather than
> telling the box, "I'm applying force to you", you tell the other
> simulator "I weigh 100 kilos and am traveling at 3 m/s" and it figures
> out that the box that's in your path should be pushed out of the way.
>
> Unfortunately this doesn't distribute the actual physics simulation load
> much, since every site that wants to host dynamic objects are required
> to effectively replicate the entire simulation -- although spatial
> partitioning can limit the scope of each simulation.
>