By the way, remember that there are two aspects to distribution of
rendering info. One aspect is transferring the model geometry and colors
(materials) to each machine with a window into the environment. The second
part is transmitting updated information and changes in location and/or
geometry.
If you want to know more about Anim, please contact Boston Dynamics, Inc at
(617) 621-2929. You might have to mention the article in Computer to help
them understand why you are interested in Anim.
>Does each machine have a seperate copy of the database (thus the data is
>replicated on each machine), or is there one distributed database which is
>shared across the machines, with each machine implementing some protocol which
>allows it to serve up the parts of the db it owns to the others, and access
>the
>parts which are distributed on the other machines ?? (and there is thus no
>real
>data replication).
If I understand it correctly, each machine that is showing the geometry has
a local copy of the geometry and the position of the geometry is updated
using point to point communication (pipes) - not very scalable but it was
already written.
>
>It strikes me that the replicated solution is more suited to getting better
>frame rates on complex dbs across a laggy network with lots of users because
>when you render, you render from a local db and don't have to ask remote dbs
>>for info,
The graphical database must be local or it couldn't be drawn. I think I
might be misunderstanding the question. Perhaps you are asking if the
database must be exactly the same on both machines at frame-drawing time.
I do not think that Anim requires exact synchronization because that would
lock the two frame rates together and synchronization would probably take a
large part of the available 100 milliseconds per frame (at 10 Hz) and not
leave enough time for drawing. Also, I don't think that slight frame
differences will make a large difference in perception for the applications
we outlined here.
>but that the non-replicated solution is much easier to implement ... in
>particular, you don't have to worry about implementing crazy synch-lock stuff
>to
>ensure that time-sequence-important world-db modifications are kept in step
>with
>each other ... so users see the same thing happening and interactivity in
>particular would seem to proceed in a simpler manner.
>
>The main problem I see
>with the non-replicated solution is that it won't scale, because the more
>machines which are rendering from the db, the more messages fly about, etc,
>etc.
>Is this why the system described suffered from scalability problems possibly ??
We never planned on scaling that particular system and I don't believe that
it would scale. In fact, to have scalability, you have to give up some
consistency somewhere, and Anim maintains consistency between the worlds.
>
>I have been wondering how much of "not seeing the same thing" (or rather. not
>seeing the same thing at the same time -- more accurate) is acceptable. This
>is
>in some sences a **really** dumb question, but one with a lot of relevance
>once
>you start thinking about how to deal with synching replicated rendering
>databases over a laggy net; and scalability while preserving interaction. It
>goes to the heart of the problems of replicating and synching world-dbs over a
>number of machines, and how this relates to interactivity. Or lack of it ..
>etc.
Do you always see the same thing as the person sitting next to you? How
about the person 3 offices away? We discussed this a lot when designing
the new system.
>
>Did whatever scheme anim implemented for distribution of the rendering db
>provide reasonable performance for the "new" version; or have you replaced it
>with another rendering database distribution scheme ? If so, could you detail
>what you are doing in this respect .. ? And any opinions you/the MERL group in
>general have in this regard .. ?
We don't own Anim and never will and we have never seen the source or the
data format. We started from scratch with much different objectives than
BDI. More details to come (please let us make sure it works well first!)
I guess "our" "opinion" is that in a large simulated environment, with
limited bandwidth, forcing consistency in a large number of replicated
databases would bring the network and the simulation to it's knees. So, we
only pay attention to the parts of the world model that we are interested
in - for instance, things that are close, virtually. We've done away with
point-to-point connections. In that way we are much like DIS.
Here are some pointers to replicated database systems:
I believe that CMU is the source of ISIS - a replicated database that is
used in Distributed Interactive Virtual Environment (from SICS in Sweden).
The DIVE folks gave some presentations at VRAIS '93 and their names and
contact information are: Stephen Travis Pope ([email protected]) and Lennart E.
Fahlen ([email protected]). There is plenty of ftp-able information about DIVE
and how it works. I think I heard that up to 4 people can be in their
environment at once, but then it gets too slow. I may be wrong, so if
someone has better information, please correct me.
Also, Division, Ltd. (UK) has a VR system that uses a replicated
(guaranteed consistent) database. They also say that about 4 people can be
in it at once.
Division Incorporated Division, Ltd.
Suite 101 19 Apex Court
400 Seaport Court Woodlands
Redwood City, CA 94063 Almondsbury
(415) 364-6067 Bristol, BS12 4JT UK
(+44) 454-615554
John B.
-------------------------
John Barrus Research Scientist
Mitsubishi Electric Research Laboratories, Inc. voice 1.617.621.7535
201 Broadway fax 1.617.621.7550
Cambridge, MA 02139 [email protected]