Inventor: CAD and other high-structure applications with substantial but not dominating performance requirements;
Performer: Real-time simulation in which performance was everything (hence the name);
Fahrenheit: Both markets. (Always a bad sign.)

SGI Inventor and Open Inventor

www.sgi.com/Technology/Inventor

SGI Performer

www.sgi.com/Technology/Performer

Performer is a "software image generator". There was once a long list of basic distinctions between a workstation running GL (predecessor, naturally, to OpenGL) and an image generator such as those used in flight simulators (and built by Evans & Sutherland, General Electric Simulation, Link and a few other manufacturers.) That list included these features which were built into the IG and thus didn't have to be programmed by the simulation developer:

- ability to load databases directly from a specialized CAD format (e. g. Multigen Flight)
- ability to deliver a fixed frame rate and fixed maximum latency ("stress load management");
- ability to return geospatial information (e. g. terrain height) to the simulation system;
- collision detection;
- automatic  level of detail management;
- load module management (paging of database segments into RAM);
- multiple display management (e. g. a 4-window helicopter cockpit);
- depth cueing via haze;
- special-effects fog (e. g. for aircraft passing through clouds);
- light points (emissive, crisp super-bright lights for night scenes.)
(sometimes, e. g. ESIG500, managed via special super-wierd dual-gun raster/calligraphic CRTs!)
- animation sequences, e. g. for flames
- billboards
- and sometimes on high-end IGs, special morphing microcode to support continuous LOD (CLOD)
and, most importantly
- texture mapping.

There have been special IGs built which were capable of dealing with geospecific phototexture. In other words, they could drape aerial imagery from aircraft or satellite photos, over elevation post terrain. This required enormous disk-to-memory bandwidth. Such an experimental IG was built by Hughes Simulation for PM-TRADE( predecessor to STRICOM). After the experiment was over, this unit was given to IST, but it was impractical to reassemble and operate it, so it was used as a junkpile.

SGI's current generation of RealityEngines has "clipTexture" which can implement geospecific phototexture over regions of up to 8m by 8m pixels. This would require 64 terabytes of disk space for a palette-based image (8 bits per pixel). ClipTexture is implemented via ClipMaps, about which SGI has provided a nice article in PDF form.

Query 9.1: At 1 cm resolution at ground level, this capability would support a square gaming area of how many by how many km?

ANSWER
1 km = 1000 m = 10⁵ cm. So  8*10⁶ cm = 80 km.
/ANSWER

Query 9.2: MIPmaps have a number of layers of texture elements (texels), each at twice the resolution (and consuming 1/4 the memory) of the previous. The recursive definition of a MIPmap specifies that an nxn three color map is stored as three nxn one-color maps, and one additional nxn region of memory is used to store an (n/2 x n/2) MIPmap.

a) How many layers could be stored in the 8m x 8m MIPmap?

ANSWER: 8m is 2²³
so there could be 23 layers. We don't actually often use the coarser LODs (who wants a 2 x 2 texture map?) but they're certainly easy to compute and store.
/ANSWER

b) A hypothetical 8m x 8m MIPmap would consume how much total storage?
ANSWER: 4/3 of 64 gb = 86 gb more or less. But who's counting a few spare gb?
/ANSWER

c) Assume that you work for Lockheed-Martin on the SSTO spacecraft project. (Extra cookies for anyone who knows what that is) and you wanted to show a continuous-zoom image from orbital altitude of 200 km, down to a height of 10m. What is the maximum FOV that could be supported by the clipTexture system described here? How many (and which) of the available texture levels would be used in displaying the descent?

ANSWER
ATAN(40/200) = 11.3 degrees, so the FOV would be 22.6 degrees. Not quite enough unless you are simulating a periscope or telescope.
/ANSWER

The reason all this wasn't built into a workstation in the 1980's was that IGs were six- or seven-figure devices. A twenty million dollar flight simulator would involve an investment of $2 to $5 million in an IG. A "low cost" IG in 1990 was the $200,000 ESIG-2000. Silicon Graphics entered the market that had been invented by Sun (which was using the 68000 microprocessor to implement a cheap and reliable Unix workstation, signaling the end of the minicomputer era.) SGI's workstations cost less than $50,000, used bit slice architecture and DSP chips to implement the CPU and graphics pipeline of the 2000 series of machines. Later they purchased CPUs from MIPS for use in the 4Dxx series of machines,  and eventually bought the company itself. The core market was CAD. These machines had no texture capability.

