ArmA 1 Forum, ArmA 1 Home, ArmA 1 Config, ArmA 1 Tools, ArmA 1 File Formats, ArmA 1 Missions, ArmA 1 3D Modeling, ArmA 1 Terrain, ArmA 1 Texturing, ArmA 1 Scripting

ArmA 1 aka Armed Assault (ArmA)

WRP File Format - 8WVR

See also OFP File Format.

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 terrain. The simplicity of the requirements for the terrain 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 terrain surface (be it land, or sea). The overall size of the terrain 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 terrain 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's texture,
• And, the texture for it's 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 terrain to

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

Official bis terrains have never used it. And I am unaware of any Oem terrain 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 terrain 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) weren't used to conserve space, but done, it wasn't.

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 terrain 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 'terrain' is revised. This has particular relevance to porting OFP terrains into Arma.

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

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 terrain.

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).

MaterialName
{
	Concatenated:
	LenString(s) RvMatFileNames[[...]]; //[[Length]]:SomePboPrefix\Some.rvmat\0[[\0x0000]][[\0x0000]];
}

• The MaterialIndex indicates what collection of textures should be used in any given cell. Ie any 50 meter chunk of the terrain. Thus, you should fully expect to see a lot of the same index value for 'sea' material.
• This 'collection' is held in an rvmat file, and might be a single texure, or multples.
• Secondly (and endemic to all wrp formats): bis use concatenated strings to express a series of rvmat files for EACH 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 concatenation to be used.
• In C code, each MaterialName entry (for 8WVR) appears as follows

MaterialName
{
	ulong Length;  // including the null char
	char  Name[[Length]];
	ulong Length2; // ALWAYS 0
};

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

Length:Ascii:AnotherLength[[Asciiz...]]AnotherLength[[Asciiz]]....

the above applies to EACH entry. (however, as stated) in the real world, this resolves to:

Length:Ascii:[[0000]] // no more lengths

• Because the Material INDEX is one based (not zero based):

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

• 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).

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).

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\