From: dlwood@mailbox.syr.edu (David L Wood)
Subject: Re: TECH: My standard is better than your standard. (LONG)
Date: Fri, 7 Aug 92 02:24:59 EDT



We're all working on the same wavelength (just about) now, I hope this
helps to bring us more together, but where I've stretched out a bit,
PLEASE comment, and excuse any ranting or prophesying: it's late. :-)
No copyright, mangle this!

There's a section number followed by a period to help in mangling the
various ideas described.

This (LONG) posting covers:
 Objects in a virtual networked environment
 Bandwidth considerations- message/packet types


How are we to define the very broad term, object?
- I suggest that we break down objects into various >types< of objects,
  with varying >attributes<.
- Attributes must be chosen carefully, they help to abstract the actual
  working manner and what levels of interaction are allowed.

What is a message, really?
- We must define different types of messages, to aide in cacheing
  objects, and abstracting redundant info on the net.
- What is update rate, how does it relate?

How is time managed in this multi-user environment without risk
of causality conflicts?
- We need a sturdy means of timestamping (timeStampeing?) messages
  and to discriminate between messages that need to be timestamped
  and those that do not.

1.
Attributes:
     To use the un*x multi-user operating system as a model to improve
on and carry over into a virtual environment, each object is analagous
to a file.  For example, as soon as a user can >SEE< another object,
that object can be copied.  The entire dataset of that object is known
to all users who can view it.  To prevent the viewing of private
objects, there should be a set of bits that define to whom the object
is VISIBLE to.  For simplicity only two cases of user are considered:
Owner and Non-Owner.  For the owner, you can select visible or
invisible, the same for non-owner.  To make an object (like the
contents of a virtual book you wish to sell) private, you make it
visible only to you.  Part of the protocol must support an exchange of
personal information (an object, a dataset, anything) very much like
private email works today.  In this manner, a virtual bookseller could
peddle his books without fear of the dataset and accompanying text
projections being copied as soon as someone caught a glimpse of it.
Making an object that you own yourself invisible to you would
sometimes be helpful if that object was something that your friends
might want to see, but which would be annoying to you if you had to
look at it every day.  A good example of this kind of object would be
a sign on your yard stating who "lives" (lives!?!) in that virtual
home.

2.
     Two other, related attributes that are essential are: Alterable,
and Manipulable.  These two bits can also be set for both the owner
and the non-owner.  Alterable means just that- should anyone be
allowed to modify your virtual house? your virtual workplace? you
virtual body? (Well, that's up to you.)  Altering also includes
>deletion<, so this bit is very important.  Manipulable means- can
this object be moved from location to location, or rotated? (Scaling?
I'd put scaling under the alter bit.) For objects that you don't want
to move around, like your virtual home, you would want to restrict the
object's motion, unless of course you want a house floating on a pond,
but that's >your< house! :) For something like a basketball, in a
virtual game you would want the manipulable bit set for non-owners as
well as owners, but the alterable bit turned off for non-owners (and
owners, unless you want to cheat with your own ball :) ) The visible
bit would also have to be set for everyone. This corresponds roughly
to the read/write/execute flags set on files in a un*x file system.
Visible == read, Alterable == write, manipulable == execute.  This
type of attribute stratification requires each object to have an
owner, which would be specified in the object's attribute set, a
subset of the dataset.

3.
  The concept of object owners can still allow for "public" objects.
These objects would have their visible, alterable, and manipulable
bits set for non-owners, and the owner field in the record structure
would be left blank.  If an object like a book is left on a virtual
tabletop, and the owner exits the system, that object should either
become: publicly available (bad idea for important items), or it
disappears (disconcerting!) Since that object "belongs" to a
particular user, the message requests that cannot be handled by the
router ( I don't know which these are, but it's a possibility) won't
be forwarded to the owner's machine because the owner is away.


:: Attributes :: Spatial :: Dataset :: - terminology

4.
  For simplicity, call all of those bits of permissions and the
owner's name of the object, "_Attributes_" of the object (more will
probably be added later), and call all the geometric data (i.e. 3d
coordinates (X,Y,Z), orientation (rotation), direction & velocity of
motion..., mass) the "_Spatial_" messages of the object. The actual
points, polygon meshes, b-splines, surface patches, whatever... are
called the "_Dataset_" of the object.  These three terms help to
abstract the actions of an object, its behavior, into smaller datum
more easily transmitted through a network with low bandwidth than raw
data.

