loki@relay.EU.net (Never Kid A Kidder) (09/21/90)
At the most fundamental level, we have to map information onto the physical senses. To do this, a VRobject must contain directives as to how to render itself. The information it uses to do this can be arbitrarily encoded - someone mentioned SmallTalk, but some language, anyway - in such a way that the object itself need not contain the info, but merely directions on how to get that info (eg, "my position is (x,y,z), and my shape is a square, and I want you to fill me with the video images from socket V", or "ask the weather database for pressure readings against lat/long, and render me as an undulating plain", or "my position is (x,y,z), I'm a box, and I'm emitting sound which you can find on socket A", or "my movements are determined by input device D on machine M"). These kinds of VRobjects, once you've received this info, don't need to bother you again unless they do something you couldn't tell from the info they contained. Now the last example I gave might be better done as informing you whenever it changes, or you are going to have to keep interrogating that input device, and given that it might be someone's DataGlove, *everyone* in that VRspace will be doing the same, to keep up to date. So the way I see it, you only need directives for this physical mapping, and I'm getting confused as to what exactly people mean by attributes; do you mean other information which can be rendered (still in one of the physical ways) on a purely voluntary basis, depending on what the user is interested in? Here are some more ideas about VRobjects. Sorry for the inclusion of cyberjargon, but it seems to fit. We are VRobjects too, as is our `deck'. We have a door object whose function is to check for (a) us wanting to exit, and (b) others wanting to enter. From the inside, this can be done by waiting for our VRhand to press an activation panel, and from the outside, the door can wait for `knock knock' packets coming in from the net. These doors can be as tight as Fort Knox if we so chose. Maybe `ICE' can be a part of this security. Once out of this door, we have a view of some kind of net (`the matrix'), with machines spacially separated in some way determined by using, say, the network address. Once through the door, we are in a VRSpace where there might be other people &c. &c.. Back to our own deck, we might want to create personal doors/windows/teevees onto our own configured reality - say one into that weather example I gave. We can then create objects which represent arbitrary information, using our universal language, and do whatever it is we want with them. This will be a personal world, but if anyone enters your deck, they will be able to share and enjoy.
hlab@milton.u.washington.edu (Human Int. Technology Lab) (09/26/90)
In article <7987@milton.u.washington.edu> moncam!loki@relay.EU.net (Never Kid A Kidder) writes: > At the most fundamental level, we have to map information onto the > physical senses. To do this, a VRobject must contain directives as to > how to render itself. I don't agree that objects should contain rendering information at all. Rendering is a process which is highly dependent on the physical and computation properties of the "deck" in use by a given user. For instance, what's the resolution, is it sufficient to resolve a given texture, is there enough power to anti-alias so there isn't any moire in the texture, can it do ray-tracing fast enough to be interactive, etc., etc. Instead, objects should contain information about themselves in a common language which can be understood and used by all observers. One good candidate for this language is physics (which might be the physics we know in the real world, or some imagined alternative). Objects know their shapes, how they react to external forces (are they rigid, elastic, permanently deformable, etc.), their interactive attributes (color, reflectivity, etc.). Some of this knowledge, especially color and other direct observables, could be indirect, in that the object would specify, for instance, that it's surface was steel, so that the common understanding of the attributes of steel could be used, but this is still not rendering information. > The information it uses to do this can be > arbitrarily encoded - someone mentioned SmallTalk, but some language, > anyway - in such a way that the object itself need not contain the > info, but merely directions on how to get that info (eg, "my position > is (x,y,z), and my shape is a square, and I want you to fill me with > the video images from socket V", or "ask the weather database for > pressure readings against lat/long, and render me as an undulating > plain", or "my position is (x,y,z), I'm a box, and I'm emitting sound > which you can find on socket A", or "my movements are determined by > input device D on machine M"). Again, this scheme exposes too much of the insides of the objects to the rest of the system. The idea behind objects in software systems is to hide the implementation, so that it can change, or be different from one computer to another, without affecting other parts of the software which depend on it's behavior. This is especially necessary for systems which reside on thousands, or millions, of computers of all types distributed all over the world, which is exactly what cyberspace, or any consensual VR, would evolve into. > > We are VRobjects too, as is our `deck'. We have a door object whose > function is to check for (a) us wanting to exit, and (b) others > wanting to enter. But that's not all a door does, and that might be significant to the designer of that part of the VR. Just because I have a VR interface designed by someone who didn't think that a door can also have a window in it, doesn't mean I should be precluded from using the window (or even seeing it!) if I come across it while wandering through a virtual reality. For that matter, suppose I wanted to leave the door ajar? -- --------------------------------------------------------------------------- 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