|PathEngine home||previous: ||next: |
The 2D content process assumes a content chain based on geometry elements being constructed, independantly,
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.)
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 first step in the federation process is then to generate an iMeshFederation object,
Each tile mesh in the federation can then be built, independantly,
In order to determine an exact set of overlapping geometry, the tile represented region should be queried with
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.)
(The process assumes a single terrain layer, for which a terrain callback can be supplied at run-time. Refer to
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.
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.00 - Copyright © 2002-2016 PathEngine||next: |