libpr consists of many facilities generally required in most visual simulation and real-time graphics applications, such as:

libpf provides a pipelined multiprocessing model for implementing visual simulation applications. The critical path pipeline stages are:

The application (APP) stage updates and queries the scene. The CULL stage traverses the scene and adds all potentially visible geometry to a special libpr display list, which is then rendered by the draw stage. Rendering pipelines can be split into separate processes to tailor the application to the number of available CPUs, as shown in Figure 2-2.

Figure 2-2. Parallel Pipeline Processes

An application might have multiple rendering pipelines drawing to multiple graphics pipelines with separate processes. The CULL task of the rendering pipeline can itself be multithreaded.

OpenGL Performer provides additional, asynchronous stages for various computations:

Multiprocess operation is largely transparent because OpenGL Performer manages the difficult multiprocessing issues for you, such as process timing, synchronization, and data exclusion and coherence.

For more information about multiprocessing stages, see Chapter 11, “Multiprocessing”.

libpf provides software constructs to facilitate visual database rendering. A pfPipe is a rendering pipeline that renders one or more pfChannels into one or more pfPipeWindows. A pfChannel is a view into a visual database, equivalent to a viewport, within a pfPipeWindow.

OpenGL Performer is designed to run at a fixed frame rate specified by the application. OpenGL Performer measures graphics load and uses that information to compute a stress value. Stress is applied to the model's level of detail to reduce scene complexity when nearing graphics overload conditions.

OpenGL Performer supports multiple pfChannels on a single pfPipeWindow, multiple pfPipeWindows on a single pfPipe, and multiple pfPipes per machine for multichannel, multiwindow, and multipipe operation. Frame synchronization between channels and between the host application and the graphics subsystem is provided. This also supports simulations that display multiple simultaneous views on different hardware displays.

A visual database is a graph of nodes with a pfScene node as its root. A pfScene is viewed by a pfChannel, which in turn is culled and drawn by a pfPipe. Scenes are typically, but not necessarily, constructed by the application at database loading time. OpenGL Performer supplies sample source code that shows how to construct a scene from several popular database formats; see OpenGL Performer Programmer's Guide for more information.

Q libpf supports a general database scene graph hierarchy, defined as a directed acyclic graph of nodes. OpenGL Performer provides specialized node types useful for visual simulation applications:

Grouping Nodes

Geometry and leaf nodes are the following:

OpenGL Performer provides traversal functions that act on a pfScene or portions thereof. These functions include:

The application can direct and customize traversals through the use of identification masks on a per-node basis using callbacks.

libpf provides an environmental model called a pfEarthSky, consisting of ground and sky polygons, which efficiently clears the viewport before rendering the scene. Atmospheric effects such as ground fog, haze, and clouds are included.

Sequenced animations, using pfSequence nodes, allow the application to efficiently render complex geometry sequences that are not easily modeled otherwise. You can think of animation sequences as a series of "flip cards," where the application controls which card is shown, and for how long.

Active Surface Definition (pfASD) is a library that handles real-time surface meshing and blending in a multiprocessing and multichannel environment. The pfASD approach uses a modeling terrain that is a single, connected surface rather than a collection of patches.

A pfASD surface contains several hierarchical level of detail (LOD) meshes where one level encapsulates a coarser level of detail than the next. When rendering a pfASD surface, an evaluation function selects polygons from the appropriate LODs, and constructs a valid meshing to best approximate a real terrain. An evaluation function, for example, might be based on distance.

Unlike existing LOD schemes, pfASD selects triangles from many different LODs and combines them into a final surface that transitions smoothly between LODs without cracks. This feature lets a fly-through over a surface use polygons from higher LODs for drawing nearby portions of the surface in combination with polygons from low LODs that represent distant portions of the surface.

Many graphics applications are limited in sending graphics commands to the Geometry Pipeline by CPU overhead. A pfGeoSet (or pfGeoArray) is a collection of like primitives such as points, lines, triangles, and triangle strips. pfGeoSets use tuned rendering loops to eliminate the CPU bottleneck.

