From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng) Subject: Re: half silvered lenses (was Re: Direct Neural Input (Was Re: Date: Thu, 14 Nov 1991 05:25:46 GMT Message-ID: <1991Nov14.052546.21344@watserv1.waterloo.edu> Organization: University of Waterloo brucec@phoebus.labs.tek.com (Bruce Cohen) writes: >I'm also unsure of the effect on users of having objects come to meet >them. There's a marvelous story about an experiment done by the British >neurosurgeon W. Gray Walter in which he used signals captured from motor >neurons to signal a slide projector to advance. The signals were >correlated with the early development of the impulse to move the >subject's finger on the advance control of the projector. The subjects >were rather disconcerted by the way that the slide projector >"anticpated" their decision to advance the slide, and frequently tried >to hit the button again, thinking they had made a mistake. Sounds weird, doesn't it? But the effect is real, and has to do with below-concsious anticipatory timing generation in the brain. There's a LOT going on there that we're not conscious of, and what does make it to awareness is often "backdated" by several hundred milliseconds. It seems the brain keeps track of "adjusted relative times" between internal and external events, and changing the internal/external delay upsets it. In effect, we're all living a good part of a second in the past... >For many tasks, I suspect that less than 10 frames per second will do, >possibly as little as 6-7. The positive feedback and loss of >coordination effect seems to have a sharp onset somewhere in this range. >But the onset does seem to depend on the task. Someone want to provide >some hard numbers? All I have are some informal experiments I did to >prove to some doubting Thomases that less than 10 frames was good enough >sometimes (they wanted me to rip apart a year's worth of work because >they were convinced that less than 20 would be unacceptable). I suspect it depends strongly on a) the amount of blurring in the motion and b) the speed of the motion itself. Does this fit? >Personally, I'd rather have the virtual world overlay the real one; I'd >be more confident of not tripping over my chair (no smilies AT ALL! >I did that once while trying to videotape an event with a minicam. >Restricting or eliminating your view of the real-world while wandering >around in it is likely to be very rough on the ankles if nothing else.) Excellent point! The only other way to prevent this is to either stay seated (virtual desk) or have a special VR room (which might be OK, as it could be thoroughly instrumented thus allowing better body tracking ). >> 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... Problem is know what is being looked at.. the general region of the screen will have to do, and even then you need a $20K+ gaze-tracking system. My experience (building and using) these shows that the correspondence between gaze position and attention can be VERY loose indeed. Seems to be more of a link between required visual acuity and gaze offset from the object (unproven, but I've got some research planned to check this out). >Agreed. In fact, I'd go a little farther and advocate variable time >allotments with maximums. Some sort of scene object then allots time to >the objects based on what's in the foveal area, what's moving, etc. Exactly. Minimum frame rates are more important than constant, over a certain threshold (10 frames/sec?). If we're getting into eye-tracking to determine what to render, though, we could do a LOT better by keeping the total pixel count lower with nonlinear optics, or by using the simplified objects outside the foveal area. Although if you're using a 4 pixel-per-degree VR eyephone (typical for these devices) the "hi-res" area that needs to be rendered is about 10x10 degrees... >Luckily, when things move we're lots worse at seeing things like fine >detail, texture, and even the total number of vertices of a polygon. >Putting blurred blobs of approximately the right size in approximately >the right place every 50 milliseconds is not only good enough, it >actually can eliminate artifacts like strobing. This lowering of >requirements for detail also happens when we move our eyes, so saccadic >motions give the graphics system time to flush the current graphic >computations, make a guess at the next hi-res area, and start some new >computations. The important word is BLURRED. For any object moving at less than 30 visual degrees/sec, the eyes can track it with very small errors (less than 1 degree, or 3 pixels with current VR systems). Thus eye movements are far more important than head movements for saving drawing bandwidth. Of couse, usually head movments correspond to attention shifts, but slow ones may be tracking movements. Maybe blurring during head movements will force the user to keep his head movements slow and infrequent. BTW, since rendering "blurred" edges can be a bit costly, what about a "postprocessor" on the video output that deliberately blurs specified picture areas? Very simple if you are using a CRT display: just change the focus voltage in the monitor. Predicting where a saccade will land for hi-res area drawing is not not very accurate, and you need a FAST eye-tracking device (>50K$) to get acceleration/velocity parameters on the saccade. I predict that the blurring extends up to 50 mS past the end of a saccade, due to the relatively long response time of retinal receptors. Thus it's probably OK to not predict the saccade, if your renderer is fast enough. -------------------------------------------------------------------------- | 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 | __________________________________________________________________________