From: pepke@scri1.scri.fsu.edu (Eric Pepke) Subject: Re: Low end VR Date: 4 Oct 91 16:42:46 GMT Organization: Florida State University, but I don't speak for them In article <1991Oct1.193045.3213@milton.u.washington.edu> twkingsb@eos.ncsu.edu (TIM WINTHROP KINGSBURY) writes: > Without first achieving a reasonable frame rate, it seems like there is very > little point in playing with home-made eyephones and Nintendo power gloves... > > Perhaps a better starting point might be to find a clever way to do some very > fast rendering directly to the screen. I think that, at least for the purposes of experimentation, it should be fairly easy to get an adequate frame rate. Have you ever seen a Macintosh game called The Colony? On my si in b&w mode, it generates what I would consider an adequate frame rate on the simpler scenes. (All of the subsequent discussion is colored by the fact that I understand the Macintosh and the Silicon Graphics fairly well, better than the PC or Amiga). Also, remember that we only really need to generate two screens of about 320 by 200 to drive the LCD monitors. I think that people have a tendency to overcomplicate the process of doing VR. I do scientific visualization on a Silicon Graphics GTX system, and I'm a big fan of high-quality rendering, but it is overrated as a method of convincing the user of realism. In many ways, the finest VR experiences I have ever had were in a video game called Battle Zone. Technologically, it was pretty boring--I think it used a Z-80 at 1 MHz, and it had a monocolor vector screen on which it showed wire-frame representations without hidden line removal. However, given that, it was very well done. One felt immediately that one was *there*, much more quickly IMHO than one does with the VPL and North Carolina systems. Responsiveness, directness, and artistry can be more important than visual realism. Nevertheless, I would like to see some discussion on garage-type solutions to the problem of homebrew VR, solutions that rely more on ingenuity than on venture capital. I'd like to spark some discussion on minimal requirements for low-end VR systems and algorithms optimized for VR. Here are some characteristics of VR, esp. low-end, for which we might want to optimize, and some ideas of possible influences in parentheses: 1) There aren't that many dots. (may influence algorithms with dot/# objects tradeoffs). 2) There are always two perspective images, spatially separated by not that much (may help share the task of hidden surface removal between views). 3) Views are close to temporal coherence as well (cache information about visibility and use it in subsequent frames?) 4) Rotation is more important for feedback than translation (cache information about viewpoints within certain bounds?) 5) The LCD displays aren't very good with subtle color variations (shading algorithms might be pointless, or at least we can use ridiculously inaccurate but fast approximations.) Now, what is a reasonable minimum for object/surface representation? The bare minimum, of course, would be wire frame without surface removal. A more reasonable minimum would be unshaded, monocolor polygons. I think triangles would be sufficient, but it might also be desirable to add quadrilaterals, too, because they are so common. There are some advantages to keeping the vertices stored separately from the objects that refer to them. The biggest is that the relatively expensive transformation to viewer coordinates could happen only once to each coordinate. VR is going to involve a lot a parallelopipeds, in which each vertex is used by an average of 4.5 triangles or 3 quadrilaterals, so this would cut down on the need to do this so much. The bitmaps are not very large, so we could afford a 16- or 24-bit Z-buffer. It's very cheap to do screen door transparency, and that would be a good effect, so why not? With only a little bit more expense, one could do two color dithering, but it might not be worth it. A 256-color system may be plenty. The classical approach is linear by polygon, updating the Z-buffer and color buffers as one goes along. This pretty much requires an offscreen bitmap which is later blasted on to the screen or a double-buffer arrangement. If one could convince oneself that 16 colors were enough on a 256-color system, then a double buffer can easily be done by editing the color map. However this would require doing the rendering into half-bytes, which is a little less efficient than rendering into bytes. (This might be fine; if we're going to render to a 640 horizontal dot board to drive a 320 horizontal dot monitor, there is no reason not to try to do colors by adjacent color dithering). On the other hand, the relative easy of accessing main memory for which there is no contention by the video sweep may make it more efficient in the long run to do offscreen rendering anyway, even given the final blast step. There are also approaches which are linear by pixel, which don't require all those buffers because once a pixel is done, it's done. The disadvantage here is that each pixel requires traversing a large data structure, which eliminates the speedup of keeping everything in registers. Now, how to get the stuff in your eye? If we use a full video board per eye, we're wasting a lot of dots. The horizontal dots get downsampled, and only half the lines are shown. Obviously one way to solve this would be to go directly from bitmap to monitor without going through video, but, failing that, might there be a way to have one eyepiece display only even frames and the other only odd frames and drive both with a single video source? One final flameworthy note: I don't think we really need floating point. Sure it's nice, but I think we can live without it. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.