Received: from milton.u.washington.edu by karazm.math.UH.EDU with SMTP id AA04000 (5.65c/IDA-1.4.4 for ); Sat, 19 Oct 1991 20:57:54 -0500 Received: by milton.u.washington.edu (5.65/UW-NDC Revision: 2.1 ) id AA10780; Sat, 19 Oct 91 18:53:53 -0700 Date: Sat, 19 Oct 91 18:53:53 -0700 From: Francis Taylor Message-Id: <9110200153.AA10780@milton.u.washington.edu> Sender: narf@milton.u.washington.edu To: glove-list@karazm.math.uh.edu Subject: Interfaces to VR devices Reply-To: narf@hitl.washington.edu Hi. I'm hacking interfaces to user interface devices at the HIT Lab in Seattle, and I've been watching this list with great interest. Lately I've seen interface software going by, and I figured I should get in my two cents' worth (I'm optomistic). There should be a standard for the software interfaces to devices like the PowerGlove, the DataGlove, the Exos DHM, the Polhemus and Bird position sensors... so we can all run the same software, whether we use a $50 Mattel PowerGlove or a $5000 VPL Dataglove. And, of course, who knows what wonderful sensors the future will bring. Won't it be nice to buy that great new device, plug it in, and get all its functionality, even using the same software you've worked with so much. The precision, range, and units of data from the sensors will be different. Also, people with floating-point processors will want to work with floats, and others may want fixed-point numbers for speed. In any event, efficiency is paramount. If a standard interface introduces significant overhead into a system, speed freaks won't use it, and we VR hackers certainly qualify as speed freaks. If you show me a computer made today that's 'fast enough' for VR, I'll buy it (I'm broke, but I'm confident). My solution to this problem (encompassing the famous Media-Lab "all of the above" attitude) is that the interface provides the data in as many different formats as suitable, and also provides the relative costs of the different formats. The application decides which formats it wants, and informs the interface, which provides exactly what is needed. The concept is similar to that of an Internet Telnet connection; each figures out what the other's got so the most featureful connection possible is established. If the interface library can provide this kind of functionality by clever use of preprocessor macros, then very efficient code can be produced for a variety of different situations. For example, I've written an RS-232 library that works with POSIX, BSD, System V, and Macintosh systems. Thanks to clever and careful use of macros, the application code is generic, and the implementations are optimal. If you're interested in pursuing these goals with me, or if you have an idea, please send me e-mail. All HIT Lab software carries the GNU Copyleft Notice, in case you're concerned about proprietary ideas.