PMC Editing Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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.

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

Little endian byte order, lsb first for numeric values, text is stored in Big endian byte order.

  * 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

<code cpp>
String
{
 ulong Length;
 char  ascii[Length];
}
</code>

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

<code cpp>
XYPair
{
 ulong x,y;
}
</code>

File Format

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


8WVR

<code cpp>
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[...];
}
</code>

  * 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

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

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

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

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.

<code cpp>
Length:Ascii:AnotherLength....
</code>

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. This too is endemic to all wrp formats.

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

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

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\
PMC Editing Wiki

User Tools

Site Tools

Page Tools
