OFP Forum, OFP Home, OFP File Formats, OFP Tools, OFP Missions, OFP 3D Modeling, OFP Terrain

Operation Flashpoint (OFP) aka ArmA: Cold War Assault (CWA)

To help understand the contents of the file format, a brief idea of what animations are, is in order. An animation takes a collection of p3d files (picture-3d files) and displays them all-at-once as a 'frame'.

Any given p3d consists of say, a head, an arm, a leg, a foot. Together, they make up the the total view, the 'frame'. Each of these pictures which make up the frame, contain information on how to display that picture. Eg, it's orientation. As such, the specific p3d and the specific information about that p3d is termed a component.

Components, make up a frame.

Each frame (a collection of pictures, a collection of 'components') also contains a single value of how long to display that frame until moving to the next frame (if any). ALL frames contain the exact same pictures but with differing orientations.

And so:

Conventions

 byte = 1 char = 8 bits
 ulong = unsigned long, 4 bytes
 ushort= unsigned short 2 bytes
 asciiz= variable length zero terminated string.
 float= 4byte (single precision)

 struct RtmFile
 {
  byte Signature[8]; // "RTM_0101" note. This is not asciiz
  float Vertex[3];   // Total Moving XZY at 0,0,0 'soldier' runs in same spot.
  ulong TotalFrames;  // Self Explanatory?
  ulong nPictures;    // (Number of) Pictures in any frame. All have same amount.
  Asciiz P3dNames[nPictures][32]; // Asciiz filenames of p3d picture files.
                                  // All, in fixed 32 byte records
                                  // The .p3d extension is default (not stored)
  struct Frame1
  (
   float FrameTime; // Values 0.0 to 1.0
   /* Represents a percentage of 'time' relative to the ''total'' time taken to display all frames.
   ** The overall time is ''not'' indicated in the rtm. External sources cause the 'frames' to move
   ** fast, or slow, or whatever. See note4 below
   */
    struct Component1
    {
     asciiz P3dName[32];     //Identical to the same name in the list above
                             //(and in same relative order)
     float  Transform[4][3]; //The orientation of the model. See note1 below.
    };
    .....
    ComonentLast{...};  // as per the nPicture value above
  };
  more Frames{...};
  FrameLast{..}         // as per the nTotalFrames value above
 };

Note1 Transform[4][3]

This is the transform matrix used directly by Microsoft DirectX engines.

In fact, the 'correct' matrix is actually 4 x 4, but the last column always represents 0,0,0,1 thus

 M11,M12 M13 (0.0)
 M21,M22,M23 (0.0)
 M31,M32,M33 (0.0)
 M41,M42,M43 (1.0)

and so is never stored.

This identical matrix is used for WRP files (both formats) and RTM files.

The last row (M41…) happens to be the position of the object X Z Y co-ordinates, and is often referred to separately.

For further information visit

Microsoft page

Note2

The exact same number of Components is specified inside every Frame, as per the initial p3d list in exactly the same order. In effect, naming the p3d file again, in every component, in every frame is redundant.

Note3

The number of frames (and components in each frame) extend to the end of file. There is no checksum or end of file signature.

Note4 Frametime

This is one of those paramaters that are easy to understand, and difficult to explain.

The value represents percentage of the expiry time for the entire frameset.

Given ten frames, all of which you want displayed for the same amount of time. the frametime value would progress, 0,0.1,0.2,0.3 etc, not, as would be intuitive, 0.1,0.1,0.1,0.1………