Differences

This shows you the differences between two versions of the page.

--- arma:file_formats:8wvr [2009-07-17 09:36]
snakeman added better info.
+++ arma:file_formats:8wvr [2009-11-22 08:22] (current)
snakeman added updated 8wvr file format.
@@ Line 1: / Line 1: @@
-====== 8WVR ======
+====== WRP File Format 8WVR ======
-Introduction
+**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.
+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.
@@ Line 12: / Line 15: @@
 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.
@@ Line 28: / Line 29: @@
 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.
+The only other necessary component of a wrp file is to populate it with objects.
-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.
+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.
-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.
+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.
-Legend
+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.
-Little endian byte order, lsb first for numeric values, text is stored in Big endian byte order.
+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.
-  * ushort: 16 bit unsigned short (2 bytes)
+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.
-  * ulong: 32 bit unsigned integer (4 bytes)
-  * float: 32 bit signed single precision floating point value (4 bytes)
-  * char: ascii character(s)
-String
+======  File Format  ======
-<code cpp>
+This file format is principally used with Armed Assault and a derivation of it was used for Elite.
-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
+====== 8WVR ======
 <code cpp>
-XYPair
+WVR
 {
- ulong x,y;
+	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>
-File Format
+  * 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.
-  * This file format is principally used with Armed Assault and a derivation of it was used for Elite.
+====== WrpHeader ======
-WVR
 <code cpp>
-WVR
+WrpHeader
 {
-   WRPHeader     Header
+	char    Filetype;        // 8WVR
-   float         Elevations   [TerrainGridSize.y][TerrainGridSize.x];
+	XYPair  TextureGridSize; // 256 x 256 eg
-   ushort        MaterialIndex[TextureGridSize.y][TextureGridSize.x]; //zero based index into MaterialNames
+	XYPair  TerrainGridSize; // ditto
-   ulong         NoOfMaterials;
+	float   CellSize;        // generally 50.0 meters
-   MaterialName  MaterialNames[NoOfMaterials];
-   Object        Objects[...];
 }
 </code>
-  * The 'Elevations' array is Cartesian mapped. It extends from Bottom-Left to Top-Right in Visitor;
+This is a fairly traditional Header for all Wrp types (including OPWRxx).
-  * The Objects extend to end of file. There is no count as such.
+  * OFP Resistance first introduced the cell Grid dimensions  (formerly hardwired to 256 in Cwc).
-  * There is always at least one Object entry.
+  * This, Arma format, simply adds a small wrinkle of a cellGrid Size. (Formerly set at 50 meters).
-  * 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
+====== MaterialName ======
 <code cpp>
-WrpHeader
+MaterialName
 {
-  char    Filetype;        // "8WVR"
+	Concatenated:
-  XYPair  TextureGridSize; // 256 x 256 eg
+	LenString(s) RvMatFileNames[[...]]; //[[Length]]:SomePboPrefix\Some.rvmat\0[[\0x0000]][[\0x0000]];
-  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.
+  * The MaterialIndex indicates what collection of textures 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' material.
+  * This 'collection' is held in an rvmat file, and might be a single texure, or multples.
-MaterialName
+  * Secondly (and endemic to all wrp formats): BI 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
 <code cpp>
 MaterialName
 {
-	Strings RvMatFileNames[...]; //[Length]:"SomePboPrefix\SomeIsland\data\layers\p_002-000_l02.rvmat" ... "\0x0000";
+	ulong Length;  // including the null char
-}
+	char  Name[[Length]];
+	ulong Length2; // ALWAYS 0
+};
 </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 .
+  * At best, there happens to be only one String per cell entry. That fact does not negate the construct.
-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.
+<code cpp>
+Length:Ascii:AnotherLength[[Asciiz...]]AnotherLength[[Asciiz]]....
+</code>
-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.
+the above applies to EACH entry. (however, as stated) in the real world, this resolves to:
-At best, there happens to be only one String per cell entry. That fact does not negate the construct.
 <code cpp>
-Length:Ascii:AnotherLength....
+Length:Ascii:[[0000]] // no more lengths
 </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.
+  * Because the Material INDEX is one based (not zero based):
-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.
+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
+====== Object ======
 <code cpp>
 Object
 {
-	float  TransformMatrix[3][4]; // standard directX transform matrix
+	float  TransformMatrix[[3]][[4]]; // standard directX transform matrix
 	ulong  ObjectId;
-	String P3dFileName[Length];   // "ca\buildings\ryb_domek.p3d"
+	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.).
+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.
@@ Line 159: / Line 155: @@
 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\
+====== 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

Differences

Page Tools