The output of the Umbra 3 Optimizer algorithm can be manually tuned by choosing appropriate values for the computation parameters. When omitted, the Optimizer will use a set of reasonable default values but as these parameters represent non-trivial aspects both of the input scene and of the desired output it is advisable to study the influence of modifying the parameters to the output data and the culling result. The parameter values always correspond to the unit scale of the scene so the same parameters will not work for scenes where the scale is different. So if for instance your scene is in centimeters instead of meters, you should input a parameter that corresponds to 3 meters as 300.

The computation parameters are defined by creating an Umbra::ComputationParams object and calling Umbra::ComputationParams::setParam() to specify the individual parameters. The utility function Umbra::ComputationParams::getParamLimits() can be used to get a range of reasonable parameter values for the given input scene.

The two most important parameters that deal with the size or scale of elements in the input geometry are:

- Smallest hole size (Umbra::ComputationParams::SMALLEST_HOLE)
- Smallest occluder size (Umbra::ComputationParams::SMALLEST_OCCLUDER)

Additionally the back-face limit parameter (Umbra::ComputationParams::BACKFACE_LIMIT) describes the scale-independent degree of closedness of occluder models.

Smallest hole size

The "smallest hole" is, as the name suggest, the smallest hole in the geometry through which the camera is supposed to see. The single float value of the parameter represents the diameter of the imaginary smallest hole, i.e. the maximum extent of a 3D object that fits through the hole.

If there is a hole in occluding geometry smaller than the smallest hole parameter, it is considered to be solid and any objects behind it may be culled away. Finding a small enough value for the smallest hole size parameter is therefore essential for correct culling results.

**How smallest hole affects visibility. The orange line represents the smallest hole computation parameter. In the upper picture the smallest hole is larger than the hole in the wall and the sphere behind the wall is culled away. In the bottom picture the computation has been done with smallest hole that is smaller than the hole in the wall and the sphere is determined to be visible from the other side of the wall.**

The trade-off is that a smaller smallest hole size parameter will increase the computation time and computation memory footprint. Very broadly speaking, halving the smallest hole size will result in up to 8 times more work in the phase of the algorithm that establishes connectivity relations in the scene. Note, however, that the value of the smallest hole parameter has no direct impact on the output data size or the runtime culling performance.

A reasonable smallest hole size filters out unintentional gaps in the models that would otherwise leak visibility through unexpected places. The Umbra 3 runtime visualizations can be used to find these kinds of leaks. When leaks are found that are caused by gaps in the geometry larger than the intended smallest hole, the only viable option is to plug the holes in the geometry.

Sometimes a very small smallest hole is required only for a specific feature in the scene, for example for a grate or grille or a peephole in a door. As the smallest hole size is a scene wide setting capturing these individual holes might mean having to process the whole scene at the granularity of the individual element. The recommendation for these situations is to split the surrounding geometry into a sufficiently large separate object (if it's not already) and to mark that object as not an occluder, essentially inflating the hole(s) to a size larger than the smallest hole parameter. While this results in lost occlusion, typically the impact is not very severe: in the example of a grate the whole grate object is a very bad occluder in any case so it is better to not treat it as one.

Based on experience, for a scene modeled in the metric scale a reasonable starting point for the smallest hole is 10 centimeters. It may also be useful to define a separate larger smallest hole size to be used during quick prototyping for faster turnaround times.

Smallest occluder size

The "smallest occluder" parameter determines the granularity of the culling result. It roughly corresponds to the size of the initial volumes for which the Optimizer algorithm starts establishing connectivity information for. The visible effect of the parameter is that geometry features smaller than the smallest occluder size are not recognized as occluders. Thus, the smaller the smallest occluder size, the better the quality of the occlusion culling results in runtime.

The trade-off for better culling from a smaller "smallest occluder" value is increased output data size and slower computation. Indirectly a smaller "smallest occluder" value also affects runtime culling performance, as a better culling result requires processing more visibility data per frame.

Choosing a good value for the smallest occluder size parameter is one of the most important things for balancing the trade-off between quality and memory use. A reasonable starting point is to use the maximum extent of the model representing the observer, for example a human player model on a metric scale would result in a smallest occluder size of 2 meters.

### Back-face limit

The back-face limit parameter (interpreted as percentage from 0 to 100, and clamped to this range) describes the maximum percent of triangle back-faces that can be visible from a valid camera position, out of the total area of the triangles seen. This is used to optimize the camera location data structure to exclude locations that are enclosed by geometry (inside walls) or otherwise deemed as "outside". Refer to the Triangle Winding and Umbra 3 Optimizer article for further information on inside and outside volumes.

Note that when view volumes are in use all locations outside of the view volume bounding boxes are automatically outside and therefore need not be considered when choosing an appropriate back-face limit.

Decreasing the back-face limit means that larger parts of the scene can be classified as outside and will therefore result in smaller output data. The lower limit for the parameter value is the maximum percentage of back-faces seen over all valid camera locations. The result of a value that is too low is incorrect culling: a valid camera location is classified as outside, stripped from the output data and therefore the culling results represent that of a undefined location. Finding the optimal value for a scene usually requires some trial and error, a reasonable starting point is a value of 20. The Umbra 3 viewer back-face visualization mode helps in finding incorrect culling caused by a too low back-face limit.

## Comments

0 comments

Please sign in to leave a comment.