From: broehl@sunee.waterloo.edu (Bernie Roehl)
Newsgroups: sci.virtual-worlds
Subject: TECH: A discussion update for newcomers: distributed worlds
Date: 22 Jul 92 02:02:40 GMT
Organization: University of Waterloo
Originator: hlab@milton.u.washington.edu



Lately, I've gotten a couple of mail messages from people who are just
now joining this discussion thread.  They've asked for a recap of
what's been discussed so far; I've mentioned that the sci.virtual-
worlds group is being archived, but they'd like a more concise
summary.

In an earlier article, I wrote:

> I don't *have* any answers!  (At least, not yet).

Well, with the help of the net I think we have more answers now than
we did then.  (Of course, we now have a number of new questions, but I
think we're making progress!)

The rest of this article is a "state of the discussion" message.
[---------------------------------------------------------------------]

There are a number of things that we seem to have a concensus on.  We
all agree that whatever standards we come up with must provide for
extensibility; no one thinks we can come up with a perfect design that
will never have any need to grow.

We all agree that objects (whatever and wherever they are) should
consist of a set of attributes (including appearance, location and so
on) and software that governs the object's behaviour.  We also agree
that objects should keep their internal structure to themselves, and
should communicate with each other by sending messages.

One major area of disagreement is the question of where the code that
operates the object should execute; the three possibilities that have
been discussed so far are:

    - the code for all objects in a given world executes on a single machine
      (or cluster of machines); there is no object-to-object communication
      over the network

    - the code for all objects in a given world executes primarily on the
      machines that are used to access the world (the "decks") with minimal
      object-to-object communication over the network

    - the code for each object executes on some machine in the network, which
      in general will not be a single large mainframe or a user "deck"; there
      is substantial object-to-object communication over the network

It is not clear which of these approaches is best; various hybrids of
the three approaches are certainly possible.  There is no question
that this decision has a profound effect on the majority of issues
listed below.

Now, on to the "questions".  In cases where I've said "the concensus
is", all I mean is that "very few people have said anything else".  It
is *not* the same as "it is unanimously agreed that...".

> left-handed versus right-handed coordinate systems

    No one seems to have expressed any opinions on this one.  What do
    other systems use?  (which way do X, Y and Z point, and which
    direction constitutes a "positive" rotation?)

> degrees vs radians for angular measurements

    The only opinions expressed so far have suggested degrees; the
    reasoning is that more people who know radians also know degrees,
    than the other way around.

> integer vs floating-point representations of coordinates

    This is a continuing topic of discussion, as yet unresolved.  The
    majority currently favor a floating-point representation, but there
    are some problems with this.

> precision of coordinate values (16, 24, 32, 64, 128 bits)

    This is also a continuing discussion.  No clear concensus; I
    suspect this is one area where "extensibility" will be important.
    (Note that this issue is *independent* of the integer vs floating
    point question; even if we use floating point, we still have to
    decide on how many bits will be in the mantissa).

> Do we associate a real-world scale with the space?

    Yes.

> How do we subdivide space into more manageable chunks (to avoid having to
> keep the entire universe's database in memory on every machine)?
> How do we define connections between areas?  How do we pass from one "world"
> to another?  Do we need a "God"?  If so, one in each "world"?  In each area?
> What does this "God" object do, exactly?  What happens if God "dies"...
> does the world come to an end?  Or does another God process start up?

    This relates in some ways to the question (disussed above) of
    "where does the object's code execute?" and is therefore a very
    grey area.

> How do we deal with the problems of synchronization and causality in a
> distributed network environment?

    The short answer seems to be "we don't".  We accept that there will
    be such problems.  Several people (on the net and in private email)
    have suggested that objects can simply respond to messages in the
    order in which they arrive; others have suggested the use of
    timestamps and "rewinding time".

> What do we do about the inherent propagation delays and possible burstiness?

    As quite a number of people have pointed out, there's nothing we
    *can* do about it.  This also relates to the "where does the object
    get implemented" discussion above.

> What should our unit of time measurement be?  What precision should it have?

    No clear answer here, but most people have said that it should be a
    simple integer value of some sort.  (in other words, time is
    quantized).

> Should we attempt to maintain synchronized 'clocks' within each world?

    Yes.

> Should we support multiple light sources?

    Yes, but their implementation is up to the rendering device.

> What properties should they have?
> (e.g. location, direction, spreading angle, color, intensity, etc...)

    People have suggested we look at how Renderman handles this; so
    far, no one has described this in any detail.

> What form should we represent color in?  24 bit RGB?

    Again, people have suggested looking at Renderman.

> What about systems with loadable palettes?

    It's up to the rendering station how they map colors via palettes.

> How do we ensure that a given color looks the same to everyone?

    We don't need to.  As long as colors can be *distinguished*, the
    precise color need not look the same to all viewers (though green
    should still be recognizably green).  In worlds where we wish to
    have some degree of fidelity to the real, physical world we may
    have to deal with this issue in more detail.

> How do we represent and share surface textures?

    The only suggestion I can recall seeing was "mips maps" (with no
    further explanation of exactly what these are).  Again, people have
    also suggested looking at Renderman.

> How do we represent object geometries?

    We should provide a variety of different "flavors" -- CSG,
    polygons, possibly others.

> Should we support multiple representations for objects?

    Yes, for those flavors of geometric representation for which it
    makes sense.

> What aspects of an object are represenation-independent?

    Not clear, but the idea of each object having an extensible list
    of arbitrary attributes seems to make the most sense.

> How should we represent these?

    It's up to each (type of) object.  There should be ways of
    accessing information in an object by sending it messages and
    having it send messages back.  It's up to the object to decide what
    it wants to tell you about itself.

> How do we define relationships between objects (i.e. connections or
> dependencies, like a lower arm connected to an upper arm
> connected to a torso)?

    As a minimum, we should allow every object to have a parent and an
    arbitrary number of children, leading to a tree-like hierarchy.

> How do we identify objects?  Names?  Numbers?
> How many bits are needed for an object id?  Can we use variable-length
> object ids?

    The most common suggestion (received from several people via email)
    is to use 64 bit numbers, possibly with shorter "nicknames".

> How do we ensure uniqueness?

    Distributed number-allocation of some sort (no real good ideas
    yet).

> How can we do collision detection in real time?

    Three possibilites: let the objects do it, let some central host do
    it, or have specialized collision-detection servers do it.  (The
    "where does the object execute" discussion once again).

> Do we want to be able to share object behaviour information?

    The "where does the object run" issue, yet again.

> If so, how do we do it in a portable way?

    The concensus seems to favor some sort of threaded interpretive
    language.

> What sort of information do we need to communicate?

    The great debate, again.

> What sort of network topology do we want?

    We shouldn't specify one; whatever we come up with should
    be portable across platforms and across networking technologies.

> Do we want a central server, maintaining world state information?

    The great debate, again.

> If so, how do we avoid the problems associated with such centralization?

    No answers have been proposed, other than "get lots and lots and
    lots of computing horsepower and network bandwidth".

> If we opt for a fully-distributed system, how do we ensure consistency of
> world models?

    Complete consistency may not be possible; this is basically the
    "network lag" problem with a different jacket on.

> What about a hybrid system?  What should happen where?

    This is *the* central issue, as described above.

[--------------------------------------------------------------------]

Anyway... it seems that if we can resolve the one big issue, a lot of
the other questions have straightforward answers.

I hope this helps bring newcomers up to speed; if you have anything to
contribute, please do!  (Especially on the "where does an object live"
issue!)

-- 
        Bernie Roehl, University of Waterloo Electrical Engineering Dept
        Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
        BangPath: uunet!watmath!sunee!broehl
        Voice:  (519) 885-1211 x 2607 [work]


-- 
        Bernie Roehl, University of Waterloo Electrical Engineering Dept
        Mail: broehl@sunee.waterloo.edu OR broehl@sunee.UWaterloo.ca
        BangPath: uunet!watmath!sunee!broehl
        Voice:  (519) 885-1211 x 2607 [work]