OpenGL Performer optimizes graphics library performance by managing state changes, and provides functions to control aspects of the graphics library state such as lighting, texture, and transparency. These functions operate in both immediate and libpr display-list mode for direct mode changes, as well as for mode caching.

Other state functions such as push, pop, and override allow extensive control of graphics state.

A pfState is an encapsulation of graphics that renders lighting, texturing, and fog—the state settings for a graphics context. Loading a pfState ensures that the graphics pipeline is configured appropriately, regardless of previous graphics state. pfGeoStates describe the state of the geometry in pfGeoSets or pfGeoArrays, and are used for simplifying and accelerating graphics state management.

OpenGL Performer supports special libpr display lists. They do not use graphics library objects, but rather a simple token/data mechanism that does not cache geometry data. These display lists cache only libpr state and rendering commands. They also support function callbacks to allow applications to perform special processing during display list rendering. Display lists can be reused and are therefore useful for multiprocessing producer/consumer situations in which one process generates a display list of the visible scene, while another one renders it. Note that you can also use OpenGL display lists in OpenGL Performer applications.

Extensive linear algebra and simple geometric functions are provided. Some supported data types are point, segment, vector, plane, matrix, cylinder, sphere, frustum, and quaternion.

Functions are provided to perform intersections of segments with cylinders, spheres, boxes, planes, and geometry. Intersection functions for spheres, cylinders, and frustums are also provided.

OpenGL Performer supports global color tables that can define the colors used by pfGeoSets and pfGeoArrays. You can use color tables for special effects such as infrared lighting, and you can switch them in real time.

Light points, defined by the pfLPointState state object, can simulate highly emissive objects such as runway lights, approach lights, strobes, beacons, and street lights. The size, direction, shape, color, and intensity of these lights can be controlled.

Calligraphic extensions to pfLPointState provide a means of displaying exceptionally bright light points on non-raster display systems.

For more information about pfLPointState, see Chapter 16, “Light Points,” in the OpenGL Performer Programmer's Guide.

OpenGL Performer is an object-oriented API. Basic object function, such as creation, deletion, and printing, are inherited from pfObject. Basic memory management is done through pfMemory.

A simple nonblocking file access method is provided to allow applications to retrieve file data during real-time operation.

OpenGL Performer includes routines to allocate memory from the application process heap or from shared memory arenas. Shared memory arenas must be used when multiple processes need to share data. The application can create its own shared memory arenas or use pfDataPools. pfDataPools are shared arenas that can be shared by multiple processes. Applications can allocate blocks of memory within pfDataPools, which can be individually locked and unlocked to provide mutual exclusion between unrelated processes.

OpenGL Performer includes high-resolution clock and video interval counter routines. pfGetTime() returns the current time at the highest resolution that the hardware supports. Processes can either share synchronized time values with other processes, or have their own individual clocks.

The video interval counter is tied to the video retrace rate and can synchronize a process with any multiple of the video rate; this mechanism is the basis for producing fixed frame rates.

OpenGL Performer provides window-system-independent window routines to allow greater portability of applications. For information about these window routines, see Chapter 11, “Windows ,” in the OpenGL Performer Programmer's Guide.

For sample programs involving windows and input handling on IRIX and Linux systems, see the following directories:

/usr/share/Performer/src/pguide/{libpr,libpf,libpfutil,libpfui}

On Windows systems, see these directories:

%PFROOT%\Src\pguide\{libpr,libpf,libpfutil,libpfui}

libpfdu contains many utilities, including DSO support for database loaders and their modes, and file path support. The heart of libpfdu is the OpenGL Performer database builder. The builder is a tool that allows users to input or output a collection of geometry and graphics state in immediate mode.

Geometric primitives with their corresponding graphics state are sent one at a time to the builder. When the builder has received all the data, the builder can return optimized OpenGL Performer data structures, which can be used as a part of a scene graph. The builder hashes geometry into different bins, based on the attribute binding types and associated graphics state of the geometry. The builder also keeps track of graphics state elements, such as textures, materials, light models, and fog, and shares state elements whenever possible.

The builder creates pfGeoSets that contain triangle meshes created by running the original geometry through the libpfdu  triangle-meshing utility.

