Difference between revisions of "ADT/v18"

From wowdev
Jump to navigation Jump to search
Line 617: Line 617:
                                   ''// It also does not seem that the client reads this data. --[[User:Schlumpf|Schlumpf]] ([[User talk:Schlumpf|talk]]) 23:01, 26 July 2015 (UTC)''
                                   ''// It also does not seem that the client reads this data. --[[User:Schlumpf|Schlumpf]] ([[User talk:Schlumpf|talk]]) 23:01, 26 July 2015 (UTC)''
                                   ''// While stated that this data is not "included in the MCNR chunk", the chunk-size defined for the MCNR chunk '''does''' cover this data. --[[User:Kruithne|Kruithne]] Feb 2016''
                                   ''// While stated that this data is not "included in the MCNR chunk", the chunk-size defined for the MCNR chunk '''does''' cover this data. --[[User:Kruithne|Kruithne]] Feb 2016''
                                  ''// ... from Cataclysm only (on LK files and before, MCNR defined size is 435 and not 448) [[User:Mjollna|Mjollna]] ([[User talk:Mjollna|talk]])
=== MCLY sub-chunk ===
=== MCLY sub-chunk ===

Revision as of 13:55, 12 March 2016

ADT files contain terrain and object information for map tiles. They have a chunked structure just like the WDT files.

A map tile is split up into 16x16 = 256 map chunks. (not the same as file chunks, although each map chunk will have its own file chunk :) ) So there will be a few initial data chunks to specify textures, objects, models, etc. followed by 256 MCNK (mapchunk) chunks :) Each MCNK chunk has a small header of its own, and additional chunks within its data block, following the same id-size-data format.

An important note about the coordinate system used

Wow's main coordinate system is really weird but understanding it is very important in order to correctly interpret the ADT files.

It's important to remember that:

  • Unlike most coordinate systems Z is used for the height, Y is used for the width and X is used for the depth.
  • Y is "reversed". The more you go to the right (if north is up), the more it decreases.
  • The center of the axis is in the center of the map.
  • The top-left corner of the map has X = 17066, Y = 17066
  • The bottom-right corner of the map has X = -17066, Y = -17066
  • The bottom-left corner of the map has X = -17006, Y = 17066
  • The top-right corner of the map has X = 17006, Y = -17066

Just to be absolutely clear, assuming you playing a character that is not flying or swimming and is facing north:

  • Forward = D3DXVECTOR3(1, 0, 0);
  • Right = D3DXVECTOR3(0, -1, 0);
  • Up = D3DXVECTOR3(0, 0, 1);

This is the coordinate system used internally in all of the network packets and on most chunks in ADT files. I believe (but I'm not sure) that some chunks in this file use a different coordinate system (in particular for objects like M2's or WMO's that don't have an absolute position but only a relative one). MODF and MDDF do indeed use a different coordinate system, even for the absolute Position. (Anyone clarify on the reasoning behind this?)

Unfortunately though whoever wrote this article decided to use yet another coordinate system to explain things, different from Wow's.. So it's kind of a mess!

Map size, blocks, chunks


All maps are divided into 64x64 blocks for a total of 4096 (some of which may be unused). Each block are divided into 16x16 chunks (not to be confused with for example the file chunks, such as the "MHDR" chunk.. Completely different thing!). While like I said blocks can be unused, each block will always use all of its 16x16 chunks.

Map size

