PathEngine home previous: Constructing Mesh Federationsnext: Tile‑by‑tile Construction with the 3D Process
Contents, Programmers Guide, World Representation, Mesh Federations, Tile‑by‑tile Construction with the 2D Process

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:

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.


Documentation for PathEngine release 6.04 - Copyright © 2002-2024 PathEnginenext: Tile‑by‑tile Construction with the 3D Process