Eventually Moore's law brought the hardware forward to the point that third parties started selling software which took on more and more IG functions. When SGI got ready to introduce the RealityEngine series which had texture mapping, they felt the need to provide a reliable and easily used software environment to protect users from the increasing complexity of managing all the RE's features. Thus, Performer was born.

Stress Management

How can one predict that a given viewing frustrum orientation and database configuration will cost more time to render than a frame can provide? The keys to this technique are based on two facts: 99% reliability looks almost as good as 100% reliability, and in realtime simulation, every frame is similar to the last one because flight speeds and slew rates are finite.

Software in a realtime loop has a time budget for each phase of the loop. IG software is set up to measure and monitor the spare time between the end of a previous frame's rendering process and the beginning of the next one which is triggered by a realtime clock. This clock event also triggers the buffer swap which reveals the result off the last rendering, thus maintaining a constant frame delivery rate in the face of varying rendering times. In a dual buffer system, until buffer swap occurs, the graphics system cannot begin rendering the new scene. There is little point in "beginning early" because there is nowhere  to put the resulting pixels until the buffer is swapped.

When a certain critical threshold of minimum slack time is reached, the IG knows it must reduce the polygon count. The simplest way to do this is to pull in (reduce) the range radii for LOD transition - but this must not be done in such a way as to cause 'popping' or sudden LOD transition. The simplest way to assure that such transitions will always be out in fuzz-land, is careful database modeling to keep the models' geometric profiles as similar as possible.

The SOF-ATS (Special Operations Forces - Advanced Training System) built for the Air Force at Ft. Campbell, KY, was designed to prevent repetitions of the Iran hostage rescue disaster in which helicopters crashed into one another at the staging area in the Iranian desert, and the mission was aborted. The ESIG 4000 image generator incorporated Continuous Level of Detail, as a means of maximizing visual scene fidelity at this LOD transition point.

Go read the CLOD paper at this point.

pfASD (page 22) is relevant here.
 

Fahrenheit

Components:

Low level API: ultimately intended to meet the same needs as Direct3D and OpenGL, while being fine-tuned to support Fahrenheit Scene Graph.
Fahrenheit Scene Graph: The main working environment.
Fahrenheit Large Model: Load management stuff like the IG-ish features of Performer.

FSG's design principles:

1. Orthogonality: Features work seamlessly with other features.

2. Configurability: you can fine tune it for memory usage, etc.

3. Modularity: you can use pieces by themselves.

4. Extensibility.

5. Performance is central.

6. Design for multiprocessing from the beginning.

7. Design for Wintel and Unix simultaneously .... so as to provide a pathway for Unix apps into Wintel's world. Use the COM model.

Usage scenarios:

* A modeler
* A quick prototype of a PC game (uses FSG's nodes and actions)
* High performance PC game (uses FSG's openness to implement fine-tuned nodes.)
* Real-Time Visual Simulation (Performer's territory.)

BUT- Performer is now on Linux, so you can do much of that without Fahrenheit. (But it isn't yet on Windows. So it's still Direct3D territory.)

In a Nutshell:

Direct3d has the ability to define Frames, but they aren't part of the X object structure. So to load a hierarchical object (e. g. Multigen Flight, or VRML)  into Direct3D would require that your loader dynamically "compile" the object by constructing frames as the object is parsed, and dumping the leaf-node geometry into D3d geometry.

Some Scene Graph Node Types:

Interior nodes

Branch node (points to a collection of children, specifies no behavior)
Link node (points to a collection of children, and also points to Core node defining the node's behavior; e. g. a transformation)
Group node = a Link node with a Core node

Switch node. Controlled by a bit mask, invokes those children whose bit is set.

Sequence node. Selects each child in a specified subrange of its children, for a certain time duration.

Matrix node. (Generalization of a transformation node.) Applies a matrix to the Cumulative Transform Matrix of all its children.

SwitchDetail node. Range-switches between children for LOD purposes.

BlendDetail node. Like a SwitchDetail using smooth dissolve instead of popping.

Decal node. Specifies a rendering order, useful for coplanar objects.

Notifier node. Uses a user-defined callback function to decide if the children are traversed.
 

Viewproxy node. Useful for attaching a camera to a point in the hierarchy without having to put geometry there.

Shape node: defines a renderable object, constructed of
 

Triangle strips and fans
lines and points

Cull - traverses the scene graph, uses bounding spheres & boxes to eliminate subgraphs outside the view frustrum.
Sort - order the graph for optimum rendering. Usually produces a second graph.
Draw - traverses the graph and calls the primitives to actually draw the scene.

Intersection testing

Terrain following
Collision detection

Object picking
 

To the syllabus
To lecture 9
To lecture 11