Software occlusion culling is often expensive, especially for smaller and older devices.

Is frustum culling alone adequate on systems that can optimally display 10k triangles at most?

If not, are there any relatively fast techniques for determining which objects (both moving and static) occlude others?

  • 1
    \$\begingroup\$ By the way, upon rereading your question, what console are we talking about? I've done a PSP game where only frustrum culling was used, but the type of game would be fairly important. In most cases (given 10000 as a limit) I'd say pure frustum culling is not enough as you get to 10000 polygons pretty fast in most types of game. \$\endgroup\$
    – Kaj
    Commented Aug 11, 2010 at 5:16
  • \$\begingroup\$ Mostly interested in the handheld consoles (Pandora, GP2X). The newer mobile phones have similar graphics performance. \$\endgroup\$
    – zmdat
    Commented Aug 11, 2010 at 11:55
  • \$\begingroup\$ Sure it is. As long as there are only 10k triangles in your frustum. \$\endgroup\$ Commented Nov 16, 2017 at 23:32

4 Answers 4


One thing to consider is what is the worst-case for your game design. If you're going to be able to go to the top of the hill and see all objects unoccluded at the same time, then an occlusion system will in fact be slowing the performance of your game in that scenario.

Another thing to consider is the consequences of not culling for your target platform and game:

  • If it is simply a drop in performance, then the performance drop may alrady be acceptable if you still have playable framerates. This is subjective and contingent upon your genre. A turn-based game can be acceptably played at lower frame rates than a fast-paced FPS might for example.
  • However, if a lack of culling means that you get polygon dropout then it's a different story. For example on the Nintendo DS, you can get visible artifacts where polygons simply disappear as you exceed your polygon budget.

The latter may necessitate changes to your level design or the inclusion of some polygon reduction technology.

I've had some success with these techniques for reducing polygons:

  • precomputed PVS with artist placed sectors for static geometry and with artist placed portals for culling dynamic objects, but then again our project had occlusion characteristics guaranteed by the game design (corridors and rooms with limited outdoor areas). If the camera is in a specific sector, then there will be a limited number of sectors visible from that sector. This means that only the static geometry and dynamic geometry in those sectors needs to be rendered. Of course this only works if your world geometry is amenable to natural occlusion characteristics.

  • A level of detail (LOD) system where we simply switched to an imposter/billboard for distant objects. In the cases that we did have lots of objects visible, this helped when some of those objects were guaranteed to be far enough from the camera to be rendered with a lower level of detail with no noticeable quality degradation. Imposters/LOD systems are a nice way to reduce polygon count if you don't hit the worst case where you have thousands of objects in the same room very close to the camera and all rendered at full detail.

  • Simply not drawing distant objects. The pop-out can be minimized by fading these objects out as they go further and then simply not drawing them when the alpha reaches zero. You can also tag these on a per object basis. eg. trees may be drawn at a further range than grass, but mountains would always be visible.


I would limit the amount you are doing at runtime. Precompute as much as possible - a PVS is a fairly standard techique for static geometry, and depending on your environment perhaps portals would work (these fairly easily cope with moving objects too).


It really depends on the problem space! If you drawing overhead because you are sending stuff through the pipeline that is occluded, and that overhead is too much, or if you get too much overdraw eating fillrate then you obviously need to investigate other culling methods (or optimizing your render pipeline or shaders). Whether that solves the problem depends on your implementation of the new culler, and the win you gain by not drawing the stuff.
If overdraw is an issue, the culler can be a win because you shift performance from the GPU to the CPU. If your pipeline is the bottleneck then it's basically whether your pipeline is too expensive.
BSP and portals seem obvious culling algorithms that are relatively cheap and reduce overdraw, but they're generally for indoor scenes. ABT or octrees can also alleviate overdraw at a cheap price. Most of them only optimize for static geo though (although you can cull some dynamics away using the knowledge it provides.
As an aside: if shader cost is the issue, make sure you are drawing back to front.


culling objects that are occluded from your view is generally worth it, especially on older GPUs with less dedicated memory (including all integrated chips) and less support for parallel processing pipelining.

This also includes console hardware, that is often more optimized for throughput and more exotic component capabilities, like some non-volatile ram properties, but in return less energy efficient and slower over all.

This older hardware benefits more from all the branches that come with more culling, as culling bounds are basically a bounding volume hierarchy.

Some culling methods benefit more from being less general, and more optimized towards special hardware limits. In return they scale significantly worse, can perform horrible for higher resolutions.

Culling is a good option, nearly essential at some point, for good performance and backwards compatibility and support for older hardware.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .