ADT/v18

From wowdev
Revision as of 02:52, 13 July 2007 by Malu05 (talk | contribs) (New page: Retrived from; http://wowdev.org/wiki/index.php/ADT == THIS IS ONLY A TEST PAGE. == From WoWDev Contents * 1 ADT Files o 1.1 MHDR chunk o 1.2 MCIN chunk ...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Retrived from; http://wowdev.org/wiki/index.php/ADT


THIS IS ONLY A TEST PAGE.

From WoWDev Contents 

   * 1 ADT Files
         o 1.1 MHDR chunk
         o 1.2 MCIN chunk
         o 1.3 MTEX chunk
         o 1.4 MMDX chunk
         o 1.5 MMID chunk
         o 1.6 MWMO chunk
         o 1.7 MWID chunk
         o 1.8 MDDF chunk
         o 1.9 MODF chunk
   * 2 MCNK chunks
         o 2.1 MCVT sub-chunk
         o 2.2 MCNR sub-chunk
         o 2.3 MCLY sub-chunk
         o 2.4 MCRF sub-chunk
         o 2.5 MCSH sub-chunk
         o 2.6 MCAL sub-chunk
         o 2.7 MCLQ sub-chunk
         o 2.8 MCSE sub-chunk

[edit] ADT Files

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. [edit] MHDR chunk

struct SMAreaHeader // 03-29-2005 By ObscuR { 

/*000h*/  UINT32 pad;
/*004h*/  UINT32 offsInfo;		
/*008h*/  UINT32 offsTex;		
/*00Ch*/  UINT32 offsModels;		
/*010h*/  UINT32 offsModelsIds;		
/*014h*/  UINT32 offsMapObejcts;		
/*018h*/  UINT32 offsMapObejctsIds;		
/*01Ch*/  UINT32 offsDoodsDef;		
/*020h*/  UINT32 offsObjectsDef;	
/*024h*/  UINT32 pad1;	
/*028h*/  UINT32 pad2;		
/*02Ch*/  UINT32 pad3;	
/*030h*/  UINT32 pad4;		
/*034h*/  UINT32 pad5;		
/*038h*/  UINT32 pad6;		
/*03Ch*/  UINT32 pad7;	
/*040h*/

};

Header chunk. Contains offsets (relative to 0x14) for some other chunks that appear in the file. Since the file follows a well-defined structure, this is redundant information. [edit] MCIN chunk

Index for MCNK chunks. Contains 256 records of 16 bytes, which have the following format: Offset Type Description 0x0 uint32 MCNK chunk absolute offset 0x4 uint32 MCNK size in bytes 0x8 8 bytes 0

struct SMChunkInfo // 03-29-2005 By ObscuR { 

/*000h*/  UINT32 offset;
/*004h*/  UINT32 size;		
/*008h*/  UINT32 flags;		
/*00Ch*/  UINT32 asyncId;;		
/*010h*/

};

This is also redundant information but kind of convenient. [edit] MTEX chunk

List of textures used by the terrain in this map tile. A contiguous block of zero-terminated strings, that are complete filenames with paths. The textures will later be identified by their position in this list. [edit] MMDX chunk

List of filenames for M2 models that appear in this map tile. A contiguous block of zero-terminated strings. [edit] MMID chunk

Lists the relative offsets of string beginnings in the above MMDX chunk. (sort of redundant) One 32-bit integer per offset. [edit] MWMO chunk

List of filenames for WMOs (world map objects) that appear in this map tile. A contiguous block of zero-terminated strings. [edit] MWID chunk

Lists the relative offsets of string beginnings in the above MWID chunk. (again, redundant) One 32-bit integer per offset. [edit] MDDF chunk

Placement information for doodads (M2 models). 36 bytes per model instance. Offset Type Description 0x00 uint32 ID (index in the MMDX list) 0x04 uint32 unique identifier for this instance 0x08 3 floats Position (X,Y,Z) 0x14 3 floats Orientation (A,B,C) 0x20 uint32 scale factor * 1024

struct SMDoodadDef // 03-31-2005 By ObscuR { /*000h*/ UINT32 nameId; /*004h*/ UINT32 uniqueId; /*008h*/ float pos[3]; /*00Ch*/ /*010h*/ /*014h*/ float rot[3]; /*018h*/ /*01Ch*/ /*020h*/ UINT16 flags; /*022h*/ UINT16 scale; /*024h*/ };

The instance information specifies the actual M2 model to use, its absolute position and orientation within the world. The orientation is defined by rotations (in degrees) about the 3 axes as such (this order of operations is for OpenGL, so the transformations "actually" happen in reverse): 

  1. Rotate around the Y axis by B-90
  2. Rotate around the Z axis by -A
  3. Rotate around the X axis by C

