Tile-by-tile Construction with the 2D Process

The 2D content process assumes a content chain based on geometry elements being constructed, independently, with instances of these geometry elements then placed into the world (usually in a custom world editor).
The process then provides a terrain that extends to the world boundaries, with the possibility for geometry elements to be placed on this terrain, and to obstruct and connect to the terrain surface and to each other.

Under this content process, each geometry element that has some effect on pathfinding and agent movement should be markup up in PathEngine's 'content chunk' format.
This markup can be generated directly through API calls, or saved out by one of PathEngine's exporters.
(Refer to this page for more details about content chunks.)

Unique IDs per geometry 'chunk'

Tile-by-tile generation under this process then requires that each marked up geometry element is assigned a unique integer ID.
(There are various ways to ensure this, with the simplest being to store a global counter that is assigned to each building that is placed, and then incremented.)

The federation construction process

The first step in the federation process is then to generate an iMeshFederation object, using iPathEngine::buildMeshFederation_TilingOnly(), to encapsulate the world bounds, and also the tiling to be applied by the federation over those world bounds.

Each tile mesh in the federation can then be built, independently, using iMeshFederation::buildTileMeshFromContent(), with a set of content chunk instances corresponding to the set of geometry objects for which markup overlaps the represented region of the tile to be built.
In order to determine an exact set of overlapping geometry, the tile represented region should be queried with iMeshFederation::getRepresentedRegion_World(), and the markup bounds for each geometry element should be queried with iContentChunkInstance::getHorizontalRange().

Each content chunk instance created here should have the 'sectionID' parameter at instantiation set to the unique ID of geometry element marked up by that chunk.
(PathEngine will then use this ID for fast and robust translation across federation tiles.)

iMeshFederation::buildTileMeshFromContent() will generate terrain stand-in geometry for the tile, so terrain geometry should not be passed in explicitly.
(The process assumes a single terrain layer, for which a terrain callback can be supplied at run-time. Refer to Working with Terrain for more details about terrain callbacks.)

For performance the horizontal bounds for each placed geometry element should usually be computed when the element is placed into the world, and then stored in some kind of data structure which then supports fast lookup of elements by horizontal range.
(One straightforward way to handle this is by dividing the world up with another regular tiling, perhaps with a file for each tile that stores a list of elements with markup overlapping that tile.)

As soon as tile meshes have been generated they are ready for pathfinding.
Is is also possible to pathfind across an incomplete federation, as long as agents don't need to translate to tiles that haven't yet been generated.

Source content limitations

The iMeshFederation::buildTileMeshFromContent() method performs essentially the same 2D content processing as iPathEngine::buildMeshFromContent(), but with the following additional restrictions:

• The sectionID face attribute must be set to a unique ID for each instanced content chunk, and therefore cannot be used for other purposes.
• Terrain stand-in geometry is generated by the process, and cannot be defined explicitly. (Obstacles for things like submerged areas or steep slopes should be added, after tile mesh generation, in the form of placed shapes.)
• Only 'terrain portals' are supported for building entrance connections (i.e. buildings cannot be placed inside other buildings).
• The content processing options for filtering steep faces or optimising external edges are not currently supported when building tile meshes.
• Edge to edge connections must be managed 'explicitly' (see below).

Edge to edge connections

The tile by tile process requires that edge to edge connections are matched 'explicitly', prior to building the tile meshes, in order to ensure that geometry matches exactly either side of an overlap between adjacent tiles.

This could be done at the same time as each geometry element is placed into the world, perhaps with the possibility to 'snap' geometry element to ensure that they connect correctly.

However this is handled, it is the client application's responsibility to ensure that connections are set up in exactly the same way for a given content chunk instance for all of the tile meshes in which that instance is included.