From: dlwood@mailbox.syr.edu (David L Wood)
Subject: Re: TECH: world description
Originator: hlab@milton.u.washington.edu
Organization: Syracuse University, Syracuse, NY
Date: Thu, 13 Aug 1992 00:59:03 GMT



In article <1992Aug10.091948.19421@icf.hrb.com> jtt@icf.hrb.com (Jack
Taylor) writes:

[ a bit Ctrl-K'ed ]

>On startup data exchange
>------------------------
>
>Part of the protocol for entry into a world would be the required
>exchange of the definition of the objects in the world to the newly
>connected local processor. As Bernie Roehl and several others have
>pointed out this is a large amount of information.

Well, the example given was for 128 bit coordinates.  If you have 1000
objects and each can be represented by as many as 400 bytes, that's a
lot.  Typically, with pseudo-CSG representations and scaled local
object coordinates (i.e. using 8 bit coordinates for the object and
that is scaled to 32) using delta encoding possibly, the quantity,
IMHO, will be around 100 bytes tops for fairly simple objects.  For
those further away, even fewer bytes are required, possibly as few as
70.  (With compression and ignoring insignificant detail.)

>Since it is unlikely that a participant will "visit" a world, or
>encounter an object, only once, there should be a method within the
>architecture where a participant can store object definitions locally.
>During the startup interchange there would only be a need to handshake
>the fact that the object exists in the local database, rather than
>exchanging every part of the object definition. Only the current state
>information would need to be exchanged.

Yes, each client will download the universe (well, not the whole thing
:)) and thenceforth all references to the object will be to the
object's unique object ID.  The router would say: Want dataset for
obj#:######, and the client will scan their list of obj id's that it
already has on disk, and then reply: no, or yes.  The object's
position/orientation and spatial data will be sent regardless.  Unless
you have a psychic client. :-)

>On second thought isn't some sort of object class database really
>helpful here? i.e. isn't that fork in the kitchen drawer in my world
>basically the same as the one that just came flying over the wall?

Most definitely, I see the net developing where each client, as it
sees "new" object and object types, developing its own database of
common objects.  An auto-purge program could delete those infrequently
observed object id's or types to conserve space.  As Dave Stampe noted
earlier, it would be a great band-width saver to allow for references
to "primitives" within an object's dataset (representation), which
could be extended to object ID's, and object types.  Suppose a new
user jumped into the net next to you, and he was carrying a fork:
Instead of downloading the representation/dataset of the fork from the
router blindly, the router could query you: "Do you have the dataset
for obj id#?" or "Do you have the dataset for object type: FORK?"

This would require careful maintenance of that object database on each
router.  Does each router have the SAME object database? Each router
must agree on the unique object ID's I would imagine.  Hmmm,
abstracting the object types into types like: FORK, SPOON, LASERGUN,
LASERGUN2, LASERGUN3, HAT1, HAT2, HAT3, will be an aid in reducing
bandwidth, but adds load to the router.  I think this calls for some
experimenting, to see what is the best balance, between complexity of
object dataset types and router load.  If the routers can handle the
storage of a huge database of complex objects, then bandwidth is more
available for animation and such, however if the router can't handle
it, the object types will have to be much much more generic than
"FORK", maybe: cylinder1, cylinder2, rectangularPrism1, etc... Even
these will require some modifying parameters, dimensions.  Hmm,
thoughts?

+-----------------------------+-----------------------------------------+
| dlwood@mailbox.syr.edu      | Gigs and gigs of NiCad memory, bummer.. |
| Cybernaut, with a thought.  | Why buy the leading brand; 90% hate it. |
+-----------------------------+-----------------------------------------+