Finally the scale factor is given by an integer, multiplied by 1024. So the model needs to be scaled by scale/1024. I wonder why they didn't just use a float. [edit] MODF chunk

Placement information for WMOs. 64 bytes per wmo instance. Offset Type Description 0x00 uint32 ID (index in the MWMO list) 0x04 uint32 unique identifier for this instance 0x08 3 floats Position (X,Y,Z) 0x14 3 floats Orientation (A,B,C) 0x20 3 floats Position 2 - ? 0x2C 3 floats Position 3 - ? 0x38 uint16 unknown (always 0?) 0x3A uint16 Doodad set index 0x3C uint32 Name set

struct SMMapObjDef // 03-29-2005 By ObscuR { /*000h*/ UINT32 nameId; /*004h*/ UINT32 uniqueId; /*008h*/ float pos[3]; /*00Ch*/ /*010h*/ /*014h*/ float rot[3]; /*018h*/ /*01Ch*/ /*020h*/ float extents[6]; /*024h*/ /*028h*/ /*02Ch*/ /*030h*/ /*034h*/ /*038h*/ UINT32 flags; /*03Ch*/ UINT16 doodadSet; /*03Eh*/ UINT16 nameSet; /*040h*/ };

The positioning and orientation is done the same way as in the MDDF chunk. There is no scaling. Two additional positions and two integers are also given. They might or might not be used for lighting...?

The unique identifier is important for WMOs, because multiple map tiles might want to draw the same WMO. This identifier is used to ensure that each specific instance can only be drawn once. (a unique identifier is required because the model name is not usable for this purpose, since it is possible to have more than one instance of the same WMO, like some bridges in Darkshore) [edit] MCNK chunks

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. I will only list the known fields in the header. Offset Type Description 0x3C uint32 holes in terrain 0x68 float Z' base coordinate 0x6C float X' base coordinate 0x70 float Y base coordinate

struct SMChunk // 03-29-2005 By ObscuR { enum { FLAG_SHADOW, FLAG_IMPASS, FLAG_LQ_RIVER, FLAG_LQ_OCEAN, FLAG_LQ_MAGMA, }; /*000h*/ UINT32 flags; /*004h*/ UINT32 IndexX; /*008h*/ UINT32 IndexY; /*00Ch*/ UINT32 nLayers; /*010h*/ UINT32 nDoodadRefs; /*014h*/ UINT32 offsHeight; /*018h*/ UINT32 offsNormal; /*01Ch*/ UINT32 offsLayer; /*020h*/ UINT32 offsRefs; /*024h*/ UINT32 offsAlpha; /*028h*/ UINT32 sizeAlpha; /*02Ch*/ UINT32 offsShadow; /*030h*/ UINT32 sizeShadow; /*034h*/ UINT32 areaid; /*038h*/ UINT32 nMapObjRefs; /*03Ch*/ UINT32 holes; /*040h*/ UINT16 unk1; /*040h*/ UINT16 unk2; /*044h*/ UINT32 unk3; /*048h*/ UINT32 unk4; /*04Ch*/ UINT32 unk5; /*050h*/ UINT32 predTex; /*054h*/ UINT32 noEffectDoodad; /*058h*/ UINT32 offsSndEmitters; /*05Ch*/ UINT32 nSndEmitters; /*060h*/ UINT32 offsLiquid; /*064h*/ UINT32 sizeLiquid; /*068h*/ float pos[3]; /*06Ch*/ /*070h*/ /*074h*/ UINT32 textureId; /*078h*/ UINT32 props; /*07Ch*/ UINT32 effectId; /*080h*/ };


The X' and Z' coordinates specify the top left corner of the map chunk, but they are in an alternate coordinate system! (yay for consistency!) This one has its 0,0 point in the middle of the world, and has the axes' directions reversed.

X = 32*533.3333 - X'

Z = 32*533.3333 - Z'

The Y base coordinate acts as a 'zero point' for the height values in the upcoming height map - that is, all height values are added to this Y height.

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

With this I've been able to fix some holes, the most obvious one being the Gates of Ironforge but there are some glitches for some other holes like the Lakeshire Inn - maybe this would require the more detailed height maps or for me to use a less cheap way to omit the hole triangles. :) [edit] MCVT sub-chunk

These are the actual height values for the 9x9+8x8 vertices. 145 floats in the following order/arrangement:. 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

. . . . . . . .


WoWmapview currently only uses the "outer" 9x9 vertices, since I couldn't figure out a way to stripify the more detailed geometry. 

   *
   o