5.
  Datasets: To make the dataset of an object smaller, you could define
a "center of object local coordinates" point in 32 bit (or however
large) numbers.  Then the object would define its coordinate bit-size
(32? 16? 8?)  and a scaling value where 1 unit of local object
coordinates equals XXX units of domain coordinates.  This would make a
simple cube EASY and compact.  The values of the vertices would be all
combinations of -1 and +1, in a three variable ordered set, (2^3 = 8
vertices of course) and the polygon data follows that.  The scaling
value could make the cube into a sugar cube or a monolith!  Of course,
if the router was in a yuppie section of the world, then it might be
able to put restrictions on the maximum allowable scaling values.  :(
You're in >>their<< domain, remember.  However, if anyone wishes to be
Zeus, I'll set up a nice domain with no restrictions if this ever
comes to be more than a text files in an archive somewhere.

  Now... Onto the basic object types:

6.
  I think the simplest type of object is a rigid, simple three
dimensional polygon mesh, or combination of surface patches,
b-splines, or other parametric bounding volume formulas.  This type of
object requires the least processing time, overlooking the rendering
computations.  In a message passing scheme, the only type of message
this object will send out are the Attributes, Dataset, and Spatial
data.  This is the virtual fork that doesn't change shape, belongs to
someone, and is capable of being thrown across the wall with
appropriate velocity when the owner feels like it. The only kind of
message that this object receives are requests for the three packet
types that define it.  As soon as the attribute and dataset packets
have been sent once, they need not be sent again until they change.
The spatial packet must be optimized for efficient compaction of
changes in 3d coordinates, rotation, or velocity.  Mass changes are
possible as well, but that would require throwing the fork at 0.1c for
a noticeable effect. :)

7.
  Another kind of object is a user object, which has, between the
virtual graphical representation and the real life user, certain
one-to-one links that allow for control or animation of the virtual
object from a human source.  This object is owned exclusively by one
user at a time.  This object may send out almost any kind of messsge,
including the standard messages: attributes/dataset/spatial data.
This object can also send messages to other user-objects anywhere in
the virtual world, (ala email, or Vmail (virtual mail?)).  This is one
type of object that can receive messages from other objects.  Whereas
a fork won't get a request to chat, a user object may (so if you
choose to look like a fork, I guess a fork object WOULD get chat
requests, but >who< wants to talk to a fork?)  The user object
requires some of the most processing time due to the user input from
the bio-sensors, as well as altering the rendering scene according to
changes in the user input stream.

8.
  Another kind of object is the non-rigid, gadget object.  This object
is similar to a simple-rigid object, but has a very different dataset
packet (more definitions) and send out more information in its spatial
packet. In the dataset of a gadget object, points of rotation and
points of contact between primitves are defined to allow the object to
have "moving parts" on it.  You could make a virtual bicycle that
allows for rotation of the wheels about an axis defined in the
dataset, and a handlebar dataset that allows for rotation about the
axis going along the stem of the bike, even pedals and brake levers.
The spatial packet would send information about the "joint" points of
rotation and changes in them to produce animation of non-user objects.
Other kinds of gadget objects could allow for "stretching polygons"
where a polygon, or a side of a polygon can expand or contract
depending on forces acting on the object.  You could have a mini-plane
whose wings bend back when it is in motion, and straighten out when at
rest.