Each block is 533.33333 yards long (yes, strange number, but that's the way it is). Since like we said above the map is divided into 64x64 blocks the total X and Y of the map will be 34133.33312 yards (but remember that since the center of the axis is at the center of the map, the maximum X and Y will be 17066.66656).

Since each block has 16x16 chunks, the size of a chunk will be 33.3333 yards.

ADT files and blocks

There is an .adt file for each existing block. If a block is unused it won't have an .adt file. The file will be: World/Maps/<InternalMapName>/<InternalMapName>_<BlockX>_<BlockY>.adt.

  • <InternalMapName> - MapRec::m_Directory
  • <BlockX> - Index of the tile on the X axis
  • <BlockY> - Index of the tile on the Y axis

Converting ADT co-ords to block X/Y can be done with the following formula (where axis is x or y): floor((32 - (axis / 533.33333)))

split files (Cata+)

This section only applies to versions ≥ Cata.

Beginning with Cataclysm, ADTs are split into multiple files: .adt (root), _tex%d.adt (tex) and _obj%d.adt (obj) with %d being the level of detail (0 or 1). Chunks are distributed over the files. To load a map, the client loads a set of three and treats them as one. While the distribution schema appears to be quite fixed, the client does not keep the semantics of which file is which and parses them all the same.

The main difference content-wise is MCIN being gone, and MCNK in tex and obj files not having the header it has in root files.

Legion added _lod.adt (lod) files as another type. They are used for increased draw distance, this time including low quality versions of liquids and geometry as well (in the end, root lod bands).

MVER chunk

  • split files: all
struct MVER {
  uint32_t version;

MHDR chunk

  • split files: root
  • Contains offsets relative to &MHDR.data in the file for specific chunks. WoW only takes this for parsing the ADT file.
struct MHDR {
  enum MHDRFlags {
    mhdr_MFBO = 1,                // contains a MFBO chunk.
    mhdr_northrend = 2,           // is set for some northrend ones.
  uint32_t flags;
  MCIN* mcin;                     // Cata+: obviously gone. probably all offsets gone.
  MTEX* mtex;
  MMDX* mmdx;
  MMID* mmid;
  MWMO* mwmo;
  MWID* mwid;
  MDDF* mddf;
  MODF* modf;
  MFBO* mfbo;                     // this is only set if flags & mhdr_MFBO.
  MH2O* mh2o;
  MTXF* mtxf;
  uint8_t mamp_value;             // Cata+, explicit MAMP chunk overrides data
  uint8_t padding[3];
  uint32_t unused[3];
} mhdr;

MCIN chunk (<Cata)

This section only applies to versions ≤ Wrath. No longer possible due to split files.
  • Pointers to MCNK chunks and their sizes.
struct MCIN {
  struct MCINEntry {
    MCNK* mcnk;                   // absolute offset.
    uint32_t size;                // the size of the MCNK chunk, this is refering to.
    uint32_t flags;               // these two are always 0. only set in the client.
    uint32_t asyncId;	
  } entries[16*16];
} mcin;

MTEX chunk

  • split files: tex
  • List of textures used for texturing the terrain in this map tile.
struct MTEX {
  char filenames[0];              // zero-terminated strings with complete paths to textures. Referenced in MCLY.

MMDX chunk

  • split files: obj
  • List of filenames for M2 models that appear in this map tile.
struct MMDX {
  char filenames[0];              // zero-terminated strings with complete paths to models. Referenced in MMID.

MMID chunk

  • split files: obj
  • List of offsets of model filenames in the MMDX chunk.
struct MMID {
  uint32_t offsets[0];            // filename starting position in MMDX chunk. These entries are getting referenced in the MDDF chunk.

MWMO chunk

  • split files: obj
  • List of filenames for WMOs (world map objects) that appear in this map tile.
struct MWMO {
  char filenames[0];              // zero-terminated strings with complete paths to models. Referenced in MWID.

MWID chunk

  • split files: obj
  • List of offsets of WMO filenames in the MWMO chunk.
struct MWID {
  uint32_t offsets[0];            // filename starting position in MWMO chunk. These entries are getting referenced in the MODF chunk.

MDDF chunk

  • split files: obj
  • Placement information for doodads (M2 models). Additional to this, the models to render are referenced in each MCRF chunk.
struct MDDF {
  enum MDDFFlags {
    mddf_biodome = 1,             // this sets internal flags to | 0x800 (WDOODADDEF.var0xC).
    mddf_shrubbery = 2,           // the actual meaning of these is unknown to me. maybe biodome is for really big M2s. seems not to check 
                                  for this flag
  struct MDDFEntry { // SMDoodadDef
    uint32_t mmidEntry;           // references an entry in the MMID chunk, specifying the model to use.
    uint32_t uniqueId;            // this ID should be unique for all ADTs currently loaded. Best, they are unique for the whole map. Blizzard has 
                                  these unique for the whole game.
    float position[3];            // This is relative to a corner of the map. Subtract 17066 from the non vertical values and you should start to see 
                                  something that makes sense. You'll then likely have to negate one of the non vertical values in whatever coordinate 
                                  system you're using to finally move it into place.
    float rotation[3];            // degrees. This is not the same coordinate system orientation like the ADT itself! (see history.)
    uint16_t scale;               // 1024 is the default size equaling 1.0f.
    uint16_t flags;               // values from enum MDDFFlags.
  } entries[0];
  • How to compute a matrix to map M2 to world coordinates

Math is the same as for MODF, only with scale being added.

Example in js with gl-matrix:

  createPlacementMatrix : function(mddf) {
    var TILESIZE = 533.333333333;

    var posx = 32 * TILESIZE - mddf.position[0];
    var posy = mddf.position[1];
    var posz = 32 * TILESIZE - mddf.position[2];

    var placementMatrix = mat4.create();

    mat4.rotateX(placementMatrix, placementMatrix, glMatrix.toRadian(90));
    mat4.rotateY(placementMatrix, placementMatrix, glMatrix.toRadian(90));

    mat4.translate(placementMatrix, placementMatrix, [posx, posy, posz]);

    mat4.rotateY(placementMatrix, placementMatrix, glMatrix.toRadian(mddf.rotation[1] - 270));
    mat4.rotateZ(placementMatrix, placementMatrix, glMatrix.toRadian(-mddf.rotation[0]));
    mat4.rotateX(placementMatrix, placementMatrix, glMatrix.toRadian(mddf.rotation[2] - 90));

    mat4.scale(placementMatrix, placementMatrix, [mddf.scale / 1024, mddf.scale / 1024, mddf.scale / 1024]);

    return placementMatrix;

MODF chunk

  • split files: obj
  • Placement information for WMOs. Additional to this, the WMOs to render are referenced in each MCRF chunk. (?)
struct MODF {
  enum MODFFlags {
    modf_destroyable = 1,         // set for destroyable buildings like the tower in DeathknightStart. This makes it a server-controllable game object.
    modf_use_lod = 2,             // WoD(?)+: also load _LOD1.WMO for use dependent on distance
    modf_unk_4 = 4,               // Legion(?)+: unknown
  struct MODFEntry {
    uint32_t mwidEntry;           // references an entry in the MWID chunk, specifying the model to use.
    uint32_t uniqueId;            // this ID should be unique for all ADTs currently loaded. Best, they are unique for the whole map.
    float position[3];
    float rotation[3];            // same as in MDDF.
    float lowerBounds[3];         // these two are position plus the wmo bounding box.
    float upperBounds[3];         // they are used for defining when if they are rendered as well as collision.
    uint16_t flags;               // values from enum MODFFlags.
    uint16_t doodadSet;           // which WMO doodad set is used.
    uint16_t nameSet;             // which WMO name set is used. Used for renaming goldshire inn to northshire inn while using the same model.
    uint16_t unk;                 // Legion(?)+: has data finally!
  } entries[0];
  • How to compute a matrix to map WMO to world coordinates

The position field in MODF is in Y-up coordinate system with upper-left corner being (0,0). And when you move to the right or down in this system the values increases.
While in WoW world coordinates are in Z-up order with the top-left corner being (17.066, 17,066) and when you move to left or down - the values decreases.
So to get a proper positioning you need to translate those values to world coordinate system by substracting them x and z (index 0 and 2 in position array) from 17,066.

The rotation field is given in degrees. You would need to translate it into radians before passing to rotate function.

Example implementation in js with gl-matrix library[1]:

function createPlacementMatrix(modf){
    var TILESIZE = 533.333333333;
    var posx = 32*TILESIZE - modf.position[0];
    var posy = modf.position[1];
    var posz = 32*TILESIZE - modf.position[2];
    var placementMatrix = mat4.create();
    //Rotate coordinate system into Z-up
    mat4.rotateX(placementMatrix, placementMatrix, glMatrix.toRadian(90));
    mat4.rotateY(placementMatrix, placementMatrix, glMatrix.toRadian(90));
    //Translate the center of coordinate system
    mat4.translate(placementMatrix, placementMatrix, [posx, posy, posz]);
    // Rotate the coordinates
    mat4.rotateY(placementMatrix, placementMatrix, glMatrix.toRadian(modf.rotation[1]-270));
    mat4.rotateZ(placementMatrix, placementMatrix, glMatrix.toRadian(-modf.rotation[0]));
    mat4.rotateX(placementMatrix, placementMatrix, glMatrix.toRadian(modf.rotation[2]-90));

    return placementMatrix;

To get WMO vertexes into world position, you would need to multiply this matrix by 4-component vertex vector from left, with index 0-2 being x, y, z and index 3 being 1.

placementMatrix * (x, y, z, 1)

Example multiplication in js with gl-matrix:

function translate (position, positionMatrix) {
  var position4 = vec4.fromValues(position[0], position[1], position[2], 1);
  vec4.transformMat4(position4 , position4 , positionMatrix);
  return position4;

For rendering, it is recommended to make this transformation in shader. So you would not have dublicate vertex data in gpu memory. Example in glsl:

attribute vec3 aPosition;
uniform mat4 uPlacementMat;

void main() {
    vec4 worldPoint = uPlacementMat * vec4(aPosition, 1);
    gl_Position = worldPoint;    

MH2O chunk (WotLK+)

This section only applies to versions ≥ Wrath. Replacement for MCLQ.
  • split files: root

Replacement for MCLQ, which is still parsed by the client for backwards compatibility.

The chunk is seperated in three parts: A header (SMLiquidChunk), the data-block (SMLiquidInstance) and the referenced data from both. Reading it all at once and then using the supplied offsets inside is recommended. All offsets are relative to the data begin of the chunk. The header is the only part with a guaranteed position. All other parts are specified by offsets.


The header is a list of 256 entries:

struct SMLiquidChunk {
  uint32_t offset_instances;       // points to SMLiquidInstance[layer_count]
  uint32_t layer_count;            // 0 if the chunk has no liquids. If > 1, the offsets will point to arrays.
  uint32_t offset_attributes;      // points to mh2o_chunk_attributes, can be ommitted for all-0
} chunks[16*16];


chunks[].offset_attributes points to one of

struct mh2o_chunk_attributes {
  uint64_t fishable;               // seems to be usable as visibility information.
  uint64_t deep;


chunks[].offset_instances points to chunks[].layer_count entries of

struct SMLiquidInstance {
  foreign_key<uint16_t, &LiquidTypeRec::m_ID> liquid_type;
  foreign_key<uint16_t, &LiquidObjectRec::m_ID> liquid_object;
  float min_height_level;
  float max_height_level;
  uint8_t x_offset;                // The X offset of the liquid square (0-7)
  uint8_t y_offset;                // The Y offset of the liquid square (0-7)
  uint8_t width;                   // The width of the liquid square (1-8)
  uint8_t height;                  // The height of the liquid square (1-8)
  uint32_t offset_exists_bitmap;   // not all tiles in the instances need to be filled. always 8*8 bits.
                                   // offset can be 0 for all-exist. also see (and extend) Talk:ADT/v18#SMLiquidInstance
  uint32_t offset_vertex_data;     // actual data format defined by LiquidMaterialRec::m_LVF via LiquidTypeRec::m_materialID
                                   // note: there is a hardcoded check that ocean (liquid_type = 2) is LVF 2 (depth only)

instance vertex data

Regardless of format, the arrays will always have (width + 1) * (height + 1) entries.

  • no heightmap means that min/max_height_level is used for all points.
  • depthmap values are mapped to [0.0 1.0] for the shaders.
struct uv_map_entry {
  uint16_t x;                      // divided by 8 for shaders
  uint16_t y;

Case 0, Height and Depth data

This is the go-to layout for pre-WoD (MoP?) data.

struct {
  float heightmap[];
  char depthmap[];

Case 1, Height and Texture Coordinate data

struct {
  float heightmap[];
  uv_map_entry uvmap[];

I couldn't get the UV coordinates to make sense so I ended up disabling them. -- Rour

Case 2, Depth only data

This format is hard coded for liquid type ocean (2).

struct {
  char depthmap[];

Case 3, Height, Depth and Texture Coordinates

struct {
  float heightmap[];
  uv_map_entry uvmap[];
  char depthmap[];

example, notes

The full heightmap that covers a whole chunk would be created from 9x9 float values, effectively creating 8x8 quadratic pieces. But since WotLK and the introduction of the MH2O chunk there is no more need to define the full heightmap if only part of a chunk is actually covered with water (such as with a thin river). Instead, MH2O_Information.x, .y, .width and .height define the size and location of a "liquid rectangle" which can be smaller than a full chunk.

An example: let's say there's a river crossing a chunk like this ('x' is the river):


This would lead to x_offset = 0, y_offset = 2, width = 8 and height = 2. The data at vertex_data.heightmap would then list 27 float values for the height map (a 9x3 height map which results in 8x2 quads, as shown in the picture above).

The data pointed to by offset_exists_bitmap would finally define which of the quads should be rendered. Its length is always eight bytes, and each byte is a bitmap which contains a 1 for each quad to be rendered and a 0 for each invisible quad. In our example this would be the following bytes: 0x00 (binary 00000000), 0x00 (binary 00000000), 0xFC (binary 11111100), 0x3F (binary 00111111), 0x00 (binary 00000000), 0x00 (binary 00000000), 0x00 (binary 00000000), 0x00 (binary 00000000).

Note that it is always possible to omit offset_exists_bitmap and/or offset_vertex_data to save some bytes in the ADT file! If offset_attributes is not given, the whole liquid instance is to be rendered. If offset_vertex_data is not given, then the height map consists only of values equal to heightLevel1 (I am not 100% sure of this one, but this approach seems to work fine for me).

MCNK chunk

  • split files: header in root, no header in obj and tex
  • After the above mentioned chunks come 256 individual MCNK chunks, row by row, starting from top-left (northwest). The MCNK chunks have a large block of data that starts with a header, and then has sub-chunks of its own.

Each map chunk has 9x9 vertices, and in between them 8x8 additional vertices, several texture layers, normal vectors, a shadow map, etc.

The MCNK header is 128 bytes large.

struct SMChunk
    uint32_t has_mcsh : 1;
    uint32_t impass : 1;
    uint32_t lq_river : 1;
    uint32_t lq_ocean : 1;
    uint32_t lq_magma : 1;
    uint32_t lq_slime : 1;
    uint32_t has_mccv : 1;
    uint32_t unknown_0x80 : 1;
    uint32_t : 7;                      // not set in
    uint32_t do_not_fix_alpha_map : 1; // "fix" alpha maps in MCAL (4 bit alpha maps are 63*63 instead of 64*64). Note that this also means that it *has* to be 4 bit alpha maps, otherwise UnpackAlphaShadowBits will assert.
    uint32_t high_res_holes : 1;       // Since ~5.3 WoW uses full 64-bit to store holes for each tile if this flag is set. The holes are a uint64_t at 0x14.
    uint32_t : 15;                     // not set in
  } flags;
/*0x004*/  UINT32 IndexX;
/*0x008*/  UINT32 IndexY;
/*0x00C*/  UINT32 nLayers;				// maximum 4
/*0x010*/  UINT32 nDoodadRefs;
/*0x014*/  MCVT* ofsHeight;
/*0x018*/  MCNR* ofsNormal;
/*0x01C*/  MCLY* ofsLayer;
/*0x020*/  MCRF* ofsRefs;
/*0x024*/  MCAL* ofsAlpha;
/*0x028*/  UINT32 sizeAlpha;
/*0x02C*/  MCSH* ofsShadow;				// only with flags.has_mcsh
/*0x030*/  UINT32 sizeShadow;
/*0x034*/  UINT32 areaid;
/*0x038*/  UINT32 nMapObjRefs;
/*0x03C*/  uint16_t holes_low_res;
/*0x03E*/  uint16_t unknown_but_used;
/*0x040*/  UINT2[8][8] ReallyLowQualityTextureingMap;	// It is used to determine which detail doodads to show. Values are an array of two bit 
                                                            unsigned integers, naming the layer.
/*0x050*/  UINT32 predTex;				// 03-29-2005 By ObscuR; TODO: Investigate    ---  WoD:  inlined MCDD chunk begins here
/*0x054*/  UINT32 noEffectDoodad;				// 03-29-2005 By ObscuR; TODO: Investigate
/*0x058*/  MCSE* ofsSndEmitters;
/*0x05C*/  UINT32 nSndEmitters;				//will be set to 0 in the client if ofsSndEmitters doesn't point to MCSE!
/*0x060*/  MCLQ* ofsLiquid;
/*0x064*/  UINT32 sizeLiquid;  			// 8 when not used; only read if >8.
/*0x068*/  C3Vector position;
/*0x074*/  MCCV* ofsMCCV;         // only with flags.has_mccv, had UINT32 textureId; in ObscuR's structure.
/*0x078*/  MCLV* ofsMCLV;         // introduced in Cataclysm
/*0x07C*/  UINT32 unused; 			                                // currently unused

About the holes in the terrain: This is a bitmapped field, the least significant 16 bits are used row-wise in the following arrangement with a 1 bit meaning that the map chunk has a hole in that part of its area:

	0x1	0x2	0x4	0x8
	0x10	0x20	0x40	0x80
	0x100	0x200	0x400	0x800
	0x1000	0x2000	0x4000	0x8000

Since approx. 5.3, WoW uses a new 64-bit hole map if needed. If so, flag high_res_holes is set in the MCNK header and the 8 bytes at offset chunkBegin+0x14 (ofsHeight and ofsNormal) contain the hole map. Otherwise, the low resolution 16-bit hole map is used. See MapChunk::CreatePointers and/or this post. Read those 8 bytes as byte array and check for holes like (Holes[row] >> col) & 1. If you interpret it as an uint64_t and shift like you did before on the 16-bit map, you have to invert the rows because of endianness.

MCVT sub-chunk

  • split files: root
  float height[9*9 + 8*8];
} mcvt;

These are the actual height values for the 9x9+8x8 vertices. 145 floats in the following order/arrangement:. The values in here are only relative to the position given in the corresponding MCNK chunk.

  1    2    3    4    5    6    7    8    9
   10   11   12   13   14   15   16   17
 18   19   20   21   22   23   24   25   26
   27   28   29   30   31   32   33   34
 35   36   37   38   39   40   41   42   43
   44   45   46   47   48   49   50   51
 52   53   54   55   56   57   58   59   60
   61   62   63   64   65   66   67   68
 69   70   71   72   73   74   75   76   77
   78   79   80   81   82   83   84   85
 86   87   88   89   90   91   92   93   94
   95   96   97   98  99  100  101  102
103  104  105  106  107  108  109  110  111
  112  113  114  115  116  117  118  119
120  121  122  123  124  125  126  127  128
  129  130  131  132  133  134  135  136
137  138  139  140  141  142  143  144  145

The inner 8 vertices are only rendered in WoW when its using the up-close LoD. Otherwise, it only renders the outer 9. Nonsense? If I only change one of these it looks like: Media:WoWScrnShot_022409_204540.jpg.

Ok, after a further look into it, WoW uses Squares out of 4 of the Outer(called NoLoD)-Vertices with one of the Inner(called LoD)-Vertices in the Center:

  1    2
 18   19

So to render them in OpenGL you can use something like this:

  for(int x=0;x<8;x++){
    for(int y=0;y<8;y++){
  	float nL1=mcvt.getValNoLOD(x, y);
  	float nL2=mcvt.getValNoLOD(x, y+1);
  	float nL3=mcvt.getValNoLOD(x+1, y);
  	float nL4=mcvt.getValNoLOD(x+1, y+1);
  	float L=mcvt.getValLOD(x, y);
  	gl.glVertex3f( y, x, nL1);
  	gl.glVertex3f( y+1, x, nL2);
  	gl.glVertex3f(y+0.5f, x+0.5f, L);
  	gl.glVertex3f( y, x, nL1);
  	gl.glVertex3f( y, x+1,nL3);
  	gl.glVertex3f(y+0.5f, x+0.5f,L);
  	gl.glVertex3f( y, x+1, nL3);
  	gl.glVertex3f( y+1, x+1, nL4);
  	gl.glVertex3f(y+0.5f, x+0.5f,L);
  	gl.glVertex3f( y+1, x,nL2);
  	gl.glVertex3f( y+1, x+1, nL4);
  	gl.glVertex3f(y+0.5f, x+0.5f, L);

Although it seems there is still a mistake :/ --Tigurius

Old ones:

To stripify try this one: ( stripsize is now : 16*18 + 7*2 + 8*2 )

void stripify(V *in, V *out)
	for (int row=0; row<8; row++) { 
		V *thisrow = &in[row*9*2];
		V *nextrow = &in[row*9*2 + 9];
		V *overrow = &in[(row+1)*9*2];
		if (row>0) *out++ = thisrow[0];// jump end
		for (int col=0; col<8; col++) {
			*out++ = thisrow[col];
			*out++ = nextrow[col];
		*out++ = thisrow[8];
		*out++ = overrow[8];
		*out++ = overrow[8];// jump start
		*out++ = thisrow[0];// jump end
		*out++ = thisrow[0];
		for (int col=0; col<8; col++) {
			*out++ = overrow[col];
 			*out++ = nextrow[col];
		if (row<8) *out++ = overrow[8];
		if (row<7) *out++ = overrow[8];// jump start

or try this one (made by tharo)

// to make it not TOO complicated u get data as 9*9 and 8*9 chain. 
// the 9th value is never used but calculation is more easy now ^^
private int stripify(Point3d[] in, Point3d[] out) {
     int outc=0;
     for (int row=0; row<8; row++) {
           int thisrow = row*9*2;
           int nextrow = row*9*2 + 9;
           int overrow = (row+1) *9*2;
           for(int col=0; col<8; col++) {
                 out[outc++] = in[thisrow+col];
                 out[outc++] = in[nextrow+col]; 
           out[outc++] = in[thisrow+8];
           for(int col=8; col>0; col--) {
                 out[outc++] = in[overrow+col];
                 out[outc++] = in[nextrow+col-1]; 
           out[outc++] = in[overrow];
           out[outc++] = in[thisrow];
           out[outc++] = in[nexttow];
           out[outc++] = in[overrow];
     for(int row=8; row>=0; row--) {
           out[outc++] = in[row*9*2];
     return outc;

These points look like they might be better organized as a triangle fan instead of a strip. This is my untested guess:

float wowData[145];
int off = 9;
float x, y;

for (y = 0; y < 8; ++y, off += 9)
    for (x = 0; x < 8; ++x, ++off)
            glVertex3f(x, y, wowData[off]);
            glVertex3f(x - 0.5f, y - 0.5f, wowData[off - 9]);
            glVertex3f(x + 0.5f, y - 0.5f, wowData[off - 8]);
            glVertex3f(x + 0.5f, y + 0.5f, wowData[off + 9]);
            glVertex3f(x - 0.5f, y + 0.5f, wowData[off + 8]);
            glVertex3f(x - 0.5f, y - 0.5f, wowData[off - 9]);


MCLV sub-chunk (Cata+)

This section only applies to versions ≥ Cata.
  • split files: root
  CArgb values[9*9 + 8*8]; // or rgba?
} chunk_lighting;

Alpha is apparently ignored. Heavily used in Deepholm. In contrast to MCCV does not only color but also lightens up the vertices.

MCCV sub-chunk (WotLK+)

This section only applies to versions ≥ Wrath.
  • split files: root
  • This is used for vertex shading. You can manipulate the color of the vertices by adding this layer of colors blended onto the terrain. You can see the effects of this in this video (see 3:25 to 3:45) from Blizzcon 09. Additionally, there is a screenshot showing some of the effects possible.
struct MCCV {
  struct MCCVEntry {
    uint8_t red;                  // these values range from 0x00 to 0xFF with 0x7F being the default.
    uint8_t green;                // you can interpret the values as 0x7F being 1.0 and these values being multiplicated with the vertex colors.
    uint8_t blue;                 // setting all values to 0x00 makes a chunk completely black.
    uint8_t alpha;                // seems not to have any effect.
  } entries[9*9+8*8];

Probably argb, not rgba? --Schlumpf (talk) 17:05, 26 July 2015 (UTC)

MCNR sub-chunk

  • split files: root
  • Normal vectors for each corresponding vector above. Its followed by some weird unknown data which is not included in the chunk itself and might be some edge flag bitmaps.
struct MCNR {
  struct MCNREntry {
    int8_t normal[3];             // normalized. X, Z, Y. 127 == 1.0, -127 == -1.0.
  } entries[9*9+8*8];
uint8_t unknown[3*3+2*2];         // this data is not included in the MCNR chunk but additional data which purpose is unknown.
                                  // always 0 112 245  18 0  8 0 0  0 84  245 18 0. Nobody yet found a different pattern. The data is not derived from the normals.
                                  // It also does not seem that the client reads this data. --Schlumpf (talk) 23:01, 26 July 2015 (UTC)
                                  // While stated that this data is not "included in the MCNR chunk", the chunk-size defined for the MCNR chunk does cover this data. --Kruithne Feb 2016
                                  // ... from Cataclysm only (on LK files and before, MCNR defined size is 435 and not 448) Mjollna (talk)

MCLY sub-chunk

  • split files: tex

Complete and right as of 19-AUG-09 (3.0.9 or higher)

  • Texture layer definitions for this map chunk. 16 bytes per layer, up to 4 layers (thus, layer count = size / 16).

Every texture layer other than the first will have an alpha map to specify blending amounts. The first layer is rendered with full opacity. To know which alphamap is used, there is an offset into the MCAL chunk. That one is relative to MCAL.

You can animate these by setting the flags. Only simple linear animations are possible. You can specify the direction in 45° steps and the speed.

The textureId is just the array index of the filename array in the MTEX chunk.

For getting the right feeling when walking, you should set the effectId which links to GroundEffectTextureRec::m_ID. It defines the little detail doodads as well as the footstep sounds and if footprints are visible. You can set the id to -1 (int16!) to have no detail doodads and footsteps at all. Also, you need to define the currently on-top layer in the MCNK structure for the correct detail doodads to show up!

Introduced in Wrath of the Lich King, terrain can now reflect a skybox. This is used for icecubes made out of ADTs to reflect something. You need to have the MTXF chunk in, if you want that. Look at an skybox Blizzard made to see how you should do it.

struct SMLayer
  uint32_t textureId; 
    uint32_t animation_rotation : 3;        // each tick is 45°
    uint32_t animation_speed : 3; 
    uint32_t animation_enabled : 1;
    uint32_t overbright : 1;                // This will make the texture way brighter. Used for lava to make it "glow".
    uint32_t use_alpha_map : 1;             // set for every layer after the first
    uint32_t alpha_map_compressed : 1;      // see MCAL chunk description
    uint32_t use_cube_map_reflection : 1;   // This makes the layer behave like its a reflection of the skybox. See below
    uint32_t unknown_0x800 : 1;             // WoD?+
    uint32_t unknown_0x1000 : 1;            // WoD?+
    uint32_t : 19;
  } flags;	
  uint32_t offsetInMCAL;
  foreign_key<uint32_t, &GroundEffectTextureRec::m_ID> effectId;     // 0xFFFFFFFF for none	
} layers[/* <= 4 */];

To know how much entries there are, read until you hit the end of the chunk. Or divide it by 16 (4 + 4 + 4 + 4)

  • Explanation for flag 0x400 (use_cube_map_reflection):

First of all you can see the effects in this video: Video The texture that became the 0x400 flag was the following: Media:4b795c7c7f36b_TCB_CrystalSong_B.jpg . Have a look at the bright points that wander with the toon as it moves. This should imitate the stars from the sky (that you can find in the texture).

There are some important things you should be aware when using the flag 0x400:

  • It doesnt matter for which layer you set the flag 0x400, it will always affect the groundlayer.
  • The common skyboxtextures need to have the same ration from width and height as the one posted above. If this isnt the case, it looks like that: Video You see that it doesnt really fit the shape.
  • All of the skyboxtextures blizzard has need to specify a special flag to be decompressed correctly. This is done using the MTXF-chunk. If the texture has a 1 in MTXF it will be interpreted correctly, else it will be green.


MCRF sub-chunk (<Cata)

This section only applies to versions ≤ Wrath. Now split into MCRD and MCRW.
  • A list of with MCNK.nDoodadRefs + MCNK.nMapObjRefs indices into the file's MDDF and MODF chunks, saying which MCNK subchunk those particular doodads and objects are drawn within. This MCRF list contains duplicates for map doodads that overlap areas.
uint32_t doodad_refs[header.nDoodadRefs]; // into MDDF
uint32_t object_refs[header.nMapObjRefs]; // into MODF

The client uses those MCRF-entries to calculate collision. Only objects which are referenced in the current chunk of the toon get checked against collision (this is only for MDX, WMO seem to have different collision). If a doodad entry from MDDF or MODF gets never referenced in a chunks MCRF it wont be drawn at all, WoW doesnt take the MDDF and MODF to draw the objects. --Cromon

MCRD (Cata+)

This section only applies to versions ≥ Cata.
  • split files: obj
uint32_t mddf_entry[];

MCRW (Cata+)

This section only applies to versions ≥ Cata.
  • split files: obj
uint32_t modf_entry[];

MCSH sub-chunk

  • split files: tex
  • Shadow map for static shadows on the terrain. Can be left out with the chunk&1 flag not set.
struct {
  uint1_t shadow_map[64][64];
} mcsh;

Thanks to Sylvain, the shadow maps work as follows: the shadows are stored per bit, not byte as 0 or 1 (off or on) so we have 8 bytes (which equates to 64 values) X 64 bytes (64 values in this case) which ends up as a square 64x64 shadowmap with either white or black. Note that the shadow values come LSB first.

MCAL sub-chunk

  • split files: tex
  • Alpha maps for additional texture layers.

There are 3 kinds of alpha maps here: Which one depends on MCLY (0x200) and WDT's MPHD (0x4 and 0x80) flags.

Uncompressed (2048)
0x200 set Compressed
0x4 or 0x80 set Uncompressed (4096)
0x200 set 0x4 or 0x80 set Compressed: MPHD is only about bit depth!

Additionally to this, MCNK can have (and mostly does have) the 0x8000 flag. If this flag is set and bit depth is 8 (WDT's MPHD has either flag), then modify alpha values so that if there is shadow at the corresponding position, the alpha value is multiplied by 0.7f (178 * alpha >> 8 to be exact).

Uncompressed (4096)

uint8_t alpha_map[64][64];

For 4096 byte chunks, just read the values straight into your alpha channel. This, again, should result in 4096 bytes for a 64px by 64px size in the final alpha map.

Uncompressed (2048)

uint4_t alpha_map[64][64]; // need to be normalized by shifting left and filling the lower nibble: (alpha << 4) | 0xF. (0 = 0xF, 1 = 0x1F, …, 15 = 0xFF) (this means that there are no zero-value entries?! the alternative would be multiplying by 17, which seems right-ish.)

Contains 2048 bytes of data, but each byte contains two values in LSB first order. This should result in a 4096 alpha map (64px by 64px).

  • Read a byte.
  • Split the byte into two 4-bit values. eg: b0101b a0101a
  • This results in 16 possible values for each pixel; 15 is full alpha and 0 is no alpha. If you want to normalize, multiply by 17 to get 0-255 values.
  • Record each value separately into the alpha channel in the order of a then b.

Not that depending on MCNK flag FLAG_DO_NOT_FIX_ALPHA_MAP, this is not actually a 64*64 map but rather a 63*63 map with the last row and column being equivalent to the previous one.

 struct { uint4_t alpha_map[63]; uint4_t ignored; }[63]; 
 uint4_t ignored[64];


alpha_map[x][63] == alpha_map[x][62]
alpha_map[63][x] == alpha_map[62][x]
alpha_map[63][63] == alpha_map[62][62]

and all "ignored" values are ignored, while still preserving the 2048 byte footprint.

  • I claim that this shall be handled by saving in fixed4444 only (i.e. always set mcnk.flags FLAG_DO_NOT_FIX_ALPHA_MAP and explicitly save the "fixed" (as in have all values) version). --Schlumpf (talk) 21:45, 24 October 2015 (UTC)


  enum class mode_t
    copy = 0,              // append value[0..count - 1]
    fill = 1,              // append value[0] count times
  uint8_t mode : 1;
  uint8_t count : 7;
  uint8_t value[];
} compressed_alpha_map[];  // size depends on content. will decompress to exactly 64*64 bytes.
                           // minimum size is 32 times copy-127-x plus one copy-32-x, thus 66 bytes
                           // maximum size is 32 times fill-127-x[127] plus one fill-32-x[127], thus 4129 bytes
  • read a byte
  • in the first bit of that byte (sign bit) check if it's true. When true that means we are in "fill" mode, if false, "copy" mode
  • the next 7 bits of the byte determine how many times we "fill" or "copy" (count) (eg, max value 127)
  • fill mode: repeat the byte following the one we just read *count* number of times into the alpha map
  • copy mode: read *count* number of following bytes into the alpha map
  • repeat until the map is complete


  • this should result in 4096 bytes in the alpha map (64 px by 64 px)
  • you should not have any extra compression data left over after completion
  • reads left to right, top to bottom

-- Michael Redig 25-5-2015

-- Flow 21-10-2008

Sample C++ code
unsigned offI = 0; //offset IN buffer
unsigned offO = 0; //offset OUT buffer
char* buffIn; // pointer to data in adt file
char buffOut[4096]; // the resulting alpha map

while( offO < 4096 )
  // fill or copy mode
  bool fill = buffIn[offI] & 0x80;
  unsigned n = buffIn[offI] & 0x7F;
  for( unsigned k = 0; k < n; k++ )
    buffOut[offO] = buffIn[offI];
    if( !fill )
  if( fill ) offI++;


Blizzard has changed the way how the additional textures are blended onto the ground texture in Northrend (old continents still seem to be blended the old way; they also don't use the new alpha map format). They have gone from a "one-layer-per-step" approach to blending all the 4 textures in a single step according to the following formula:

finalColor = tex0 * (1.0 - (alpha1 + alpha2 + alpha3)) + tex1 * alpha1 + tex2 * alpha2 + tex3 * alpha3

So all the alpha values for the different layers including the ground layer add up to 1.0; the ground layer's alpha value is calculated to match this constraint.

-- Slartibartfast 01-11-2008

How to render

It is of course possible to devise different ways to render such terrain; one way I use and of which I know that it's working is a 2-pass-approach: first render all ground textures without blending, then use a fragment shader program to mix the 1-3 additional layer textures and render them with a glBlendFunc setting of (GL_ONE, GL_ONE_MINUS_SRC_ALPHA) on top of the ground texture already present in the framebuffer. The fragment program that mixes the textures would have to work like this short GLSL example:

gl_FragColor =   texture2D(texture0, vec2(gl_TexCoord[0])) * texture2D(texture3, vec2(gl_TexCoord[3])).r
               + texture2D(texture1, vec2(gl_TexCoord[1])) * texture2D(texture3, vec2(gl_TexCoord[3])).g
               + texture2D(texture2, vec2(gl_TexCoord[2])) * texture2D(texture3, vec2(gl_TexCoord[3])).b;

(this example uses 4 texture units: texture0 - texture3; the first 3 of them contain the actual textures, while the fourth unit contains the alpha maps combined in one RGB texture)

Also, seems like alpha textures are upscaled using bicubic interpolation. --Deamon (talk) 21:49, 11 October 2015 (UTC)

MCLQ sub-chunk

This section only applies to versions ≤ BC. Deprecated, but still parsed. Replaced with MH2O.
  • split files: root
  • Water levels for this map chunk. This chunk is old and not really used anymore. Still, there is backwards compatibility in the client as old ADTs are not updated as it would be much data to patch it. I guess, it will be done in some expansion. You can fully use this chunk, even to have multiple water. You can have a lot of stacked water with this and the MH2O one.
  • Deprecated with WotLK: I advise you to implement the MH2O one as its better if you want to write a editor for ADT files.

The size of the chunk is in the mapchunk header. The type of liquid is given in the mapchunk flags, also in the header.

This information is old and incomplete as well as maybe wrong.

The first two floats specify the minimum and maximum liquid height level. After them comes a 9x9 height map for the water with the following format per vertex:

Offset 	Type 	Description
0x00 	int16 	?
0x02 	int16 	?
0x04 	float 	height value

The unknown int values might be color or transparency info, or something entirely different... Most frequently they are 0.

Followed by 8x8 bytes of flags for every liquid "tile" between the 9x9 vertex grid. The value 0x0F means do not render. (the specific flag for this seems to be 8 but I'm not sure - but it fixes some places where there was extra "water" sticking into the rest of the scenery)

Finally, 0x54 bytes of additional data, no idea what it's used for.

MCSE sub-chunk

  • split files: root
  • Sound emitters.

This seems to be a bit different to that structure, ObscuR posted back then. From what I can see, WoW takes only 0x1C bytes per entry. Quite a big difference. This change might have happened, when they introduced the SoundEntriesAdvancedRec.

struct CWSoundEmitter
/*000h*/  foreign_key<uint32_t, &SoundEntriesAdvancedRec::m_ID> entry_id;
/*004h*/  C3Vector position;
/*010h*/  C3Vector size; 					// I'm not really sure with this. I'm far too lazy to analyze this. Seems like 
                                                           noone ever needed these anyway.
} MCSE[];

old one by ObscuR (for older versions)

struct CWSoundEmitter // 04-29-2005 By ObscuR (Maybe not accurate but should look like this :p )
/*000h*/  UINT32 soundPointID;		
/*004h*/  UINT32 soundNameID;		
/*008h*/  float  pos[3];		
/*014h*/  float minDistance;	 		
/*018h*/  float maxDistance;	
/*01Ch*/  float cutoffDistance;		
/*020h*/  UINT16 startTime;	
/*022h*/  UINT16 endTime;
/*024h*/  UINT16 groupSilenceMin;		
/*026h*/  UINT16 groupSilenceMax; 	
/*028h*/  UINT16 playInstancesMin;
/*02Ah*/  UINT16 playInstancesMax;	
/*02Ch*/  UINT16 loopCountMin;
/*02Eh*/  UINT16 loopCountMax;
/*030h*/  UINT16 interSoundGapMin;
/*032h*/  UINT16 interSoundGapMax;
} MCSE[];


This section only applies to versions ≥ Mists.
  • split files: root
struct // blend batches. max 256 per MCNK
  uint32_t mbmh_index;
  uint32_t indexCount; // MBMI
  uint32_t indexFirst; // in addition to mbmh.mbnv_base
  uint32_t vertexCount; // MBNV 
  uint32_t vertexFirst; // in addition to mbmh.mbnv_base
} MCBB[];

MCMT (Cata+)

This section only applies to versions ≥ Cata.
  • split files: tex
  foreign_key<uint8_t, &TerrainMaterialRec::m_ID> material_id[4]; // per MCLY

MCDD (Cata?+)

This section only applies to versions ≥ Cata.
  • split files: root?
struct // at least seen in WoD
  // there seems to be a high-res (?) mode which is not taken into account 
  // in live clients (32 bytes instead of 8) (?). if inlined to MCNK is low-res.
  uint1_t disable[8][8];          // disable detail doodads here
  // uint1_t disable[16][16];

MFBO chunk (BC+)

This section only applies to versions ≥ BC.
  • split files: root
  • A bounding box for flying.

This chunk is a "box" defining, where you can fly and where you can't. It also defines the height at which one you will fall into nowhere while your camera remains at the same position. Its actually two planes with 3*3 coordinates per plane.

Therefore the structure is:

struct plane{
   short[3][3] height;
   plane maximum;
   plane minimum;

MTXF chunk (WotLK+)

This section only applies to versions ≥ Wrath.
  • split files: tex

Array of flags for entries in MTEX. Always same number of entries as MTEX.

struct SMTextureFlags
  uint32_t do_not_load_specular_or_height_texture : 1; // probably just 'disable_all_shading'
  uint32_t : 3;                                        // no non-zero values in 20490
  uint32_t texture_scale : 4;                          // MoP+
  uint32_t : 24;                                       // no non-zero values in 20490
} MTXF[];

In WotLK this is mostly used for layers using terrain cube maps (e.g. crystalsong's "TILESET\\Terrain Cube Maps\\TCB_CrystalSong_A.blp"). Without this flag, it would try to load the _s.blp and fail loading.

MTXP chunk (MoP?+)

This section only applies to versions ≥ Mists.
  • split files: tex
struct SMTextureParams
  SMTextureFlags flags; // same as in mtxf (or taken from there if no mtxp present)
  float height;         // default 0.0 -- the _h texture values are scaled to [0, value) to determine actual "height".
                        // this determines if textures overlap or not (e.g. roots on top of roads)
  float unk2;           // default 1.0 -- some kind of weight
  uint32_t unk3;        // padding? (no default, no non-zero values in 20490)
} MTXP[];

If unk1 == 0.0 and unk2 == 1.0, it will not load a _h texture.


This section only applies to versions ≥ Mists.
  • split files: root
  • there can be multiple entries per map object (as different textures are possible)
struct // blend mesh header
  uint32_t mapObjectID; // (unique ID)
  uint32_t textureId; // of linked WMO
  char unknown[0xc];
  uint32_t mbmi_base; // first index into MBMI for this mesh
  uint32_t mbnv_base; // first index into MBNV for this mesh
} MBMH[];


This section only applies to versions ≥ Mists.
  • split files: root
  • each one corresponds to a MBMH entry of same index
struct // blend mesh bounding boxes
  uint32_t mapObjectID; // (unique ID) -- repeated for unknown reason
  CAaBox bounding;
} MBBB[];


This section only applies to versions ≥ Mists.
  • split files: root
struct // blend mesh vertices
  C3Vector pos;
  C3Vector normal;
  C2Vector texture_coordinates;
  CArgb color[3]; // used: PN: none; PNC: 0; PNC2: 0, 1; PNC2T: 0, 2
} MBNV[];


This section only applies to versions ≥ Mists.
  • split files: root
struct // blend mesh indices
  uint16_t index;
} MBMI[];

MAMP (Cata+)

This section only applies to versions ≥ Cata.
  • split files: tex
  char fred; // texture_size = 64 / (2^mamp_value). either defined here or in MHDR.mamp_value. 
} mamp;

MLHD (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
  uint32_t unknown;
  float some_kind_of_bounding[6];
} ml_header;

MLVH (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
float ml_v_heightData[129*129 + 128*128 + additional]; // interleaved global height map + additional data of not fixed size 

MLVI (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
uint16_t ml_v_indices[];

MLLL (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
  float _0; // some kind of size/lod band/distance/level, 32, 16, 8…
  uint32_t _1;
  uint32_t _2;
  uint32_t _3;
  uint32_t _4;
} ml_ll;

MLND (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
  uint32_t _0;
  uint32_t _1;
  uint32_t _2;
  uint32_t _3;
  uint16_t indices[4];
} ml_nd[];

MLSI (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
uint16_t ml_skirtIndices[]; // into MLVH

MLLD (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
struct SMLodLiquidData
    Flag_HasTileData = 1,
    _compressed_A = 2,
    _compressed_B = 4,
  uint32_t m_flags;
  // … compressed (rle?) or uncompressed data, two blobs (16384 and 2048)
} lodLiquidData[];

MLLN (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod

MLLN, MLLI and MLLV are order-dependent. A MLLN introduces a new liquid, the following MLLI defines the indices, the next MLLV the vertices.

struct MLLN
  uint32_t _0;
  uint32_t num_indices; // MLLI
  uint32_t _2;
  uint16_t _3a;
  uint16_t _3b;
  uint32_t _4;
  uint32_t _5;
} ml_liquid_n;

MLLV (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
C3Vector ml_liquid_vertices[];

MLLI (Legion+)

This section only applies to versions ≥ Legion.
  • split files: lod
C3sVector ml_liquid_indices[]; // 3 shorts into MLLV

MLMD (Legion+)

This section only applies to versions ≥ Legion.
  • split files: obj1
struct {                        // same as MODF but without bounding box (may be out of sync), better look at both
  uint32_t mwidEntry;
  uint32_t uniqueId;
  C3Vector position;
  C3Vector rotation;
  uint16_t flags;
  uint16_t doodadSet;
  uint16_t nameSet;
  uint16_t unk;
} lod_object_defs[];

MLMX (Legion+)

This section only applies to versions ≥ Legion.
  • split files: obj1
  CAaBox bounding;
  float radius;
} lod_object_extents[]; // same count as MLMD

MLDD (Legion+)

This section only applies to versions ≥ Legion.
  • split files: obj1
SMDoodadDef lod_doodad_defs[]; // see MDDF

MLDX (Legion+)

This section only applies to versions ≥ Legion.
  • split files: obj1
  CAaBox bounding;
  float radius;
} lod_doodad_extents[]; // same count as MLDD