From: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng)
Newsgroups: sci.virtual-worlds
Subject: SCI: Toward a REALIZABLE network VR standard...
Date: 27 Jul 92 05:10:59 GMT
Organization: University of Waterloo
Originator: hlab@milton.u.washington.edu


OK...  I think it's time that some limits be noted in terms of what a
do-it-now VR protocol for general use must use.  If you have more
resources, fine, but that doesn't mean that the standard will be
designed to need that much to work-- but it will have options to use
it.

Network bandwidth: Must work acceptably with data rates as low as 1000
baud (100 bytes/sec) to the stations, although servers can have a lot
more.  By "stations" I mean a computer that does not manage an object
or area in the world.  These will probably have to be limited to
larger machines, unless you have an Ethernet connection.  Just traffic
volume, nothing to do with machine power.

Object resolution: Let's get real.  Most objects can be expressed in
local (object-frame) coordinates of 16 bits or less.  The object can
have area (or world) coordinates of 32 bits, and pose can be sent with
16-bit (or less) angles.  Again, it's a message size issue.  We can
have multiple versions of each object, or perhaps a CSG representation
(it will depend on how "pretty" the expanded CSG looks on remote
machines: the option of having a hand-tuned poly rep is essential).
And as for object complexity, try to keep it well under 100 polys
(average of 20 is nice).  But a simple system NOW and extensibility
will get the thing going.  Add a request facility for CSG or texture
mapped or other stuff.

Areas: Definitely split up the world.  Not just to keep the resources
required to manage the world under control, but to control visibility
and object detail (representation) as well.  Use planes to define
areas, and NEVER assume axis-alignment.  Try to cache a bit of the
local world "structure" at the local server to prevent a long pause as
"where am I NOW" messages are exchanged.  It's possible to use a
static form of BSP trees for this purpose, and to generate small
subsets for checking local motion.  Visibility can be handled by
region and by distance (i.e. server maintains object visibility lists
between areas, including simplified object lists for distant regions).
GOAL: less than 100 objects needed to start the world up.

Motion: Forget any system that sends updates more than one a second.
Use a predictive stratagy, i.e. encode the local motion's goal, speed,
direction, and acceleration curve.  Object "owners" (whoever can move
an object at this instant) handle collision detection with that
object-- which includes your body.  Autonomous moving objects should
be handled by either the area server or their object server.  WE HAVE
TO KEEP LOCAL REALTIME.  Interruptions to switch areas and to get
ownership of objects are barely permissable (but needed).  ALWAYS
assume there may be a 1 or 2 second delay in transmission, and that
the medium may be bursty (and the bursts may split your packet).  It's
a tough net, folks.

Support: Users will be interfacing with keyboards, joysticks, mice,
gloves, Sega glasses, HMDs, ...  so ALL must be supported.  How?  Not
really the net's business!  All we can do is provide the visual raw
material and let the local implementation decide how to create the
move commands or how to navigate.  Although with keyboards some
attatched text commands for an object would be nice, such as scripts
to be executed (open door, etc).

Human Factors (or how to cheat): In the end, the system will be used
by people.  It will probably NOT be used to run submolecular
simulations or other tasks that require enormous complexity or even
accuracy.  So local area scales will work fine (and are essential for
natural interfacing and the development of perceptual maps of the
system).  Stuff like limits on resolution or quantized motion or force
thresholds to make control simpler etc. fits into this catagory.

In summary, it's a real world out there.  If you match the ideas to
the limits, you can spend your time solving problems and finding
extensible solutions.  Otherwise, you're just part of the Dream-Team
trying to simulate the universe on a C-64.

--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | dstamp@watserv1.uwaterloo.ca |
__________________________________________________________________________