From: dlwood@mailbox.syr.edu (David L Wood)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: My standard is better than your standard. (LONG)
Date: 12 Aug 92 22:32:20 GMT
Organization: Syracuse University, Syracuse, NY
Originator: hlab@milton.u.washington.edu



In article <Bsn5BJ.201@watserv1.uwaterloo.ca>
dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) writes:

>dlwood@mailbox.syr.edu (David L Wood) writes:
>
>1: Attributes--  Invisible objects could be done at the routing or
>object simply by giving them a null representation.  If you send 
>an invisible object, then the rep would only be useful for collision 
>detection.

Sounds great, for those objects that ONLY the owner can see, the
representation will be stored ONLY on his/her local machine.  For an
object which may be seen by some people, and not by others, it would
be stored on the router/filter which also suggests another attribute
toggle: Solidity/Ethereality.  Some objects son't require a physical
solidity, and some do.  My hand needs solidity but a door does not
need it.  It makes knocking hard, but I don't suspect that door knocks
will be implemented in the first version :).

>2: Alterable-- methods of altering an object haven't been discussed.
>If it's an actual change, and not a joint bend etc. then maybe just
>attaching or defining a new representation is OK.  Expensive on
>bandwidth, however.

A delta coding scheme, like: these vertices for object # xxxxx are
changed: followed by the data.  I was thinking of "dragging" a vertex
around.  And a joint bend would be a "manipulation", sound okay? The
manipulation message update would be very concise: obj#,joint#,degrees
rotated.

>3: Ownership-- Something like access priviliges.  But what about the
>temporary ownership that gives you manipulation privilges exclusively
>until you release the object?  That should mean that the object arbitrer
>controls the ownership thus is the locking device.

Hmmm, assuming we only allow (at first) one person to manipulate a
particular object at one time, then the object arbiter (the computer
that receives the "grab" messages) will have to reset the ownerships
and manipulation toggles when the object's ownership is transferred.
Am I understanding this? Think there's a better way?

>5: Datasets-- It might be useful to have a small library of geometric
>primitives (cubes, prisms, etc) at each machine, and just send delta
>datasets: colors, scale, etc.

Excellent, this allows our data-set representations to take advantage
of CSG'ish compactness, and polygon mesh simplicity.

>6: I think representations should refer to the visible basis of an
>object.  Many of the "gadgets", "devices", etc. are then an object
>with a program as well as a representation.  Fixed objects have no
>motion control structure (like the segments in REND386) attached.  And
>so on.  Composite objects (like the bicycle) are then a hirearchy of
>objects linked by the motion control structures.  Stretching polys are
>nice, and should be included but I presume the number of polys will be
>preserved (at least as a simplification for now).  Then the control
>object/points are linked to motion control structures.

Hmm, maybe the object types can be more generally described as:
Objects w/ executable code vs.  Objects w/ no executable code.  The
object types, simple-rigid objects, and gadget (bicycle) types would
fall into the superset of no-code objects.  The device objects would
be linked-to-code type objects.  Beneath each type it could be broken
down even further.

>11: Protected spaces--  If there's no reason for a visibility link, 
>I think we can actually have a much looser region structure.  You might
>even put the lab in a pup tent, or behind the call button (actually 
>there's no need to put it anywhere in the world at all, if you seperate
>visibility from other data links.  To call up someone on virtual TV, you
>link their region to the window.  Not a huge extension, and moves away
>from the rigid 3D space region idea (at least as an option) which IMHO
>is a good idea.

Sounds good, but how do you transfer your body into this "hidden"
space? How is it addressed? Does it have a 128 bit universal
coordinate counterpart?

>12: Object code-- If you have a fixed or simple object, run the code
>locally.  If the code is network-intensive, your object invokes a
>FTP program somewhere.  If we seperate object functions (ownership
>to the object negotiator, representation to its database, motion
>to the local machine with current ownership or to an object default
>owner) then we can keep delays low as well, and distribute loads.  Also
>no buggy code for complex functions need be run across the net.

Yep, objects like a virtual pen or wand would be controlled locally,
and an object that is a "hunter" object moving through the network
would be handled on high-BW lines.

>14: Sound-- Not bad, but I'd suggest a small default set of sounds as
>well, for those with crummy PC beeps or synthesizer chips.  The playback
>sound idea could eat up lots of bandwidth itself, but synthesis could
>relieve it for now. 

Synthesis, and "banks" of pre-loaded instruments is terrific.  The
trigger packet could even contain "music", albeit pretty crappy if
it's coming out of the PC speaker.

>15: Coordinate systems-- Why not scale within regions (assuming they're
>nested) then you can translate to global coords using the scale factor.
>No doubt on the first implementations a fixed scale will be used, but 
>that's just because there's a lot of behind-the-scenes stuff to figure
>out there.  The local software will not need upgrading as it should be
>written to handle this in the first release.  Anyway, we will need better
>than 1 mm in some regions and more than 4000 km in others.  Scaled nesting
>lets this be done efficiently.

I don't quite understand how this could be integrated into the router
system? Again, how do you transfer your body and senses? It would be
great to have different "pockets" of space with different coordinate
systems, but how do you see one pocket from another? Does the router
do the scaling around for you?

>17: Object control--  Not really clear-- does the winner get a message
>before he can move the object?  Does the loser have the object fly out
>of his hand?  Assume at least a 500 mS delay before answering, so that
>the result will be visible.

The winner would "see" no message, but his local software would
receive one.  Well, the local software >could< display a message but
that is for end-users' comfort.  The loser would probably receive a
message, object owned by Mr. Armitage, or whatever.

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