The ShiVa3D realtime 3D engine has a default rendering optimization technique called Viewing Frustum Culling: objects outside the viewing frustum are left out of the rendering process, so less geometry results in higher framerates. This feature is switched on permanently and there is no option to disable it.

Another two useful ShiVa features for improving performance of geometry heavy games and 3D applications are Dynamic and Static Occlusion Culling. Both of them will further reduce the amount of geometry to render, namely those objects which entirely get behind occluder objects, from the viewpoint of the main camera.

To make use of these great features, first you need to designate some of the larger objects to be occluders. Choose objects which are placed in your 3D environment in such a way, that they are likely to hide many other smaller objects as the camera moves. The path to these settings is: Attributes Editor -> Shape Attributes -> Is a dynamic/static visibility occluder. Just take a look at the topmost image to see them in the Shiva Editor UI.

Next you need to tell Shiva which objects to check to determine if they are behind any occluders. Luckily, every object’s default setting is “Occludable”, so you rather need to unset just those you wish to leave out of the process.

Do not set too many objects having a lot of triangles to be dynamic occluders, as performance might drop due to constant frame-by-frame occlusion calculation. With the static version you won’t have such issue, because it is a precalculated solution which you need to perform once in the Ambience Editor -> Optimization -> PVS. Keep in mind that static really means static, do not use it for objects which may leave their original location.

Demonstration

When you set up occlusion, you normally don’t notice anything on the screen, except that you should have better frames per seconds (FPS). But if you are curious whether occlusion is really happening or not, how would you check it?

To create a simple demonstration for this, we took a quite old sample made by Stonetrip. This First Person Shooter game framework has a rather retro look, but serves well for our purpose. We added some extra fire-power, anti-gravity, a bunch of crates to occlude, and a couple monolithic occluders in the middle.
The main camera can be controlled by the arrow keys and the mouse, that’s what the main screenshow. We also have a top-down rendermap camera set to show most of the territory in a HUD element placed in the top left part of the viewport. That is the Minimap where you can check occlusion visually.

Performance

There is also a performance reporter tool included on the left side where you can check just how much FPS you gain when you don’t see all the objects in the scene. On our test hardware we saw FPS increase from a low 30 ( looking down from a high point in space) to a great 60 ( walking around in the middle).

Notes

- The top-down camera probably has its own Viewing Frustum Culling process, as it showed every object in the beginning. But if an object got occluded for the main camera, that object became invisible for the top-down camera, too, so occlusion seems to be of higher priority. To reproduce Viewing Frustum Culling of the main camera in the HUD, we forced every object using a Frustum Activation property and a script to become invisible when they get out of the frustum of the main camera.
- A similar “higher priority” case seems to happen for visibility distances, meaning an object’s visibility is checked based on its distance from the main camera, so even if the object is close to a rendermap camera, it will not be shown in the rendermap. We do not use visibilty distances in this demo.
- The sheer amount of falling crates will slow down the game in the beginning, but when they get settled in a resting situation, FPS will normalize.

News:

- The running demonstration used to exploit a bug that occluded objects for the main active camera were also hidden from the overview remdermap camera which otherwise would be able to see them. An update to the ShiVa3D engine caused things to work like they should, so the running demonstration is no longer demonstrating how occluders work. Occluders supposedly still work, just there is no way of checking them visually any more.