Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!brucec%phoebus.phoebus.labs.tek.com@RELAY.CS. From: brucec%phoebus.phoebus.labs.tek.com@RELAY.CS. (Bruce Cohen;;50-662;LP=A;) Newsgroups: sci.virtual-worlds Subject: Re: Who says what to whom (was Re: VR Protocols.) Message-ID: <7523@milton.u.washington.edu> Date: 14 Sep 90 01:30:28 GMT References: <31304@unix.cis.pitt.edu> <7507@milton.u.washington.edu> Sender: hlab@milton.u.washington.edu Organization: Tektronix Inc. Lines: 79 Approved: hitl@hardy.u.washington.edu In article <7507@milton.u.washington.edu> wex@dali.pws.bull.com (Buckaroo Banzai ) writes: > > 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. No question, this is a nasty problem. I can think, off hand, of two possible solutions (read: here are a couple of wild ideas, I have no idea if they will solve the problem or not). 1) The object and the building negotiate the list(s) of attributes they will communicate. This is the technique used in standard interfaces which must be extensible, or at least support optional parts of the interface protocol. One requirement of this approach is that there be a bounded list of possible attributes, and that there be some minimal list of attributes that can be relied upon to be present. Then the party requesting the use of an attribute can handle the respondent's lack of it by negotiating the use of attributes which it can use to emulate the missing attribute. If the possible number of optional attributes is large, the number of such emulation strategies can also be large, and that's where this scheme can break down. 2) Treat attributes as objects in themselves. This is an approach I toyed with briefly when working on an object-oriented graphics system. Graphics is typically divided into rendering primitives (which may contain a grouping mechanism to make "compound primitives" :-)), and attributes; trying to implement the primitives as objects which have attribute values as part of their internal state can get you into exactly the kinds of trouble you describe. Suppose instead that you build inheritance hierarchies of attribute object classes, starting from some small set of root classes (the base set of attributes which all "interacting objects" know about). Then maybe you can structure the inheritance so that the specialization of a subclass is such that the emulation I described in suggestion 1) happens as a result of the polymorphic invocation of the attribute objects' methods. > > 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. > I don't see how to make the knowledge sets in two separate frames impinging on each other for the first time mesh. I guess I'm not sure how you mean to relate the objects and the frames. -- --------------------------------------------------------------------------- NOTE: USE THIS ADDRESS TO REPLY, REPLY-TO IN HEADER MAY BE BROKEN! Bruce Cohen, Computer Research Lab email: brucec@tekcrl.labs.tek.com Tektronix Laboratories, Tektronix, Inc. phone: (503)627-5241 M/S 50-662, P.O. Box 500, Beaverton, OR 97077