This chapter contains many useful ideas. In fact, it provides the overview that is the basis for the entire book, and I wonder why the author didn't put it at the beginning. I will try to use these notes and queries to highlight the most important of them. But in fact these notes are mostly about terrain databases and Level of Detail control.
The Big Picture. See Figure 6.1, page 167. In class, we will develop a more generic chart which replaces specific devices with the terms display and input device. We will then instantiate (that is, make a couple of instances, or examples of) this generic model, by showing the details of a classic flight simulator, and of a location-based entertainment (LBE) device. The LBE system we will study is Disney Quest's build-your-own-roller-coaster ride.
Databases for Virtual Environments. Section 6.1 discusses the structure of simulation (VR) databases. In VRML and other educational systems like Alice, the database is small enough that it can all be loaded into RAM. But in a real VR system the world is often far too complex to handle in this way.
NOTE: The following story about the SIMNET system is being prepared at a time and place where I don't have access to reference documents. So some details may vary from the actual SIMNET system - but the spirit of the discussion is valid. Your computations should be based on the following assumptions as stated.
Consider the SIMNET networked tank and aircraft training system, designed in 1984 and constructed between 1985 and 1992. Its image generation system consisted of an eight channel special purpose image generator that produced images that were 640 pixels wide and 128 pixels high, at 15 frames per second. This crude imagery was deemed appropriate for SIMNET tank simulators because the vision blocks (periscopes) of a tank have that aspect ratio. Fifteen f/s is certainly too slow for aircraft, but tanks don't fly quite as fast as A-10s or helicopters.
SIMNET's terrain consisted of a 125-meter elevation grid. An 8 x 8 patch of such posts would define 64 quadrangles or 128 triangles. Such a load module would cover an area of one square kilometer. The range-to-horizon was artificially declared to be three kilometers or about two miles, since this is about how far a tank commander can see on rolling terrain. (Of course, one can see much farther than this in the desert.). The load modules which represent this region had to be loaded into the image generator's RAM memory so that if the viewpoint suddenly spun around 360 degrees, the terrain imagery would be visible.
SIMNET's image generator was capable of rendering 2000 triangles in each rendering cycle. Of these, somewhat more than half had to be allocated to moving models (tanks and aircraft.)
Query 13.1. The square active region model considers that the viewpoint is located anywhere in some central load module C. To assure at least a 3 km range to horizon, the system must have, in addition to C, three load modules "ahead of you" in all directions (including diagonal directions.)
Under the simple minded "square active region" plan, how many terrain triangles would be loaded into the image generator's active memory at any given time?
Query 13.2. If a given channel of the image generator had a field of view of 45 degrees, then how many triangles would be visible at any given time? Check this figure against the IG's polygon budget.
Query 13.3. When the point of view (POV) crossed a LM boundary, how many new LMs had to be paged in (copied from disk drive to RAM)?
Query 13.4. With a fixed terrain triangulation such as SIMNET, the only data that is actually needed per vertex is its height, which is stored in a two-byte fixed precision number. (What is a fixed precision number and how does it differ from a floating point number?) How many bytes are needed per LM for SIMNET to store the elevation grid?
In addition to the elevation, each triangle (128 per LM) has a one-byte color attribute, so that the ground's color can vary depending on vegetation, road surface, water etc. So the total storage would be (how much) per LM?
Query 13.5. An M1A1 tank can travel at 50 miles an hour over most kinds of terrain (unless it's full of boulders, trees or houses.) In fact its fuel trucks have a hard time keeping up. To design a SIMNET database capable of simulating a free-play tank battle that will last two hours, how large a database (in square km, and in megabytes) should be provided? Note: A km=5/8 of a mile.
Query 13.6. Now the combat engineers want to play bulldozer games. They request that the entire system be rebuilt with 1 meter resolution terrain. Assuming that nobody knows about Level of Detail control, what must the polygon capacity (triangles/frame) of the IG be, still assuming 45 degree field of view? What must the capacity of the hard disk drive be?
Most importantly, what fact did you forget to ask for, in Query 13.6?
Level of Detail Control
It is possible to render fine-grained detail for parts of the environment that are close to the observer. For instance, the nearest nine 125-meter quads (including the one containing the POV) could be rendered in 1 meter resolution.
Query 13.7. If this were done, how many triangles would we have to render to manage the high-LOD region?
Query 13.8. Still overloaded, huh? Well what if I give you a 5000 triangle budget. How many load modules (125 meter squares) would you recommend that we cut up into one-meter triangles? What's left over for the rest of the 3 km horizon, still using the big old 125 m quadrangles?
Of course, the SIMNET plan would not work optimally for such a 'dozer simulation, because you would doze right up to the edge of a load module of 1 meter quads, and ahead of you would be a 125 meter flat polygon. This is called a visual discontinuity. In fact the edge of a 1m tesselation and a 125m tesselation mightcontain numerous topographic discontinuities - triangular "holes" where you could see through to the nether world. So smart database designers make sure to plug up these holes by bringing all the high res triangles down to match the low res edge.
Moving Models
Enough about terrain. Consider moving models (tanks.) They can also
be modeled at various LOD. Typically in a high fidelity system there will
be 3 to 8 different LOD models. How to transition between them? This question
also applies to terrain of course. The main techniques are:
Query 13.9. Use the example of a hanging telephone wire, as in Moshell's lecture, to explain how Geometry Blending is used to produce a continuous level of detail.
Tracking is a very important topic for VR. Magnetic trackers have dominated VR for many years because they are affordable, lightweight and reasonably fast. But they are not the ultimate fast tracker. Optical systems win this contest. You will see a very good optical tracker when you tour Dr. Rolland's lab next week.
Mag trackers suffer from speed problems in part because they normally acquire x, y, z and roll, pitch, yaw information in three separate operations, then provide the new data to the user. Gary Bishop at University of North Carolina recently published a much better technique in which the user's software receives updated information three times as often. A new and more accurate X value will be blended with an "extrapolated" version of Y and Z (rather than the old and increasingly inaccurate values for those dimensions); then the same trick is repeated as fresh data arrive for Y and Z.
Gloves. A traditional VR glove contains flex sensors, but this
has proven to be troublesome because of the "gesture recognition problem".
People's hands vary in size and the gestures folks make vary in shape.
So Dan Mapes at IST invented the Pinch Glove. This glove has metallic contacts
in the fingertips and palms, and uses direct connections rather than approximate
gestures to indicate options. The pinch glove is becoming more popular;
I saw them last week in use at Ga Tech.
Back to the course index
Back to the course syllabus
Back to the previous lecture
Onward to the next lecture