Occlude Object Physics

    There is a demo blend-file to exemplify some concepts:

    • A messed-up, subdivided Cube named "Cube".
    • Another one behind a "Physics Type: Occlude" plane, named "Cube.BG".

    • Another one outside the view Frustum, named "Cube.OffCamera".Now observe what happens to the profiling stats for each of the following (in order):

    • Delete the "Cube.OffCamera" object above,and notice that there is no improvement in speed.This is the view frustum culling working for you — it does not matter if that object exists or not.
    • Hit Z to view wireframe. Notice that in the 3D View you can see "Cube.BG",but once you press P, it is not there.
    • Make the "Occluder" object take up the whole camera's view with S X 5.You will see a huge leap in frame rate,since almost nothing is being Rasterized. On my system the Rasterizer step drops to 5ms.
    • Try a run with World properties ‣ Physics ‣ Occlusion Culling disabled.It will be slow again.
    • Reenable World properties ‣ Physics ‣ Occlusion Cullingand run it one more time to prove to yourself that your speed is back.
    • Change it back to "Physics Type: Occlude".
    • Now make the "Occluder" invisible. The frame rate is back down to its original, slow rate.

    As far as Physics is concerned, this type is equivalent to Rigid Object "No collision".The reason why the Occluder mode is mutually exclusive with other physics mode isto emphasize the fact that occluders should be specifically designed forthat purpose and not every mesh should be an occluder.However, you can enable the Occlusion capability on physics objects using Python and Logic bricks.See (Link- TODO).

    The resolution of the Z-depth buffer is controllable in the World settings withthe "Occlusion Culling Resolution" button:

    By default the resolution is 128 pixels for the largest dimension of the viewportwhile the resolution of the other dimension is set proportionally.Although 128 is a very low resolution, it is sufficient for the purpose of culling.The resolution can be increased to maximum 1024 but at great CPU expense.

    The BGE traverses the DBVT (Dynamic Bounding Volume Tree)and for each node checks if it is entirely hidden by the occluders and if so, culls the node(and all the objects it contains).

    To further optimize the feature, the BGE builds and uses the Z-depth buffer onlywhen at least one occluder is in the view frustum.Until then, there is no performance decrease compared to regular view frustum culling.

    Recommendations

    There are situations where occlusion culling will not bring any benefit:

    • If the occluders are small and do not hide many objects.

    In that case, occlusion culling is just dragging your CPU down.

    • If the occluders are large but hides simple objects.

    In that case, you are better off sending the objects to the GPU.

    • If the occluders are large and hides many complex objects but in a very predictable way.

    Example: a house full of complex objects. Although occlusion culling will perform well in this case,you will get better performance by implementing a specific logic that hides/unhides the objects;for instance making the objects visible only when the camera enters the house.