Version 0.2, by Michael Martin <mcmartin at sf dot net>
SVAF (Simple Vector Array Format) is a geometry model format, optimized for easy rendering in OpenGL. It represents various arrays usable by the OpenGL specification, and then specifies various basic geometries supported by OpenGL.
SVAF files fit the Interchange File Format (IFF) specification.
A full overview of IFF can be found at http://www.szonye.com/bradd/iff.html, but is mostly beyond the scope of this specification. The short form goes as follows:
An IFF file is made out of chunks. A chunk is a 4-byte identifier, followed by a 4-byte unsigned integer giving the length of the chunk contents, then the chunk contents itself. All values are big-endian.
(In this document, an underscore in a chunk identifier represents a space.)
The FORM chunk begins with a four-byte identifier for the type of the form, and then a series of chunks.
SVAF files are a single FORM chunk of type SVAF. Thus, the first 12 bytes will be:
46 4f 52 4d xx xx xx xx 53 56 41 46
Where "xx xx xx xx" is a big-endian integer corresponding to the file length, minus 8.
A SVAF file must contain the following chunks. These chunks may occur anywhere in the file, but they all must be present.
The PNTS chunk specifies all the vertices in the model. Each point is three single-precision floats representing x, y, and z coordinates.
Following the OpenGL system, the coordinate system is right-handed: positive x is right, positive y is up, and positive z is out.
The length of a PNTS chunk thus must be a multiple of 12.
The NRML chunk is formatted exactly like the PNTS chunk, and must be the same length. Each entry in the NRML chunk is also three single-precision floats, these giving the vertex normal for the corresponding point in the PNTS chunk.
Vectors in the NRML chunk need not be normalized, but none may be length zero.
The TXTR chunk specifies all the textures used in the model. It is optional -- a model that does not use textures need not include a TXTR chunk.
The TXTR chunk is composed of a series of texture sub-chunks. Each sub-chunk specifies a texture. The first sub-chunk specifies texture #1, the second texture #2, and so on.
The texture sub-chunks are specified as follows.
The contents of a PNG_ subchunk is an embedded PNG file.
The RGBA sub-chunk specifies an uncompressed texture. The structure looks as follows:
struct rgba_chunk {
u16 width, height;
struct { u8 r, g, b, a; } pixels[width * height];
}
The length of an RGBA subchunk is thus (width * height * 4) + 4. Pixels are specified left-to-right, top-to-bottom.
The contents of a TXID sub-chunk are not specified by the SVAF specification. The information within them is application specific, and is likely to be some kind of filename, generic resource identifier, or URI. An application that wishes to recycle texture data across models will likely use this subchunk to specify the texture.
Use of TXID subchunks will of course render a model non-self-contained and as such they should only be used with caution.
This concludes the TXTR sub-chunk definitions.
The UVXY chunk associates UV-style texture coordinates for each point in the model. If present, it must have the same number of entries as the PNTS and NRML chunks. Unlike those chunks, each point only uses two single-precision floats representing the u and v coordinates for the texture at that point.
The precise texture used is not specified in this chunk. Texture representation is specified by the BTEX command chunk.
At most one UVXY chunk may be present in a SVAF model. It is only necessary for models that include texture information.
This chunk type specifies bounding boxes for the model. If it is not present, the bounding box will be taken to simply be the smallest axis-aligned bounding box that can enclose the model.
The BBOX chunk is defined by a series of single-precision floating-point 6-tuples: (xmin, ymin, zmin, xmax, ymax, zmax). Each defines an axis-aligned bounding box.
The first box defined is a coarse bounding box; it should enclose all parts of the model with which collision is possible. Each successive box is a fine bounding box, which provides greater granularity for complex-shaped objects. The space enclosed by the fine bounding boxes is the volume that will be treated as the outline of the object for collision detection.
More precisely, a collision detection algorithm for SVAF models is as follows:
Command chunks translate directly to actual rendering commands. While not strictly mandatory, without any of polygon-based command chunks, the model will not represent anything, and without a MTRL chunk, color and lighting information will be undefined. (Implementations may define it: In particuar, engines that wish to support the 3D equivalent of a "palette-swap" are permitted to demand a lack of MTRL chunks.) A model that contains element chunks before a MTRL chunk will be non-self-contained.
The MTRL chunk specifies the "material" for lighting calculations. It is 52 bytes long, comprising 13 single-precision floats:
struct material {
float ambient_and_diffuse[4];
float specular[4];
float emissive[4];
float shininess;
}
Each set of four floats specifies, in order, the red, green, blue, and alpha components of the color.
All polygon chunks are lists of zero-based indices into the vertex array. These indices are all 2-byte unsigned integers. Each type of polygon specifies a different type of element, and corresponds exactly to one of OpenGL's geometric primitive modes.
Following the OpenGL default, all polygonal windings are counterclockwise.
This binds (selects) a texture for use in the model. It is two bytes long, and contains a 2-byte unsigned integer that lists which texture from the TXTR chunk to use. These are 1-indexed; binding texture #0 disables texturing entirely.
When textures are not disabled, the UV coordinates of each point are specified by the corresponding entry in the UVXY chunk.