From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng) Subject: Superscape 3D Construction Kit Demo report Date: Sat, 30 Nov 1991 06:22:10 GMT Message-ID: <1991Nov30.062210.7327@watserv1.waterloo.edu> Organization: University of Waterloo I've been running the Superscape 3D Construction Kit demo (available by FTP from sunee.uwaterloo.edu in the /pub/vr directory). Here are some notes on it. It runs in 256-color mode, using 150x320 of the screen (rest of screen is a logo). I ran it on a 486/25 with a Paradise VGA card (average access speed). It gets between 3 and 8 frames/sec of video performance, depending on how much detail there is in the scene. The update rate seems to be fairly dependent on what is shown, even though multiple-resolution objects are used (discussed later). Interestingly, the program does not use the VGA X mode: it uses the normal 1-page 256-color mode, and copies the image in from the RAM buffer in which it was drawn. This can result in a fair amount of flashing during fast movements (rotations around viewpoints, for example). I calculate that it takes 65 mS just to do this copy, over and above the actual drawing time. Of course the picture is drawn faster in RAM, but I'm not sure if the overall balance is positive or not. The demo "world" itself is a group of buildings and streets. There are a few trees and bushes throw in too. A walking person (well animated) 2 cars and a helicopter can be controlled. There are 5 viewoints, 1 attached to each of the mobile objects plus one "free" viewpoint. The viewpoints may be moved in relation to their objects, and may turn with them. Object speed and direction are controllable by keys. There appears to be some rudimentary "collision" detection, and some objects may be moved by other objects. However, there seems to be a large" capture" area around some objects (such as the cars) which limits their manuverability near barriers. Also, some barriers can be tricked: i.e. the person and the cars can go thru walls at certain angles. This is probably an oversight in programming the demo world. The graphics seems to use fixed colors for objects (no lighting sources) which is not a real problem. Shading is preselected from the 256 colors available at world-construction time. The world seems to contain about 5000 to 7000 polygons, with some objects containing 100 or so polys the cars and the person). The rendering speed seems to be 1500-2400 polys/sec, plus the 65 mS copy to the VGA card memory. This is a bit worse than what could be done using X-mode (3000 polys/sec plus 20 mS to clear screen or 40 mS to copy). Of course, 16-color mode would more than double the speed. An interesting feature is the use of spheres as well as polygons, and semi-transparent polygons for windows (using halftones). These are simple tricks which may be useful to remember. Spheres look like circles from any angle, so you just add a filled-circle drawing routine and compute a radius (based on depth) and a center point coordinate. Transparancy is simple and I may add it to my poly blitter in a month or so. The method of ordering poly drawing seems to be based on objects. It is hard to tell, though, as there is no way to move objects inside other objects (convex collision detection "bounding boxes" perhaps). But it is not difficult to trick the depth-sorting into producing errors, and the results point to object-based drawing orders (i.e the object will never be erroniously cut in half by part of an object: it's always wrongly shown if the depth-sort fails). Could be some simplified BSP algorithm. There are other bugs than the depth-sort, too. The polygon edge joins in objects often split at the seams, showing other surfaces. This is worst when only a small piece of a polygon shows on the screen (possibly a problem with clipping). Probably due to integer math clipping (my blitter avoids it by clipping inside the poly blitter). Elimination of polygons to be drawn takes 2 forms. First, all polys facing away from the viewer (backside) are discarded. This shows up when you get your viewpoint where it doesn't belong (inside a car or an empty building). Suddenly only a few pieces of the object can be seen (buildings become a roof without walls, and the roof is lost from buildings with contents if you're between the roof and ceiling). Even more entertaining is going below the ground, and looking "inside" things from underneath! Second, there are multiple resolution versions of objects. There seems to be a set distance for each new instance of an object (the "d" key lets you toggle the thresholds up or down). Simplifications range from simple disapperance to having 4 or 5 seperate versions of objects. Lettering seems (from the way it scales with distance) to be done by adding polys to an existing object. In summary, the Superscape demo is a good example of low-end VR video, including aliasing, jittery images during motion, etc. I recommend you try it if you want to see what these phenomena look like. Having said this, I don't think the 3D Construction set is good enough for anything except simple systems. Its update rate is too low for eyephone-type VR, and the (presumably) precompiled worlds are not easily interfaced to other software (no idea on what the professional development stuff costs, or how it's accessed). Finally, the bugs in the depth-sort and the apparantly inflexible collision detection make it unusable for 3D editing/interaction systems with the PowerGlove. DISCLAIMER: The facts above were deduced by experimenting with the demo software. No dissasembly was done, so I relied on test results and bug hunting to figure out what was happening. I'd be interested in hearing from someone who's done actual development with the 3D Construction Kit. -------------------------------------------------------------------------- | 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 | __________________________________________________________________________