Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!brucec%phoebus.phoebus.labs.tek.com@RELAY.CS.NET
From: brucec%phoebus.phoebus.labs.tek.com@RELAY.CS.NET (Bruce Cohen)
Newsgroups: sci.virtual-worlds
Subject: Re: Who says what to whom (was Re: VR Protocols.)
Message-ID: <7986@milton.u.washington.edu>
Date: 20 Sep 90 22:40:05 GMT
References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu> <7801@milto
Sender: hlab@milton.u.washington.edu
Organization: Tektronix Inc.
Lines: 64
Approved: hitl@hardy.u.washington.edu



In article <7801@milton.u.washington.edu> wex@dali.pws.bull.com (Buckaroo Banzai
) writes:
> We did try one design in which
> there was a special object known as Space, which contained a naive-physics
> model and interacted with the objects in it.  Unfortunately, the machine
> immediately bogged down in zillions of message passes, as everyone wanted to
> talk to Space almost all the time.  I always thought this model was on the
> right track, but people moved on before we could explore the possibilities
> more fully.

I like the idea of objectifying Space, but maybe the problem is having a
unique Space object.  Suppose instead that there are a number of them; in
the limit, one for each "material" object (surely we can come up with some
terminology to make talking about virtual objects easier!).  Each Space
object has some spatial locality to be concerned about, and has knowledge
about and control over the geometry in that locality (incidentally
making multiplex manifolds easy to implement).

Whether or not Space objects are shared, no object should directly
send messages to a Space object other than ones which are local to the
position of the object (there might be more than one if the object was on
the boundary between two localities).  A bat object might send a message to
its Space saying "I am being thrusted to the left (in my local coordinate
system) with a force of xx newtons; I mass yy kilos and have such & such a
cross-section in the plane transverse to the thrust" (I'm begging the model
of physical interaction here, of course that's not a sufficient
specification for a realistic baseball simulation, but it should be enough
for the example).  The Space keeps track of the position and velocity of
the bat as modified by gravity, air resistance, etc., and sends a message
to the ball indicating any acceleration forces on it as a result of its motion.

Now if a ball is moving towards the bat, at some point its Space will hand
it or copies of its messages off to the bat's Space, just like a handoff in
a cellular phone network.  When the ball collides with the bat, the local
Space(s) will modify the positions, and velocities of the bat and ball, and
send new force messages back to them.

While in this scheme there are probably more total messages than if there
a single Space, there is a greater potential for parallelism, since we
have, very literally, a great deal of locality of reference.  Since VR
worlds are likely to be highly ditributed, I think this is a win.

> The problem is that the people paying the bills were airlines; they wanted a
> system that more or less accurately modeled the real world.  Sure, it would
> be nice if we could drop annoying things like gravity and collisions.
> They're *hard*.  But that doesn't mean we can dodge them forever.  And I
> don't favor building up a protocol/system which is going to collapse the
> first time you throw a real problem at it.

Agreed.  Its also true that if we can't model the worlds we know about, we
can have no confidence in being able to model different worlds in a
self-consistent way.  Just because we change the rules to make a new world
doesn't mean we can predict the ways in which the new rules will interact
in manifesting that world, and if we flange the rules to make the world
easier to implement, we may find out (or never know) that we've missed out
on some interesting behavior because of the broken rules (pun intended).
--
---------------------------------------------------------------------------
NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN!
Bruce Cohen, Computer Research Lab        email: brucec@tekcrl.labs.tek.com
Tektronix Laboratories, Tektronix, Inc.                phone: (503)627-5241
M/S 50-662, P.O. Box 500, Beaverton, OR  97077