For each pfGeoSet, the builder creates a pfGeoState (OpenGL Performer's encapsulated state primitive), which has been optimized to share as many attributes as possible with other pfGeoStates being built (and possibly with the default pfGeoState that can be attached to a channel with pfChanGState()).

Having created all of these primitives (pfGeoSets and pfGeoStates), the builder places them in a leaf node (pfGeode), and optionally creates a spatial hierarchy (for increased culling efficiency) by running the new database through a spatial breakup utility function, which is also contained in libpfdu.

---

Note: The builder allows the user to extend the notion of a graphics state by registering callback functionality through the builder API, and then treating this state or functionality like any other OpenGL Performer state or mode (although such uses of the builder are slightly more complicated).

---

Graphics systems can display only a finite number of geometric primitives per frame at a specified frame rate. Because of these limitations, the fundamental problem of database construction for real-time simulation is to maximize visual cues and minimize scene complexity. With level of detail selection, one of several similar models of varying complexity is displayed based on how visible the object is from the eyepoint. Level of detail selection is one of the best tools available for improving display performance by reducing database complexity. For more detailed information, see Chapter 15, “Optimizing Performance”.

Many of the objects in databases can be considered to have one or more axes of symmetry. Trees, for example, tend to look nearly the same from all horizontal directions of view. An effective approach to drawing such objects with less graphic complexity is to place a texture image of the object onto a single polygon and then rotate the polygon during simulation to face the observer. These self-orienting objects are commonly called billboards. For information on billboards, see Chapter 15, “Optimizing Performance”.

Animated events in simulation environments often have a sequence of stages that follow each other without variation. Where this is the case, you can often define this behavior in the database during database construction. The behavior can be implemented by the real-time visual system without intervention by the application process.

An example of this would be illuminated traffic signals in a driving simulator database. There are three mutually exclusive states of the signal, one with a green lamp, one with the amber, and one with the red. The duration of each state is known and can be recorded in the database. With these intervals built into the database, simulations can be performed without requiring the simulation application to cycle the traffic signal from one state to the next.

The simplest type of animation sequence is known as a geometry movie. It is a sequence of exclusive objects that are selected for display based on elapsed time from a trigger event. Advancement is tied to frames rather than time, or is based on specific events within the database.

For further information on animation, see the section, “pfSequence Nodes” in the OpenGL Performer Programmer's Guide.

A ntialiased image generation can have a significant effect on image quality in visual simulation. The difference, though subtle in some cases, has very significant effects on the sense of reality and the suitability of simulators for training. Military simulators often center on the goal of detecting and recognizing small objects on the horizon. Aliased graphics systems produce a “ sparkle” or “ twinkle” effect when drawing small objects. This artifact is unacceptable in these training applications because the student will come to subconsciously expect such effects to announce the arrival of an opponent and this unfulfilled expectation can prove fatal.

The idea of antialiasing is for image pixels to represent an average or other convolution of the image fragments within the area of a pixel rather than simply be a sample taken at the center of the pixel. This idea is easily stated but difficult to implement while maintaining high performance.

InfiniteReality continues the RealityEngine antialiasing approach known as multisampling. In this system, each pixel is considered to be composed of multiple subpixels. Multisampling stores a complete set of pixel information for each of the several subpixels. This includes such information as color, transparency, and (most importantly) a Z-buffer value.

Providing multiple independent Z-buffered subpixels (the so-called subpixel Z-buffer) per image pixel allows opaque polygons to be drawn in an arbitrary order because the subpixel Z-comparison will implement proper visibility testing. Converting the multiple color values that exist within a pixel into a single result can either be done as each fragment is rendered into the multisampling buffer or after all polygons have been rendered. For the best visual result, transparent polygons are rendered after all opaque polygons have been drawn.

The most obvious use of texture mapping is to generate the appearance of surface details on geometric objects, without making those details into actual geometry. One valuable and widely used addition to these texture processing features is the concept of partly transparent textures. An example of this is the use of billboards (see “Rendering Slices of Shapes” in Chapter 15). For example, to display a tree using textures and billboards, you would create a texture map of a tree (from a photograph, perhaps), marking the background (any part of the texture that does not show part of the tree) as transparent. Then, using a flat rectangle for the billboard, map the texture to the billboard; the transparent regions in the texture become transparent regions of the billboard, allowing other geometry to show through.

You can use textures to simulate reflections (usually in a curved surface) of a 3D environment such as a room by using the viewing vector and the surface normal of the geometry to compute the index of each screen pixel into the texture image. The texture used for this process, the environment map, must contain images of the environment to be reflected.

You can use the environment mapping technique to implement lighting equations by noting that the environment map image represents the image seen in each direction from a chosen point. Interpreting this image as the illumination reflected from an incident light source as a function of angle, the intensities rather than the colors of the environment map can be used to scale the colors of objects in the database in order to implement complex lighting models (such as Phong shading) with high performance. You can use this method to provide elaborate lighting environments with systems in which per-pixel shading calculations would not otherwise be available.

You can also use texture mapping to project images such as aircraft landing lights and vehicle headlights into images. These projective texture techniques, when combined with the ability to use Z-buffer contents to texture images, allow the generation of real-time images with true 3D cast shadows.

The shared-memory, multiprocessed system architecture with high bandwidth for graphics subsystems in the SGI product line provide ideal systems for real-time high quality character animation. Vertex position, colors, normal vectors, and texture coordinates can all be interpolated between two versions of a model, a process known as morphing, with the OpenGL Performer pfEngine and pfFlux objects. You can also apply more complex functions between multiple versions of a model. You can use morphing to fill in motion between a start position and an end position for an object or—in its fully generalized form—parts of an animated character (such as facial expressions).

For more information about morphing, see Chapter 14, “Dynamic Data” , in the OpenGL Performer Programmer's Guide.

Simple pair-wise morphing is not sufficient to give animated characters life-like emotional expressions and behavior. You need the ability to model multiple expressions in an orthogonal manner and then combine them with arbitrary weighting factors during real-time simulation.

One current approach to human facial animation is to build a geometric model of an expressionless face, and then to distort this neutral model into an independent target for each desired expression. Examples include faces with frowns and smiles, faces with eye gestures, and faces with eyebrow movement. Subtracting the neutral face from the smile face gives a set of smile displacement vectors and increases efficiency by allowing removal of null displacements. Completing this process for each of the other gestures yields the input needed by a real-time system: a base or neutral model and a collection of displacement vector sets.

In actual use, you would process the data in a straightforward manner. You would specify the weights of each source model (or corresponding displacement vector set) before each frame is begun. For example, a particular setting might be “62% grin and 87% arched eyebrows” for a clownish physiognomy. The algorithmic implication is simply a weighted linear combination of the indicated vectors with the base model.

These processing steps are made more complicated in practice by the performance-inspired need to execute the operations in a multiprocessing environment. Parallel processing is needed because users of this technology:

Together, these demands can require significant resources, even when only vertex coordinates are interpolated. When colors, normals, and texture coordinates are also interpolated, and especially when shared vertex normals are recomputed, the computational complexity is correspondingly increased.

The computational demands can be reduced when the rate of morphing is less than the image update rate. You can often improve the quality of the interpolated result by applying a non-linear interpolation operation, such as the eased cosine curves and splines found useful in other applications of computer animation.

A successful concept in computer-assisted 2D animation systems is the notion of skeleton animation. With this method you interpolate a defining skeleton and then position artwork relative to the interpolated skeleton. In essence, the skeleton defines a deformation of the original 2D plane, and the original image is transformed by this mapping to create the interpolated image. This process can be extended directly into the 3D domain of real-time computer image generation systems and used for character animation in entertainment applications.

The techniques of generalized morphing and skeleton animation can be used together to create advanced entertainment applications with life-like animated characters. One application of the two methods is to first perform a generalized" betweening" operation that builds a character with the desired pre-planned animation aspects, such as eye or mouth motion, and then to set the matrices or other transformation operators of the skeleton transformation operation to represent hierarchical motions such as those of arms or legs. The result of these animation operations is a freshly posed character ready for display.