your explanation of how to create an interactive VRML world in the same
sense of the InPerson whiteboard is interesting, but I am concerned
about synchronization problems between clients. Suppose one
client/browser has a 14.4 connection, while another one is located at the
other end of a T3. Also, because of network traffic, it takes forever for
packets to even get _routed_ to the 14.4 modem, let alone transfer over
the modem. Then, under your model, the user of client A@T3 could make
changes to his world (say, take the coffee off of the maker) which would be
transfered to the server; unfortunately it takes almost 1 minute for this
message to reach client [email protected]. Meanwhile, the user of client B decides
it would be fun to smash the coffee pot (which to him remains on coffee
maker) into tiny shards of glass, and he does so. His message gets sent
back to the server. What happens then? The two versions of the same world
are now inconsistent.
One way to fix up this problem (but I don't like it) is simply to have
the client make _requests_ for changes to the server. When a server
recieves a _request_, it sends the message off to all other client
programs, which make the change in the request packet and send back to
the server an "O.K. I'm Done" Packet. When the server recieves such
packets from all clients it sent the request to, the server then proceeds
to send an "O.K. your request was approved" packet back to the client.
This option isn't too spiffy, since network traffic is greatly increased.
Another (better?) way of handling the problem would be with message
queues, but I am busy and must run now...
>> David Peck http://www.mbhs.edu/~dpeck/ Music, Photography, Macintosh <<
On Thu, 4 May 1995, Chris Marrin wrote:
> > 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"
>