Path: utzoo!attcan!uunet!snorkelwacker!mintaka!ogicse!milton!wex@dali.pws.bull.com
From: wex@dali.pws.bull.com (Buckaroo Banzai)
Newsgroups: sci.virtual-worlds
Subject: Re: Who says what to whom (was Re: VR Protocols.)
Message-ID: <7802@milton.u.washington.edu>
Date: 17 Sep 90 22:25:37 GMT
References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu>
Sender: hlab@milton.u.washington.edu
Organization: Bull Worldwide Information Systems Inc.
Lines: 54
Approved: hitl@hardy.u.washington.edu



In article <7661@milton.u.washington.edu> brucec%phoebus.phoebus.labs.tek.com@RE
LAY.CS. (Bruce Cohen;;50-662;LP=A;) writes:
   Sorry, I wasn't clear there: by strategy, I meant a per-attribute strategy
   for emulating that attribute using some set of other attributes.  For
   instance, in graphics texture is frequently emulated with crosshatching or
   some other regular pattern.

OK - it just looks to me that if there are per-attribute strategies it's
going to get awfully messy.  Essentially you'd need some kind of forward- or
backward-chaining system to say "Here are the attributes I have, here's what
I need, here are strategies for getting from to any A from some subset of A,
now synthesize the rest."

   I'm still a little hazy on this, so let me try to rephrase it and correct
   me if I'm wrong.  I think you are saying that the frames contain (inter
   alia) knowledge of the attributes valid to some sublattice of the object
   inheritance graph, and that an object (the baseball, say) wanting to
   negotiate attributes with another object (the bat) can find the
   intersection of the attribute lists in the ball's frame and the bat's
   frame.

Nope.  What I meant was that when we try to build a VR that models some
attributes of the world, we in some way "encode" real-world knowledge.  At
the same time, we have to invent "world-things" which do our VR stuff, like
display themselves, interact with users, etc.  Most systems that I know of
build the real-world knowledge into the objects.

I think that the right way to go about this is to separate the two kinds of
information.  Then we provide some way for objects to refer into the
knowledge lattice based on something about an object (e.g. the class to
which the object bleongs).  The requestor then asks something about the real
world, which the requested object can try to answer.  This avoids the
problem of the requestor having to know anything about the implementation of
the requestee.

   If this is what you are saying, how is this different from each object
   having the ability to emit its attribute list on request?  There still has
   to be a computation somewhere which determines how to map the things the
   ball can do to the things the bat wants to do to it; where is this done?

Objects can, of course, be queried for their attribute lists.  And, true,
there's still computation to be done.  In fact, my scheme *increases* the
amount of computation, but *decreases* the message passing.  That is why we
were looking at something like parallel Smalltalk for implementation.  If
you can have each object computing away on its own (in parallel) any only
rarely passing messages, we felt we had a better chance at a usable
implementation.  Unfortunately, we never got a chance to try out the idea.

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