Re: copies of vr; 1 for public to trample, 1 for your files, ...

Joe Andrieu (andrieu@presence.COM)
Mon, 31 Oct 94 10:38:03 PST

At 1:55 PM 10/29/94 +0000, Chris Holt wrote:
>James Martin writes:
>
>> When you have a vr scene that you have stuff in that you may want later,
>> cannot you release a copy for the public (or subset thereof) to play with,
>> and retain a pristine copy for your own reference? [deletia]
>
>Interesting and different problems will arise. Suppose you have a
>party room that you give free external copy permission. Some
>people come along, have a look in, decide they don't like the
>party going on, and copy the room, creating a new, empty version
>that they go into. Now along comes another party group; they
>want to be able to look in at both the existing parties before
>deciding whether to create a new copy themselves. Since the
>party is global, there may well be non-ending parties (though
>presumably when a party ends by everyone leaving, it gets
>garbage collected). Now suppose someone in a party wants to
>look at the other parties, because s/he's bored, and finds
>an interesting one. S/he wants to create a gateway between
>the two copies, so people can move between them: "Oh, Amanda,
>I just saw someone in Copy 32 that I *know* you'd love to
>meet." Should there be a generic mechanism for linking together
>these "parallel universes"? It should, of course, be left up
>to the room designer, but there should be standard defaults.
>Problems of scale arise; if there is a hypergate leading to the
>path between all the copies, then if the number of copies gets
>past a thousand or so it gets very hard to keep track of where
>you are, and where you want to go; Grand Central Station is
>confusing.

This is a very interesting take on the possibilities. I think what we are
really talking about here is templates v. instantiations; and thrown in we
might have some janitors.

The author/architect/scenemaster definitely need to be able to return to a
pristine copy. What I found interesting is your suggestion to allow a
random user to pop open _another_ instantiation from the same template
after visiting a cool site.

The dynamics of the space present a lot of exciting opportunities for
opening your own private alcove off the main party. Not only can we add
objects, and modify the space, we can modify topology on the fly. Very
cool.

Designing some effective hypergates to deal with the issues of 1000 rooms
connected to the same party will be a challenge. What I understand about
the current VRML spec allows a variety of solutions.

The key is that each instantiation needs to exist as a single scene on a
single server (not considering advanced/hierarchical mirroring, which is
cool, but I don't know much about real work being done today). The
problems of redundancy and internal system-to-system communication become a
huge beast if your are trying to operate multiple copies of the same
instantiation, and probably is being best addressed by other groups.

Another way to have our cake and eat it too, is to have janitors. Janitor
agents who hang out in the room and return its objects to the original
state when no one else is playing with them. This removes the need for a
mechanism that redirects the entire scene in one blow. And it gets us back
to behaviors, which is IMHO the biggest unaddressed issue, and the most
exiting one.

We should be able to have objects that are controlled remotely, like a
player object. And it would also be good to offer a local
behavior/scripting abilities. How are these being addressed now in the
spec and what are the options for moving the spec forward.

-j

--
Joe Andrieu                          *Internet Construction Ahead*
andrieu@presence.com                      http://www.presence.com/
V.P. of Marketing                              voice: 800-626-6100
Presence Information Design                    fax:   818-405-1817