From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng)
Subject: Re: half silvered lenses (was Re: Direct Neural Input (Was Re:
Date: Wed, 13 Nov 1991 05:20:28 GMT
Message-ID: <1991Nov13.052028.1844@watserv1.waterloo.edu>
Organization: University of Waterloo



craig@utcs.utoronto.ca (Craig Hubley) writes:

>So far there is no information that couldn't be provided to the interface
>via proximity or bend sensing, of the magnetic, sonar, radar, or video
>varieties...  In other words, the computer could track the same things
>albeit less directly and more crudely...
>

You're missing the point: that seeing your own arm/hand directly
(no delay) lets you control it better than seeing a delayed image
of it drawn by the computer.  Now the delay only causes problems
with the virtual objects... which you'd like to be firmly "in hand",
but actually will seem to ooze thru your grasp.  Not as bad as
motion sickness, though.

>So the key, as with all user interfaces, is fast response time?  If I
>understand this correctly you need a frame rate of only about 10 fps...
>hardly insurmountable.  For one thing, if we are mixing virtual objects
>with the real world, and need not render a background, we need not 
>necessarily have very high-res anyway.  Personally I think NTSC would do.
>For anything more detailed than this, you will probably want to switch
>over to all-virtual mode so that you can concentrate on the details 
>without the distractions of transparency, clutter of physical objects, etc.

Again, the point is that DELAY is the problem.  10 fps gives
decent animation (movements begin to look fluid instead of jerky)
but you still have a minimum of 100 mS delay (the rendering cycle)
and possibly much more (tracking device delays, pipelining in the
renderer, etc).  It's the DELAY that causes the motion problems.
100 mS is definitely getting into the "problem" delay range, and
will result in poor coordination.  The user may have to compensate
with slow movements.

>The "right" answer is variable-resolution objects and prefixed allotments
>of rendering time.  At the focus of the users' attention and action (which
>is easy to tell given that you know what they're doing / looking at) you
>render furiously, starting with gross shapes and going to more detail as
>you get background objects roughed in... when he moves his head you 
>rapidly do it again... anyone else get angry when you want to flip a view of
>some complex object around 60 degrees and the stupid draw/CAD-CAD/anything
>software insists on rendering the entire thing in full detail at each 5 degree
>increment ?

Problem with variable-resolution is that it's unnatural if done
indisciminantly.  Does the world "decay" when you move your head, 
then slowly recover?  Of course not.  You'll see it too, since
your eyes can see very well during head movements, due to nystagmus
stablization.  

The "prefixed" rendering time allotments should rather be time-limited 
to prevent excess delays in the system, which is more confusing to
the user than a small variation in rendering intervals.  Speed of
motion of objects need not change with rendering speed, as the 
position increment can vary to match the gap.  The important thing 
is the MINIMUM rendering rate.

>Clearly, there are many situations in reality where the quality of our view
>of something is degraded - dark, fog, smoke, lost my glasses, etc.  Our
>brains deal well with this and are good at assuming detail.  However, there

Yes, but the degradation is a) constant with our actions and b) of a
simple type (blurring).  This type of image degradation is what the 
brain is DESIGNED to handle.  An object changing from a tree to a plane
to a cone to a tree after a head movement is not going to be fixed by 
the brain.  Too bad we don't have a "blur box" to stick on the video
output...

>Graphics toolkit developers take note - the first usable toolkit that supports
>variable-resolution, fixed-frame-rate opportunistic rendering will WIPE THE

Mellow out!  This is exactly what the gamesmiths do for their 3D
graphics.  The problem so far is that present VR systems are always built
around Silicon Graphics or other high-powered hardware, with the
result that the rendering process is sometimes a "black box" to the 
VR designer.  Programming using "high-level" VR languages can fool you 
as to time.  

Work is only just starting on VR on low-end hardware (i.e. my VGA
poly blitter package) where the need for these techniques is known,
and the need for squeezing the last bit of speed out of the hardware
encourages the use of variable-resolution objects and informed decisions
as to algorithms etc.  Working with assembly code as well as C really
removes any illusions as to what is happening in that "simple" code.

>>the brain's response is to assume that the correction didn't occur, and
>>to increase the correction.  Out on the arm, which really did correct,
>>this will cause overshoot and oscillation.  If you manage to get close
>
>OK, I get it.  The brain takes the law into its own hands...!

You better believe it.

Don't get me wrong: I'm not against variable-resolution objects-- in
fact, I consider them essential to the implementation of low-end
VR.  But only small, distant objects can be considered for simplifying,
if we're not to have a hallucinatory, changing world.

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