IRIS Performer is a SGI (Silicon Graphics) software toolkit for 3D rendering. Performer plays a role in this work because vtk (visualization toolkit) wasn't designed for rendering to multiple channels (views) simultaneously. Rendering to multiple channels simultaneously is needed in multi-headed displays such as the CAVE here at NCSA.
By using vtk and Performer, we are able to make use of all the visualization algorithms that vtk provides and make use of the rendering capabilities of Performer. However, some work had to be done in order to get these toolkits to work together. This work is described in the vtkActorToPF section.
The main concept behind Performer is the notion of a scene graph. Essentially, the use of a scene graph emphasizes 3D objects rather than drawings. [17] The scene graph is a database which stores all the information about the objects in the scene. The information in the database can be used in a variety of ways, the most common being rendering (displaying an image of the 3D objects on the screen). Other actions that can be applied to a scene graph include picking, calculating bounding boxes, writing to a file, etc.
Performer uses OpenGL for rendering. OpenGL is a standard API for graphics programming. However, in OpenGL, rendering is explicit. OpenGL code describes the primitives that are to be drawn. In Performer, the scene is organized into higher level objects rather then just individual primitives. This makes it easier to manipulate individual objects within the scene. During rendering, the scene is traversed and each object knows how to render itself (using OpenGL). As a result, working with scene graphs is a lot easier than working directly with OpenGL.
The structure of the Performer scene graph is a tree structure which permits shared instancing. Shared instancing means that multiple parents can share the same child. Due to the shared instancing, a reference counting mechanism is provided to ensure that deleting objects is not a dangerous operation. [3] Each node in the tree is an object. Typically, leaves in the scene graph represent geometry objects and interior nodes represent transformation objects. The shared instancing mechanism offers database and program economy [17]. A subtree in the scene graph may represent an object in the scene (the object itself may be made of subcomponents). If multiple copies of that object are going to populate the scene, then it is efficient to reuse the same subtree in different parts of the graph. Also, any change in that subtree will be reflected in all instances of it.
For the purposes of this work, only two types of Peformer nodes are utilized, pfGeode and pfDCS. The pfGeode is a geometry node that contains a list of geometry structures called pfGeoSets [3]. pfGeoSets encapsulate state and geometry. Each individual pfGeoSet holds one type of primitive. Altogether a pfGeode describes the attributes and primitives of a geometrical object in the scene. The pfDCS node is a branch node (interior node) that represents a dynamic coordinate system [3]. This type of node is used to place the geometry in 3D space.
As detailed in the vtkActorToPF section, vtk is used for its visualization algorithms. The resulting geometry is stored in vtk objects called vtkActors. A vtkActor is the equivalent of a pfGeode. However, since these are two different toolkits, the geometry representation is different. In order to be able to render the geometry using Performer, each vtkActor is translated into an equivalent pfGeode and inserted into the Performer scene graph. Whenever a vtkActor changes, the corresponding pfGeode must be retranslated.
