From: dlwood@mailbox.syr.edu (David L Wood)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: Using Timestamps
Date: 11 Aug 92 23:03:25 GMT
Organization: Syracuse University, Syracuse, NY
Originator: hlab@milton.u.washington.edu



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

>harrison@beta.lanl.gov (David A. Harrison) writes:
>
>>>Objects running near each other-- if you (or more than one person at a
>>>time) are attempting to interact with the roomful of objects, this is
>>>impossible.  At least objects know what they'll be doing in the future
>>>and can send predictive messages.

- With parametric motion, the exact times of collisions could be
pre-computed, or at the very least, estimated in a sort of Newton's
Root finding method manner: Approximate, re-approximate,
re-approximate, ad nauseum or until you get a consistent answer or you
hit the other object.

[ stuff deleted ... ]

>>As far as timestamping is concerned.  How will you synchronize the
>>computers?  This is nearly impossible when many computers are
>>involved.  As far as parametric motion is concerned, I agree that this
>>is a very good way of reducing network traffic.
>
>How about combining these?  To prevent backtracking, use ownership
>negotiation based on message arrival at the object's server (whatever
>and whereever it is-- perhaps the negotiation process can be hosted at
>a network hub to keep delays low, but the object's representation can
>be hosted by whoever created it to keep storage low at the hubs.  Now
>the only need for timestamping is for motion control.  Assume you send
>parametric motion with delta times, and an update later with a delta
>start time.  If a small added delay is introducred between the
>messages, the local model can be smoothly interpolated to prevent
>discontinuities in motion.  If too much delay or the sender dies, then
>maybe the object slows or stops when it collides with something.

- If the negotiation process entails transferring ownership when
different users "grab" object, and deciding who has ownership when
there is a tie, or trying to break up a tug-of-war, then my response
is: The beginning network will have not nearly the resources or
efficiency to handle that many object-object collisions and
user-object collisions in its infancy.  The problem is academic at
this point in time, really, any kluge to fake the negotiation would be
acceptable right off the bat.

>As you work with this stuff, I'm interested in your opinion on this
>idea.  It's important that the results look good, and it's not
>extremely important to simulate physical processes exactly. Glitches
>of 200 mS can probably be tolerated.

Perhaps a proximity approach similar to the size/distance problem
could be entertained to isolate only those objects that MAY
interact/collide with each object within the room.  This requires
arbitrary limits on average object speed or object spontaneity, but
would cut down the number of object/object collision computations
necessary.  A bounding volume is the most primitive, but I fear they
may be no "elegant" solution short of brute-force.

Is it just me, or is the length of time between "bursts" of posts rather 
long? 

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

[MODERATOR'S NOTE:  It could be just you. :-\   Bob Jacobson]