9.
  There must be provisions of "Attaching" two objects so that once
connected, the two act as a single object in terms of direction and
velocity of motion.  In the bicycle example, the user would have to be
attached to the bike for him/her to use it as a form of transportation
(albeit a tiring form of transportation for a 128 bit world :) ).  To
effectively and realistically attach a human shaped body to a bicycle
in a VE, you would have to define "points of contact" where the user
could move both their appendage and the part of the bike it is glued
to at the same time.  For the feet this works great with the pedals,
however the hands would have to be kept "loosely" attached to the
handlebars, so that the user can turn their head and wave without
making the bike do a 180.  For different objects, the type of "gluing"
performed could get really complicated.

10.
  Another kind of object, that would make VR into a serious tool, is a
"device" object, which could be more similar to either a simple-rigid
or a gadget object.  This object would have another type of object
description, called a "Script" definition.  This really acts like a
device, in that it can receive messages from the environment around it
and execute a 'script' within itself, perhaps even reacting to stimuli
like an organism.  An example is a virtual door camera.  You float to
a company's secure virtual R&D lab, and come to the door.  As soon as
you enter a certain range of the doorway, the camera switches on, and
captures all information about you from the messages it receives
(being a device object, it will define within itself WHICH message
types it wants to receive, which it could update at any time.)  Your
image is then compared within the script program that is executing
inside the camera, and if you pass some sort of test then the camera
will announce your presence to the techie's in the lab.  (Ideally it
would not look at your dataset, but your attributes which contain your
user id.)  The camera could also switch on a terminal screen in front
of you in which you have to type in a code, or speak a phrase into a
microphone, or something like that.  Another device object would be a
"scout" object that goes out into the VE and copies the datasets of
everyone it passes near.  The appeal of VR will lie in the versatility
that can be built into a device object.  I'd want a virtual home with
doors that slide open when I walk up to them, lights that dim when I
leave a room (I know, I know, it won't be saving any energy, but it's
psychological okay? :) ), as well as a whole slew of "robot" devices
that I can program any way I like.

11.
  This brings us into the idea of "protected" spaces where I could
build my own virtual home, or a lab in which I could work with a
researcher on a project without being disturbed, or receiving any
attribute/dataset/spatial message packets from anyone else.  This
protected area could have its own set of local coordinates (however
many bits as desired per coordinate) and wouldn't have to even be a
part of the 128 bit universe.  This way, no prying eyes could take a
peek into the labs because the lab representation in the "regular" (!)
virtual world will have an empty shell of a lab, or what appears to be
that because of visibility flag being left off.  The occupants of a
protected space could define those user-ids which it will accept
message packets from, and which message packets it will recognize.  In
the example of the camera for the R&D lab, it would be a recognized
message sender for the protected space in the lab, so a light would
flash, a buzzer would beep and the camera's analysis would appear on a
lab terminal for the personel there to allow access to the protected
space.  This would be a message to the router that it wishes to
include userid, XXXXXXXX, into the protected space that it has set up
already.  From the message router's point of view, it knows to only
send messages to the users in protected space #AAA from those users on
a list somewhere (i.e. the camera).  A list of valid message packets
that will be accepted from any outside user could also be supplied to
the message router, for example the lab may wish to allow all messages
of an "email" nature to be accepted.  A device there could handle the
message packet and alert the techie's when mail has arrived (a little
yapping dog named biff!) :) Where should the actual data be stored for
that protected space? Possibly on the router's disk space for that
domain... This will be a tricky thing, rather like the California gold
rush, do we allow squatter's rights to areas? But with 4,000 km of 1mm
resolution space, I don't think it'll be a problem. Maybe the space
could be >allotted< to a particular user, for him/her to fill up
whenever they're online?  Or another site on the network could
maintain the space for the user... (see below on the use of remote
processors for taking advantage of higher speed links in the network,
the two are related.)

