From: dlwood@mailbox.syr.edu (David L Wood)
Subject: Re: TECH: My standard is better than your standard.
Originator: hlab@milton.u.washington.edu
Organization: Syracuse University, Syracuse, NY
Date: Wed, 12 Aug 1992 22:54:54 GMT



In article <1992Aug10.040508.20131@u.washington.edu>
Jeremiah.Blatz@dartmouth.edu (Jeremiah Blatz) writes:

>In article <BsIKKu.FAo@watserv1.uwaterloo.ca>
>dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng) writes:
>
>> I feel strongly that position updates are the wrong way to go for moving
>> objects: use a motion codeing system so the machine displaying the
>> object can update the position 100x a seocnd if desired.  MUCH less
>> bandwidth needed.
>
[ little bit deleted ]
>That way there would be no lag from predictive tracking,
>and a system could find the object's position whenever it wanted. That
>wat, objects like, say, an airplane, would only require a few
>up/downloads (except on takeoff/landong). Is this too complicated?

Using vectors for motion (speed & direction) is the simplest means
without using updates of position.  No one wants updates of position
it appears.

Using a polynomial withing the vector to describe speed as a function
of time is okay, but for high speeds in a congested area, an object
that swerves aside from hitting another object (updates it's motion
data/vectors) there will be a lag between the time the object claims a
new set of vectors and when observers receive the message.  One way to
combat the "ghost" image of that speeding object from going through
the "target" :) and then careening off in another direction would be
to send not only the new motion vectors, but including a coordinate at
which the object turned would allow the observer to see the speeder
hit the target, then "hop" back to the position where it turned, and
then speed away in the new direction.  For the first incarnations of
cyberspace this ought to be >feasible< in terms of computing power,
and telecommunication speeds.  If the speeder could send the message
ahead of time that it's going to turn when it reaches Such-and-Such a
coordinate, then the entire "hopping" problem is eliminated.  This
would be fairly transparent.

To handle collisions, I had an idea first about using bounding
spheres, and using these spheres to eliminate those objects that
couldn't possibly intersect.  Perhaps using more than one sphere like
this would help:

Sphere 1: center coordinate & radius of sphere ENTIRELY containing the object.
Sphere 2: cntr coord. and radius of sphere entirely contained BY the object.
          (this would be the largest sphere you could entirely fit inside
           the object)
Sphere 3: data for sphere intersecting the MOST faces.  This would be tricky
          to compute, but has a purpose.

In a crowded room, you first would check #1 spheres, to eliminate all
those impossible collisions, and then you would take the #2 sphere and
compute all the CONFIRMED possible collisions (meaning obj1 and obj2's
sph #2's are on a collision course.)  For those remaining objects, you
could compute a "probability" of collision based on sphere#3.

Sphere 1 contains #3, and #3 contains #2.  

How does this sound?  Intersections with spheres is inexpensive and
using three of these seems as though it would provide 90+% accuracy?
(Hope this spurs some other schemers to brew up a more novel
approach.)

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