Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!shebs@Apple.COM
From: shebs@Apple.COM (Stan Shebs)
Newsgroups: sci.virtual-worlds
Subject: Re: Who says what to whom (was Re: VR Protocols.)
Message-ID: <7570@milton.u.washington.edu>
Date: 14 Sep 90 18:53:53 GMT
References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu>
Sender: hlab@milton.u.washington.edu
Organization: Apple Computer Inc., Cupertino, CA
Lines: 48
Approved: hitl@hardy.u.washington.edu



In article <7507@milton.u.washington.edu> wex@dali.pws.bull.com (Buckaroo Banzai
) writes:

>   3. The user tells the building what attributes to send
>   4. The building tells the user what user attributes to send
>
>I'd like to talk about 3&4 particularly, as they raise annoying model
>questions.  The problem is this: in order for the user to tell the building
>what attributes to send, the user has to know what attributes the building
>*might* send, which means he knows a hell of a lot about the building's
>structure (and probably a fair amount about the *implementation* of the
>building's structure, which is even worse).

In the system I've been working on, the game^H^H^H^Hvirtual world designer
decides which attributes will be communicated to which users, then it's up
to the users' proxy/client code to decide what (if anything) is to be done
with the attributes.  The trick is then to write clients that can deal with
different sorts of data reasonably.  I assume that most clients will be
customized to particular kinds of worlds, although I've been working on a
Mac client that tries to set up reasonable menus and windows using only
datatype info coming from the server - it does do the right thing sometimes!...

>This problem carries along as we add more and more interacting objects,
>until you have a situation where a supposedly-simple object (like a
>baseball) has to "know" a hell of a lot about the world.

I started my (meta)world design from a literal rendering of the physical
world, where you could track every atom if you had enough resources, then
introduced scaled-down concepts "for efficiency" :-).  The resulting object
hierarchy seems to be fairly good for modeling.  For instance, "physical
objects" or "physobs" reside in "spaces" of assorted shapes, while behavior
can be specified as "processes" or "events".  Motion, for example, is a
process acting uniformly over physobs in a space, and governed by a few
parameters that are attached to the physobs.  A baseball wouldn't need
much more than a shape, mass, elasticity, and color.

In general, physical modelling seems to disfavor the normal computer
science models of computation.  I suspect that it's more fruitful to
let the general computational model be a "non-primitive" (so to speak)
of the virtual reality, in much the same way that physical computers
have to be constructed out of complicated assemblages of materials operating
according to physical laws.  This sounds very ethereal - practical advice
is "don't let arbitrary C/Lisp/etc code into your VR!".

                                                stan shebs
                                                shebs@apple.com