Received: from watserv1.uwaterloo.ca (watserv1.waterloo.edu) by karazm.math.UH.EDU with SMTP id AA07850 (5.65c/IDA-1.4.4 for ); Sun, 20 Oct 1991 23:32:43 -0500 Received: by watserv1.uwaterloo.ca id ; Mon, 21 Oct 91 00:28:38 -0400 Date: Mon, 21 Oct 91 00:28:38 -0400 From: Dave Stampe-Psy+Eng Message-Id: <9110210428.AA14274@watserv1.uwaterloo.ca> To: glove-list@karazm.math.uh.edu jdb9608@cs.rit.edu (John D Beutel) replies: >That's what I'm wondering. If the samples are made at a constant >rate (like by the original hi-res routine), then are the samples that >the glove makes itself limited by this? I've listened to the clicks >that the glove makes while being sampled at a constant speed, >and I can't hear any difference between open and closed fingers. >I'm not sure I can tell the difference between 13 and 17 Hz, >but I suspect the glove has a constant sample rate when polled >with the original method, independent of finger position. Quite possible: I have'nt scoped the transmitter and glove read lines in the glove myself. I suspect that there *is* a small effect even if you read th glove at a constant rate, in terms of how often the glove is readable. What may happen is that the glove finishes reading the fingers ahead of time if the hand is open, then starts the next cycle either when the cycle timer expires (internal to the glove CPU) or it's asked for the data. This explains why you trash data if the glove is read too soon: there's nothing in the buffer yet to read, and the glove starts its next conversion cycle too soon. >must be synchronized with the glove polling. But, if the >fingers are open and there's only 58 ms between polls, >then that's all the time the graphics routines will have, >so they must be able to do their job in 58 ms. If the >fingers are closed and there's 80 ms between polls, then >the extra 22 ms will be wasted (unless the graphics can >be written to do the minimum rendering in 58 ms and some >worthwhile extra rendering if more time (up to 22 ms) happens >to be available). > >However, the whole point to sync'ing the code and the glove >is to avoid an average 30 ms extra lag time, so if the >original polling method adds any extra lag time to the >quick-polling method, then it may not be worth sync'ing >(or it may be worth accepting the wasted CPU time). > >-- >J. David Beutel 11011011 jdb9608@cs.rit.edu "I am, therefore I am." True, but the AVERAGE delay is reduced by reading the glove as fast as possible. In all likelihood it's going to be difficult to lock the video rendering to the glove read rate anyway, and the system will be asynchronous. If you double-buffer the video, the renderer ends up syncronized with the vertical sync of the video card (16.7 mS), so you have to choose between 4 (66.6mS) and 5 (83.3mS) display periods anyway. The REAL problem is going to be doing a decent job of rendering in the available time. It takes 82mS just to access each pixel once on a 320x200x256 color IBM PC mode picture in assembly language (some cards may be faster) although clearing it can be done in 22mS by reprogramming the hardware. THat means that unless wireframe graphics are used, we may have to use a lower resolution mode such as 320x200x16 color. Of course, partial screen updates reduce the time, but if the system uses eyephones, pretty much the whole scene must be redrawn when the user's head moves. In case you're not using an IBM, video access is less of a problem. However, the problem now becomes the other stages of rendering: deciding what gets shown and what is hidden. Assuming a "world" database of 3000 polygons, at LEAST 90% may have to be eliminated before rendering starts, so CPU power comes into the picture. Object-level clipping, partial screen updates, and scan-line drawing algorithms are just some of techniques that will be needed. (Scan-line algorithms attempt to access each pixel on the screen once per drawing.) As you can see, I'm thinking mostly about graphics problems right now. Issues such as how to represent polys, how many colors to use, Gorand shading and texturized objects (and other future considerations) depend on the type of rendering system chosen, as well as processor power and graphics hardware of the computer. BTW, using Gourand shading and textureing are practical, but both take a 30-40% "hit" in rendering performance. I'll try to throw up test ideas every now and then... I REALLY appreciate the feedback I'm getting on this. - Dave Stampe