Integer Coordinates and Approximation

PathEngine works with integer representations of horizontal coordinates internally, and throughout the PathEngine API.
This offers some significant advantages over floating-point based approaches, enabling the implementation of robust geometric functionality with results independent of distance from origin, as well as helping to ensure repeatable execution across platforms.
(See Why Integer Coordinates? for more discussion of this issue.)

The implications of this choice for content creators are two-fold:
First of all, it is important to be aware that geometry is approximated to an integer grid.
Secondly, PathEngine supports geometry across a fixed coordinate range, with validation errors being emitted for geometry outside this range (see this page for details).

Because PathEngine works in terms of integer coordinates, the choice of units for these coordinates is a key issue.
A small unit offers more precision, but reduces the range (in real distances) that can be representated.
A larger unit increases the range that can be represented, but at the cost of precision.

As an example, consider a choice of a 1 centimetre unit for PathEngine coordinates. Because PathEngine supports geometry in the range -1500000 to 1500000, this gives you a range of 30 kilometre, with the geometry within that range being approximated to points on a 1cm grid before export.
In contrast, a 1 millimetre unit results in a range of 3 kilometres, but with a finer grid.

Using different units for PathEngine coordinates and application world coordinates

It's not necessary for the unit for PathEngine coordinates to be the same as the unit for general application side world coordinates.
If range or precision requirements are tight then choosing a PathEngine coordinates unit independently gives you more flexibility with respect to these requirements.

The coordinate unit used within content applications will usually be the same as the world coordinate unit used by the application run-time.
The PathEngine content exporters allow you to specify a scale factor, which will be applied to geometry before export, to effectively convert from this world coordinate scale to the scale implied by the unit chosen for PathEngine coordinates.
As an example, if the base coordinate unit within a content application is 1 metre, and a PathEngine coordinate unit of 1 centimetre is desired, this scale should be set to a value of 10.

For consistency, geometry is also divided by the same scale factor on import.

Breaking out of coordinate range constraints for very large worlds

When working with very large worlds PathEngine's 'mesh federation' tiling mechanism enables issues with total coordinate range to be avoided by using local coordinates for each 'mesh federation tile'.

Validation and the 3D content process

As with the rest of the Content Creatror's Guide, these issues relate mostly to the 2D content process.
The 3D content process is designed to process completely arbitrary geometry, and the only validation constraint for that process is the coordinate range constraint.
(Some issues, such as awareness about the approximation to an integer grid are also relevant for 3D processing.)

Errors introduced by approximation

It's important to be aware that the approximation to integer coordinates (in the 2D content processing pipeline) can introduce errors that are not necessarily apparent in the source geometry.
In particular, approximation of the vertices of sliver triangles can result in those triangles becoming zero area, or downward facing.

If you get these kinds of errors for geometry that looks ok, then there are two things that can be done to check if scaling is the cause.

First of all, try increasing the value of the scale factor and re-exporting.
If the error goes away then this is a good indication that the error is being caused by approximation.
(Make sure to perform this test export to a temporary directory, and don't forget to set the scale back afterwards, to avoid badly scaled assets gettings sent down the content pipeline!)

Secondly, to see exactly what is going wrong, export the geometry as a 'source content snapshot', and then reimport.
This shows you exactly what the geometry looks like after approximation, but before any of PathEngine's content processing functionality has been applied.
(See Source Content Snapshots for more information.)