3O Format

From ModdingWiki
Jump to navigation Jump to search
3O Format
Format type3D Model
Model typePolygon
Maximum number of polygons400
Maximum number of vertices938

The 3O Format is used by Chasm: The Rift to store most of the game's 3D objects, such as scenery and collectible items. Monsters and the player use the more complicated CAR Format instead.

! Figure out flags and animation. Animations seem to require a separate .ANI file to be associated with the object.

There aren't any headers, footers or "magic number" in this format. There are, however, some values sandwiched between the vertex and skin data that one might expect to appear in a header instead.

The data in the 3O is divided into three distinct sections, which appear at fixed positions in the file, and only the skin data is allowed to vary in length. Unused entries in the polygon and vertex arrays are generally filled with junk data.

Based on the amount of space alloted to the arrays, the upper limit of the format ought to be 938 vertices and 400 polygons.

Skins are always 64 pixels wide.

Offset Type Description
0x0000 Array Polygon array.
0x3200 Array Vertex array.
0x4800 UINT16LE Number of valid vertex entries.
0x4802 UINT16LE Number of valid polygon entries.
0x4804 UINT16LE Skin height
0x4806 64 × skin height array of UINT8 Skin image, each byte defines a pixel by palette index

Polygon definition

This format uses quads, rather than triangles. Each polygon uses 32 bytes.

Relative position Type Description
0x00 UINT16LE Index of first vertex
0x02 UINT16LE Index of second vertex
0x04 UINT16LE Index of third vertex
0x06 UINT16LE Index of fourth vertex
0x08 UINT16LE U coordinate of first vertex
0x0A UINT16LE V coordinate of first vertex
0x0C UINT16LE U coordinate of second vertex
0x0E UINT16LE V coordinate of second vertex
0x10 UINT16LE U coordinate of third vertex
0x12 UINT16LE V coordinate of third vertex
0x14 UINT16LE U coordinate of fourth vertex
0x16 UINT16LE V coordinate of fourth vertex
0x18 Four bytes ! Unknown, always zero? May be filler.
0x1C Byte ! Usually 0x01, but sometimes 0x02, 0x03 etc. May be a grouping mechanism of sorts? Changing the value doesn't seem to have an effect on non-animated objects.
0x1D UINT8 Bit properties.
  • bit 0: Draw from both sides (normally the back of the poly is invisible)
  • bit 1: ?
  • bit 2: Translucent poly
  • bit 3: Translucent poly (More visible than bit 2 version. Setting both seems to result in neither.)
  • bit 4: ? ! Seems like it might be set on objects that can block/be stood on, but toggling the bit doesn't affect them functioning as such.
  • bit 5: Invisible poly?
  • bit 6: Invisible poly?
  • bit 7: Invisible poly?

! What do the other bits do? What's the deal with the high bits making the poly invisible?

0x1E INT16LE Appears to be a UV mapping offset, value added to the V coordinates.

If this directs the mapping outside of the skin data, other data may appear on the model as a skin, causing a garbled appearance.

Vertex definition

Each vertex in the array uses 6 bytes. The first two coordinates position the vertex on the horizontal axes, while the third is the vertical position.

Relative position Type Description
0x00 INT16LE X coordinate (signed)
0x02 INT16LE Y coordinate (signed)
0x04 INT16LE Z coordinate (signed)

Early version

The Chasm Demo Test v1.02 (Entering Shadow Zone) uses an earlier version of the format. It is almost identical, but there are two important differences:

  • The polygon array reserves space for 300 polys (100 fewer than the full version). Vertex array therefore begins at 0x2580.
  • While not related to the 3O format per se, this version has a slightly different palette.

Therefore, it is possible to get a bare-bones readable conversion between the two formats by adding/truncating entries in the file's polygon array, but a GOOD conversion will also require fixing the skin graphic to account for the palette differences.