From: dstampe@psych.toronto.edu (Dave Stampe)
Subject: Re: SCI: Object behavior in VR
Originator: hlab@stein.u.washington.edu
Organization: Department of Psychology, University of Toronto
Date: Tue, 13 Oct 1992 14:32:06 GMT


marc%remarque.Berkeley.EDU@ucbvax.Berkeley.EDU (Marc DeGroot) writes:
>
>
>Whoa! 1000 times a second?  Are you really going to try to test for
>object collision on a real-time basis?  What happens if there's 1000
>objects in your space?  What happens if the processor just can't keep up?
>For collision, the best thing is to solve the simultaneous equation of
>the two objects' trajectories and see if they overlap.  That way, you
>can visit the collision code only 5 times a second without fear of missing
>a collision.  

No, what I meant is that the kernal (has object A hit object B) is
done thousands of times per second.  There are a lot of ways to cut
down the overhead, but this is best done by code that has access to
optimized object data structures that were designed for the purpose--
the interface/simulator.

>It sounds to me like you're talking about developing code for a single-user
>stand-alone system.  You're thinking about how you like to do code development.
>That's fine.  I'm not trying to take away your development platform or 
>language.  I'm looking for a way to transmit pieces of the universe from
>one machine to another and have two or more users interacting in a room
>in cyberspace together.

Nope.  You probably missed the July/Auguast tread on VR network stuff,
so I'll forgive you (B-{)).  I suggest you get this out of the archives,
and read it.  The issue is FAR more complex than just programming languages.
>
>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.  

>If that's the case, then what language should the code be written in?
>Dave, I believe you'd agree that C is not the correct answer.  Even with
>the compilation times you can get on a fast 486, the application argues
>heavily for pre-compiled code that is interpreted.  Pre-compiled because
>there really isn't time to compile the downloaded code, and interpreted
>for portability and consistency across multiple platforms.  Yes, C can
>be byte-coded and interpreted, but it is the wrong choice for several
>reasons.  The language was designed ONLY with compilation in mind.  

Of course C is not the right answer! but neither is sending ANY kind
of source code for object control on another machine.  C would be used
only for system construction, and for object-behavior code construction.
Completely off-line.

>Regardless of the speed of your C compiler, Forth will ALWAYS be able to
>compile faster, like as fast as you can type.  Yes, literally.  If I showed
>you how simple the Forth compilation process is, you'd agree.

I've programmed in Forth and written Forth compilers.  Not a great
argument, when you aren't sending any source code.  In any case, you're 
assuming an intermediate format (like P-code, long may it rust!) so
if you really wanted to you could send that.

>Anyway, [...] I believe the best thing to do is the following:
>In the data structure for the object, provide two pointers for the behavior
>code: a pointer to code, and a pointer to data.  That way, Dave can write
>his routine in C, and put the pointer to the code in the data structure.
>When his code is called, it is passed an optional pointer to data.  For my
>purposes, I can put the pointer to the Forth interpreter's entry point in
>the code pointer, and I can put the pointer to my compiled Forth code in
>the pointer to data.  Mr. Technically Sweet can put similar pointers in
>for his Scheme code.
>
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.  



--------------------------------------------------------------------------
| My life is Hardware,                    |         Dave Stampe          | 
| my destiny is Software,                 | dstampe@psych.toronto.edu    |
| my CPU is Wetware...                    | dstampe@sunee.uwaterloo.ca   | 
| Am I a techno-psychologist, or just an engineer dabbling in psychology?|
---------------------------------------------------------------------------