From: marc%remarque.Berkeley.EDU@ucbvax.Berkeley.EDU (Marc DeGroot)
Subject: Re: SCI: Object behavior in VR
Date: 18 Oct 1992 02:38:00 GMT
Organization: University of California, Berkeley


In article <1992Oct14.010116.6049@u.washington.edu> dstampe@psych.toronto.edu (Dave Stampe) writes:
>
>marc%remarque.Berkeley.EDU@ucbvax.Berkeley.EDU (Marc DeGroot) writes:
>>I'm thinking about a scenario like this:
>>
>>For the dodecahedrons' behavior we have a choice:
>>1) You run the entire simulation on your processor and transmit
>>   position and orientation data over the net to me;
>>2) You download the simulation code to me and I run it locally,
>>   and we periodically make sure we're synchronized over the net.
>>
>>(1) is fine for a small number of objects, and low latency
>>(lag time) over the net.  But for 100 or 1000 objects, (2) is the
>>only system that makes sense, from a network bandwidth standpoint.
>>
>Ah, but for simple spinning objects, why send a program?  For more 
>complex motions, or ones triggered by a user's motions (unpredictable)
>a method for motion control (a sort of motion-packet that is able to
>do things like simple "tumbles", drive cars around curves, and so on)
>is much more efficient.  It could even have simple list-switch 
>capabilities to do sequential motion.  

What you are suggesting is that it is more efficient to send perhaps a
byte with a function code and the arguments to that function.
In a byte-code interpreted Forth, you would be transmitting little more than 
that anyway.  The presumption I make is that the Forth interpreter has a
robust set of routines that make the job of describing behavior as easy
as possible.  One subset of these routines might be a "motion manager"
which provides a small number of powerful routines that can control motion
of objects in several ways.  Calling three or four of these routines
requires little overhead.

Forth's extensibility and short routines naturally work to decrease
network bandwidth.  Any time a string of Forth instructions is needed
more than once, it is recoded as a subroutine and simply called.  If
the programmer is attentive to factoring the code this way, there is 
a substantial compression that can take place.  If the underlying Forth
system is carefully written, it will be possible to get far greater 
compression downloading Forth routines.  Finally, for those situations that
simply cannot be handled by the pre-conceived "motion manager" routines,
it will be possible to create an alternative.

>The VR net thread suggested something similar but with a crucual difference:
>the code for object behavior may not be running on your machine at all.
>It communicates with other machines, broadcasts motion packets, and so
>on.  

I'm looking through the archive for this thread.

-- 
Marc de Groot (KG6KF) San Francisco |
Internet: marc@kg6kf.ampr.org       |      "Penny for your thoughts, twenty
UUCP: ..!uunet!hoptoad!noe!marc     |          cents for your paradigm."
Packet radio: KG6KF @ K3MC          |