Performance Considerations

The time taken to complete the 3D content processing and memory load are very much dependant on the data passed in, and the parameters and options specified.

If you're experiencing long processing times, or significant memory load, then there are usually a number of things that can be done to improve the situation.

Using a timing progress callback object, i.e. one that logs progress reports with time stamps, is a good way to quickly get an idea about what is going on at the top level of the 3D processing operation, and which of the following optimisation points is likely to apply most to a given situation.

BSP process: Polygon soup is more expensive than solid data

BSP generation for polygon soup data can be very significantly more expensive then for an equivalent scene that is represented in solid form.

See Generating Convex Solids for some ways of generating suitable solid representations from a scene with a minimum amount of markup.

BSP process: Use collision geometry, if available

If you have a low detail representation of the objects in a scene (e.g. for 3D collision, or level of detail rendering) then use these instead of the full detail rendering geometry.
(Example code for building directly from some popular 3rd party physics engines can be found here).

BSP process: Reduce the complexity of the mesh source data

If you don't have a low detail representation then there are a number of tools available (both free and commercial) for generating low detail representation from high detail rendering geometry.
Note that, as far as PathEngine's 3D content processing is concerned, things like texture coordinates, lighting, and so on are not an issue, so this simplifies the geometry reduction problem.

BSP process: Exclude unreachable geometry

If there is a significant amount of geometry in a scene which will never be reached by pathfinding agents then it can be worth marking this geometry as excluded from PathEngine 3D content processing.

BSP process: Avoid expensive progress callbacks

When a progress callback is passed in, the update function for this callback can be called a large number of times, so it is important to ensure that this function is fast.

Timing 3D processing for the same source content data with and without the progress callback is a quick way to determine if this is an issue.

Voxel process: Voxel size

The key factor in processing times with the voxel process is voxel size.
Larger voxel sizes can mean significantly faster processing.
If you need to increase voxel size it is important to be aware that this can have the effect of closing things like narrow doorways in the ground mesh result.
One way to counter this can then be to also reduce the pathfinding agent shape used at run-time.

Voxel process: Subdivision

Subdividing large areas of ground can be a performance hog, in some situations, in particular where there are large ground areas to be processed.
If possible, ensure that the 'stripTerrainHeightDetail' is also being specified, and attributes for terrain regions are being specified correctly.

Memory

Processing large scenes can require a significant working set, and if the OS needs to start swapping to disk then this can start to slow things down significantly.
If you need to process large scenes then it's a good idea to ensure that the machines being used for the content processing have a decent amount of RAM.

Use tiled processing

Whenever large worlds need to be processed, splitting these up into tiles (with Tiled 3D Content Processing) will usually be a big performance gain.
This limits the maximum memory load to per tile complexity rather than whole world complexity, makes the process as a whole scale essentially linearly with respect to world size, and enables incremental and parallel per tile processing.

Convex solids with high vertex count

Wrapping scene elements is generally a good thing, particularly for the BSP processing, but in certain situations where very large numbers of vertices are being passed in for convex solid generation this part of the process can then potentially become a bottleneck, itself.

A good way to work around this issue (if this happens) is to pre-process point sets per object type, using iContentProcessing3D::buildHullMeshesForVisualisation(), and to then strip a reduced point set back out of the face vertex mesh object(s) generated by this method.
This basically gives you a minimal set of hull points that can be transformed around for individual placed object instance convex solid definitions, eliminating the need for any per-placed-object large point-set processing.