This tutorial demonstrates how to perform hadware accelerated occlusion culling using the OpenGL extension GL_ARB_occlusion_query.
For more information about the OpenGL extension GL_ARB_occlusion_query see also http://oss.sgi.com/projects/ogl-sample/registry/ARB/occlusion_query.txt
| Sample Foreset Model (1681 trees) - Benchmark on NVIDIA GeForce 8600M GT, Intel Core 2 Duo 2.0GHz | |||
|---|---|---|---|
| 
| 
| 
|
Large occluder in red:
| View of the forest from above:
| View from under, the ground is a very good occluder:
| View of the forest from inside:
|
When rendering highly detailed and densely populated scenes most of the rendered geometry is actually hidden by the other objects and geometry which are closer to the camera. This means that a consistent part the GPU time and computational power is spent to render objects that will not be visible in the final rendering. Consider for example a dense forest with thousands of trees. The trees that are close to the camera will have a high chance to be visible but the ones that are far away from the camera will probably not be visible due to the fact that the close ones occlude a significant part of the view. The term "occlusion culling" refers to a set of techniques that try to exploit this fact. By detecting in advance which objects will be occluded and thus invisible, we can avoid rendering objects that will not significantly contribute to the scene, potentially obtaining a dramatic rendering boost as seen from the figures above.
- Drawbacks
The OpenGL extension GL_ARB_occlusion_query allows a program to request if a given object will contribute or not to the final rendering providing a huge potential in terms of rendering performances increase as we have seen. Unfortunately this technique has also some drawbacks due to the way the GPU and CPU collaborate, the most important being the fact that once you requested this occlusion visibility check, the OpenGL driver cannot reply before having executed all the OpenGL commands that precede such request. For this reason in order to maximize the CPU/GPU concurrency (and with it the rendering performances) Visualization Library waits one rendering frame before checking the result of the occlusion queries. This means that at any given frame the result of such query actually refers to the position that the camera and the objects had relative to each other in the previous frame. As a result of this occasional flickers might occur when an invisible object becomes visible especially when the camera or such object is moving fast compared to the rendering refresh rate. An example of such problem is shown below.
In the image above the camera is quickly moving to the left uncovering a part of the trees that in the preceding frame were covered by the red occluder. Such trees weren't visible in the previous frame and are thus not rendered in the current frame producing a temporary "hole" in the forest. Note that such "hole" lasts for a single rendering frame but potentially new holes might occur while the camera continues its movement.
Artifacts like this might be more or less noticeable based on the kind of scene rendered and based on the refresh rate of the rendering. For example, it is very easy to notice this effect at 10 fps, but is much more difficult if not impossible to notice them at let say 160 fps.
Note that requesting the result of an occlusion query in the same frame in which it is issued is not an option as this would not only kill the GPU/CPU concurrency but would also cause a vicious cpu-stall/gpu-starvation circle that would result in unacceptable performances even for simple scenes.
- Enabling Occlusion Culling
Exploiting the huge potential of OpenGL accelerated occlusion culling with Visualization Library is extremely simple. From vesion 2010.10.1115 VL implements a new occlusion culling mechanism which is much more general and efficient than the previous one. The user no longer has to install a specific render token sorter, pay attention to render rank and render blocks, evaluate large occluders etc. because VL will simply use the whole z-buffer of the preceding rendering to occlude contents of the next one! The new vl::OcclusionCullRenderer class implement an occlusion culling strategy that filters out the objects rendered by a specific vl::Renderer, the usage of the vl::OcclusionCullRenderer class is shown in the example below.
[From App_OcclusionCulling.cpp]