Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!xanthian@zorch.SF-Bay.ORG From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: sci.virtual-worlds Subject: Re: Who says what to whom (was Re: VR Protocols.) Message-ID: <7989@milton.u.washington.edu> Date: 23 Sep 90 04:05:46 GMT References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu> <7801@milto Sender: hlab@milton.u.washington.edu Organization: SF-Bay Public-Access Unix Lines: 60 Approved: hitl@hardy.u.washington.edu wex@dali.pws.bull.com (Buckaroo Banzai) writes: > >broehl@watserv1.waterloo.edu (Bernie Roehl) writes: > 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. > >The problem is not one of implementation - of course you can construct >special cases for buildings, chairs, planes, balls, bats, etc. ad nauseum. >But wouldn't it be better to have a model of objects where you could define >some general rules (for what attributes you want to ask about) and just >specialize a few of them? > >The other problem is that you're more or less violating the "object-ness" of >the model. The more one object knows about the internal implementation of >another object, the less modular your implementation, etc. > > 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. > >So what's the default value for something like "has a door I can walk >through"? Do you see how much knowledge is presupposed simply in asking >that question? This is what led me to want to separate out the real-world- >modeling aspects from the objects-that-implement-stuff aspects. But in the real world, nothing screams at me "has a(nother) door I can walk through" when I enter a room. What I get, with the aid of a lot of visual system processing is: "has a rectangular parallelopiped with a striated texture and two shiny cylinders on one side's edge and one white shiny circular object on the other". It is _my_ knowledge base/subsequent processing that classifies that as "probable door, two brass hinges, one enamel doorknob", with a possible alternate, subject to further interactive test, classification of "photorealistic painting". So until I bring my (defined to the building) physical envelope within contact distance of that doorknob, all the building has to do about the door is send responses to my "accepts visual input of types location, geometric form, color, texture, reflectance, transparency" profile, and depend on me to correctly classify them. It need not send semantics (heck, the _building_ doesn't know that's a "door", merely that it is a physical, impenetrable object that pivots out of the way on one side and has a latching mechanism on the other; how I use it is up to me.) Similarly, while the building needs to know about my mass and physical extent and position, unless it contains mirrors, it is probably intensely uninterested in the fact that I can provide visual information, and it is probably inappropriate design to put that capability in the building, simply to transport it to the other users or to the mirror. At some predefined interaction distance (subsumes at least one pixel), let the _mirror_ tell me it accepts and provides visual stimuli. Let the _doorknob_ tell me at contact distance that it provides tactile stimuli, and accepts both push and torque input. Kent, the man from xanth.