From: dstamp@watserv1.uwaterloo.ca (Dave Stampe-Psy+Eng)
Newsgroups: sci.virtual-worlds
Subject: Re: TECH: world description
Date: 11 Aug 92 14:08:14 GMT
Organization: University of Waterloo
Originator: hlab@milton.u.washington.edu



jtt@icf.hrb.com (Jack Taylor) writes:

>There is a concept/approach which has been defined in the SIMNET/DIS
>protocols which addresses the problem of update rates for the
>distribution of state vectors for the moving objects in the
>simulation.  The protocols specify use of a "dead-reckoning" algorithm
>which is used by the displaying local processor to predict the motion
>of objects in the environment.

Is it possible to get a copy of these protocols?  Or are there any
references on the SIMNET?

>The local processor receives the initial state vector from the
>originating object.  The state vector contains current position,
>velocity and rotation in three dimensions. The local processor then
>uses the dead-reckoning algorithm to predict the motion and position
>of the object between objects.
>
>The key to the approach is that the originating workstation which
>contains the moving object runs the dead-reckoning algorithm for the
>object as well as the actual directed motion. The broadcast of new
>state vector information for an object is controlled by the use of a
>threshold between the actual directed motion of the object and the
>dead-reckoning calculations. When the difference between the objects
>actual directed motion and its dead-reckoning calculation exceeds the
>threshold a new state vector is transmitted. The thresholds are
>programmable so they may be varied based on the type of object and its
>rate of change.
>
>This approach can reduce network traffic by allowing a variable amount
>of time between updates for objects with simple motion parameters
>since they seldom deviate from their predictive calculations. This
>will obviously not eliminate the need for rapid updates for fast
>moving objects, and it will be necessary to establish some maximum
>rate for each object, but it can cut down on unnecessary messages.

This is the basis of what I'm suggesting, but I'd like to add the
acceleration (optional) and a rotation for the motion direction.  All
of these would be optional.  The time aspect, because we'd be using
unpredictable low-bandwidth nets, would add a valid-time to a motion
packet, and an elapsed-time message to the next packet.  This would
let the receiving machine compensate for the elapsed time as well.

>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.

And mechanisms must exist for drasticly reducing it to low-BW users.
I'm looking at stuff ranging from CSG to predefined primitives to
variable coordinate sizes...  All sorts of possibilities, and the
result would be a burst of prototypes and visible objects at startup
followed by bursts as objects became visible.  Objects would take a
fraction of a second to become visible for low-BW connections.

>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.
>
>This would at least eliminate the need to pass all the interpreted
>method (behavior) information. This is not suggesting some universal
>object database, which would be a nightmare to maintain, just some
>means of communicating the fact that my local processor already knows
>what that object is.

Also needed is a method of handshakeing through a low-BW link for
this.  I suuggest the "filter" keep a list of all objects the user
knows about, then it's up to the user to purge objects from the
filter's list as it deletes them from its local cache.  This will cut
down drasticaly on the number of query-and-reply exchanges, which are
bad on a bursty network.  If the filter thinks all of the object
description is needed, it starts to send it.  The user can say "whoa"
perhaps.

>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?

This is handled by having several parts to an object: motion model,
characteristics (including behavior), >representation< (which can be
cached and shared), and rep modifications.


--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | dstamp@watserv1.uwaterloo.ca |
__________________________________________________________________________