DSF Raster Data RFC
From X-Plane Wiki
This page contains a Request For Comment (RFC). RFCs are posted to facilitate discussion of possible features; an RFC does not mean that the feature will be implemented, or that the feature will be implemented exactly as specified in the RFC! Do not assume an RFC will be implemented; do not create and post content that uses extensions proposed in the RFC. Wait for the final specification before creating airplanes and models!
2/20/2012 - Update 2/19/2011 - Initial Revision
Status: implemented in X-Plane 10.0
This is a proposal for raster data to be directly encodeable in a DSF file.
Traditionally, per-entity parameters are encoded on the various geometric parts of a DSF, e.g. triangle vertices, object,s etc.
However, sometimes it may be desirable to encode low frequency data - in this case:
- Nearby building blocks like objects or roads would all have the same data (or data that could have been calculated by interpolation); per-block storage is not efficient.
- If the data is spatial in nature, separate blocks would have the same data, e.g. two objects next to a road would all have the same value; per-block storage means duplication.
This proposal would allow the DSF to contain one or more raster layers that would imply a low-frequency data set 'over' the entire DSF.
Proposed basic implementation:
- Each raster layer would live in its own one-plane 16-bit point pool. A corresponding scaling atom would help 'decode' the data.
- A string table atom in the definitions section would provide a master key from string-based raster layer definitions to the particular pool providing the data, using an in-order scheme.
- No new commands are introduced.