Exporting Content Chunks

The supplied content integration plugins support export in the form of 'content chunks'.
This is essentially a snapshot of markup associated with a block of content geometry, before PathEngine's 2D content processing is applied (i.e. before things like automatic building connections are resolved).
The content chunk will then be placed in the world at a later stage in the content pipeline, and connected together with other geometry to form a seamless set of ground surfaces.

What can be included in a content chunk?

Content chunks may contain arbitrary ground geometry, plus anchors and pinned shapes.
(Ground geometry is currently limited to a single object by the current set of plugins, but this restriction can be worked around by combining disjoint mesh parts together into a single content-platform object.)

Issues with deferred instantiation of markup

Because content chunk placement in the world is deferred, details about the positions and orientations at which the chunk will be placed are not known at the time of content chunk export.
And the exact final position of vertices in the geometry depends on approximation after things like scaling and rotation have been applied.
(This is not just an issue with PathEngine's integer coordinates, but is something that would also occur with floating point coordinates, although perhaps less often. With floating point coordinates issues can often arise when you come to represent geometry further out from the coordinate origin, and are less predictable and thus harder to resolve.)

To address this issue PathEngine offers the possibility to limit the possibilites for instantiation of content chunks, in particular by limiting rotation of the chunks to a fixed set of rotations, and by disallowing arbitrary scaling.
These limitations then enable the full set of possible placements of the chunk to be 'pre-validated' at the time of content chunk export.

Because limitations on things like scaling and rotation at content chunk instantiation are not always desirable, this is not enforced.
It is possible to choose, for each content process, whether or not to use restricted instantiation.
Where restricted instantiation can be used then this offers the advantage of early feedback about any validation errors.
(Where the limitations of restricting instantiation turn out to be a problem a good compromise is to use restricted instantiation by default, but then to offer world builders the option to turn off restrictions if necessary, on a case-by-case basis.)

If restricted instantiation is being used in a content process then this option should be turned on before content chunk export.

Rotational restrictions

Rotation of content chunks is always restricted to rotation around the z axis, since full 3D rotation of markup boundaries, and of things like pinned shapes, generally doesn't make sense.

When restricted instantiation is being used, content chunks can only be rotated to a fixed set of 64 orientations.
This means 5.625 degrees (360 / 64) between each possible orientation for the chunk, at placement time.

Two adjacent orientations of a content chunk, rotated about the axis shown in green

When restricted instantiation is not being used arbitrary floating point values may be used for the orientation angle.

Scaling restrictions

When restricted instantiation is being used, content chunks content chunk scaling is limited to integer scale value.
So content chunks can then be scaled to twice or three times the size on export, but not reduced in scale or scaled to non-integral values.

To make content chunk scaling practical, then, in the context of restricted instantiation, it is necessary to export content chunks at a reduced scale and then scale up on instantiation.
So, for example, content chunks could be exported at 1/10 scale, and then always scaled up, by default, with a scaling value of ten. This scaling value can then be modified, to 9, 11, and so on, to adjust the scale of the placed geometry.

The 'contentchunks' example, which can be found here, provides a worked example of this kind of scaling setup.

When restricted instantiation is not being used arbitrary floating point values may be used for content chunk scaling.

Declaring translation and scaling ranges

In order for range issues to be validated correctly at content chunk export it is necessary for maximum values for translation and scaling to be declared.
A 'translation range' declared a maximum value that may be used by horizontal coordinates of the content chunk origin at instantiation. (So, for example, a value of 100000 means that the content chunk may be instantiated at positions with X and Y coordinate in the range -100000 to 10000.)
A maximum scaling value declares the maximum scale that may be applied to the chunk on instantiation.

Information about the validation applied to each content chunk is saved out with the chunk, and warnings issued if content chunks are subsequently placed outside the declared ranges.

Further information

Additional information about working with content chunks can be found here, in the Programmers Guide.