Back patch culling occurs before the primitives are processed by the graphics pipeline. As a result, back patch culling off-loads some of the graphics pipeline work to the CPU, yielding an added degree of parallelism between the two processors.

In back face culling, all of the triangles in a geometry are processed and then those on one side of a geometry are discarded. The amount of processing can be significant, including

Not displaying back faces is only a small part of the face processing. Consequently, culling back faces may not significantly enhance application performance.

In back patch culling, all primitives seen only on one side of a geometry are culled before their triangles are processed by the graphics pipeline. Back patch culling often improves application performance by not performing unnecessary processing.

Back patch culling usually reduces the work done by the graphics hardware but it does increase the workload of the host. Performance is enhanced when the time spent performing back patch culling is roughly equal to the time spent processing culled triangles in the graphics hardware.

Back patch culling is most effective when:

If the primitives are short, the processing time of the back patch culling might approximate the rendering time for no net gain in performance. If most of the primitives wrap around to both sides of a geometry, few primitives are back patch culled.

To determine which side of a geometry an element of a primitive is on, the angle between the viewing vector and the normal to each element of a primitive is calculated. If the viewing angle is less than 90 degrees, the element is on the front of the geometry, as shown in Figure 14-2.

Figure 14-2. Viewing Angle

Normals

Two types of normals can be used to calculate the viewing angle:

• Face normal—the normal to the surface of an element.

• Primitive normal—the normal to all of the vertices of the elements when the PER_VERTEX_NORMAL binding is used, or the normal to the csGeoSet when any other binding is used.

Figure 14-3 shows these two types of normals.

Figure 14-3. Face and Primitive Normals

Face normals can be calculated given the vertices; primitive normals must be provided by the scene graph.

The direction of the face normal follows the right hand rule: your thumb points in the direction of the normal when the fingers on your right hand wrap in the direction of the ordered vertices, as shown in Figure 14-4.

Figure 14-4. Direction of Normals

There are two steps you take to implement back patch culling:

Now that you understand all the facets of back patch culling, Example 14-1 presents the series of calls your application must make to implement back patch culling.

// Create a draw action.
csDrawAction *drawAction = new csDrawAction;
...

// Set the back patch culling mode.
drawAction->setBPCullMode(csDrawAction::DRAW_FRONT_FACING);

// Build scene graph.
csNode *scene = new csNode;
...

// Build back patch culling data for scene graph by using 
// csGeoSet::buildBPCullData() in the following developer-supplied 
// method.
buildBPCullSceneData(scene);

// Apply the draw action to the scene graph.
drawAction->apply(scene);

The distance, called the range, that determines which child of the csLOD is displayed is defined as the distance between a camera and a shape's center. Each child node of a csLOD node is associated with a range of distance values. The range is computed during the traversal of the scene graph. You set the range value using csLOD methods:

void setCenter(const csVec3f& c);
void getCenter(csVec3f &c) const;

void setRange(int index, float nearDistance,float farDistance);
void setRangeNear(int child,float distance);
void setRangeFar(int child,float distance);

int getNumRanges() const {return numRanges; }
float getRangeNear(int child) const;
float getRangeFar(int child) const;

The setCenter() method specifies the center of the LOD. The center point aids in calculating the range between the camera and the shape.

The setRange() method specifies the ranges over which a child node of the csLOD node is selected for display. The number of ranges must correspond to the number of csLOD child nodes. If that is not the case:

Instead of using setRange(), you can use setRangeNear() together with setRangeFar() to specify the range over which a child node of a csLOD node is selected for display.

The camera may disregard range values and

---

Tip: For best results, specify ranges only where necessary; give browsers as much freedom as possible to choose levels of detail based on performance.

---

The transition() method specifies the range over which one csLOD child changes into the next, as shown in Figure 14-5.

Figure 14-5. csLOD Ranges

Many of the fields in csContext set the appearance of a geometry. The fields in csAppearance match those in csContext. Setting a csAppearance field overrides the values of the same fields set in csContext. Overriding csContext values, however, reduces performance because the field has to be reevaluated every time the csAppearance object is applied.

To maximize performance:

In this way, you set the minimum number of csAppearance fields.

Some of the fields set in csAppearance are much more graphics-intensive than others. In particular, the blending, texture, and lighting fields require larger amounts of CPU time. To improve performance, it is better not to turn on these modes if your application does not need them.

You can specify the appearance of all the csGeoSet elements making up a geometry either individually or collectively. You have the option of specifying the attribute values sequentially, so that the first element is described by the first csAttribute values or you can use an index system.

Choosing to index the attribute values (or not) can dramatically affect application performance. The general rule to remember when indexing or not is to determine whether many elements share the same vertices, or not. If many elements share the same vertex, index the attribute values; if a vertex is not shared by many elements, specify the attribute values of the elements sequentially.

For more information about indexing, see “Indexing Attributes”.

Whether you set the transformation matrix explicitly or you use the csContext methods that set the transformation matrix for you, rendering performance is optimized for the following reason: a shape can be translated, scaled, and rotated. Rather than computing these methods every time a shape is drawn, the transformation matrix represents the product of all three methods. Likewise, when a transformation matrix node is the parent of many shape nodes, the transformation for all of the children shape nodes is captured in a single transformation matrix.

Although there are no restrictions on the way in which you create a scene graph, it is customary to find that pieces deep in a scene graph branch add to pieces above them, which add to pieces above them until an entire object is described. For example, the lowest node in a branch might be a toe, the node above it might be the foot, the node above that the leg, the node above that the body; taken together, the nodes describe one side of the lower half of a body, as shown in Figure 14-6.

Figure 14-6. Arranging Scene Graph Nodes

When an action traverses a scene graph, the more nodes it visits, the longer it takes to execute the action. If scene graph branches are deep, the traversal can become expensive. To correct this problem, if you find that the elements in a branch do not change often, you can precompile that branch using csCompileAction. This action compiles a specified subgraph into a data structure, which optimizes setting the traversal state.

To compile a subgraph, create a csCompileAction object and apply it to the root node of the scene graph, as follows

csCompileAction *compileIt = new csCompileAction;
compileIt->apply(node_name);

node_name is the name of the node below which you want to precompile.