Subject: Re: [mmox] mmox Digest, Vol 2, Issue 3

From: "zedmaster" <[email-masked]>
Date: Sun, 1 Mar 2009 21:49:42 -0000

One model implemented in the early networked VR systems (dVS, DIVE - both 
developed in the early 90's) was a fully distributed process model where the 
visual, acoustic, haptic (touch feedback), input (gestural) and physical 
(collision) simulations were all executing as concurrent tasks.  Such 
high-end VR simulators were built up from a set of these processes, e.g. 
each user had full body tracking, stereo display, audio and (local) 
collision detection - these managed the "user" in the simulation, and would 
broadcast information about the user out to the rest of the simulators.  The 
"world" was being managed by another set of services, executing scripted/AI 
behaviours etc.   Multiple worlds (regions) were just replications of this. 
Each user simulator simply registers in the regions they are interested in, 
and the changes from the different animations and collision services get 
routed to them.  The same principals of federated services were used in 
SIMNET / DIS / HLA.

One of the benefits of local and world collision services is that you can 
minimise the visual disparities caused by objects temporarily going through 
others, by localising the processing to your viewer.  It was especially 
important in these VR simulators where the user's limbs, being tracked using 
6DOF tracking systems, are not moving according to any form of predictive 
movement, thus making it difficult to predict (and correct) using dead 
reckoning techniques - hands and feet can accelerate very quickly.  Hence it 
was easier to do the full collision detection on a (small) subset of the 
world model, close to the user.   The full world simulator, moving cars or 
whatever, didnt have to worry about this level of collision detail, because 
the user wasnt likely to see it unless very close anyway.

I have only just started to catch up with the procedings here on the mmox 
list, so appologies if you've already covered some of these older ideas.  If 
you haven't, however, I'd encourage you to take a look because the ideas 
have been around for a while and some (dVS) are still operating 
commercially.  What also may be of interest to this group is that the two 
base systems (dVS, DIVE) were successfully connected together in an funded 
interoperability project (codenamed COVEN - 
http://vrlab.epfl.ch/Projects/coven.html) to demonstrate a collaborative VR 
environment.  Many of the issues you face here - remote simulation, 
collision detection, disparate scene graphs, cross-system connections 
(teleporting and voice comms) etc. were all tackled succesfully.  I seem to 
remember seeing a DIVE avatar hand an item to a dVS avatar, demonstating a 
very primitive form of cross-system asset transfer.

I guess the encouraging news is that VR system interoperability has been 
demonstrated to be practical in the past, so you guys should have no problem 
sorting it out properly this time :-)

dirk

----- Original Message ----- 
>
> Then that third order information needs to include things like
> collisions that will happen, or you will have to make a choice:
> 1) display objects "behind time" by whatever your transmission latency is
> 2) display objects as momentarily going through walls etc, and then
> correcting on the next update
>
> Btw: LESS is designed to allow each implementation to choose which of
> those three it implements (local collision, delayed display, or
> momentary penetrations).
>
> Most common computer games (especially the "action" and "MMO" ones) run
> local collision detection to avoid objects going through walls, even if
> they have an authoritative simulation version on the server. If SL
> doesn't do that, that's fine for them; that probably means they have to
> send a greater amount of update data. For an MMO with forward
> extrapolation and client-side collision, you can get away with as little
> as one update per second in many cases. If you're doing dead reckoning
> without any simulation in display, I would expect that to break down
> below about 15 updates per second, and I would want something like 30
> for "full fidelity" displays.
>
> Anyway, this is one of the reasons why I want to keep the
> server<->client display protocol separate from interoperability -- there
> are simply too many different approaches, each of which is optimized for
> a different use case, and if you try to force another model on the
> original use case, that won't work very well.
>