Occlusion Culling

Occlusion Culling

This article is an adaptation of a technical document from the development of Fallout 3. As such, it may contain some features or functionality not available in the retail release of Fallout 3, but is included here for education and posterity.

Purpose

The purpose of occlusion culling is to find geometry that has zero effect on the final render buffer because it is behind other geometry, and eliminate that geometry as early in the render process as possible to reduce wasted cpu and gpu time.

Occlusion Planes

Overview

An Occlusion plane is a surface created and placed in the editor. A computation is done every frame testing each multibound shape against each occlusion plane. If a multibound is occluded, it is not rendered.

Example

This example tries to show how this system would be applied to the cell ChevyChaseMetroEntrance (Found in DCworld01). Here we are working on two specific areas that have a lot of detail, they are blocked out in multibounds, drawn here in blue. Also, an occlusion surface (in green) has been added in the building to the right, as it can be used to block many objects behind it.

1st person view

In the overhead view below we can see how the view frustum (light blue) and occlusion frustum (yellow) overlap. The occlusion frustum is formed by projecting the occlusion surface out from the camera position.

top down overview

Both multibound shapes pass the frustum culling test, as they are both at least partially within the view frustum volume. Normally, this would mean that we would render all the contents of both of the multibounds. However, when doing testing the further multibound shape against the occlusion frustum volume, we determine that it is completely within the occluded space of our sample occlusion surface. Based on this we completely skip over that multibound and all its contents during geometry accumulation, removing them entirely from the rendering pipeline and saving a large amount of time.

Details

Computing occlusion

Multibounds take advantage of view frustum testing by building a frustum based on the camera and the occlusion surface to create a new occluded frustum volume. If a multibound is entirely within that volume it is occluded - as compared to if a multibound is entirely outside of the view frustum volume.

Since multibounds are 100% static and the camera only changes once per frame, we compute their occlusion before render accumulation begins - hopefully while other pre-rendering processing is being done in another thread (AI updates, non-player collision resolving, etc). Even if the contents of a multibound change, the visibility test remains the same and occlusion will correctly affect the new contents.

Usage

Because each occlusion surface must be tested against each multibound shape, we want to limit them to areas where they'll have the biggest impact. Level designers use the flow of the level and its varying detail level in order to place occlusion surfaces and multibounds to produce the most efficient occlusion. Too many or poorly placed occlusion surfaces and multibounds and the game will waste time doing unproductive calculations. Too few (or, again, poorly placed) and the game will waste time rendering geometry that doesn't affect the final render buffer.

TFC 2 Visualization Explanation

While in-game, entering 'TFC 2' in the console (~) will force the renderer to continue to render exactly what was visible at that frame - but will allow you to still move the camera around. Multibounds and occlusion planes become visible (along with other relevant debug geometry) and are color coded to help visualize the state of those systems.

A large light-blue pyramid is the view frustum, with some error since the front clipping plane is not actually shown.

Purple geometry shows either a frustum culled occlusion plane (dark purple, single quad), or a projected occlusion volume (lighter purple, frustum volume).

Frustum culled multibounds (outside of the camera's viewing volume) are dark blue.

Multibounds occluded by occlusion planes are dark red.

Multibounds that are visible and not occluded are green.

Portals and Rooms (PortalMultibounds)

Overview

To further refine the ability to define spaces and occluders, the GECK introduces more sophisticated spatial organization with portals/roombounds. Portal spaces are enclosed spaces which have very few visibility connections (portals) to other spaces. The portals can connect to other portal spaces, or can connect to the open, unbounded world.

When the camera is within a portal space, the system firsts tests any portals against the view frustum. If a portal is visible, the contents of the space it connects to are accumulated based on an intersection of the view frustum with the portals projected volume - this new volume becoming the new view frustum. If the connected space is a portal space, this process can repeat as necessary.

Examples

In these examples, space A has a single portal a which connects to space B. Space B also contains a (a two way portal), and also b, a portal to the unbounded world. For all these examples, the view point is within space A.

Portal a is within the view frustum so space B is accumulated and rendered with the projected volume of portal a intersected with the view frustum. Portal b is not within this view frustum, so this is as far as rendering proceeds. And below you can see the resulting frustums used for each room with BSCompoundFrustum.

---

This case is similar to that above, except that portal b is visible, so the unbounded world is accumulated using the projected volume of portal b intersected with the view frustum. And below you can see the resulting frustums used for each room with BSCompoundFrustum.

---

This illustrates how occlusion planes can interact with the portal system. In this situation, while both portal a and portal b are within the view frustum, portal a is occluded by an occlusion plane, so space B is never accumulated. Note that portal b is not actually occluded, but because portal a is occluded, we don't even need to test portal b, as none of its contents or those it connects to can possibly be visible.

Portal Debugging Systems

The GECK equivalent of TFC 4

In game

• TFC 2 and 3 will show you rooms and portals colored to indicate their visibility. (green visible, red not visible)
  • NOTE: This view is also available in the GECK by pressing the hotkey 3
  • NOTE: This does not work in New Vegas, unconfirmed in FO3

• TFC 4 will put an overhead view of the rooms in the upper right corner of the render window. The view frustum will show up blue, and rooms will be colored the same as TFC 2 and 3.
  • NOTE: This view is also available in the GECK by pressing the hotkey 4
  • NOTE: This does not work in New Vegas, unconfirmed in FO3

• Toggling wireframe (twf) and walking around should also give you a good indication of what items are visible when a room is hidden or rendered.
  • NOTE:This view is also available in the GECK by pressing the hotkey W

• MBC will disable all multibound and room/portal visibility calculations and render everything within the frustum.

By default, occlusion culling is disabled while using the GECK. The keyboard shortcuts 3 and 4, mentioned above, enable a preview of culling in the editor. Note that the view modes are not very useful in conjunction with each other.

This does not appear to be available or enabled in the consumer version of the GECK.