Re: Portals vs Links

Chris Marrin ([email protected])
Thu, 4 May 1995 20:13:28 -0700


> When a user enters a "room" the room's VRML code is sent to the user's
> browser to render. What then? How can interaction take place?

Before working on WebSpace, I worked on InPerson, which is a
teleconferencing product. Users could join a remote conference with
audio, video and a shared whiteboard. The part that is interesting to
this discussion is the shared whiteboard. This is a flat surface upon
which you can draw, drop images and 3D objects, and type text.
Whiteboards on all machines display the same thing. If I mark on my
whiteboard, I see it locally, and you see it remotely. Additionally
everyone sees everyone elses cursor position in the form of unique sprite.
When I talk about a 3D object that got placed on the whiteboard, I can
move my cursor around it and everyone can see what I'm talking about.
This seems like a 2D version of the same problem we're trying to solve.

Here's how we could do it:

- A server is running through which all information flows (for us this
would probably run on the machine on which the VRML world resides).

- The server keeps a scene graph of any dynamic object in the world (such
as Avatars for visitors, or objects dropped into the room)

- When someone goes to that world (by selecting the URL, as today) s/he
gets sent the original world and any dynamic objects the server is
storing. That new visitor also gets added to the server's object list.

- The new visitor gets sent the VRML world and the dynamic objects which
are displayed in his/her viewer.

- When the visitor moves, picks up an object, or performs any other
action, his/her viewer sends the change to the server and updates the
change locally.

- When the server receives a change it updates its dynamic objects and
propagates the change to its list of visitors (but not the originator of
the change since it's already been updated there).

- When a viewer receives a remote change (through some sort of server push
operation) it updates its scene.

- When a visitor leaves, the server removes his/her name from the list of
current visitors and removes the Avatar from its object store.

This would minimize traffic since the server would only ever have to talk
to those currently in the world and even then only to the visitor who did
NOT originate the change. If I walk into a room that has no other
visitors, drop an object and leave, the server never had to send out any
information. Also, only changes to the world would be sent, further
reducing traffic.

Both the server and the browsers would have to understand a set of
messages beyond simple GET style URLs (update my position, add a new
object to the scene, etc.).

In InPerson, we encountered issues of latency and baton passing to make
operations atomic but the basic protocol was very solid.

Note that this deals only with the issue of shared presence in a world and
not connectivity between worlds. I see that as a separate and orthogonal
issue.

-- 
chris marrin      Silicon      http://www.sgi.com/Products/WebFORCE/WebSpace
(415) 390-5367    Graphics  ," http://reality.sgi.com/employees/cmarrin/
[email protected]   Inc.    b`    ,                             ,,.
                        mP     b"                            , 1$'
        ,.`           ,b`    ,`                              :$$' 
     ,|`             mP    ,`                                             ,mm
   ,b"              b"   ,`                ,mm      m$$    ,m          ,,`P$$
  m$`             ,b`  .` ,mm          ,.`'|$P   ,|"1$`  ,b$P       ,,`   :$1
 b$`             ,$: :,`` |$$       ,:`    $$` ,|` ,$$,,`"$$      .`      :$|
b$|            _m$`,:`    :$1    ,:`      ,$Pm|`    `    :$$,..;"'        |$:
P$b,      _;b$$b$1"       |$$ ,,``       ,$$"             ``'             $$
 ```"```'"    `"`         `""`           ""`                             ,P`
"As a general rule, don't solve puzzles that open portals to Hell."-...-'
		   - excerpt from "A Horror Movie Character's Survival Guide"