Inner 8 vertices are only rendered in WoW when its using the up-close LoD. Otherwise, it only renders the outer 9. -Eric 

   *
   o


+ + + + [guest] : 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 } }

+ + + +

- will do, thanks :) - Z. [edit] MCNR sub-chunk

Normal vectors for each vertex, encoded as 3 signed bytes per normal, in the same order as specified above.

The size field of this chunk is wrong! Actually, it isn't wrong, but there are a few junk (unknown?) bytes between the MCNR chunk's end and the next chunk. The size of the MCNR chunk should be adjusted to 0x1C0 bytes instead of 0x1B3 bytes.

Normals are stored in X,Z,Y order, with 127 being 1.0 and -127 being -1.0. The vectors are normalized.

--Log 09:23, 28 May 2006 (EEST) May be the extra data are "edge flags" bitmap that used only by client for smoothing normals around adjustent triangles ? I did't check it, just a hint. [edit] MCLY sub-chunk

Texture layer definitions for this map chunk. 16 bytes per layer, up to 4 layers. Offset Type Description 0x0 uint32 texture ID (offset into MTEX list) 0x4 uint32 flags 0x8 uint32 offset to alpha map 0xC uint32 detail texture ID Flag Description 0x80  ? 0x100 Use alpha map - set for every layer after the first

The flags 0x1E0 are often used for Lava textures that might be animated in the Searing Gorge. Not sure about the individual flags. The detail texture ID refers to the first column in GroundEffectTexture.dbc.


struct SMLayer // 03-29-2005 By ObscuR { /*000h*/ UINT32 textureId; /*004h*/ UINT32 props; /*008h*/ UINT32 offsAlpha; /*00Ch*/ UINT32 effectId;; /*010h*/ };


The size of this chunk will determine the number of textures used for this map chunk. Every texture layer other than the first will have an alpha map to specify blending amounts. The first layer is rendered with full opacity. [edit] MCRF sub-chunk

A list of indices into the parent file's MDDF chunk, saying which MCNK subchunk those particular MDDF doodads are drawn within. This MCRF list contains duplicates for map doodads that overlap areas. But I guess that's what the MDDF's UniqueID field is for. [edit] MCSH sub-chunk

Shadow map for static shadows on the terrain.

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

Note that the shadow values come LSB first. - Z. [edit] MCAL sub-chunk

Alpha maps for additional texture layers. For every layer, a 32x64 array of alpha values. Can be used as a secondary texture with the modulation op to control the blending of the texture layers. For video cards with 2 texture units, this requires one pass per layer. (For 4 or more texture units, maybe this could be done faster using register combiners? Pixel shaders maybe?)

The size field of this chunk might be wrong for map chunks with zero texture layers. There are a couple of these in some of the development maps.

Similar to the shadow maps, the 32x64 bytes is really a 64x64 alpha map. There are 2 alpha values per byte, first 4 bits and second 4 bits. -Eric

Funny how this happened to work for the wrong sizes, too, because the upper 4 bits became the most significant in the alpha map, and the lower 4 appeared as noise. I sure didn't notice the difference :) It's fixed now of course. - Z. [edit] MCLQ sub-chunk

Water levels for this map chunk


The size field of this chunk is wrong! It's always 0. If there is really no data, an empty MCSE chunk will follow right after the size field.

Currently I'm only using the first float for a static water level per chunk, however, there is more data that needs to be figured out :) and for non-horizontal rivers or waterfalls it should be used properly.

Note by ObscuR : The first float is the water altitude, second is the base magma heigth ,and the rest of data is the magma heigth map (8*8)


My second look at this chunk:

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

The first two floats specify a liquid height level. (they are identical...?), 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 bu 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. [edit] MCSE sub-chunk

Sound emitters

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];		
/*00Ch*/   		
/*010h*/  		
/*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;
/*034h*/

};

Retrieved from "http://wowdev.org/wiki/index.php/ADT"

Categories: World of Warcraft Files | Files World Views 

   * Article
   * Discussion
   * Edit
   * History

Personal tools 

   * Create an account or log in

Navigation 

   * Main Page
   * Community portal
   * Current events
   * Recent changes
   * Random page
   * Help
   * Donations

Search

Toolbox 

   * What links here
   * Related changes
   * Upload file
   * Special pages
   * Printable version

MediaWiki GNU Free Documentation License 1.2 

   * This page was last modified 05:32, 14 January 2007.
   * This page has been accessed 3,510 times.
   * Content is available under GNU Free Documentation License 1.2.
   * About WoWDev
   * Disclaimers
Retrieved from "https://wowdev.wiki/index.php?title=ADT/v18&oldid=6"