Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!wex@dali.pws.bull.com
From: wex@dali.pws.bull.com (Buckaroo Banzai)
Newsgroups: sci.virtual-worlds
Subject: Who says what to whom (was Re: VR Protocols.)
Message-ID: <7507@milton.u.washington.edu>
Date: 13 Sep 90 14:12:30 GMT
References: <31304@unix.cis.pitt.edu>
Sender: hlab@milton.u.washington.edu
Organization: Bull Worldwide Information Systems Inc.
Lines: 51
Approved: hitl@hardy.u.washington.edu



In article <1990Sep9.182518.12605@watserv1.waterloo.edu> broehl@watserv1.waterlo
o.edu (Bernie Roehl) writes:
   Some protocol thoughts...

   There should be an initial interchange with the building, in which:

   1. The user identifies him/herself to the building
   2. The building either welcomes the user or rejects them (e.g. building close
d)
   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).

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.

We ran into this problem while trying to design a system that could model
gravity and collisions by objects interacting intelligently.  We had three
test cases we wanted to be able to solve:
        - 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.

Simpler versions of these problems have been solved by other approaches,
such as cognitive modeling and constraint-based programming.  We wanted to
see if the interacting-objects model could do as well, but we got bogged
down in the issue of how much knowledge objects need.

We ended up with a ridiculously topheavy structure where the generic
superclasses had all sorts of specialized information which was used to
optimize the enormous searches that the leaf-class objects were required to
perform.

I had an idea for improving this by going from a pure object representation
to a frames+objects representation, where the objects would handle action
rules and the frames would contain "knowledge" in the AI/KR sense.  However,
I haven't had a chance to test out this idea.

--
--Alan Wexelblat                        phone: (508)294-7485
Bull Worldwide Information Systems      internet: wex@pws.bull.com
"Politics is Comedy plus Pretense."