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)

For a general description of wrp files see 8WVR.

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

• byte 8 bits, unsigned.
• ushort 2 bytes, unsigned.
• ulong 4 bytes, unsigned.
• float 4 bytes, signed.
• asciiz variable length zero terminated string
• char: ascii character(s)

XYPair
{
 ulong x,y;
}

XYZTriplet
{
 float    x,y,z;
}
Normally, this structure is normally associated with positional information.

Texture and Terrain Grid Sizes are derived from the header.

• OPRW17 (Elite) does not have the PackedBytes1
• OPRW20 (sara and desert pbo's) :So far, this is the SAME format as 18

OPRWv17:
OPRWv18:
OPRWv20
{
 WrpHeader     Header;
 
 ushort        UnknownGrid1[TextureCellSizeXY]; // a gridblock
 byte          UnknownGrid2[TextureCellSizeXY]; // a gridblock // mostly the value 0x03 and probablay related to Config.cpp CfgEnvSounds class
 
 ulong         nPeaks;
 XYZTriplet    PeakPositions[nPeaks];
 
 ushort        TextureIndex[TextureCellSizeXY]; // a gridblock
 ushort        PackedRandom[TextureGridSizeXY]; //probably random values needed for calculating clutter models position
 if !Elite
  byte         PackedBytes1[TerrainGridSizeXY]; //seems to be related to clutters or sat mask distance as it is
 endif                                           responsible for the clutterbug
 
 float         PackedElevation[TerrainGridSizeXY];
 
 ulong         nTextures;
 Texture       Textures[nTextures];             //"PrefixRoot\data\layers\some.rvmat\0\0"
 
 ulong         nModels;
 asciiz        modelPaths[nModels];	         //"ca\buildings\kostelik.p3d\0"
 
 ulong         nClassedModels;
 ClassedModel  Models[nClassedModels];          //"Land_Hangar\0" : "ca\buildings\Hangar.p3d\0"
 
 byte          UnknownGrid3[TextureCellSizeXY]; // a gridblock
 
 ulong         SizeOfObjects;                   //in bytes
 
 byte          UnknownGrid4[TextureCellSizeXY]; // a gridblock
 
 ulong         SizeOfMapInfo;                   //in bytes
 
 byte          PackedBytes2[TextureGridSizeXY]; //seems to be connected to roads, runways and special grounds
 byte          PackedBytes3[TerrainGridSizeXY]; //unknown but 0x00 for forests and roads and sea, mostly 0x03 and rarely 0x02
 ulong         maxObjectID;
 
 ulong         SizeOfRoadNets;                  //in bytes
 RoadNet       RoadNets[SizeOfRoadNets];
 
 Object        Objects[SizeOfObjects/SizeOfObject]; // SizeOfObject ==60
 
 MapInfo       MapInfos[...];
}

• Because of the variable length of the asciiz strings in RoadParts, the actual position of the following #Objects block cannot be pre-calculated. Therefore the SizeOfRoadNets can be used, as it is the size (in bytes) of this RoadNet block.
• Similarly, SizeOfObjects can be used to skip to the MapInfo

WrpHeader
{
 char    Filetype;        // "OPWR"
 ulong   version;         // 0x12 = 18
 XYPair  TextureGridSize; // 256 x 256 eg
 XYPair  TerrainGridSize; // ditto
 float   CellSize;        // generally 50.0 meters
}

This is a traditional wrp header endemic to most wrp formats. The CellSize was introduced during Elit

The result of decompressing any GridBlock is to produce an array the size of the Header's TextureGridSizeXY, at the TypeSize specified. Eg be it byte, or ushort.

There are five gridblocks in the file, two ushort arrays, and 3 byte arrays(if present)

• when present, the leading flag = 0x01
• when a null GridBlock exists

{
  byte  flag;     // =0
  ulong NullBits; // = 0
}

GridBlock is currently in the 'discussion tab'.

Texture
{
 Concatenated Asciiz TextureFilenames; //"PrefixRoot\data\layers\some.rvmat\0\0" (Arma)
                                       //"PrefixRoot\desert\data\pt.bimpas\0\0"  (ELite)
                                       //"PboRoot\more_anim.01.pac\0"            (OFP)(by way of example)
}

• The ofp entry is solely here by way of example. No such entry exists in arma/Elite format.

This entry, and it's TextureIndices, are erroneously referred to as “Materials”. This because of the rvMat(erial) extension to the filename. However, the original file name was bimpas (for elite) and in both cases they comprise, ultimately of (a series of) pac/paa files. Thus, this documentation refers to texturing intent and retains that concept from previous versions of wrp files.

• see PrefixRoot\ description. Essentially, it is a reference to a pbo.

Each cell in the grid references a (series of) texture(s) for it's surface. The TextureIndex is an index into these texture filenames.

Thus, each entry of this materials list consists of concatenated asciiz strings in the form

“AnRvmatFile\0AnotherOne\0EvenMore\0\0”

Ie, the end of this entry = \0\0

It so happens that only one, single 'texture', a single rvmat file, is used per cell, but, the construct is there to have any amount.

therefore, this list is of the form

“AnRvmatFile\0\0”

There is always, at least one materials entry. The 1st entry. The first entry (effectively index 0) is a dummy, with an empty path, because it will never be accessed. Indexes start at 1.

Similar to it's 8WVR cousin (from which it is derived)the rvmat filenames *should* be unique (redundant, duplicate entries, defeat the purpose of the index). However, there is quite often some duplication.

The ushort Textureindices (once decomposed from a GridBlock) contain references to a 'texture'. no index value of zero can exist. (The first texture of the list is always a dummy entry)

 ClassedModel { asciiz class_name; //"Land_Hangar\0" asciiz model_path; //"ca\buildings\Hangar.p3d" XYZTriplet Position; ulong unknown; }

This is a fairly repetitious list of often identically named class and model, used as an index from an as yet unknown grid table.

 RoadNet { ulong nRoadParts; // Zero or More... RoadPart RoadParts[nRoadParts]; } TextureGridSizeXY];

Every cell on the terrain has a RoadNet entry. If there are no road(s) for that cell, there are no RoadParts (nRoadParts=0)

RoadParts, while, ultimately being no more (or less) than just another P3D model, are contained separately to models generally, to better realize terrain streaming and for AI driving ability.

 RoadPart { ushort nRoadPositions; XYZTriplet RoadPositions[nRoadPositions]; byte Flags[4]; asciiz Model; float matrix[12]; }

 Object { ulong ObjectID; ulong modelIndex; // into the [[#Models|models path name list]] (1 based) float TransformMatrix[3][4]; // standard directX transform matrix ulong 0x02; }

• maxObjectID is somewhat irrelevant. It is indeed the id of the highest value ObjectID, but, these 'ID's, while unique are highly arbitrary in nature and alter on any change to the 'world' when editing in oxygen/visitor. This ID can occur anywhere in the object list, and the id values before it are non-sequential. maxObjectID cannot be used as a nObject ID's eg.
• If SizeOfObjects above == 0 then there are no objects.

Note that unlike it's 4/8WVR cousin, where each Object entry contains (an often) repetitious list of p3d files. The same construct is (now) used as per Textures and Indexes. Namely, a common list of models is indexed into, by each Object entry.

MapInfo
{
 ulong infoType;
 MapData[...];
}

Mapinfo, when it exists, extends to end of file. The sizeof each entry, is determined by it's info type thus:

MapData
{
 if(infoType in [0,1,2,10,11,13,14,15,16,17,22,23,26,27,30]) MapType1;
 if(infoType in [24,31,32])                                  MapType2;
 if(infoType in [25,33])                                     MapType3;
 if(infoType in [3,4,8,9,18,19,20,28,29])                    MapType4;
 if(infoType in [34])                                        MapType5;
}

MapType1 { ulong ObjectId float x, z }

MapType2 { ulong ObjectId float Bounds[4][2]; }

MapType3 { ulong unknown[2]; float line[2][2];? }

MapType4 { ulong ObjectId float Bounds[4][2]; byte Color[4] //rgba }

MapType5 { ulong ObjectId float line[2][2];? }

All variables starting with “Packed” are compressed with the common bis algorithm that is also used in paa and OFP pbo files.

bimpas files are associated with Xbox elite they were the precursor to ArmA's rvmat files

in both cases they define a series of textures for p3d models (and wrps)

The new, visitor 3 graphical editor tool refers to bimpas files as

• rvmat surface materials
• bimpas transition materials

rvmat files are a series of paas bimpas files are a series of rvmats

Ordinarily, these files, if binarised, are rapified in the normal xbox/arma manner

some files, possibly in error, contain substituted space characters for zeroes.

this is either an encryption, or, possibly a simple error

class Pass0
{
	material = "ca\introofp\ps.rvmat";
	texture = "ca\introofp\ps.paa";
	tlAlpha = 1;
	trAlpha = 1;
	blAlpha = 1;
	brAlpha = 1;
};
 
class Pass0
{
	material = "LandText\az.rvmat";
	texture = "LandText\az.paa";
	trAlpha = 1;
};
 
class Pass1
{
	material = "LandText\ba.rvmat";
	texture = "LandText\ba.paa";
	blAlpha = 1;
};
 
class Pass2
{
	material = "LandText\_N.rvmat";
	texture = "LandText\_N.paa";
	brAlpha = 1;
};
 
class Pass3
{
	material = "LandText\Dl.rvmat";
	texture = "LandText\Dl.paa";
	tlAlpha = 1;
};