Re: LANG: Re: scalability (VRML)

Chris Holt (Chris.Holt@newcastle.ac.uk)
Thu, 16 Jun 1994 15:47:52 +0100 (BST)


> From: Brian Behlendorf <brian@wired.com>
> Mark Waks wrote:
> >
> > Which gets us back to the language issue of object classes. As this
> > discussion goes along, I become more and more convinced that, at least
> > in the long run, we *must* have a really object-oriented solution here.
> > The description of a scene shouldn't incorporate a thousand polygons --
> > it should say "Put a six-foot refrigerator over there"...
>
> Aha! Here's an interesting problem. At what point does the author's
> wish to have you see "his" refrigerator conflict with your desire not
> to have to download "his" refrigerator but view one of your own?
...
> The author added a semantic, hidden tag to the
> refrigerator object saying, essentially, "This is a REFRIDGERATOR -
> its code is at <URL>" Now, your browser happened to find in its
> local cache an object which was named "REFRIDGERATOR", so it gives
> you the option of loading the local version (stretched to fit in the
> right place) or fetching the "real" one. Now, if the author REALLY
> wanted you to see his fridge, he could call it "REFRIDGERATOR-NEW"
> or "REFRIDGERATOR-<AUTHOR>", and it wouldn't give you the choice of
> locading the local one.

Suppose there is a hierarchy of refinements: the first message would
say "there is an object", the second would say "there is a large
object", the third would say "there is a large fridge", the fourth
could add information about colour and style, and so forth. This
gives the user the ability to stop getting more information at any
step in the process, either by the equivalent of clicking on the
spinning Mosaic world, or by having pre-set defaults in the viewer.

This could also apply to the world info: the first message gives the
dimensionality of the world and whether it's bounded, the second
could give more precise information about its size, and so forth.
With respect to position, the first message would say that an
object is at the lower left, an object is behind it, and another
object is at the upper right; and positions could be refined as
well. An example:

3D bounded NESWC:
object SE1, SE2, NW, C
link E, W, C

means there is a room bounded in all four compass directions and
in front (C for center) that contains four objects: one at the bottom
right, another behind it (but visible), one at the top left, and
one in the center. There are links to other places on the left,
the right, and dead ahead.

object SE1:
size large
name fridge
action open, close, get, put

says that the first object at the bottom right is large, it's called
a fridge (which can create an image if the name is locally available),
and that four actions can be performed on it (with constraints about
their orders following later).

I'm sure there are better ways to write these things; I haven't
been involved in the construction of MUDs, but experiences there
must be able to help.

------------------------------------------------------------------------------
Chris.Holt@newcastle.ac.uk ftp://tuda.ncl.ac.uk/pub/local/ncmh1/nameplate.html
------------------------------------------------------------------------------
I had rather be a dog and bay the moon, / Than such a cybernaut.