12.
  Where should the code for the device objects be run?  On the local
machine?  On the message router's machine?  On a machine that serves
only as a >workhorse< for devices? (limited access of course, like a
university only processing device object's code for those devices that
belong to students, or companies for their employees.)  A public
domain device executer would be nice, too.  The idea of running a
device object's code on another machine would take advantage of the
high speed links that a router will most likely have between another
router/device processor.  If the device object is in the domain of the
machine who will process the owner's devices then that device will run
much faster than when the device is far removed (in the network,
meaning passing through several routers) from the main processor.
This could allow for some interesting experiments with parallel
processing device objects!  Think about it!

13.
  To accomodate objects that are animated in a set, pre-programmed way
one could constantly update the object's spatial packet's motion
vectors at precise intervals, or we could have set another type of
packet describing the object's motion that includes (credit to Dave
Stampe) an interperative-like language that reminds me of LOGO.  The
behavior of the object could be described by a preset list of motions
(like the motions of a virtual bird) or, even more audaciously- an
object that has its motions depend on the proximity of other objects.
For example, a virtual puppy could avoid all objects from the
corporate data offices, but tend to follow those objects from the
Little Rich Kids' Learning Center for the (Economically) Gifted, as
long as they didn't run away.  These objects could have even deeper
behavior coded into them on a query basis:

LITTLE KID: Hiya puppy!
ROBOPUP: Arf Arf!
LITTLE KID: Who's your owner?
ROBOPUP: My owner (arf) is Howard Rheingold, author of....

  Okay, so we'll have to prevent >walking advertisements< but, you can
see the potential for education if you took it more seriously than I.
An object could be programmed with a type of behavior that endorses
communication with only those people that care.  The robopup avoids
the real cybernauts who have work to do and would have little to learn
from a 7680 bytes program, whereas a little kid could have hours of
fun talking to Eliza, the pup's intelligent momma.

14.
  Much more variety can be dreamed up with variations on objects and
messages.  A good message type that is independent of object is a
sound packet, maybe a digitized sound that is played on cue with
another type of packet, a playing description placket.  You define the
sound (waveform, I'd suggest a raw 8-bit sample for now) just as you
would define the dataset of the object.  (It could be included in the
geometric dataset of the object, but sound does not need to be tied to
an object, I want to be able to ventriliquize without moving my lips!
:-) ) The trigger for the sound could tell your auditory renderer how
loud, at what pitch, etc... to play the sound at.  A good
philosophical question would be: Should the router/filter machine
delay the transmission of sound trigger packets when two objects are
far enough away that the speed of light and the speed of sound is
noticeable?  Should we have sound broadcast at the speed of light?
Will this make people uncomfortable? Would the sounds of thunder from
the lightning above my virtual frankenstein laboratory contribute to a
more realistic horror show if they followed the regular rules of
physics?  Should we build the speed of sound into the trigger packet?
Can we redefine and modify the speed of sound without afflicting
everyone with a strange form of motion sickness as-yet undiscovered?

15.
  That's enough for objects (for now, I admit there should be a LOT
more).  A coordinate system is vital for the VNE (Virtual Networked
Environment) to work.  The size of a particular message router's
>domain< should be defined by that message router.  I'd recommend a 32
bit coordinate system for beginning domains, which would allow for
either continental size with milimeter resolution (add in projected
image maps with higher resolution that the "control points" as well)
or a continental/4 expanse at an incredible resolution.  To "match the
user" so to speak, a higher resolution than 1mm/unit may be needed.  I
don't know the exact specs on human vision, but I do know the
limitations of computing power, and for now at least, we can't
entirely match the user.  Besides, I wouldn't mind living in a
cartoon! :) However, the coordinate system for the universe in the VNE
wouldn't have to be limited to 128 bit numbers or anything that
arbitrary, it could be variable length coordinates, even.  The router
however, _must_ limit the coordinates to something small enough for
the renderers within the domain to handle and small enough to take
little bandwidth and much information.

