\chapter{Height Field Files}

This appendix describes the format of the files that store data
for the height field primitive.
The format is an historical relic; a better format is needed.

Height field data is stored in binary form.
The first record in the file is a
32-bit integer giving the square root of number of data
points in the file.
We'll call this number
the size of the height field.

The size is
followed by altitude ($z$) values stored as 32-bit
floating point values.  The 0th value in the file specifies the $z$
coordinate
of the lower-left corner of the height field (0, 0).
The next
specifies the Z coordinate for $(1/(size-1), 0)$.  The last specifies the
coordinate for $(1., 1.)$.  In other words, the $i^{th}$ value 
in the heightfield file specifies the $z$ coordinate for the point
whose $x$ coordinate is
$(i \% size) / (size -1)$, and whose
$y$ coordinate is $(i / size) / (size -1)$.
Non-square height fields may be rendered by specifying altitude values
less than or equal to the magic value
$-1000$.  Triangles that have any vertex less than
or equal in altitude to this value are not rendered.

While this file format is compact, it sacrifices portability for
ease of use.  While creating and handling height field files is
simple, transporting a height field from one machine to another
is problematical due to the fact that differences in byte order
and floating-point format between machines is not taken into
account.

These problems could be circumvented by writing the height field file
in a fixed-point format, taking care to write the bytes that
encode a given value in a consistent way from machine to machine.
An even better idea would be to write a set of tools for
manipulating arbitrary 2D arrays of floating-point values in a compact,
portable way, allowing for comments and the like in the file\ldots
