Selecting Which Sectors to Rebuild

When you have a terrain with multiple sectors, you always need to pass the triangles for all sectors in each run of the NavData generation system in order for those sectors to be stitchable at runtime. However, if the geometry has changed in only one sector, you may not want to re-build the NavData for the entire world, but rather just for the changed sector and the overlaps between the changed sector and its neighbors.

Likewise, in a production environment with collaborative workflow and asset versioning, it is likely that some NavData overlapping a particular sector will be locked. You need to be able to rebuild any sector given this constraint.

The Gameware Navigation data generation system fully supports these scenarios. If you use the API of the NavData generation system directly, you can easily configure which sectors should be re-generated, and which should be re-loaded only to take into account the geometry that overlaps the adjacent sectors. In this process, the Generator reads the input data for the unchanged sectors either directly from the .ClientInput created during the last generation run or by invoking the GeneratorInputProducer to feed the triangles for the sector.

Indicating which sectors to rebuild

For each GeneratorSector in the list maintained by the GeneratorInputOutput, you can set two flags to control the rebuild process:

GeneratorSector::m_buildMode indicates whether or not you want to rebuild the NavData for this particular sector.
GeneratorSector::m_inputSource indicates whether you intend to provide the geometry for this sector using your GeneratorInputProducer, or from the .ClientInput file generated in the previous generation run. If the terrain of a sector has not changed since the last time you generated NavData, you may be able to speed up your generation even further by using the .ClientInput file previously generated for it.

Typical workflow

A typical scenario for iterative rebuild is:

A list of all sectors in the game is defined.
This list is used to create a GeneratorInputOutput object that defines a full generation run on all sectors. This may be saved in a .GenIO file, which is shared among all the persons responsible for the various levels associated with these sectors.
Every person responsible for a particular sector can load this .GenIO file into a GeneratorInputOutput, and flag the sector he or she wants to rebuild as described in the previous section.
Having flagged the sector(s) to be rebuilt, and having write permission on the associated NavData and read permission on the input data of all the neighbor sectors, a generation can be launched using the modified GeneratorInputOutput.
A periodic full rebuild is performed on all sectors to ensure that the data for overlapping sectors is up to date. See the next section for details. This requires read-access to all the input files and write access to all the output .NavData files. Typically, this full rebuild can easily be integrated in an automatic nightly build framework.

Managing Overlap Data

The ability to rebuild individual sectors is primarily intended to allow level designers working within a defined sector of a larger terrain to always be capable of generating NavData for the areas under their control without modifying any neighboring sectors, so that their play-tests can always reflect the most recent changes to their own terrains.

However, in this scenario, areas of overlap with other sectors are not guaranteed to be kept up-to-date. Because the NavData for the areas of overlap may be kept in any one of the overlapping sectors, it is only guaranteed to be updated when you generate NavData for all overlapping sectors in the same generation run.

In order to ensure that your bots are always able to cross sector boundaries properly at runtime, you should always rebuild the NavData for all of your sectors together in a single generation run before using it in a production version of your game, or before doing any play-tests that involve sector boundaries.