16.
  As far as bandwidth is concerned, massive savings are realized with
the higher abstraction you can make between the information and the
contents of the message the better it is for bandwidth.  If an object
moves, only its spatial message packet is sent to nearby users;
coupled with data compression the speed of the network (meaning update
rates) most definitely CAN be real-time with existing hardware!

17.
  How do we solve the problem of potential causality conflicts when
two users try to perform non-reentrant tasks (like moving the same
object at the same time, ala tug-of-war)?  One way would be to have
the message router perform all the time stamping for you.  If a user
is to take control of an object that has its manipulable bit set, it
must send a message to the router when it seizes control of the
object, the router records this and sets the manipulable bit to off.
If user A grabs object C, a weed, and user B also tries to pull the
same weed, then whoever sends the message, "I seize control of object
# XXXXXX right now, dammit!" to the router/filter >first< gets control
of the object.  Whoever sends that message a microsecond too late gets
back a message from the router saying basically, "Sorry, you have not
won the million-dollar jackpot, but please try again at any time.
Thank you for playing."  The priority of object "attachment" or
temporary ownership needs to rank fairly high in the router/filter's
agenda, because too long of a delay between grabbing an object and
receiving confirmation would be distracting.  To help offset the
potential lags that this might create, the deal with time stamping the
"I seize control!..." messages would only be necessary if another user
were within a certain threshhold distance of the "grabber" and the
"grabee" objects.  In this way, I can rearrange my virtual home
without fear of waiting forever during "rush-hour" computing.  Indeed,
for objects that are only manipulable by the owner, there would be
zero need for confirmation of "grabbingness success" if you are the
real McCoy.  I think this is a realizeable solution to temporal
causality violations.  Also consider that the only messages that need
to be time stamped are: attributes and possibly spatial messages.
Attributes would determine who got control of an object first, spatial
messages would need to be time stamped for virtual racing I suppose, a
rather futile effort, >I< would teleport myself to the finish line!

18.
  Now, update rates: If an object's motion vector (direction &
magnitude) has been sent to the observing user object, then no updates
for that object need to be sent until the vector changes.  This way,
if I stare at a virtual highway of really really cool cars (post-2000
looking!) then I would only have to receive 2 messages: the dataset &
attribute packet which would tell me that I can't kick the cars off
the road, and the spatial packet which would probably change a few
times as the car sped up, slowed down, and teleported.  The update
rate of my own rendering machine is absolutely independent of the
update rate of the moving car.  If the car comes to a complete halt, I
receive a packet saying the car is now at zero velocity in a nul
direction, facing this direction, and at these coordinates.  My
renderer would probably have already computed the frame for the car
still in motion, but that's a renderer problem which will be cured
only by a faster link to the router/filter.  This problem should not
be addressed by the protocol if we wish to keep the rendering and the
filtering/routing processes separate (and transparent).

19.
  As to packet compression, we should use simple LZW bitwise
compression at first (easy to code, fast in execution, and good (not
fantastic, but good) compression ratios), and then allow for various
"levels" of compression types as new algorithms are worked out, and
machines become fast enough to attempt the more hefty compression
algorithms, i.e. Ashford compression (see ddj).  This would afford
slower machines to make a trade-off between update rates on packet
receipt frequency and length of time to decompress/compress packets.
For now, however, LZW'ish compression is just fine.


This isn't copyrighted, go ahead and copy it, edit it, reprint it, amd
steal it.  Fold, spindle, and mutilate at will.

Written in a collaboration between David Wood and Trip V. Reece.  --

+-----------------------------+-----------------------------------------+
| dlwood@mailbox.syr.edu | drive on a parkway, park on a driveway | |
Cybernaut, with a thought.  | Choosy netters choose GIF.  |
+-----------------------------+-----------------------------------------+