Wrp File Format - 8WVR

Introduction

The 8WVR.wrp file should be viewed as an intermediate file format and of little use to the community at large. 
The reason being it is not editable in Visitor directly (it is the product of exporting a .pew file) and the format is in an unoptimized state for use in the Real Virtuality game engine.

A wrp file is the 'world map' for the given island. The simplicity of the requirements for the map are very neatly exposed in the structure below.

A 'world' is a square dimension divided into equidistant grids. Each Cell of the grid is a uniform 50 meter square of the map surface (be it land, or sea). The overall size of the map is a fixed-in-concrete dimension of the number of grids and their uniform cell size.

All that is required within each of these cells are definitions of

• it's mean elevation (above or below sea level),
• the texture for it's surface.

The 'elevation' is clearly a mean, or average value, since chunks of cells don't suddenly jump 200 meters etc. Instead, the engine smooths the differences. Textures in arma can be very simple 'sea' or quite complex 'land terrain' and are represented in .rvmat files. Textures don't, of themselves, complicate the structure of a wrp file.

Provisions exist to alter the map to

• Non Square dimensions
• Separate grids for Textures versus Elevations.
• Something other than 50 meter cells.

Official BI maps have never used it. And I am unaware of any Oem map that does so.

The only other necessary component of a wrp file is to populate it with objects. Objects are models, and as such, any single model is represented by a p3d file. Naturally and of course, the same model (Pine tree) can be referred to multiple times. Each one is a unique Object from the perspective of the wrp file. P3d models can of course be quite complex, even to the point of being inter-active, eg opening doors, but again, of themselves, they do no complicate the structural arrangement of a wrp file. Objects are independent of the cell grid structure. They are placed on the map using their own dimensional space transform. For all the engine cares, the building could be upside down and buried 10 meters under the sea.

For the purposes of game play, and no other reason, each, identical pine tree has a unique 'ID' number. (as does every other object). A soldier is told to goto THAT pine tree (as opposed to any other). The IDvalue, while guaranteed to be unique, is highly arbitrary. Any alterations / additions / deletions to the map and it's objects will result in different numbers for some / most / all of the objects. This represents no problem with game commands using NearestObject() style functions that return the ID of relevance, but, missions relying on a specific building ID (eg) will mostly fail if the 'island' is revised. This has particular relevance to porting OFP islands into Arma.

Legend

• ushort: 16 bit unsigned short (2 bytes)
• ulong: 32 bit unsigned integer (4 bytes)
• float: 32 bit signed single precision floating point value (4 bytes)
• char: ascii character(s)

String

String
{
 ulong Length;
 char  ascii[Length];
}

This is a Basic or Pascal way of doing things. Unlike the more familiar Asciiz (null terminated) strings used in other file formats, here, speed is used to NOT calculate string length (or at least hunt the null char)

XYPair

XYPair
{
 ulong x,y;
}

File Format

• This file format is principally used with Armed Assault and a derivation of it was used for Elite.

8WVR

 8WVR
 {
   WRPHeader     Header
   float         Elevations   [TerrainGridSize.y][TerrainGridSize.x];
   ushort        MaterialIndex[TextureGridSize.y][TextureGridSize.x]; //zero based index into MaterialNames
   ulong         NoOfMaterials;
   MaterialName  MaterialNames[NoOfMaterials];
   Object        Objects[...];
}

• The 'Elevations' array is Cartesian mapped. It extends from Bottom-Left to Top-Right in Visitor;

• The Objects extend to end of file. There is no count as such.
• There is always at least one Object entry.
• The last, (and possibly only) entry, has no p3d filename associated with it. This is the 'default' object specifying the 'center' of the map.

WrpHeader

WrpHeader
{
  char    Filetype;        // "8WVR"
  XYPair  TextureGridSize; // 256 x 256 eg
  XYPair  TerrainGridSize; // ditto
  float   CellSize;        // generally 50.0 meters
}

This is a fairly traditional Header for all Wrp types (including "OPWRxx"). OFP Resistance first introduced the cell Grid dimensions : formely hardwired to 256. And this, Arma format, simply adds a small wrinkle of a cellGrid Size. Formerly set at 50 meters.

MaterialName

   MaterialName
   {
     Strings RvMatFileNames[...]; //[Length]:"SomePboPrefix\SomeIsland\data\layers\p_002-000_l02.rvmat" ... "\0x0000";
   }

Conceptually, these are lists of all the textures that are used by this 'world'. The MaterialIndex array indicates what type of textures (plural) should be used in any given cell. Ie any 50 meter chunk of the map. Thus, you should fully expect to see a lot of the same index value for 'sea' texture .

Endemic to all wrp formats: BI use concatenated Strings to express a series of rvmat files for the given cell. More than one rvmat file *could* be used per cell. In practice this never happens. However, the construct exists in all Wrp formats for it to be used.

In this wrp format, specifically 8WVR, BI use Length Strings rather than the more familiar Asciiz strings. The end result is the same. A zero length entry, is, the end of (this series of) concatenated rvmat files.

At best, there happens to be only one String per cell entry. That fact does not negate the construct.

Length:Ascii:AnotherLength....

To complicate the matter slightly, A zero value in the MaterialIndex array would indicate 'no rvmat' (no texture) for this cell. In practice, a zero never occurs for any cell (all cells have a texture) but the construct is there for it to happen.

To this end, the very first MaterialName entry is always null. There is no file associated with it, because it will never be accessed. For the first entry only then there is a single ulong length value (four bytes) == 0. All other entries contain a length , followed by a string, followed by a length of zero. The latter, meaning, no more rvmats for this cell.

• Note that file paths are *always* hard - wired to the (virtual) PrefixRoot\ directory. Like ArmA P3d files, there is NO, relative addressing.

Object

   Object 
   {
     float  TransformMatrix[4][3]; // standard directX transform matrix
     ulong  ObjectId;
     String P3dFileName[Length];   // "ca\buildings\ryb_domek.p3d"
   }

• The 'TransformMatrix' for a given object is a standard 4 x 3 transform matrix which when decomposed determines the objects x,z,y position, scale & orientation (NB: Special logic must be applied to decompose the orientation from a Matrix.).