View-frustum culling identifies csGeoSets in a scene graph whose geometry is not in the viewing frustum, and prevents their further processing in the graphics pipeline, clearly a potential benefit for all downstream resources.

Cosmo3D provides integrated, hierarchical view-frustum culling, which runs as part of the rendering process. OpenGL Optimizer provides an additional method for multiprocess view-frustum culling as part of the occlusion culler discussed in the next section.

Occlusion culling identifies triangles in a scene graph that are occluded by objects in the foreground and prevents their further processing in the graphics pipeline.

---

Note: If you set opDrawAction::setVFCullMode to true, the occlusion culler performs view frustum culling before occlusion culling to reduce the number of objects for which occlusion culling has to be performed.

---

You can control what you mean by “occluded;” the occlusion culler allows you to eliminate objects for which a specified fraction of their bounding boxes are occluded by foreground objects. This partial occlusion control allows you to further reduce the load on the graphics pipeline; the efficacy of culling surges as you decrease the fraction, but at the possible cost of eliminating partially visible objects.

The default fraction for culling, 100%, is conservative in that the occlusion culler never eliminates a visible triangle; however, it might not cull all occluded triangles. You can change the fraction according to your needs, and update it dynamically in response to graphics-pipeline load as a closed-loop frame rate control mechanism.

Rendering occluded triangles does not generate an incorrect image because the depth buffer test eliminates occluded pixels, but that test occurs late in the rasterization stage after vertices have been transformed, so relying on depth-buffer testing for occlusion culling wastes graphics hardware processing cycles.

Just like view-frustum culling, occlusion culling is clearly a potential benefit for all downstream processing resources.

When to Use Occlusion Culling

Occlusion culling is appropriate for scenes with high depth complexity, that is, with many objects that may be occluded. For example, 95% of the triangles in a typical view of an automobile or other complicated mechanical assembly are occluded. Occlusion culling provides less of a benefit for scenes with less depth complexity. In a visual simulation application, where objects do not contain internal parts, more than half the triangles are commonly visible. In this case, an occlusion culler would have a significant effect on frame rate.

Figure 5-1. Combined Effects of View Frustum and Occlusion Culling

Figure 5-1 illustrates how view frustum and occlusion culling work together to greatly reduce the amount of geometry that needs to be rendered. This is the first step in high-fidelity, large-model visualization.

You can run the occlusion culler on multiple processes, and you can choose the number of processes. Even on a single-processor machine, you may benefit from using multiple processes because the host can cull while the OpenGL process is blocked, waiting for the graphics FIFO to unclog.

Occlusion Culling and Pipeline Load Balancing

If you set opDrawAction::setVFCullMode to true, the occlusion culler performs view frustum culling before occlusion culling. As a result, all view frustum performance characteristics also apply to occlusion culling.

If the time required for occlusion culling is greater than the rendering time saved, culling only moves a bottleneck to the host and increases the processing time of the graphics pipeline. If occlusion culling takes less time than drawing, you can use the extra time to eliminate more triangles from a scene graph, thus further reducing the load on the graphics hardware and shifting the balance of tasks in the graphics pipeline.

---

Note: You get lower-quality culling if a scene occupies only a portion of the total z-range of the depth buffer. For the best precision, set the z-clipping tightly around your scene.

---

Spatialization to Balance Pipeline Load When Occlusion Culling

You can adjust the execution times of the host and the graphics hardware by controlling the number of triangles in each csGeoSet (see Chapter 6, “Organizing the Scene Graph Spatially”).

• Coarser granularities, which are characterized by a few large csGeoSets, make culling run faster at the risk of drawing more occluded geometry.

• Finer granularities give more precise culling at the cost of extra culling time.

The culler uses bounding boxes to determine whether a csGeoSet is occluded. Although it may increase the time spent culling, creating smaller csGeoSets with tighter bounding boxes may have a particularly dramatic impact on graphics hardware processing. For example, in many tightly-packed mechanical assemblies, the corner of a bounding box may be visible, even though its enclosed csGeoSet is fully occluded. In that case, the graphics hardware is engaged in an unproductive rendering task. In summary, long csGeoSets are bad, small rectangular ones are good.

Changing the Fraction of the Bounding Box Required for Elimination

You can dynamically shift the load between the host and the OpenGL pipeline by varying the fraction of a bounding box that must be occluded before it is eliminated from the pipeline: thus you can create a closed-loop frame rate control mechanism.

The class opDrawAction is a csDrawAction that allows you to traverse a scene graph and draw the scene with occlusion culling, view-frustum culling, or both. You can also set the background color for the scene by specifying RGBA values.

To draw with an opDrawAction, follow these steps:

If the scene graph is modified while occlusion culling is enabled, the method opDrawAction::reset() must be called after the scene graph modification.

