Sectorizing the Terrain

In many projects, only a relatively small chunk of the terrain needs to be loaded at any given time during the course of the game. These chunks, or sectors, are swapped in and out of memory as needed—typically in response to the movements of player characters. The decision to use sectors, and how those sectors should be organized, is typically dictated by production workflows, gameplay design, and technical considerations of the sub-systems within your engine such as physics or rendering.

Approaches to sectorization

The NavData generation framework offers a highly flexible system for dealing with multiple sectors, designed to dovetail smoothly with typical production workflows and to be easy to handle at runtime.

Single-sector terrains

Using multiple sectors is not mandatory with Gameware Navigation. You can feel free to pass your whole terrain to the NavData generation system in one shot, and generate a single NavMesh that cover your whole terrain. However:

You may need a large amount of runtime memory to hold all the data. The memory size of the data grows quickly as the area it represents increases.
As your data set increases in size, the performance of the pathfinding framework may suffer, as it may end up exploring enormous numbers of vertices and edges. This is particularly true if you try to calculate a path to an unreachable destination, because all triangles in the NavMesh will necessarily be explored.

The NavData generated for single-sector terrains cannot be stitched automatically at runtime to any other NavData, even if the two sets of NavData overlap in 3D space.

User-defined sectors

In many projects, the desired boundaries between adjacent sectors are driven by gameplay—for example, when a player character crosses a certain boundary, the collision world and textures for the previous area are un-streamed, and those for the new area are streamed in. Sector boundaries may be also set by the division of labor between the artists and level designers working in parallel on the same terrain, where each works on a separate mesh or sub-level that are streamed in and out as coherent chunks during the course of the game at runtime.

In this situation, you will likely want your NavData sectors to follow approximately the same boundaries as the sectors or sub-levels that you use for your other kinds of data. This is transparently supported by the NavData generation tools, since the divisions between your sectors is explicitly defined by the way you pass the triangles in your terrain meshes to the Gameware Navigation system.

When you load adjacent sectors created in this way into memory at runtime, their NavData will be stitched together automatically wherever they overlap.

Creating sectors in the NavData generation tools

Each of the NavData generation tools handles sectorization slightly differently. By far, the API of the NavData generation framework offers the most flexible approach, but as always you can choose any tool that suits the needs of your production pipeline.

Sectors and the Navigation Lab

Currently, the Navigation Lab creates one sector for each .obj file.

However, if you load a .navgenproj file that contains a <sector> definition configured with multiple .obj files, the Navigation Lab will merge all the triangles in all of those input .obj files.

Sectors and the NavData generation API

When you use the API of the NavData generation system directly, you have total control over the sectorization of your terrain. You configure one GeneratorSectorConfig object for each sector, and add all of your sectors to the GeneratorInputOutput structure that you provide to the Generator.

Creating single-sector terrains: You can create a single-sector terrain by defining only one sector for the Generator, and feeding that sector with the full set of triangles in your entire terrain.
Creating multiple user-defined sectors: You can create multiple sectors whose boundaries and contents you set explicitly. You define each sector you want to create for the Generator separately, and feed each sector with only the triangles that should be considered part of that sector.

When the Generator creates the NavData, it automatically detects which sectors are adjacent to each other, handles their areas of overlap, and prepares the data for automatic stitching at runtime. In order for adjacent sectors to be stitched together at runtime, the triangles along their common boundary should be very close to each other or overlapping. See also Handling Sector Overlaps.