Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!broehl@watserv1.waterloo.edu
From: broehl@watserv1.waterloo.edu (Bernie Roehl)
Newsgroups: sci.virtual-worlds
Subject: Re: Who says what to whom (was Re: VR Protocols.)
Message-ID: <1990Sep14.190247.10645@watserv1.waterloo.edu>
Date: 14 Sep 90 19:02:47 GMT
References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu>
Sender: hlab@milton.u.washington.edu
Organization: University of Waterloo
Lines: 64
Approved: hitl@hardy.u.washington.edu


In article <7507@milton.u.washington.edu> wex@dali.pws.bull.com (Buckaroo Banzai
) writes:
>In article <1990Sep9.182518.12605@watserv1.waterloo.edu> broehl@watserv1.waterl
o
>   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...

Apparently my explanation (later in the article you quote) wasn't very clear.
(That's what I get for writing in a hurry).

My idea is that the attributes the building sends to the user *must* be
defined by the user.  If I'm on a monochrome display, I tell the building
not to send color.  I do this my not including 'color' is the list of
attributes I want the building to send.

In other words, the attributes I can handle are determined by my hardware
and software, and if the building learns about additional attributes I can't
be expected to deal with them intelligently.  So I only tell the building
what I *can* handle.  If I list an attribute  *it* doesn't know about, that's
fine; it doesn't send it and I leave the attribute at its default value.
(The first VR stations that implement, say, barometric pressure will have it
at its default value until such time as buildings begin to support it).

The same is true in the other direction (though I suspect most buildings
would accept all attributes and simply store them; the building does
very little actual processing, and mostly just relays attribute information
between occupants).

>We ran into this problem while trying to design a system that could model
>gravity and collisions by objects interacting intelligently.

A very complex problem that might best be solved (at least initially) by
altering (read eliminating) many of the physical laws that apply to a given
VR.  Bear in mind that (as I pointed out in an earlier posting) a Newtonian
model is not necessarily what we want.  If I were designing reality, I
might well choose not to implement gravity (even if doing so were easy,
which it's not).  "Collisions" are often a *bad* thing.

>        - the baseball being pitched and hit;
>        - a jet airliner taxiing to a halt at a terminal gate;
>        - a glass of water falling off a table to the floor.

Good examples, all of which can be done more easily in the real, physical
world than in a virtual one.

I think we're entering into what may be one of the great ongoing debates in
the realm of VR: are we trying to model existing physical reality, or are
we trying to define new worlds with new sets of properties and physical laws?

I think the answer may be "both", but that the latter (being far easier) will
be the first to be implemented.

-- 
        Bernie Roehl, University of Waterloo Electrical Engineering Dept
        Mail: broehl@watserv1.waterloo.edu OR broehl@watserv1.UWaterloo.ca
        BangPath: {allegra,decvax,utzoo,clyde}!watmath!watserv1!broehl
        Voice:  (519) 885-1211 x 2607 [work]