Re: PHIL: How to Get Around

Daniel D. Todd (
Mon, 13 Jun 1994 21:35:19 -0700

At 01:55 AM 6/14/94 --100, Jose Pina Miranda wrote:

>I think this group is arguing about a top-down WWW VR system approach. First
>the "world map", landscapes, ... and then we will see.
>Should we not be discussing a bottom-up WWW VR system approach ?
>I.e., first we define the atomic objects of a VR system (maybe rectangles,
>circles, ... - I don't know, I'm not a VR expert) and the markup associated
>with them (VRML = Virtual Relaity MARKUP Language - I think).
>Only then we can discuss the actions allowed and how we can build complex
>objects upon the atomic ones.
The problem is that whatever way we decide to connect these 'atoms'
(AuTonomous Objects in MetaSpace?) has to be laid out from the beginning.
Is the direction going to be go left three blocks and turn right, will it be
goto location 12,456,763 (x,y,z) or will it be the old standby, Until we decide what point of reference we are going to
use there isn't much use in creating the atoms.

I envision a place where I can define where objects go in my space and what
links show up. It would be really nice to be able to watch other WWWers as
they traverse space too. I can see objects of a certain color if they are
unexplored and just grabbed on the advice of another or sent to me by a
friend. A second color (or texture) would denote areas I've entered but
only travelled through a couple of the links, a third for rooms which have
been fully explored and another full series of colors to somehow denote my
own traffic through these sites so I can quickly find my favorite sites. It
would also be nice to have these colors (or whatever) alterable on the fly
so when doing a demo I can change the display to show other traffic patterns
or current status, or even topic. "All members with sports references turn
red now." Now I'm starting to blabber. This started out about references
right? :-)

>In my point of view, the local client should have the ability to learn and
>remember how complex objects are build (so that the client has to ask the
>server about any complex object, only once ). Probably we will need something
>like an Object Uniform Resource Name (OURN).
This seems the best solution since I may pick different objects to represent
something than you would. For example I may have my weather sites
represented by a storm cloud and you may display them as an anemometer.


* This space intentionally left blank, almost*