[ODE] networking

[Eric Cha]

Anselm's solution is what I call the "classic" solution.  It's "classic"
in the sense that I know of several games which actually use that system
(or something very similar).  Just as a point of discussion, there are
several other ways to approach the problem... For example, here is what
we did with Dreadnoughts (a game which we were working on using Havok):

Dreadnoughts had/has pretty extreme physics engine requirements.  It's a
first person shooter with HUGE vehicles (ever seen Stargate the movie?
Think of the flying pyramids..)  We had to simulate moving structures
which were large enough so that entire Quake-style levels would fit
INSIDE of them.  The player could run around inside these ships and then
go outside and run around a huge outdoor world.  At the same time, the
ships themselves were moving and could battle it out with each other and
interact with full physics with the environment.   All this had to take
place seamlessly.  If a player was inside the ship looking out, he/she
could see the other players running/flying around the terrain and could
interact with those players..

Anyway, we found that because of memory constraints, we could not do the
"master heartbeat physics server" method (the levels were so large that
we were paging them in and out of memory as you moved around..)
Instead, we chopped the world up into regions (pretty easy as the world
was already partitioned into regions for our paging system) and
dynamically assigned client computers as the physics master simulators.
It was/is very tricky to implement, and not without problems in
implementation.  However, the end result was full physics simulation of
a HUGE environment with the load being (relatively) evenly distributed
amongst participant's computers...

Eric

> -----Original Message-----
> From: ode-admin@q12.org [mailto:ode-admin@q12.org] On Behalf Of Nate W
> Sent: Wednesday, October 16, 2002 3:28 PM
> To: ode@q12.org
> Subject: RE: [ODE] networking
> 
> 
> On Wed, 16 Oct 2002, Eric Cha wrote:
> 
> > A better way (for physics) to do things would be to designate one 
> > computer as "the physics simulator".  Do the entire scene 
> simulation 
> > on that computer, and then just transmit 
> position/orientation/velocity 
> > updates to other computers.  Of course, other computers 
> would transmit 
> > user inputs (or even impulse/velocity/acceleration changes) to the 
> > simulator computer to control their respective robot.
> 
> I hope you all don't mind too much my attempt to hijack this 
> thread and turn it into a discussion of networked physics in 
> general. :-)
> 
> Having a single computer be "the" simulator solves a lot of 
> problems, and in many cases would be the best solution.  A 
> co-worker and I did a multi-user simulation this way a few 
> years ago and it worked well.  (We didn't have physics to 
> worry about, but we did have related issues with maintaining 
> coherent world states on all of the 'client' machines.)
> 
> The thing that makes me want to avoid that model today is 
> that physics takes a lot of CPU power.  Every client brings a 
> fast CPU to the party... if there's a way to make use of that 
> power, many clients together could be able to do much more 
> complex simulations than a single server (or rather, "more 
> complex that the server *I* can afford").  Ideally, it gets a 
> lot cheaper to scale the system to support more users, becase 
> each user brings enough CPU power to do their share of the 
> computation.  Practically it will never be quite that 
> scalable, but I still like the idea.
> 
> If you can have each client simulate the parts of the 
> player's body or vehicle, then broadcast the positions and 
> orientations, the server's CPU requirements go down quite a 
> bit.  Note that I'm assuming a game sort of paradigm here, 
> but other scenarios could use other methods of assigning 
> objects to CPUs.
> 
> I'd elaborate, but I see that Anselm has already described 
> something like what I had in mind, only better. :-)
> 
> -- 
> 
> Nate Waddoups
> Redmond WA USA
> http://www.natew.com
> 
> 
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.394 / Virus Database: 224 - Release Date: 10/3/2002