Wrp File Format - 8WVR

Disclaimer: This page describes internal undocumented structures of Bohemia Interactive software.

This page contains unofficial information.

Some usage of this information may constitute a violation of the rights of Bohemia Interactive and is in no way endorsed or recommended by Bohemia Interactive.
Bohemia Interactive is not willing to tolerate use of such tools if it contravenes any general licenses granted to end users of this community wiki or BI products.

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.
Note: Bohemia Interactive's .WRP is unrelated to 3D System's Geomagic .WRP file format.

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.

There are in fact only two components to a wrp.

• A cell grid of textures (alias materials, alias RvMat files) that 'texture' the surface of the world with hills, sea, land.
• A contiguous list of 'objects' (alias 'models', alias p3dFiles) that are placed on the map independently of the cells with pine trees, houses, etc.

All that is required within each of cell are definitions of

• The mean elevation (above or below sea level) of it is texture,
• And, the texture for it is surface.

The textures themselves are height independent. Meaning the same 'sand' texture (eg) could be used at different 'elevations'. As such, 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.

Naturally, and of course, the same 'texture' can be repeated in many cells, often with the same elevation (sea), and often not. Therefore, the wrp file 'cell' is an index to a list of rvmat files. This is a neat way of preventing repetitious structures.

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.

Unlike cell indexes however, each identical pine tree is listed separately, rather than simply have a table. There's no particular reason why a table (and indexes) were not used to conserve space, but done, it was not.

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 is 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

see Generic FileFormat Data Types

File Format

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

8WVR/WBV9

vbs WBV9 files exported from Visitor 4 are identical to 8WVR except that there can be multiple rvmat layers.

 8WVR/WBV9 
 {
   WRPHeader     Header
   float         Elevations   [TerrainGridSize.y][TerrainGridSize.x];
   ushort        MaterialIndex[TextureGridSize.y][TextureGridSize.x]; //zero based index into MaterialNames
   RvmatLayer    RvmatLayers[...];
   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 (formerly hardwired to 256 in Cwc).
• This, Arma format, simply adds a small wrinkle of a cellGrid Size. (Formerly set at 50 meters).

RvmatLayer

 RvmatLayer
 {
    ulong               nMaterials; // including the dummy index0 entry;
    MaterialName  MaterialNames[nMaterials];
 }

There is only one RvmatLayer for 8WVR. WBV9 has as many layers as a piece of string. The end of WBV9 layers is when NoOfMaterials=0

MaterialName

MaterialName
{
  ConcatStrings[...];// in practice only one
}

 concatString
 {
   ulong BufferLength; // a 0 terminates the chain
   char  Name[BufferLength];
 };

• The first, entry (or 0th index) has no filename associated with it and hence nothing further

• The MaterialIndex declares a specific rvmat file to use for each cell of the map. Thus, you should fully expect to see a lot of the same index value for 'sea' material, as it refers to one, common 'sea' rvmat.

• Note that this list of rvmat files while intended to only contain unique instances, does not. Occasionally, the very same rvmat file is listed more than once (with an obviously different index entry to each).
• BufferLengthh this value is NOT a strlen. It is the number of bytes used to hold the rvmat filename. It sometimes may(WBV9), or may not (8WVR) be null terminated.

Object

   Object 
   {
     float  TransformMatrix[3][4]; // 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.).

Objects extend to end of file. There is no count as such.

There is at least one Object entry.

The last (or only) object entry is a dummy. There is ZERO length (and consequently no p3d file associated) for this dummy entry. (the other data content is that of the penultimate object, and ignored). The engine uses this fact to iterate thru the list of Objects when hunting down the ObjectID (par exemple). (end-of-file is a useless concept for the engine which has long since dispensed with file io and simply malloc'd this chunk into memory)

Note that unlike the cell-indexes which refer to a single unique rvmat file. There is no index-list of p3d files (but perhaps should be, because of the enormous quantity of repetitions silver oak pine trees etc).

FilePaths

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