class opDrawAction : public csDrawAction
{
public:
opDrawAction( int nProcs=1,opBool computeStats=false);
virtual ~opDrawAction();

// Drawing the scene 
virtual void setScene ( csNode* node);
virtual void initializeScene ( );
virtual csTravDirective apply ( csNode* node);
virtual void postDraw ( );
//Accessor functions 
csNode* getScene ( );
void setLights (int nLights, csLight** lights);
void setWindowSize (int width, int height);
void setConservativeMode (opBool enabled=1);
void setVFCullMode (opBool enabled=1);
void setOCCullMode (opBool enabled=1);
void setDrawCulledMode (opBool enabled=1);
void setBPCullMode (csDrawAction::BpcModeEnum bpcMode);
int getVFShapesCount ();
int getVFTrisCount ();
int getShapesDrawnCount ();
int getTrisDrawnCount ();
void setClearColor (const csVec4f& c);
void getClearColor ( csVec4f& c);
};

To use the occlusion-culling algorithm in a rendering application, you can register an opOccDrawImpl in an opViewer. An example appears inAppendix C, “opviewer Sample Application.”

The class opOccDrawImpl is an opDrawImpl, which is the base class for drawing implementations discussed in “Controlling Rendering: opKeyCallback and opDrawImpl”.

opOccDrawImpl defines key bindings that control its rendering options in an opViewer application, and that allow you to record a sequence of control operations so that you can save a “tour” of a scene.

opOccDrawImpl uses opDrawAction to render the scene in an opViewer application.

Class Declaration for opOccDrawImpl

The class has the following main methods

class opOccDrawImpl : public opDrawImpl
{
public:
opOccDrawImpl(opViewer *viewer,int nProcs = 2);
~opOccDrawImpl();

virtual void draw(unsigned frame);
virtual void activated();
virtual void deactivated();
virtual void reset();

static opBool keyHandler(opDrawImpl *,int);

void setConservativeMode(opBool enabled);
void setDrawCulledMode(opBool enabled);
void setOCullMode(opBool enabled);
void setVFCullMode(opBool enabled);

opBool getConservativeMode() const;
opBool getDrawCulledMode() const;
opBool getOCullMode() const;
opBool getVFCullMode() const;

int  loadRecording(const char *filename);
void saveRecording(const char *filename);
void beginRecording();
int  endRecording();
void playback(opViewer *viewer, void *userData);
};

The central concern for tuning occlusion culling is load balance. The goal is to avoid bottlenecks, see “Bottlenecks in the Pipeline”. Some tuning controls are the number of processors, the size of the csGeoSets, spatialization, and the z-resolution of the framebuffer. Because every database is different, you have to measure performance to identify bottlenecks. An iterative process of measuring performance, adjusting tuning parameters, and measuring performance again is usually appropriate. The sections below describe some common problems and their likely causes:

Level-of-detail nodes are useful for adjusting the number of vertices associated with any given object. In some cases, however, it is most appropriate not to render objects below a certain size. The methods of opDetailSimplify allow you to remove geometry from csShapes that are “small.” Small is determined by a threshold for the ratio of shape size to overall scene graph size, calculated from the radii of their respective bounding spheres. You can explicitly set the large-scale dimension and thus have more direct control over which objects are culled.

Small csShape nodes are not removed from the graph; the scene graph structure remains the same. You can therefore use as an LOD a scene graph that has been detail simplified.

class opDetailSimplify
{
public:
opDetailSimplify (void) 
~opDetailSimplify (void) 

// --- ratio of shape size to overall size
void  setSizeRatio (float ratio)    
float getSizeRatio ()               

// --- detail cull scene graph below root
void  apply (csNode *root);
void  setRootRadius(float radius)
};

Typically, triangles should not be rendered when their front sides do not face the viewpoint. Such pieces of a surface are called back faces. Figure 5-2 illustrates the back faces of an open and a capped cylinder: the back faces are those for which the normals point away from the viewpoint.

Back-face culling keeps these triangles from being rasterized, thus saving on pixel fill time. Because the cull operation depends on the orientation of the triangles relative to the viewer, back-face culling occurs in the graphics pipeline after the transform stage: only rasterization and display stages are affected.

It is not always appropriate to cull back faces. If a surface has any holes, you should render the back faces because they may be visible through the holes at certain viewing angles. For example, if you can see into a pipe, render the pipe's back face. Figure 5-2 illustrates this point by showing the effects of back-face culling on an open and a capped cylinder.

Figure 5-2. Back Faces, Back-Face Culling, and Two-Sided Lighting Effects

Occasionally surface normals are inconsistent or inappropriate. For example, the normals to a car body part might point towards the interior. Rather than maintain consistent normals, many CAD applications ignore sidedness of surfaces and light scenes with two-sided lighting: the front and back sides of triangles are made renderable that way. To make this work, materials must be set to be two-sided. The right-most panel in Figure 5-2 illustrates the effect.

Two-sided lighting is inefficient for two reasons:

An OpenGL Optimizer tool that accommodates inconsistent normals and gives faster rendering than two lights is the Gaussian light reflection map, discussed in “Gaussian Map”.