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: Sun, 11 Oct 1992 20:03:50 GMT


d8andjo@dtek.chalmers.se (Johan Andersson) writes:
>
>
>> On Oct 6, 11:05pm, Dave Stampe wrote:
>>
>> } I'm not sure either Scheme or Forth are a good idea.  The problem can
>> } be summarized: is it efficient and is it required?
>>
>> Dave then goes on to explain that the world simulation system needs to
>> be very efficient and so it will consist of an animation database that
>> the programmer creates and starts rolling.  Agreed.
>
>Whatever has a 'world simulation system' to do with an animation
>database?
>To me the 'world simulation system' is what we call the 'virtual
>world'.
>The virtual world is a simulation of all rules, all attributes, and
>especially all interactions between the virtual objects making up the
>world...
>VR is one such interface with which we can render the virtual world to
>a user, graphics on a screen is another, as is simple text on a
>terminal.
>IMHO, what the 'VR-field' is doing now is comparable to building a
>car, with comfortable seats, nice steering wheel, crystal clear
>windscreen and no engine.
>Do not get me wrong, the interface is very important and the work of
>people like Dave Stampe is very impressive. But if there is nothing
>interesting to interface to, the interface is worthless.

That's setting an artificial division.  Look at it this way:  in the
early days of computers, everyone had to write their own i/o code,
then eventually BIOS and OS systems came along to unload that.
Next it was offloading assembly coding with compilers and interperters.
GUIs unload a lot of the command-line interactions.  And so on, with much 
of the functionality being subsumed into the "interface" system.

Same thing with VR.  A lot of the stuff being done by coding (for example,
updating object positions for linear motion, or the effect of gravity) can
be subsumed into the interface/simulation system.  Next to go is collision
detection, then complex object interactions, and so on.  The key to all 
these is that they are performed extremely often, and are very deterministic.
Things like collision detection are extremely expensive and the interface/
simulator system should firmly take them in hand to make sure they are 
performed as efficiently as possible.

What you want to end up with is a control language that consists of
an interface to the simulator/interface and a number of "event handlers"
that rely on output from the simulator/interface.  The interface section
is nothing as simple as an i/o mechanism: it is mostly a precompiler
to set up "action structures" that the interface/simulator can use to
control objects very efficiently.  This way you can have complex or
"intelligent" object actions controlled by the language, and stereotyped
and repetitive actions controlled by the interface/simulator code.
The advantages should be obvious, and this sort of opens the door
to just about any control language you want.  Specify a good set of
"action structures" and give then to a good simulator/interface
programmer, instead of trying to get a do-everything language to
work and having 90% of your code as #include "std.object.control.h"
or something like that.


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