M2
M2 files (also called MDX) contain model objects. Each M2 file describes the vertices, faces, materials, texture names, animations and properties of one model. M2 files don't have a chunked format like most other WoW formats (except in Legion). Since it is chunked in Legion, all offsets are relative to beginning of the MD21 chunk's data rather than the beginning of the file.
Models are used for doodads (decoration objects), players, monsters and really everything in the game except for Terrain and WMOs.
M2 files do not store all the data for the model in them. Additional model information is stored in these files: .anim, .skin, .phys, .bone, .skel which may vary depending on the client version. Details on how to request and read them are described in the page below.
Header
The header has mostly the layout of number-offset pairs, containing the number of a particular record in the file, and the offset. These appear at fixed places in the header. Record sizes are not specified in the file.
struct
{
// note: Offsets are for ≥ 
!
/*0x000*/ uint32_t magic; // "MD20". Legion uses a chunked file format starting with MD21.
/*0x004*/ uint32_t version;
/*0x008*/ M2Array<char> name; // should be globally unique, used to reload by name in internal clients, empty string in files updated in or after 9.2.0.41462+
/*0x010*/ struct
{
uint32_t flag_tilt_x : 1;
uint32_t flag_tilt_y : 1;
uint32_t : 1;
#if ≥ 
// TODO: verify version
uint32_t flag_use_texture_combiner_combosᵛ : 1; // add textureCombinerCombos array to end of data (alt. name: Second_Texture_Material_Override_Combos)
uint32_t : 1;
#if ≥ 
uint32_t flag_load_phys_data : 1;
uint32_t : 1;
#if ≥ 
uint32_t flag_unk_0x80 : 1; // with this flag unset, demon hunter tattoos stop glowing
// since 
(4.0.1.12911)ᵘ everyᵘ model now has this flag
uint32_t flag_camera_related : 1; // TODO: verify version
#if ≥ 
// TODO: verify version, these are just added based on where I first saw them -- schlumpf.
uint32_t flag_new_particle_record : 1; // In CATA: new version of ParticleEmitters. By default, length of M2ParticleOld is 476.
// But if 0x200 is set or if version is bigger than 271, length of M2ParticleOld is 492.
uint32_t flag_unk_0x400 : 1;
uint32_t flag_texture_transforms_use_bone_sequences : 1; // ≥ 0x800 -- When set, texture transforms are animated using the sequence being played on the bone found by index in tex_unit_lookup_table[textureTransformIndex], instead of using the sequence being played on the model's first bone. Example model: 6DU_HellfireRaid_FelSiege03_Creature
uint32_t flag_unk_0x1000 : 1;
uint32_t ChunkedAnimFiles_0x2000 : 1; // seen in various legion models
uint32_t flag_unk_0x4000 : 1; // "armor2 model"?
uint32_t flag_unk_0x8000 : 1; // seen in UI_MainMenu_Legion
uint32_t flag_unk_0x10000 : 1;
uint32_t flag_unk_0x20000 : 1;
uint32_t flag_unk_0x40000 : 1;
uint32_t flag_unk_0x80000 : 1;
uint32_t flag_unk_0x100000 : 1;
uint32_t flag_unk_0x200000 : 1; // apparently: use 24500 upgraded model format: chunked .anim files, change in the exporter reordering sequence+bone blocks before name
#endif
#endif
#endif
#endif
} global_flags;
/*0x014*/ M2Array<M2Loopⁱ> global_loops; // Timestamps used in global looping animations.
/*0x01C*/ M2Array<M2Sequenceⁱ> sequences; // Information about the animations in the model.
/*0x024*/ M2Array<uint16_tⁱ> sequenceIdxHashById; // Mapping of sequence IDs to the entries in the Animation sequences block.
#if ≤
M2Array<M2SequenceFallbackⁱ> playable_animation_lookup;
#endif
/*0x02C*/ M2Array<M2CompBoneⁱ> bones; // MAX_BONES = 0x100 => Creature\SlimeGiant\GiantSlime.M2 has 312 bones ()
=> World\Expansion01\Doodads\Auchindoun\Passivedoodads\Bridge_FX\Auchindoun_Bridge_Spirits_Flying.m2 has 305 bones ()
/*0x034*/ M2Array<uint16_tⁱ> boneIndicesById; //Lookup table for key skeletal bones. (alt. name: key_bone_lookup)
/*0x03C*/ M2Array<M2Vertexⁱ> vertices;
#if ≤
M2Array<M2SkinProfileⁱ> skin_profiles;
#else
/*0x044*/ uint32_t num_skin_profiles; // Views (LOD) are now in .skins.
#endif
/*0x048*/ M2Array<M2Colorⁱ> colors; // Color and alpha animations definitions.
/*0x050*/ M2Array<M2Textureⁱ> textures;
/*0x058*/ M2Array<M2TextureWeightⁱ> texture_weights; // Transparency of textures.
#if ≤
M2Array<M2TextureFlipbook> texture_flipbooks; // never seen in file, 4 uint32_t fields. (M2Track<ushort>)
#endif
/*0x060*/ M2Array<M2TextureTransformⁱ> texture_transforms;
/*0x068*/ M2Array<uint16_tⁱ> textureIndicesById; // (alt. name: replacable_texture_lookup)
/*0x070*/ M2Array<M2Materialⁱ> materials; // Blending modes / render flags.
/*0x078*/ M2Array<uint16_tⁱ> boneCombos; // (alt. name: bone_lookup_table)
/*0x080*/ M2Array<uint16_tⁱ> textureCombos; // (alt. name: texture_lookup_table)
/*0x088*/ M2Array<uint16_tⁱ> textureCoordCombosᵛ; // (alt. name: tex_unit_lookup_table, texture_mapping_lookup_table)
/*0x090*/ M2Array<uint16_tⁱ> textureWeightCombos; // (alt. name: transparency_lookup_table)
/*0x098*/ M2Array<uint16_tⁱ> textureTransformCombos; // (alt. name: texture_transforms_lookup_table)
/*0x0A0*/ CAaBoxⁱ bounding_box; // min/max( [1].z, 2.0277779f ) - 0.16f seems to be the maximum camera height
/*0x0B8*/ float bounding_sphere_radius; // detail doodad draw dist = clamp (bounding_sphere_radius * detailDoodadDensityFade * detailDoodadDist, …)
/*0x0BC*/ CAaBoxⁱ collision_box;
/*0x0D4*/ float collision_sphere_radius;
/*0x0D8*/ M2Array<uint16_tⁱ> collisionIndices; // (alt. name: collision_triangles)
/*0x0E0*/ M2Array<C3Vectorⁱ> collisionPositions; // (alt. name: collision_vertices)
/*0x0E8*/ M2Array<C3Vectorⁱ> collisionFaceNormals; // (alt. name: collision_normals)
/*0x0F0*/ M2Array<M2Attachmentⁱ> attachments; // position of equipped weapons or effects
/*0x0F8*/ M2Array<uint16_tⁱ> attachmentIndicesById; // (alt. name: attachment_lookup_table)
/*0x100*/ M2Array<M2Eventⁱ> events; // Used for playing sounds when dying and a lot else.
/*0x108*/ M2Array<M2Lightⁱ> lights; // Lights are mainly used in loginscreens but in wands and some doodads too.
/*0x110*/ M2Array<M2Cameraⁱ> cameras; // The cameras are present in most models for having a model in the character tab.
/*0x118*/ M2Array<uint16_tⁱ> cameraIndicesById; // (alt. name: camera_lookup_table)
/*0x120*/ M2Array<M2Ribbonⁱ> ribbon_emitters; // Things swirling around. See the CoT-entrance for light-trails.
/*0x128*/ M2Array<M2Particleⁱ> particle_emitters;
#if ≥ // TODO: verify version
if (flag_use_texture_combiner_combos)
{
/*0x130*/ M2Array<uint16_tⁱ> textureCombinerCombos; // (alt. name: Second_Texture_Material_Override_Combos) When set, m2 multitexturing will use the second material from here, instead of current index material + 1, for blending with the first texture
}
#endif
} header;
Types
struct M2Bounds {
CAaBox extent;
float radius;
};
template<typename T>
struct M2Array {
uint32_t size;
uint32_t offset; // pointer to T, relative to begin of m2 data block (i.e. MD21 chunk content or begin of file)
};
struct M2TrackBase {
uint16_t trackType;
uint16_t loopIndex;
M2Array<M2SequenceTimes> sequenceTimes;
};
template<typename T>
struct M2PartTrack {
M2Array<fixed16> times;
M2Array<T> values;
};
template<typename T>
struct M2SplineKey {
T value;
T inTan;
T outTan;
};
struct M2Range {
uint32_t minimum;
uint32_t maximum;
};
Versions
Files get handled differently depending on this! Ranges are inclusive. Note that these versions are only rough estimates of their range. Prefer looking at the model you're opening rather than relying on the expansion mapping here.
| Version | Version (Major, Minor) | Expansion |
|---|---|---|
| 272-274 | 1.16-1.18 | Legion, Battle for Azeroth, Shadowlands |
| 272 | 1.16 | Mists of Pandaria, Warlords of Draenor |
| 265-272 | 1.9-1.16 | Cataclysm |
| 264 | 1.8 | Wrath of the Lich King |
| 260-263 | 1.4-1.7 | The Burning Crusade |
| 256-257 | 1.0-1.1 | Classic |
| 256 | 1.0 | Pre-Release |
The version is most likely a double-byte with major and minor version. This makes version 256 to 1.0, and 274 to 1.18 respectively.
Chunks
(7.0.1.20740).From Legion and up, the file might be chunked instead. If this is the case, the magic will be anything but 'MD20' and the m2 data will be in the 'MD21' chunk. If the first magic is 'MD20', it will be loaded just fine like it did previously. Note that the chunks can be in any order with MD21 often being first.
NOTE: Unlike all other chunked formats in WoW, chunk names in M2 are NOT reversed. Example: AFID == AFID in file.
MD21
(7.0.1.20740).The MD21 chunk contains the not yet chunked data, just like in the old format. The content literally is an pre legion file, starting with the MD20 magic. This also implies that all offsets inside this chunk are relative to the chunk, not the file.
M2Data pre_legion_style_data;
PFID
(7.0.1.20740). This used to be filename based, using ${basename}.phys.uint32_t phys_file_id;
SFID
(7.0.1.20740). This used to be filename based, using ${basename}${view}.skin and ${basename}_lod${lodband}.skin.uint32_t skinFileDataIDs[header.nViews]; uint32_t lod_skinFileDataIDs[lodBands /* 2? */];
Some model files, for example 'Creature\NightborneFemaleCitizen\NightborneFemaleCitizen.m2' have 4 skin files and 2 lod files but only 20 bytes are in chunk. In chunk there are 4 skins and 1 lod present.
Lod skins are selected based on distance to entity/doodad and chosen based on GetCVar("entityLodDist")/X and GetCVar("doodadLodDist")/X where X - distance. Lods are ignored when "M2UseLOD" CVar is set to 0.
AFID
(7.0.1.20740). This used to be filename based, using ${basename}${anim_id}-${sub_anim_id}.anim.struct
{
uint16_t anim_id;
uint16_t sub_anim_id;
uint32_t file_id; // might be 0 for "none" (so this is probably not sparse, even if it could be)
} anim_file_ids[];
BFID
(7.0.1.20740). This used to be filename based, using ${basename}_${i}.bone.uint32_t boneFileDataIDs[];
TXAC
. It is unknown what this replaced. Exact build unknown, not the first one thoughᵘ.struct {
char unk[2]; // likely used in CM2SceneRender::SetupTextureTransforms and uploaded to the shader directly. 0 otherwise.
} texture_ac[m2data.header.materials.count + m2data.header.particles.count];
This chunk doesn't seem to be used directly. Inside CParticleEmitter2 class there are non-null checks that deal with selection of VertexBufferFormat for particles. Apart from that, the usage of these fields is unknown
EXPT
. Appears to partially replace M2ParticleOld's variables. Exact build unknown, not the first one thoughᵘ.struct {
float zSource;
float colorMult;
float alphaMult;
} extended_particle[m2data.header.particles.count];
Probably outdated chunk after introduction of EXP2 chunk. If EXP2 doesnt exist, client tries to reconstruct it with data from EXPT chunk.
EXP2
(7.3.???). Appears to partially replace M2ParticleOld's variables. Exact build unknownᵘ.struct M2ExtendedParticle
{
float zSource;
float colorMult;
float alphaMult;
M2PartTrack<fixed16> alphaCutoff;
};
struct M2InitExtendedParticleArray
{
M2Array<M2ExtendedParticle> content;
} exp2;
The length of this M2Array is the same as length of particle_emitters
alphaCutoff is for alphaTest per particle. Index into alphaCutoff is particle's current lifetime
colorMult is applied against particle's diffuse color
alphaMult is applied against particle's opacity.
PABC
(7.3.???). Appears to replace #Animation_Lookupᵘ from old file. Exact build unknownᵘ.M2Array<uint16t> m_replacementParentSequenceLookups; // only seen in quillboarbrute*.m2. Contains AnimationIds
Replaces parentSequencesLookups. But unlike header.sequence_lookups of parent model, this is straight array and not a map. If index with target animation is not found in here, parentSequencesLookups are used instead.
This chunk called BlacklistAnimData in client.
Client doesnt seem to use found index and thus whole array is used only to check if the target animation is present.
M2InitBlacklistAnimData: sequenceIds
PADC
(7.3.???). Moves texture weights from old file to a chunk. Exact build unknownᵘ.Defines replacement for header.texture_weights (WHY?)
struct PADC {
M2Array<M2TextureWeight> texture_weights;
}
M2InitParentAnimData: parentTextureWeights
PSBC
(7.3.???). Exact build unknownᵘ.Defines ParentSequenceBounds
M2Array<M2Bounds> parentSequenceBounds;
M2InitParentSequenceBoundsData: M2Bounds
PEDC
(7.3.???). Exact build unknownᵘ.M2Array<M2TrackBase> parentEventData;
M2InitParentEventData: eventTracks
SKID
(7.3.???). This used to be filename based, using ${basename}.skel. Exact build unknownᵘ.uint32_t SKeletonfileID; // links to M2/.skel
TXID
(8.0.1.26629). Replaces the filename for {{#Textures}} with hardcoded type..Replaces in-file texture filenames.
struct {
uint32_t fileDataID;
} textureID[]
LDV1
(8.0.1.26629).Defines LodData
struct LodData
{
uint16 unk0;
uint16 lodCount; //maxLod = lodCount-1;
float unk2_f;
uint8_t particleBoneLod[4]; //lod serves as indes into this array
_DWORD unk4;
};
Somehow defines _lod%0d.skin files. On pandarenfemale.m2, lodCount == 4. SFID has 7 files first 4 are ordinary .skin files and last 3 are _lod%0d.skin files. Enumeration for _lod%0d.skin files for that model starts from 1, and last file in SFID is pandarenfemale_lod03.skin So technically maxLod indeed represents maximum Lod
unk2_f is used in formula, but it's purpose is unknown
fmaxf(fminf(740.0 / unk2_f, 5.0), 0.5);
LodData.particleBoneLod works this way: Each model has current lod which is [0..3]. Next:
if ( lod < 1 )
result = 0;
if ( LodData)
result = (0x10000 << LodData->particleBoneLod[lod]);
else
result = (0x10000 << (lod- 1));
...
//For each ParticleEmitter and related M2Particle record
if ( result & M2CompBone[M2Particle->old.boneIndex].flags ) {
//Do not animate this emitter
}
RPID
(8.1.0.27826). Replaces #M2ParticleOld's recursion_model_filename.struct {
uint32_t fileDataID; // referance a m2
} recursive_particle_models[particle count];
GPID
(8.1.0.27826). Replaces #M2ParticleOld's geometry_model_filename.struct {
uint32_t fileDataID; // referance a m2
} geometry_particle_models[particle count];
WFV1
(8.2.0.30080).struct WFV1 {
// unknown
};
WFV1 = WaterFallVersion1 Tells that model has PBR-ish stuff and normal map. It uses separate render path from usual M2.
First tested on waterfall in 8.2.0 (fdid 2445860). And at that moment it was WFV1.
Later this same tech was used to create different models, which have no relation to waterfalls. But internally even the name "waterfall" was kept.
Even stuff around areas in Shadowlands map is still called waterfall internally (fdid 3445776 for example). These models have WFV3 chunk.
WFV2
(8.2.0.30080).struct WFV2 {
// unknown
};
PGD1
(1.13.2.30172).ParticleGeosetData
struct PGD1Entry {
uint16_t geoset;
};
M2Array<PGD1Entry> p_g_d_v1; // count is equivalent to particle count
M2InitParticleGeosetData: m_emitterSelectionGroup
This sets geoset for each Particle emitter. And with this value Particle Emitter start to obey same geoset rules as in M2SkinSection.
WFV3
(9.0.1.33978). struct WaterFallDataV3 {
float bumpScale; //Passed to vertex shader
float value0_x;
float value0_y;
float value0_z;
float value1_w;
float value0_w;
float value1_x;
float value1_y;
float value2_w;
float value3_y;
float value3_x;
CImVector basecolor; // in rgba (not bgra)
uint16_t flags;
uint16_t unk0;
float values3_w;
float values3_z;
float values4_y;
float unk1;
float unk2;
float unk3;
float unk4;
}
"value" fields are passed directly to fragment shader.
PFDC
(9.0.1.33978).PHYS physics; char PADDING[6]; // follows right after the last chunk in PHYS, or it could be data, only seen 0's // likely it isn't 6 but "whatever is needed until the next 8 (or 16?) byte alignment". --Schlumpf (talk)
Contains inline physics information in the same structure as the .phys files.
EDGF
(9.0.1.33978).struct EDGF {
/*0x00*/ float _0x0[2];
/*0x08*/ float _0x8;
/*0x0C*/ char _0xC[0xC]
} edgf[];
EdgeFade. This data is applied to mesh only if M2Batch.flags2 has 0x8 flag
NERF
(9.0.1.33978).struct NERF {
C2Vector coefs;
};
Something related to calculation of alpha for whole model and related to distance. Components of coefs form ration with squared length of instanced model radius.
(coefs.x - squaredRadius) / (coefs.x - coefs.y)
And this value is used as multiplier for model instace's alpha.
Deamon (talk) 08:35, 30 April 2020 (CEST)
DETL
(9.0.1.34365).struct
{
/*0x00*/ uint16_t flags;
/*0x02*/ float16 scale; //scale for shadow RT matrix in half-float format
/*0x04*/ float16 diffuseColorMultiplier; // multiplier for M2Light.diffuse_color in half-float format
/*0x06*/ uint16_t unk0;
/*0x08*/ uint32_t unk1;
/*0x0a*/
} DETL_recs[m2data.header.lights.count];
Something related to lights
DBOC
(9.0.1.33978).struct
{
float unk1_1;
float unk1_2;
uint32 unk1_3;
uint32 unk1_4;
} DBOC;
Observed as 32 bytes in 9ARD_NebulaCloud_B01.m2, might be 2 entries, might not be. 10be_bloodelf_rf_banner01.m2 contains DBOC with a length of 16 bytes
AFRA
.Not observed in any files yet, presumably added in DF.
Skeleton and animation
Global sequences
A list of timestamps that act as upper limits for global sequence ranges.
struct M2Loop
{
uint32_t timestamp;
} loops[];
Standard animation block
- < uses a single-timeline approach, chaining all animations into one long piece and separating them via begin and end given in animation data. ≥ , each animation has an own timeline.
- Animation blocks contain a list of lists of timestamps and a list of lists of values, where the first list is by animation and the second one by timestamp-entry.
- Many values that change with time are specified using blocks like the following.
template<typename T>
struct M2Array
{
/*0x00*/ uint32_t number;
/*0x04*/ uint32_t offset_elements;
/*0x08*/
};
struct M2TrackBase
{
/*0x00*/ uint16_t interpolation_type;
/*0x02*/ uint16_t global_sequence;
#if <
M2Array<pair<uint32_t>> interpolation_ranges; // no longer required ≥ , as implicit by minimum and maximum timestamp per sequence.
M2Array<uint32_t> timestamps;
#else
/*0x04*/ M2Array<M2Array<uint32_t>> timestamps;
#endif
/*0x0C*/
};
template<typename T>
struct M2Track : M2TrackBase
{
/*0x00*/ // base
#if <
M2Array<T> values;
#else
/*0x0C*/ M2Array<M2Array<T>> values;
#endif
/*0x14*/
};
- Thus, as example, with
M2CompBoneⁱ b;
one may get the number of animations having translation information with
b.translation.timestamps.number
and the number of timestamps in the first animation using
b.translation.timestamps.elements[0].number
and the first timestamp value of the first animation via
b.translation.timestamps.elements[0].elements[0]
The actual translation vector for animation 0 at timestamp 0 is at
b.translation.values.elements[0].elements[0]
- Some timestamps/values.elements entries may have number/elements = 0, if for that animation id no animation is given.
- .anim files are just a blob of data which may as well be in the main model file, that is pointed to by the first array_ref layer.
- [model file name][animation id]-[animation sub-id].anim
- it seems like it is possible to detect if animation data is stored in-m2 or externally via
- All animations which have flags & 0x20 are stored internally.
- Animations which do not have flags & 0x20 are not stored internally.
- Animations which do not have flags & 0x20 AND do not have flags & 0x40 are in .anim files
- Animations which do not have flags & 0x20 AND DO have flags 0x40 are stored... somewhere. I have no clue.
Global Sequences
If a block has a sequence >= 0, the block has a completely separate max timestamp. This is the value in the model's ofsGlobalSequences table; index into that table with this sequence value and use that as the block's max timestamp. Blocks that use these global sequences also only have one track, so at the same time as clipping the current timestamp to the max time above, interpolated value should always be taken from track 0 in the block.
A global sequence is completely unrelated to animations. It just always loops. This way, the sequence is not interrupted when an animation is launched.
This appears to be frequently used by models that don't have more conventional animations (login screen animations, items/weapons with animated effects, etc).
-- Rour, additionally, these sequences can be longer or shorter than whatever animation is running for a given model, so I recommend taking a global scene timestamp and then clipping that value into the given max timestamp range. Otherwise animations will appear to reset when the regular animation loops, which is not good.
Interpolation
- If the interpolation type is 0, then values will change instantly at the timestamp, with no interpolation whatsoever.
- If the interpolation type is 1, then the block linearly interpolates between keyframe values (lerp for vectors/colours, nlerp for quaternions).
- If the interpolation type is 2, then cubic bezier spline interpolation is used. This is only valid for M2SplineKey tracks. When interpolating between two spline keys, the first control point is the first spline key's
value, the second control point is the first spline key'stanOut, the third control point is the second spline key'stanIn, and the fourth control point is the second spline key'svalue. - If the interpolation type is 3, then cubic hermite spline interpolation is used. This is only valid for M2SplineKey tracks. When interpolating between two spline keys, the starting point is the first spline key's
value, the starting tangent is the first spline key'stanOut, the ending tangent is the second spline key'stanIn, and the ending point is the second spline key'svalue.
NOTE: There is confusion about type 2 and 3 being hermite/bezier or bezier/hermite. Alpha says that 2 = hermite, WoD says that 2 = bezier. This was changed when the format went from MDL to M2. --Schlumpf (talk) 01:53, 4 September 2017 (CEST), --Barncastle (talk) 19:15, 14 November 2018 (GMT)
In WotLK 2 appears to be bezier, which pretty much confirms it being bezier for wotlk+. TBC and classic need further checking though. -- Skarn (talk) 01:38, 16 June 2018 (CEST)
.anim files
.Low priority sequences (e.g. emotes, one shot animations) are in extra files to allow for lazy loading. These files are raw data of timestamps and values for animation blocks. Blizzard's exporter prefers to align blocks to a 16 byte boundary, but that's not required.
The client loads .anim files if (M2Sequence.flags & 0x130 ) == 0. The .anim file to use is "%s%04d-%02d.anim" % (model_filename_without_extension, anim.id, anim.sub_anim_id).
Legion 24500
In Legion, these files are optionally chunked now. They are chunked either
- if M2 header's 0x200000 flag is set and thus the new mid expansion format change is used
- if the M2 has a .skel file
For new format M2s, .anim is pretty much unchanged except that there is the AFM2 chunk header. The AFSA and AFSB chunks do not appear in that case. If it is a .skel file based model, the chunks are present and animation data is split into bone and attach data. The AFM2 chunk then contains the animation data for only Events, the AFSA chunk that for attachments and the AFSB chunk that for bones. See .skel files for that.
AFM2
The same content as an old anim file would have. In fact, files that were just converted to the new format are bit identical except for the chunk header.
AFSA
skeleton data for attachments
AFSB
skeleton data for bones
Animation sequences
List of animations present in the model.
struct M2Sequence
{
/*0x00*/ uint16_t id; // Animation id in AnimationData.dbc
/*0x02*/ uint16_t variationIndex; // Sub-animation id: Which number in a row of animations this one is.
#if ≤
/*0x04*/ uint32_t start_timestamp;
/*0x08*/ uint32_t end_timestamp;
#else
/*0x04*/ uint32_t duration; // The length of this animation sequence in milliseconds.
#endif
/*0x08*/ float movespeed; // This is the speed the character moves with in this animation.
/*0x0c*/ uint32_t flags; // See below.
/*0x10*/ int16_t frequency; // This is used to determine how often the animation is played. For all animations of the same type, this adds up to 0x7FFF (32767).
/*0x12*/ uint16_t _padding;
/*0x14*/ M2Range replay; // May both be 0 to not repeat. Client will pick a random number of repetitions within bounds if given.
#if version < ??? < 6.0.1
/*0x1c*/ uint32_t blendTime;
#else
/*0x1c*/ uint16_t blendTimeIn; // The client blends (lerp) animation states between animations where the end and start values differ. This specifies how long that blending takes. Values: 0, 50, 100, 150, 200, 250, 300, 350, 500.
/*0x1e*/ uint16_t blendTimeOut; // The client blends between this sequence and the next sequence for blendTimeOut milliseconds.
#endif
// For both blendTimeIn and blendTimeOut, the client plays both sequences simultaneously while interpolating between their animation transforms.
M2Bounds bounds;
/*0x20*/ int16_t variationNext; // id of the following animation of this AnimationID, points to an Index or is -1 if none.
/*0x22*/ uint16_t aliasNext; // id in the list of animations. Used to find actual animation if this sequence is an alias (flags & 0x40)
/*0x24*/
} sequences[];
--Koward (talk) 09:50, 18 December 2015 (UTC) In M2 v274 (Legion), it looks like blend_time has been divided in two uint16_t, and for standard animations the old blend_time is duplicated in both fields (ex : uint32 150 becomes two uint16 150). Maybe start and end blend_time values ? See Creature/GennGreymane/GennGreymane.m2 .
Flags
One thing I saw in the source is that "-1 animationblocks" in bones wont get parsed if 0x20 is not set.
| Flag | Description |
|---|---|
| 0x01 | Sets 0x80 when loaded. (M2Init) |
| 0x02 | |
| 0x04 | |
| 0x08 | |
| 0x10 | apparently set during runtime in CM2Shared::LoadLowPrioritySequence for all entries of a loaded sequence (including aliases) |
| 0x20 | primary bone sequence -- If set, the animation data is in the .m2 file. If not set, the animation data is in an .anim file. Was named 'looped animation' by schlumpf years ago, without source.ᵘ |
| 0x40 | has next / is alias (To find the animation data, the client skips these by following aliasNext until an animation without 0x40 is found.) |
| 0x80 | Blended animation (if either side of a transition has 0x80, lerp between end->start states, unless end==start by comparing bone values) |
| 0x100 | sequence stored in model ? |
| 0x200 | Signals that uint32_t blendTime is two fields: blendTimeIn and blendTimeOut. (Actual usage and influence of blendTimeIn and blendTimeOut depends on blendTimeOperation, which is not stored in files, but code and context dependent) |
| 0x400 | |
| 0x800 | seen in Legion 24500 models |
| 0x1000 | |
| 0x2000 |
-- Rour, some animations rely on blending to look right. The MoP mage CM shoulders only animate half of their movement and rely on lerping back to the start position to look correct.
Animation Lookup
Hash table for Animations in AnimationData.dbc. For a list of animation names, see M2/AnimationList.
struct
{
int16_t animation_index; // Index at ofsAnimations which represents the animation in AnimationData.dbc. -1 if none.
} animation_lookups[];
The hash used is anim_id % num_buckets. If a bucket is used, a stride of n^2 is added with n = 1, 2, … until the entry is matching:
M2Sequence* find_entry (uint32_t anim_id)
{
size_t i (anim_id % animation_lookups.count);
for (size_t stride (1); true; ++stride)
{
if (animation_lookups[i] == -1)
{
return nullptr;
}
if (animation_sequences[animation_lookups[i]].id == anim_id)
{
return &animation_sequences[i];
}
i = (i + stride * stride) % animation_lookups.count;
// so original_i + 1, original_i + 1 + 4, original_i + 1 + 4 + 9, …
}
[[unreachable]];
}
The entry referenced is the first in the `nextAlias` chain of a given animation id. Thus, num_buckets < num_animations, even if a model would have all animations multiple times.
Playable Animation Lookup
.Lookup table for Playable Animation in AnimationData.dbc
Offset Type Description 0x00 int16 Fallback Animation ID in AnimationData.dbc 0x02 int16 Flags (0, 1, 3 seen)
[Wall] Many templates have this section wrong and it's easy to misinterpret. It's two side-by-side int16 (animationID and flag) for each DBC animation sequence, denoting which animation plays for the enumerated animation, along with flags on how the animation is handled. WotLK models have 226 entries.
struct M2Fallback {
int16 fallbackAnimationID;
int16 flags;
} fallbacks[];
Models don't present all animations sequences. This table maps from global animation list to available animation for the current model. The engine uses it to know which animation clip to play. That's why there are a lot of zeros ("Stand") for creatures.
Flags are used to modify how the clip should be played:
Value Meaning 0 Play normal 1 Play backwards 2 Frame-by-frame 3 Freeze
For instance, the "HumanMale/HumanMale.m2" model has just one "Loot" animation sequence. "LootHold" and "LootUp" are obtained with flags 3 and 1.
Bones
struct M2CompBone // probably M2Bone ≤{ int32_t key_bone_id; // Back-reference to the key bone lookup table. -1 if this is no key bone. enum { ignoreParentTranslate = 0x1, ignoreParentScale = 0x2, ignoreParentRotation = 0x4, spherical_billboard = 0x8, cylindrical_billboard_lock_x = 0x10, cylindrical_billboard_lock_y = 0x20, cylindrical_billboard_lock_z = 0x40, transformed = 0x200, kinematic_bone = 0x400, // MoP+: allow physics to influence this bone helmet_anim_scaled = 0x1000, // set blend_modificator to helmetAnimScalingRec.m_amount for this bone something_sequence_id = 0x2000, // <=bfa+, parent_bone+submesh_id are a sequence id instead?! }; uint32_t flags; int16_t parent_bone; // Parent bone ID or -1 if there is none. uint16_t submesh_id; // Mesh part ID OR uDistToParent? union { // only ≥
The bone indices in the vertex definitions seem to index into this data.
Billboards
The billboarding bits are used for various things:
- Light halos around lamps must always face the viewer
- The cannonball stack model (in the Deadmines or Booty Bay), where each cannonball is a crude hemisphere, they always face the viewer to create the illusion of actual cannonballs.
Spherical and cylindrical billboard bits are mutually exclusive. Only one of them can be used for the bone.
Bone Lookup Table
Lookup table for bones referenced from M2SkinSection.
struct
{
uint16_t bone;
} bone_lookup_table[];
Key-Bone Lookup
Its a lookup table for key skeletal bones like hands, arms, legs, etc. nKeyBoneLookup is 27 for the most models up to WotLK, then 35, whatever the biggest named key bone was at the given expansion. For static models it is mostly 1.
struct
{
uint16_t bone; // -1 if none
} key_bone_lookup[];
Key Bone Names
The key bone name table is collapsed by default to reduce page length. Click expand on the right to expand.
Confirmed names (matching CRC) highlighted in greenᵛ, unverified/made up names are unmarked.
| ID | Name | Notes |
|---|---|---|
| 00 | ArmLᵛ | |
| 01 | ArmRᵛ | |
| 02 | ShoulderLᵛ | |
| 03 | ShoulderRᵛ | |
| 04 | SpineLowᵛ | "Upper Body" in animkits, if not present use Head |
| 05 | Waistᵛ | |
| 06 | Headᵛ | |
| 07 | Jawᵛ | |
| 08 | IndexFingerRᵛ | |
| 09 | MiddleFingerRᵛ | |
| 10 | PinkyFingerRᵛ | |
| 11 | RingFingerRᵛ | |
| 12 | ThumbRᵛ | |
| 13 | IndexFingerLᵛ | |
| 14 | MiddleFingerLᵛ | |
| 15 | PinkyFingerLᵛ | |
| 16 | RingFingerLᵛ | |
| 17 | ThumbLᵛ | |
| 18 | $BTHᵛ | |
| 19 | $CSRᵛ | |
| 20 | $CSLᵛ | |
| 21 | _Breathᵛ | |
| 22 | _Nameᵛ | |
| 23 | _NameMountᵛ | |
| 24 | $CHDᵛ | |
| 25 | $CCHᵛ | |
| 26 | Rootᵛ | |
| 27 | Wheel1ᵛ | ≥
|
| 28 | Wheel2ᵛ | ≥
|
| 29 | Wheel3ᵛ | ≥
|
| 30 | Wheel4ᵛ | ≥
|
| 31 | Wheel5ᵛ | ≥
|
| 32 | Wheel6ᵛ | ≥
|
| 33 | Wheel7ᵛ | ≥
|
| 34 | Wheel8ᵛ | ≥ , higher bone IDs not present in WotLK
|
| 35 | FaceAttenuationᵛ | |
| 36 | EXP_C1_Cape1ᵛ | Previous unconfirmed name was "CapeParent" |
| 37 | EXP_C1_Cape2ᵛ | Previous unconfirmed name was "CapeChild1" |
| 38 | EXP_C1_Cape3ᵛ | Previous unconfirmed name was "CapeChild2" |
| 39 | EXP_C1_Cape4ᵛ | Previous unconfirmed name was "CapeChild3" |
| 40 | EXP_C1_Cape5ᵛ | Previous unconfirmed name was "CapeChild4" |
| 41 | EXP_C1_Tail1ᵛ | |
| 42 | EXP_C1_Tail2ᵛ | |
| 43 | EXP_C1_LoinBk1ᵛ | Previous unconfirmed name was "TabardParent" |
| 44 | EXP_C1_LoinBk2ᵛ | Previous unconfirmed name was "TabardChild1" |
| 45 | EXP_C1_LoinBk3ᵛ | Previous unconfirmed name was "TabardChild2" |
| 48 | EXP_C1_Spine2ᵛ | Previous unconfirmed name was "UpperBodyParent" |
| 49 | EXP_C1_Neck1ᵛ | Previous unconfirmed name was "NeckParent" |
| 50 | EXP_C1_Neck2ᵛ | Previous unconfirmed name was "NeckChild1" |
| 51 | EXP_C1_Pelvis1ᵛ | Previous unconfirmed name was "LowerBodyParent" |
| 52 | Buckleᵛ | |
| 53 | Chestᵛ | |
| 54 | Mainᵛ | |
| 55 | EXP_R1_Leg1Twist1ᵛ | Previous unconfirmed name was "LegR" |
| 56 | EXP_L1_Leg1Twist1ᵛ | Previous unconfirmed name was "LegL" |
| 57 | EXP_R1_Leg2Twist1ᵛ | Previous unconfirmed name was "KneeR" |
| 58 | EXP_L1_Leg2Twist1ᵛ | Previous unconfirmed name was "KneeL" |
| 59 | FootLᵛ | |
| 60 | FootRᵛ | |
| 61 | ElbowRᵛ | |
| 62 | ElbowLᵛ | |
| 63 | EXP_L1_Shield1ᵛ | Previous unconfirmed name was "Unk_ElbowL_Child" |
| 64 | HandRᵛ | |
| 65 | HandLᵛ | |
| 66 | WeaponRᵛ | |
| 67 | WeaponLᵛ | |
| 68 | SpellHandLᵛ | Previous unconfirmed name was "Unk_WristL_Child" |
| 69 | SpellHandRᵛ | Previous unconfirmed name was "Unk_WristR_Child" |
| 70 | EXP_R1_Leg1Twist3ᵛ | Previous unconfirmed name was "KneeR_UpperRig" |
| 71 | EXP_L1_Leg1Twist3ᵛ | Previous unconfirmed name was "KneeL_UpperRig" |
| 72 | EXP_R1_Arm1Twist2ᵛ | Previous unconfirmed name was "ArmR_2" |
| 73 | EXP_L1_Arm1Twist2ᵛ | Previous unconfirmed name was "ArmL_2" |
| 74 | EXP_R1_Arm1Twist3ᵛ | Previous unconfirmed name was "ElbowR_UpperRig" |
| 75 | EXP_L1_Arm1Twist3ᵛ | Previous unconfirmed name was "ElbowL_UpperRig" |
| 76 | EXP_R1_Arm2Twist2ᵛ | Previous unconfirmed name was "ForearmR" |
| 77 | EXP_L1_Arm2Twist2ᵛ | Previous unconfirmed name was "ForearmL" |
| 78 | EXP_R1_Arm2Twist3ᵛ | Previous unconfirmed name was "WristR_UpperRig" |
| 79 | EXP_L1_Arm2Twist3ᵛ | Previous unconfirmed name was "WristL_UpperRig" |
| 80 | ForearmRᵛ | |
| 81 | ForearmLᵛ | |
| 82 | EXP_R1_Arm1Twist1ᵛ | |
| 83 | EXP_L1_Arm1Twist1ᵛ | |
| 84 | EXP_R1_Arm2Twist1ᵛ | |
| 85 | EXP_L1_Arm2Twist1ᵛ | |
| 86 | EXP_R1_FingerClawA1ᵛ | |
| 87 | EXP_R1_FingerClawB1ᵛ | |
| 88 | EXP_L1_FingerClawA1ᵛ | |
| 89 | EXP_L1_FingerClawB1ᵛ | |
| 190 | _BackCloakᵛ | |
| 191 | face_hair_00_M_JNTᵛ | |
| 192 | face_beard_00_M_JNTᵛ | |
| 193 | face_cheek_02_L_SkinPointᵛ | IGC (in-game cinematic) models only |
| 194 | face_cheek_02_R_SkinPointᵛ | IGC models only |
| 195 | face_eyeCornerIn_00_L_SkinPointᵛ | IGC models only |
| 196 | face_eyeCornerIn_00_R_SkinPointᵛ | IGC models only |
| 197 | face_eyeCornerOut_00_L_SkinPointᵛ | IGC models only |
| 198 | face_eyeCornerOut_00_R_SkinPointᵛ | IGC models only |
| 199 | face_eyebrow_00_L_SkinPointᵛ | IGC models only |
| 200 | face_eyebrow_00_M_SkinPointᵛ | IGC models only |
| 201 | face_eyebrow_00_R_SkinPointᵛ | IGC models only |
| 202 | face_eyebrow_01_L_SkinPointᵛ | IGC models only |
| 203 | face_eyebrow_01_R_SkinPointᵛ | IGC models only |
| 204 | face_eyebrow_02_L_SkinPointᵛ | IGC models only |
| 205 | face_eyebrow_02_R_SkinPointᵛ | IGC models only |
| 206 | face_eyebrow_03_L_SkinPointᵛ | IGC models only |
| 207 | face_eyebrow_03_R_SkinPointᵛ | IGC models only |
| 208 | face_eyelidBot_00_L_SkinPointᵛ | IGC models only |
| 209 | face_eyelidBot_00_R_SkinPointᵛ | IGC models only |
| 210 | face_eyelidBot_01_L_SkinPointᵛ | IGC models only |
| 211 | face_eyelidBot_01_R_SkinPointᵛ | IGC models only |
| 212 | face_eyelidBot_02_L_SkinPointᵛ | IGC models only |
| 213 | face_eyelidBot_02_R_SkinPointᵛ | IGC models only |
| 214 | face_eyelidTop_00_L_SkinPointᵛ | IGC models only |
| 215 | face_eyelidTop_00_R_SkinPointᵛ | IGC models only |
| 216 | face_eyelidTop_01_L_SkinPointᵛ | IGC models only |
| 217 | face_eyelidTop_01_R_SkinPointᵛ | IGC models only |
| 218 | face_eyelidTop_02_L_SkinPointᵛ | IGC models only |
| 219 | face_eyelidTop_02_R_SkinPointᵛ | IGC models only |
| 220 | face_noseBridge_00_L_SkinPointᵛ | IGC models only |
| 221 | face_noseBridge_00_R_SkinPointᵛ | IGC models only |
| 222 | face_overEye_00_L_SkinPointᵛ | IGC models only |
| 223 | face_overEye_00_R_SkinPointᵛ | IGC models only |
| 224 | face_overOuterEye_00_L_SkinPointᵛ | IGC models only |
| 225 | face_overOuterEye_00_R_SkinPointᵛ | IGC models only |
| 226 | face_underEye_00_L_SkinPointᵛ | IGC models only |
| 227 | face_underEye_00_R_SkinPointᵛ | IGC models only |
| 228 | face_cheekPuff_00_L_SkinPointᵛ | IGC models only |
| 229 | face_cheekPuff_00_R_SkinPointᵛ | IGC models only |
| 230 | face_cheek_00_L_SkinPointᵛ | IGC models only |
| 231 | face_cheek_00_R_SkinPointᵛ | IGC models only |
| 232 | face_cheek_01_L_SkinPointᵛ | IGC models only |
| 233 | face_cheek_01_R_SkinPointᵛ | IGC models only |
| 234 | face_chin_00_L_SkinPointᵛ | IGC models only |
| 235 | face_chin_00_M_SkinPointᵛ | IGC models only |
| 236 | face_chin_00_R_SkinPointᵛ | IGC models only |
| 237 | face_ear_00_L_SkinPointᵛ | IGC models only |
| 238 | face_ear_00_R_SkinPointᵛ | IGC models only |
| 239 | face_jaw_01_M_SkinPointᵛ | IGC models only |
| 240 | face_jowl_00_L_SkinPointᵛ | IGC models only |
| 241 | face_jowl_00_R_SkinPointᵛ | IGC models only |
| 242 | face_jowl_01_L_SkinPointᵛ | IGC models only |
| 243 | face_jowl_01_R_SkinPointᵛ | IGC models only |
| 244 | face_lipBotBase_00_M_SkinPointᵛ | IGC models only |
| 245 | face_lipTopBase_00_M_SkinPointᵛ | IGC models only |
| 246 | face_mouthCorner_00_L_SkinPointᵛ | IGC models only |
| 247 | face_mouthCorner_00_R_SkinPointᵛ | IGC models only |
| 248 | face_mouthCurlBot_00_M_SkinPointᵛ | IGC models only |
| 249 | face_mouthCurlTop_00_M_SkinPointᵛ | IGC models only |
| 250 | face_mouth_00_M_SkinPointᵛ | IGC models only |
| 251 | face_nasLab_00_L_SkinPointᵛ | IGC models only |
| 252 | face_nasLab_00_R_SkinPointᵛ | IGC models only |
| 253 | face_nasLab_01_L_SkinPointᵛ | IGC models only |
| 254 | face_nasLab_01_R_SkinPointᵛ | IGC models only |
| 255 | face_noseBase_00_M_SkinPointᵛ | IGC models only |
| 256 | face_sneerDriver_00_L_SkinPointᵛ | IGC models only |
| 257 | face_sneerDriver_00_R_SkinPointᵛ | IGC models only |
| 258 | face_sneerLower_00_L_SkinPointᵛ | IGC models only |
| 259 | face_sneerLower_00_R_SkinPointᵛ | IGC models only |
| 260 | face_sneer_00_L_SkinPointᵛ | IGC models only |
| 261 | face_sneer_00_R_SkinPointᵛ | IGC models only |
| 262 | face_teethBot_00_M_SkinPointᵛ | IGC models only |
| 263 | face_teethTop_00_M_SkinPointᵛ | IGC models only |
| 264 | face_tongue_00_M_SkinPointᵛ | IGC models only |
| 265 | root_main_00_M_SkinPointᵛ | IGC models only |
| 266 | spine_mainBendy_00_M_SkinPointᵛ | IGC models only |
| 267 | clavicle_main_00_L_SkinPointᵛ | IGC models only |
| 268 | arm_shoulderBendy_00_L_SkinPointᵛ | IGC models only |
| 269 | hand_main_00_L_JNTᵛ | |
| 270 | hand_index_00_L_SkinPointᵛ | IGC models only |
| 271 | hand_main_00_L_SkinPointᵛ | IGC models only |
| 272 | hand_ring_00_L_SkinPointᵛ | IGC models only |
| 273 | hand_pinky_00_L_SkinPointᵛ | IGC models only |
| 274 | hand_thumb_00_L_SkinPointᵛ | IGC models only |
| 275 | clavicle_main_00_R_SkinPointᵛ | IGC models only |
| 276 | arm_shoulderBendy_00_R_SkinPointᵛ | IGC models only |
| 277 | hand_main_00_R_JNTᵛ | |
| 278 | hand_main_00_R_SkinPointᵛ | IGC models only |
| 279 | hand_middle_00_R_SkinPointᵛ | IGC models only |
| 280 | hand_ring_00_R_SkinPointᵛ | IGC models only |
| 281 | hand_pinky_00_R_SkinPointᵛ | IGC models only |
| 282 | hand_thumb_00_R_SkinPointᵛ | IGC models only |
| 283 | head_main_00_M_SkinPointᵛ | IGC models only |
| 284 | face_jaw_00_M_SkinPointᵛ | IGC models only |
| 285 | EXP_L1_Eye1ᵛ | |
| 286 | EXP_R1_Eye1ᵛ | |
| 287 | EXP_L1_EyeLid1ᵛ | |
| 288 | EXP_R1_EyeLid1ᵛ | |
| 289 | EXP_L1_EyeLid2ᵛ | |
| 290 | EXP_R1_EyeLid2ᵛ | |
| 292 | EXP_L1_WingArm1Twist1ᵛ | |
| 293 | EXP_R1_WingArm1Twist1ᵛ | |
| 296 | waterfall_top_soundᵛ | |
| 297 | waterfall_bottom_soundᵛ |
Non-Key Bone Names
The below list is confirmed bone names (the CRC for these still appears in models), although they aren't used as key bones.
The non-key bone name table is collapsed by default to reduce page length. Click expand on the right to expand.
| Name | CRC |
|---|---|
| $BWA | 0x892b044e |
| $BWP | 0xe39b24bc |
| $BWR | 0x0d954590 |
| $BWS | 0x7a927506 |
| $CAH | 0xedad630a |
| $CPP | 0xad18d84c |
| $CSS | 0x1f3cda35 |
| $CST | 0x81584f96 |
| $DTH | 0xdf57939b |
| $ESD | 0x98622340 |
| $FD1 | 0xbfc89c3c |
| $FL0 | 0x001626a2 |
| $FR0 | 0xd457197d |
| $FSD | 0x9a249d19 |
| $HIT | 0x3d205aac |
| $SCD | 0xca0beed3 |
| $SHL | 0x2724bf2a |
| $SHR | 0xdd2b8249 |
| $TRD | 0x9c9ddb46 |
| -Blid_L01 | 0x952640dd |
| -EF_Eyelid01 | 0xff05e0fc |
| -EF_Eyelid_Death | 0x91249ce5 |
| -Eye01 | 0x4c50b066 |
| -Flid_R01 | 0x07d4c05d |
| ankle_L | 0x1114bd09 |
| ankle_R | 0xeb1b806a |
| arm_L | 0xa100d5a4 |
| arm_R | 0x5b0fe8c7 |
| B_Loin_01 | 0x46c1b68f |
| B_Loin_02 | 0xdfc8e735 |
| Belly | 0x49b52472 |
| Blid_L | 0xe42907dd |
| Blid_R | 0x1e263abe |
| CalfL | 0x57ebb63c |
| CalfR | 0xade48b5f |
| CheekL | 0x2acb54c0 |
| CheekR | 0xd0c469a3 |
| ChestL | 0xff3a859c |
| ChestR | 0x0535b8ff |
| dSpine1_joint | 0xfdba68c8 |
| Ear_L_01 | 0xed8d18a0 |
| Ear_L_02 | 0x7484491a |
| Ear_R_01 | 0x5d4b380c |
| Ear_R_02 | 0xc44269b6 |
| elbow_L | 0xa8948290 |
| elbow_R | 0x529bbff3 |
| eye_L | 0x8d92a5dd |
| eye_R | 0x779d98be |
| EyeBowL | 0x9b22dfb5 |
| EyeBowR | 0x612de2d6 |
| EyebrowL | 0x5bcd3a5c |
| EyebrowR | 0xa1c2073f |
| F_Loin_01 | 0x1b2de783 |
| F_Loin_02 | 0x8224b639 |
| F_Loin_03 | 0xf52386af |
| fin | 0xad2ef231 |
| finger_L | 0x6da04d3b |
| finger_R | 0x97af7058 |
| FinLeft_joint50 | 0x4eb9c4de |
| FinRight_joint51 | 0x9d4d0569 |
| Flid_L | 0x7fb845cb |
| Flid_R | 0x85b778a8 |
| foot_L | 0x06f9c681 |
| foot_R | 0xfcf6fbe2 |
| FootBackL | 0xbd5cfe0e |
| FootBackR | 0x4753c36d |
| FootFrontL | 0xad3efd23 |
| FootFrontR | 0x5731c040 |
| Geo_EyeLid_Death | 0x35d090eb |
| GEO_EyelidL | 0x428bb93e |
| GEO_EyelidR | 0xb884845d |
| hand_L | 0x2759dd85 |
| hand_R | 0xdd56e0e6 |
| HeadScale_joint22 | 0x9b0a86ea |
| hip_L | 0x3ff65768 |
| hip_R | 0xc5f96a0b |
| HipL | 0x68b72b2c |
| HipR | 0x92b8164f |
| Hips | 0xded10611 |
| Hump | 0xad8861a3 |
| IndexFingerTipL | 0x76451c91 |
| IndexFingerTipR | 0x8c4a21f2 |
| IndexL01 | 0x135d4e78 |
| IndexL02 | 0x8a541fc2 |
| IndexL03 | 0xfd532f54 |
| IndexR01 | 0x05e5c002 |
| IndexR02 | 0x9cec91b8 |
| IndexR03 | 0xebeba12e |
| JawBottomL | 0xa914ce26 |
| JawBottomR | 0x531bf345 |
| JawTopL | 0xa2fc75cc |
| JawTopR | 0x58f348af |
| knee_L | 0xf55ed5cc |
| knee_R | 0x0f51e8af |
| KneeL | 0x1b0485e7 |
| KneeR | 0xe10bb884 |
| Leg01_Back_L | 0x2755d694 |
| Leg01_Back_R | 0xdd5aebf7 |
| Leg01_Front_R | 0x76f67c58 |
| Leg01_Middle_R | 0x239aad94 |
| Leg01Front_L | 0x8b498ad5 |
| Leg01Middle_L | 0x9e20ef43 |
| Leg02_Back_L | 0xa9dad177 |
| Leg02_Back_R | 0x53d5ec14 |
| Leg02_Front_R | 0x4f7b409d |
| Leg02_Middle_L | 0x32a22bf4 |
| Leg02_Middle_R | 0xc8ad1697 |
| Leg02Front_L | 0x05c68d36 |
| Leg03_Back_L | 0x6570d1e9 |
| Leg03_Back_R | 0x9f7fec8a |
| Leg03_Front_R | 0x580054de |
| Leg03_Middle_L | 0xdd6040ca |
| Leg03_Middle_R | 0x276f7da9 |
| Leg03Front_L | 0xc96c8da8 |
| LegBackL01 | 0x7e47654c |
| LegBackL02 | 0xe74e34f6 |
| LegBackR01 | 0x68ffeb36 |
| LegBackR02 | 0xf1f6ba8c |
| LegFrontL01 | 0xe0f912f0 |
| LegFrontL02 | 0x79f0434a |
| LegFrontR01 | 0xf6419c8a |
| LegFrontR02 | 0x6f48cd30 |
| LegL | 0xeb4cc189 |
| LegR | 0x1143fcea |
| LFLeg_joint41 | 0x88363db0 |
| LFLeg_joint42 | 0x113f6c0a |
| LFLeg_joint43 | 0x66385c9c |
| LFLeg_joint46 | 0x1652a813 |
| LMLeg_joint41 | 0xf9a499be |
| LMLeg_joint42 | 0x60adc804 |
| LMLeg_joint43 | 0x17aaf892 |
| LMLeg_joint45 | 0xfec95da7 |
| Lower_01 | 0x0955c6d0 |
| Lower_02 | 0x905c976a |
| Lower_03 | 0xe75ba7fc |
| Lower_04 | 0x793f325f |
| Lower_05 | 0x0e3802c9 |
| Lower_06 | 0x97315373 |
| MiddleFingerTipL | 0xc820b7d8 |
| MiddleFingerTipR | 0x322f8abb |
| Neck | 0x8023796d |
| NoseLeft_joint18 | 0xbc61b1ae |
| Object26 | 0x29aadf6c |
| PinkyFingerTipL | 0x33785489 |
| PinkyFingerTipR | 0xc97769ea |
| PinkyL01 | 0x1319a094 |
| PinkyL02 | 0x8a10f12e |
| PinkyL03 | 0xfd17c1b8 |
| PinkyR01 | 0x05a12eee |
| PinkyR02 | 0x9ca87f54 |
| PinkyR03 | 0xebaf4fc2 |
| Plane01 | 0x7ea01827 |
| Plane02 | 0xe7a9499d |
| Plane03 | 0x90ae790b |
| Plane04 | 0x0ecaeca8 |
| Plane05 | 0x79cddc3e |
| RFLeg_joint41 | 0xc6d797da |
| RFLeg_joint42 | 0x5fdec660 |
| RFLeg_joint43 | 0x28d9f6f6 |
| RFLeg_joint49 | 0xc80c1fe8 |
| RingFingerTipL | 0x46372b47 |
| RingFingerTipR | 0xbc381624 |
| RLLeg_joint042 | 0x3c3468ef |
| RLLeg_joint043 | 0x4b335879 |
| RLLeg_joint044 | 0xd557cdda |
| RLLeg_joint40 | 0x5be74f2d |
| RLLeg_joint41 | 0x2ce07fbb |
| RLLeg_joint42 | 0xb5e92e01 |
| RLLeg_joint43 | 0xc2ee1e97 |
| RLLeg_joint47 | 0xc583da8e |
| RMLeg_joint41 | 0xb74533d4 |
| RMLeg_joint42 | 0x2e4c626e |
| RMLeg_joint43 | 0x594b52f8 |
| RMLeg_joint48 | 0xce998b70 |
| Spine1Sale_joint | 0x65038b0e |
| Spine2_joint | 0x76b94270 |
| Spine2Scale_joint | 0xff91da65 |
| Spine3_joint | 0xd0ce49c4 |
| Spine3Scale_joint | 0x6434960a |
| SpineLower | 0x04672713 |
| SpineUp | 0x127d657f |
| SpineUpper | 0x64a283ac |
| Tail01 | 0x0bf409bb |
| Tail02 | 0x92fd5801 |
| Tail1_joint | 0x425a6dd1 |
| Tail2_joint | 0x73b2774c |
| Tail3_joint | 0xd5c57cf8 |
| Tail3Scale_joint | 0xb632d0ba |
| Tail4_joint | 0x10624276 |
| Taile4Scale_joint | 0x991f686c |
| TailScale_joint | 0x0e8b6be9 |
| thumb_L | 0x9088b57e |
| thumb_R | 0x6a87881d |
| ThumbTipL | 0x704d64e8 |
| ThumbTipR | 0x8a42598b |
| ToeBackL | 0x83d2d151 |
| ToeBackR | 0x79ddec32 |
| ToeFrontL | 0x56d43f69 |
| ToeFrontR | 0xacdb020a |
| ToeL | 0x414059ad |
| ToeR | 0xbb4f64ce |
| Upper_01 | 0xe632304f |
| Upper_02 | 0x7f3b61f5 |
| Upper_03 | 0x083c5163 |
| Upper_04 | 0x9658c4c0 |
| Upper_05 | 0xe15ff456 |
| Upper_06 | 0x7856a5ec |
| WristL | 0x07fbf58a |
The following are unconfirmed names for non-keybones that were likely used in the past but are no longer used in any models today.
- Geo_EyeglowR
- Leg02Middle_L
- Leg03Middle_L
- NoseRight_joint39
Hierarchy requirement
from animkits (some 8.x+9.x build):
- Full Body (-1 or 26 or 5)
- Upper Body (4)
- Right Shoulder (2)
- Right Arm (1)
- Right Hand (8 or 9 or 10 or 11 or 12)
- Right Arm (1)
- Left Shoulder (3)
- Left Arm (0)
- Left Hand (13 or 14 or 15 or 16 or 17)
- Left Arm (0)
- Head (6)
- Jaw (7)
- Face Upper (193) ≥
(9.0.1.34081) - Face Lower (228) ≥ (9.0.1.34081)
- Hair (191) ≥ (9.0.1.34081)
- Beard (192) ≥ (9.0.1.34081)
- Right Shoulder (2)
- Wheel1…8 (27…34)
- Upper Body (4)
Geometry and rendering
Vertices
struct M2Vertex
{
C3Vectorⁱ pos;
uint8 bone_weights[4];
uint8 bone_indices[4];
C3Vectorⁱ normal;
C2Vectorⁱ tex_coords[2]; // two textures, depending on shader used
};
Models, too, use a Z-up coordinate systems, so in order to convert to Y-up, the X, Y, Z values become (X, -Z, Y).
-- Rour, the WoW vertex shaders all follow the same pattern, "Diffuse_XX_YY" (or sometimes XX, YY and Env). The particular vertex shader that is used chooses which set of texture coordinates to use. So Diffuse_T1 sends T1 texcoords to the fragment shader. Where Diffuse_T1_T2 sends both (for textures 0 and 1) but Diffuse_T1_T1 sends the same coords for both textures. Etc.
Views (LOD)
Skin profiles describe LOD views onto the model. They use all those lookup tables to be able to reference only parts of the lists while not being dynamically sized within the profile data.
≤ they were stored in the M2 itself, ≥ they have been moved to .skin files. The offsets are relative to the file the skin profile header is defined in. There is one .skin file per profile, each with a separate header, while in the inlined version, all headers are sequential. See the .skin file page for formats of both versions.
Render flags and blending modes
struct M2Material
{
uint16_t flags;
uint16_t blending_mode; // apparently a bitfield
} materials[];
- Flags:
| Flag | Meaning |
|---|---|
| 0x01 | Unlit |
| 0x02 | Unfogged |
| 0x04 | Two-sided (no backface culling if set) |
| 0x08 | depthTest |
| 0x10 | depthWrite |
| 0x40 | shadow batch related ??? (seen in WoD) (seen in 31 models in Wrath) |
| 0x80 | shadow batch related ??? (seen in WoD) (seen in 2 models in Wrath : SpectralTiger.m2 and SpectralTigerEpic.m2) |
| 0x100 | (seen in 1 model in Wrath : HFjord_Fog_02.m2) |
| 0x200 | shadow batch related ??? (seen in WoD) |
| 0x400 | ??? (seen in WoD) |
| 0x800 | prevent alpha for custom elements. if set, use (fully) opaque or transparent. (litSphere, shadowMonk) (MoP+) |
- Blending mode
See the table at M2/Rendering#M2BLEND for a list of the current blend modes in the client.
Second Texture Material Override Combo
If this block is present (globalflags&8) the M2 will use multitexturing differently, the second texture will get the material to use from here (flags and blending mode) instead of current index material + 1, the Shader ID from the [Texture Unit] will tell what Second Texture Material to use (so, Shader ID will always be an even number), while materialIndex will still be used as the material for the first texture.
When multitexturing is applied, the second texture will get all the needed information from the first texture + 1, so, the texture to use will be the Index into Texture lookup table + 1, same for [Texture Mapping], TexAnim, etc.
According to wod, if the M2 Header has flag 0x08, instead of reading blend mode from M2 RenderFlags, blendMode is read from the raw blend maps referenced in header.
var flags = renderFlags[texUnit.renderFlags]; var blendMode = flags >> 16; if ((header.GlobalModelFlags & 0x08) != 0 && texUnit.shader_id < mBlendMap.Length) blendMode = mBlendMap[texUnit.shader_id];
Texture mapping lookup table
. Still present but unused in Cataclysm.struct
{
int16 unit; // -1, 0, or 1. see below
} tex_mapping_lookup_table[]; (alt. name: tex_unit_lookup_table, textureCoordCombos)
| Value | Description |
|---|---|
| -1 | Environment mapping |
| 0 | First UVMap |
| 1 | Second UVMap |
Referenced in the [Skin Texture Unit], defines the mapping to be used for textures. Typically, when there's no multitexturing, the value is set to 0, indicating the use of the first UVMap. However, it can also be set to 1 or -1, representing the second UVMap or environment mapping, respectively. For models that utilize multitexturing, the table also specifies the mappings to be used by both textures. It functions in pairs, like the [Texture Lookup Table]. The first texture will use the mapping corresponding to the provided ID, while the second texture will use the mapping associated with the next ID in sequence.
One model is of special interest, Creature/KelThuzad/KelThuzad.m2, which is the only one that has an nTexUnits of 3, and has three texture units specified for some of its submeshes. Sure enough, two of those map to 0 and 1, and one maps to -1.
More confusion thanks to my favorite "weird" model, World/Generic/Gnome/Passive Doodads/GnomeMachine/GnomeSubwayGlass.m2, which is the translucent, environment mapped glass tunnel in the Deeprun Tram. It only has a single value in this block, -1, which is used for the single texture layer in both render operations in the model. This and the magic with rendering flags/blend modes make up the neat transparent-reflective glass effect, but confuse me even more about how envmapping and such is handled. (and where it seems to get the bluish color from - is it in the model (no color blocks in this particular model), the wmo, a solid background color, or simply the result of the blending used?)
As a side note, on my (dated) system WoW does every texture unit in a single pass.
Colors and transparency
Colors
struct M2Color
{
M2Track<C3Vectorⁱ> color; // vertex colors in rgb order
M2Track<fixed16ⁱ> alpha; // 0 - transparent, 0x7FFF - opaque. Normaly NonInterp
} colors[];
This block is the M2 equivalent to the GEOA chunk in MDX files, it represents the vertex color and visibility animations for meshes. Referenced from the Texture Unit blocks in the *.skin. If a texunit belonging to a submesh has a value of -1 then the submesh doesnot use this block. Contains a separate timeline for transparency values. If no animation is used, the given value is constant.
Transparency
struct M2TextureWeight
{
M2Track<fixed16ⁱ> weight;
} textureWeights[];
Specifies global transparency values in addition to the values given in the Color block. I assume these are multiplied together eventually.
Transparency lookup table
struct
{
uint16_t transparency;
} transparency_lookup[];
Contains indices into the Transparency block. Used by the texture unit definitions in the LOD block.
Textures
- Textures are defined globally in a list, additionally, a lookup table is given, referenced during rendering, to select textures.
struct M2Texture
{
uint32_t type; // see below
uint32_t flags; // see below
M2Array<char> filename; // for non-hardcoded textures (type != 0), this still points to a zero-byte-only string.
} textures[];
Note that at least 
(6.0.1.18179) relies on both
- non-type-0 textures having a one-byte sized string that has a first byte of \0
- the filename to contain a zero terminating character as it is reading them into an uninitialized buffer and passes that buffer on without the size given.
Thus, filename's size shall contain the zero byte, i.e. buffer size rather than string length.
Also note that this buffer is on the stack and sized the usual 0x108 bytes, so this is a n implicit texture filename length limit.
Note that at least (9.1.5.40944) expects M2Array filename to be zeroed in order to lookup BLP FileDataIDs from TXID chunk. Otherwise you get a green texture in the game.
Texture Types
Texture type is 0 for regular textures, nonzero for skinned textures (filename not referenced in the M2 file!) For instance, in the NightElfFemale model, her eye glow is a type 0 texture and has a file name, the other 3 textures have types of 1, 2 and 6. The texture filenames for these come from client database files:
- DBFilesClient\CharSections.dbc
- DBFilesClient\CreatureDisplayInfo.dbc
- DBFilesClient\ItemDisplayInfo.dbc
- (possibly more)
| Value | Meaning |
|---|---|
| 0 | - NONE - -- Texture given in filename |
| 1 | TEX_COMPONENT_SKIN -- Skin -- Body + clothes |
| 2 | TEX_COMPONENT_OBJECT_SKIN -- Object Skin -- Item, Capes ("Item\ObjectComponents\Cape\*.blp") |
| 3 | TEX_COMPONENT_WEAPON_BLADE -- Weapon Blade -- Used on several models but not used in the client as far as I see. Armor Reflect? |
| 4 | TEX_COMPONENT_WEAPON_HANDLE -- Weapon Handle |
| 5 | TEX_COMPONENT_ENVIRONMENT -- (OBSOLETE) Environment (Please remove from source art) |
| 6 | TEX_COMPONENT_CHAR_HAIR -- Character Hair |
| 7 | TEX_COMPONENT_CHAR_FACIAL_HAIR -- (OBSOLETE) Character Facial Hair (Please remove from source art) |
| 8 | TEX_COMPONENT_SKIN_EXTRA -- Skin Extra |
| 9 | TEX_COMPONENT_UI_SKIN -- UI Skin -- Used on inventory art M2s (1): inventoryartgeometry.m2 and inventoryartgeometryold.m2 |
| 10 | TEX_COMPONENT_TAUREN_MANE -- Character Misc // (OBSOLETE) Tauren Mane (Please remove from source art) |
| 11 | TEX_COMPONENT_MONSTER_1 -- Monster Skin 1 -- Skin for creatures or gameobjects #1 |
| 12 | TEX_COMPONENT_MONSTER_2 -- Monster Skin 2 -- Skin for creatures or gameobjects #2 |
| 13 | TEX_COMPONENT_MONSTER_3 -- Monster Skin 3 -- Skin for creatures or gameobjects #3 |
| 14 | TEX_COMPONENT_ITEM_ICON -- Item Icon -- Used on inventory art M2s (2): ui-button.m2 and forcedbackpackitem.m2 (CSimpleModel_ReplaceIconTexture("texture")) |
| 15 | ≥ Guild Background Color
|
| 16 | ≥ Guild Emblem Color
|
| 17 | ≥ Guild Border Color
|
| 18 | ≥ Guild Emblem
|
| 19 | ≥ Character Eyes
|
| 20 | ≥ Character Jewelry // Accessory
|
| 21 | ≥ Character Secondary Skin
|
| 22 | ≥ Character Secondary Hair
|
| 23 | ≥ Character Secondary Armor
|
| 24 | ≥
|
| 25 | Seen in DracthyrDragon.m2 (10.0.0+) |
| 26 | Seen in DracthyrDragon.m2 (10.0.0+) |
Flags
| Value | Meaning |
|---|---|
| 0x1 | Texture wrap X |
| 0x2 | Texture wrap Y |
| 0x1+0x2 | Texture wrap X+Texture wrap Y |
Texture lookup table
struct
{
uint16_t texture;
} texture_lookup[];
Replacable texture lookup
struct
{
uint16_t replacement;
} texture_replacements[];
A reverse lookup table for 'replaced' textures, mapping replacable ids to texture indices or -1. Only goes up to the maximum id used in the model.
Its strange, that HARDCODED is in the list, as a model can have more than one of course. Its just the last one written to the file.
Effects
Texture Transforms
- This block contains definitions for texture animations, for example, flowing water or lava in some models. The keyframe values are used in the texture transform matrix.
struct M2TextureTransform
{
M2Track<C3Vectorⁱ> translation;
M2Track<C4Quaternionⁱ> rotation; // rotation center is texture center (0.5, 0.5)
M2Track<C3Vectorⁱ> scaling;
} textureTransforms[];
Seems like UV rotation in some models are made against (0.5, 0.5) point instead of (0, 0). At least it's the case for world\goober\g_scourgerunecirclecrystal.m2
So to get the proper UV rotation it would be necessary apply rotation this way:
- Translate UV anim matrix to point (0.5, 0.5)
- Apply rotation mat from quaternion
- UV anim matrix to point (-0.5, -0.5)
Texture Transforms lookup table
struct
{
uint16_t anim_texture_id; // -1 for static
} anim_texture_lookup[];
Ribbon emitters
struct M2Ribbon
{
uint32_t ribbonId; // Always (as I have seen): -1.
uint32_t boneIndex; // A bone to attach to.
C3Vectorⁱ position; // And a position, relative to that bone.
M2Array<uint16_t> textureIndices; // into textures
M2Array<uint16_t> materialIndices; // into materials
M2Track<C3Vectorⁱ> colorTrack; // An RGB multiple for the material.[1]
M2Track<fixed16ⁱ> alphaTrack; // And an alpha value in a short, where: 0 - transparent, 0x7FFF - opaque.
M2Track<float> heightAboveTrack; // Above and Below – These fields define the width of a ribbon in units based on their offset from the origin.[1]
M2Track<float> heightBelowTrack; // do not set to same!
float edgesPerSecond; // this defines how smooth the ribbon is. A low value may produce a lot of edges.
// Edges/Sec – The number of quads generated.[1]
float edgeLifetime; // the length aka Lifespan. in seconds
// Time in seconds that the quads stay around after being generated.[1]
float gravity; // use arcsin(val) to get the emission angle in degree
// Can be positive or negative. Will cause the ribbon to sink or rise in the z axis over time.[1]
uint16_t textureRows; // tiles in texture
uint16_t textureCols; // Texture Rows and Cols – Allows an animating texture similar to BlizParticle. Set the number of rows and columns equal to the texture.[1]
M2Track<uint16_t> texSlotTrack; // Pick the index number of rows and columns, and animate this number to get a cycle.[1]
M2Track<uchar> visibilityTrack;
#if ≥ // TODO: verify version
int16_t priorityPlane;
int8_t RibbonColorIndex;
int8_t textureTransformLookupIndex; //Index into m2data.header.textureTransformCombos. Applied only if m2data.header.global_flags.flag_unk_0x20000 flag is set
#endif
} ribbons[];
Some models that contain ribbon emitters and are viewable in the game world are: Wisps in BFD, Al'ar the Phoenix in Tempest Keep and any other phoenix models and the energy trails in the COT (not the actual instance, but the entrance cave in Tanaris Desert). Other models with ribbon emitters are spells and effects.
Parameters from the MDL format that are probably in here somewhere: emission rate, rows, cols ...?
Particle emitters
This is partly wrong as hell! Do not rely on this block, at all. It might even be wrong for WotLK.
M2ParticleOld
struct M2ParticleOld {
/*0x00*/ uint32 particleId; // Always (as I have seen): -1.
/*0x04*/ uint32 flags; // See Below
/*0x08*/ C3Vectorⁱ Position; // The position. Relative to the following bone.
/*0x14*/ uint16 bone; // The bone its attached to.
/*0x16*/ union
{
uint16 texture; // And the textures that are used.
#if ≥
struct // For multi-textured particles actually three ids
{
uint16_t texture_0 : 5;
uint16_t texture_1 : 5;
uint16_t texture_2 : 5;
uint16_t : 1;
};
#endif
};
/*0x18*/ M2Array<char> geometry_model_filename; // if given, this emitter spawns models
/*0x20*/ M2Array<char> recursion_model_filename; // if given, this emitter is an alias for the (maximum 4) emitters of the given model
#if >= 262 (late Burning Crusade)
/*0x28*/ uint8 blendingType; // A blending type for the particle. See Below
/*0x29*/ uint8 emitterType; // 1 - Plane (rectangle), 2 - Sphere, 3 - Spline, 4 - Bone
/*0x2a*/ uint16 particleColorIndex; // This one is used for ParticleColor.dbc. See below.
#else
/*0x28*/ uint16 blendingType; // A blending type for the particle. See Below
/*0x2a*/ uint16 emitterType; // 1 - Plane (rectangle), 2 - Sphere, 3 - Spline, 4 - Bone
#endif
#if ≥
/*0x2c*/ fixed_pointⁱ<uint8_t, 2, 5> multiTextureParamX[2];
#else
/*0x2c*/ uint8 particleType; // Found below.
/*0x2d*/ uint8 headorTail; // 0 - Head, 1 - Tail, 2 - Both
// Head - The particle is a billboarded square quad;[1]
// Tail – A tail particle is billboarded along the axis of motion and stretches in length based on speed;[1]
// Both – Draws both heads and tails;[1]
#endif
uint16 textureTileRotation; // Rotation for the texture tile. (Values: -1,0,1) -- priorityPlane
uint16 textureDimensions_rows; // for tiled textures
uint16 textureDimensions_columns;
M2Track<float> emissionSpeed; // Base velocity at which particles are emitted.
M2Track<float> speedVariation; // Random variation in particle emission speed. (range: 0 to 1)
M2Track<float> verticalRange; // longitude; Drifting away vertically. (range: 0 to pi) For plane generators, this is the maximum polar angle of the initial velocity;
// 0 makes the velocity straight up (+z). For sphere generators, this is the maximum elevation of the initial position;
// 0 makes the initial position entirely in the x-y plane (z=0).
M2Track<float> horizontalRange; // latitude; They can do it horizontally too! (range: 0 to 2*pi) For plane generators, this is the maximum azimuth angle of the initial velocity;
// 0 makes the velocity have no sideways (y-axis) component.
// For sphere generators, this is the maximum azimuth angle of the initial position.
M2Track<float> gravity; // Not necessarily a float; see below.
M2Track<float> lifespan; // Number of seconds each particle continues to be drawn after its creation.[1]
#if ≥
float lifespanVary; // An individual particle's lifespan is added to by lifespanVary * random(-1, 1)
#endif
M2Track<float> emissionRate;
#if ≥
float emissionRateVary; // This adds to the base emissionRate value the same way as lifespanVary. The random value is different every update.
#endif
M2Track<float> emissionAreaLength; // For plane generators, this is the width of the plane in the x-axis.
// For sphere generators, this is the minimum radius.
M2Track<float> emissionAreaWidth; // For plane generators, this is the width of the plane in the y-axis.
// For sphere generators, this is the maximum radius.
M2Track<float> zSource; // When greater than 0, the initial velocity of the particle is (particle.position - C3Vector(0, 0, zSource)).Normalize()
#if ≥
FBlock<C3Vectorⁱ> colorTrack; // Most likely they all have 3 timestamps for {start, middle, end}.
FBlock<fixed16ⁱ> alphaTrack;
FBlock<C2Vectorⁱ> scaleTrack;
C2Vectorⁱ scaleVary; // A percentage amount to randomly vary the scale of each particle
FBlock<uint16> headCellTrack; // Some kind of intensity values seen: 0,16,17,32 (if set to different it will have high intensity)
FBlock<uint16> tailCellTrack;
#else
float midPoint; // middleTime; Middle point in lifespan (0 to 1).
// Time (parametric) Middle – The relative time of the middle key to the life.[1]
CImVectorⁱ[3] colorValues; // Color, Start/Middle/End – Three values of BGRA Multiply for the particle.[1]
float[3] scaleValues; // Scale, Start/Middle/End – Scale of the particle in units across.[1]
uint16[3] lifespanUVAnim; // Lifespan Head UV Anim – Starting, middle and ending cell number for animating texture sequence of the first half of the Head particle’s life. Repeat will cause this animating texture to cycle.[1]
uint16[3] decayUVAnim; // Decay Head UV Anim - Starting, middle and ending cell number for animating texture sequence of the second half of the Head particle’s life. Repeat will cause this animating texture to cycle.[1]
int16[2] tailUVAnim; // Lifespan Tail UV Anim - Starting and ending cell number for animating texture sequence of the first half of the Tail particle’s life. Repeat will cause this animating texture to cycle.[1]
int16[2] tailDecayUVAnim; // Decay Tail UV Anim - Starting and ending cell number for animating texture sequence of the second half of the Tail particle’s life. Repeat will cause this animating texture to cycle.[1]
#endif
float tailLength; // A multiplier to the calculated tail particle length.[1]
float twinkleSpeed; // twinkleFPS; has something to do with the spread
float twinklePercent; // same mechanic as MDL twinkleOnOff but non-binary in 0.11.0
CRangeⁱ twinkleScale; // min, max
float burstMultiplier; // ivelScale; requires (flags & 0x40)
float drag; // For a non-zero values, instead of travelling linearly the particles seem to slow down sooner. Speed is multiplied by exp( -drag * t ).
#if ≥
float baseSpin; // Initial rotation of the particle quad
float baseSpinVary;
float spin; // Rotation of the particle quad per second
float spinVary;
#else
float spin; // 0.0 for none, 1.0 to rotate the particle 360 degrees throughout its lifetime.
#endif
M2Box tumble;
C3Vectorⁱ windVector;
float windTime;
float followSpeed1;
float followScale1;
float followSpeed2;
float followScale2;
M2Array<C3Vector> splinePoints; // Set only for spline praticle emitter. Contains array of points for spline
M2Track<uchar> enabledIn; // (boolean) Appears to be used sparely now, probably there's a flag that links particles to animation sets where they are enabled.
} particles[];
Spin can be a float value greater or less one. Results look better if use it as a "phase shift": particle_rotate = randfloat(-sys->rotation * pi, sys->rotation * pi); --Igor
M2Particle (Cata+)
.- Cata+ has multi texture support
using fp_6_9 = fixed_pointⁱ<uint16_t, 6, 9>; struct vector_2fp_6_9 { fp_6_9 x; fp_6_9 y; }; struct M2Particle { M2ParticleOld old; vector_2fp_6_9 multiTextureParam0[2]; vector_2fp_6_9 multiTextureParam1[2]; } particles[];
In addition to these two parameters, ParticleType and HeadOrTail got reused (as in replaced at their current position) as multiTextureParamX[2] where all arrays are one entry per additional texture.
I don't know if the previous meaning of the two parameters still exists, got moved, or was just never used to begin with. ParticleType appears to be implicit by having flags & 0x10100000 (→ multi texture), a model (→ model) or neither (→ default).--Schlumpf (talk) 23:47, 29 October 2015 (UTC)
Particle Flags
| Value | Description |
|---|---|
| 0x1 | Particles are affected by lighting; |
| 0x2 | Unknown - Probably particle related |
| 0x4 | On emission, particle orientation is affected by player orientation |
| 0x8 | Particles travel "up" in world space, rather than model. |
| 0x10 | Do not Trail |
| 0x20 | Unlightning |
| 0x40 | Use Burst Multiplier |
| 0x80 | Particles in Model Space (Causes animation of the particle emitter to be carried over to the particles.[1]) |
| 0x100 | |
| 0x200 | spawn position randomized in some way? |
| 0x400 | STYLE: Pinned Particles, their quad enlarges from their creation position to where they expand. |
| 0x800 | |
| 0x1000 | XYQuad Particles. They align to XY axis facing Z axis direction. (Causes the particles to be a type of tail that orients to the XY grid.[1]) |
| 0x2000 | clamp to ground; call CParticleEmitter2::ProjectParticle |
| 0x4000 | |
| 0x8000 | |
| 0x10000 | ChooseRandomTexture |
| 0x20000 | STYLE: "Outward" particles, most emitters have this and their particles move away from the origin, when they don't the particles start at origin+(speed*life) and move towards the origin. |
| 0x40000 | STYLE: unknown. In a large proportion of particles this seems to be simply the opposite of the above flag, but in some (e.g. voidgod.m2 or wingedlionmount.m2) both flags are true. |
| 0x80000 | If set, ScaleVary affects x and y independently; if not set, ScaleVary.x affects x and y uniformly, and ScaleVary.y is not used. |
| 0x200000 | Random FlipBookStart |
| 0x400000 | Ignores Distance (or 0x4000000?!, CMapObjDef::SetDoodadEmittersIgnoresDistance has this one) |
| 0x800000 | gravity values are compressed vectors instead of z-axis values (see Compressed Particle Gravity below) |
| 0x1000000 | bone generator = bone, not joint |
| 0x4000000 | do not throttle emission rate based on distance |
| 0x10000000 | Particle uses multi-texturing (could be one of the other WoD-specific flags), see multi-textured section. |
--Barncastle (talk) A comparison of 0.10.0's MDX files to 0.11.0's and 1.12.1's M2 files indicates that the MDX PRE2 flags (≥0x8000) were probably unchanged during the switch from MDL to M2, albeit separated into their own enum.
ParticleColorIndex
This is used in conjunction with ParticleColor.dbc to alter the default colour of particles. If the particle colour is not meant to be changed then its ParticleColorIndex will have a value of zero. If the particle colour may be changed then the value will be 11, 12 or 13, indicating whether the first, second or third Start, Mid and End colours are to be used, respectively. The row of ParticleColor.dbc to be used is determined its ID value, which should correspond to the ParticleColorID value supplied by CreatureDisplayInfo.dbc or ItemDisplayInfo.dbc for creatures or items.
Particle types
| Value | Description |
|---|---|
| 0 | "normal" particle |
| 1 | large quad from the particle's origin to its position (used in Moonwell water effects) |
| 2 | seems to be the same as 0 (found some in the Deeprun Tram blinky-lights-sign thing) |
ParticleType is always 0 and, maybe, now (Flags & 0x40000) != 0 means "particles from origin to position". --Igor Checked and verified --BlinkHawk
Particle Blendings
| Value | Description |
|---|---|
| 0 | glDisable(GL_BLEND); glDisable(GL_ALPHA_TEST); |
| 1 | glBlendFunc(GL_SRC_COLOR, GL_ONE); |
| 2 | glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA); |
| 3 | glDisable(GL_BLEND); glEnable(GL_ALPHA_TEST); |
| 4 | glBlendFunc(GL_SRC_ALPHA, GL_ONE); |
from Modelviewer source -- Rour, some WoD particle effects are using blend mode 0x7 here.
The Fake-AnimationBlock
- Its pretty much like the real one but without the "header".
| Offset | Type | Name | Description |
|---|---|---|---|
| 0x000 | uint32 | nTimestamps | The number of timestamps. |
| 0x004 | uint32 | ofsTimestamps | And the offset to them. The timestamps are shorts!!! |
| 0x008 | uint32 | nKeys | The same number again. This time its the number of Keys / Values. |
| 0x00C | uint32 | ofsKeys | And their offset. |
But they're unable to change between different animations, so they directly point to the data.
Compressed Particle Gravity
Key values in the gravity track are decompressed at load time from a 4-byte value to a C3Vector.
struct CompressedParticleGravity {
int8_t x, y;
int16_t z;
};
for (/* each 4-byte value in the particle gravity track */) {
float *pValue;
C3Vector *pDst;
if (particle.flags & 0x800000) {
// interpret the 4 bytes at pValue as CompressedParticleGravity:
CompressedParticleGravity v = new (pValue) CompressedParticleGravity();
C3Vector dir = C3Vector(v.x, v.y, 0) * (1.0f / 128.0f);
float z = sqrtf(1.0f - dir.Dot(dir));
float mag = v.z * 0.04238648f;
if (mag < 0) {
z = -z;
mag = -mag;
}
dir.z = z;
dir *= mag;
*pDst = dir;
} else {
*pDst = C3Vector(0, 0, -(*pValue));
}
}
M2Box
struct M2Box {
C3Vectorⁱ ModelRotationSpeedMin;
C3Vectorⁱ ModelRotationSpeedMax;
}
Miscellaneous
Name
char name[];
Informative name used for debugging purposes. Not used in retail clients.
Bounding volumes
These blocks give a simplified bounding volume for the model. Characters and creatures have just a simple box.
Vertices
This block defines the possible points used for the model. They are referenced in the triangles block later.
struct
{
C3Vectorⁱ position;
} bounding_vertices[];
Triangles
The number in the header tells us how many uint16s there are, not how many triangles. To use this better, you should group three of them into an array. The nBoundingTriangles/3 indices will tell you which vertices are used for the triangle then.
struct
{
uint16_t index; // three entries pointing to vertices per triangle
} bounding_triangles[];
The number nBoundingTriangles once again contains the number of indices used, so divide by 3 to get the number of triangles.
Normals
This one defines a normal per triangle. The vectors are normalized, but Blizzard seems to have some problems getting a simple vector normalized leading in several 0,0,0.999999999 ones. Whatever.
As each vertex has a corresponding normal vector, it should be true that nBoundingNormals = nBoundingTriangles / 3.
struct
{
C3Vectorⁱ normal;
} bounding_normals[];
Lights
struct M2Light
{
/*0x00*/ uint16_t type; // Types are listed below.
/*0x02*/ int16_t bone; // -1 if not attached to a bone
/*0x04*/ C3Vectorⁱ position; // relative to bone, if given
/*0x10*/ M2Track<C3Vectorⁱ> ambient_color;
/*0x24*/ M2Track<float> ambient_intensity; // defaults to 1.0
/*0x38*/ M2Track<C3Vectorⁱ> diffuse_color;
/*0x4C*/ M2Track<float> diffuse_intensity; // defaults to 1.0
/*0x60*/ M2Track<float> attenuation_start;
/*0x74*/ M2Track<float> attenuation_end;
/*0x88*/ M2Track<uint8_t> visibility; // enabled?
/*0x9C*/
} lights[];
Two light types:
| Value | Description |
|---|---|
| 0 | Directional |
| 1 | Point light |
Directional light type is not used (at least in 3.3.5) outside login screen, and doesn't seem to be taken into account in world.
In burning crusade (and maybe more versions) the glues models hardcode constant attenuation to 0, linear attenuation to 0.7 and quadratic attenuation to 0.03
Cameras
These blocks are present in the "flyby" camera models which completely lack geometry and the main menu backdrop models which are supposed to have a fixed camera. Additionally, characters and monsters also have this block. The reason that non-mainmenu and non-geometry M2s have cameras was is you can see the unit's portrait and the character info tab.
struct M2Camera
{
uint32_t type; // 0: portrait, 1: characterinfo; -1: else (flyby etc.); referenced backwards in the lookup table.
#if <
float fov; // Diagonal FOV in radians. See below for conversion.
#endif
float far_clip;
float near_clip;
M2Track<M2SplineKey<C3Vectorⁱ>> positions; // How the camera's position moves. Should be 3*3 floats.
C3Vectorⁱ position_base;
M2Track<M2SplineKey<C3Vectorⁱ>> target_position; // How the target moves. Should be 3*3 floats.
C3Vectorⁱ target_position_base;
M2Track<M2SplineKey<float>> roll; // The camera can have some roll-effect. Its 0 to 2*Pi.
#if ≥
M2Track<M2SplineKey<float>> FoV; //Diagonal FOV in radians. See below for conversion.
#endif
} cameras[];
Camera field of view
The fov included in M2Camera is a diagonal field of view (in radians). The client converts it to a vertical field of view at runtime using the following formula:
float vfov = dfov / sqrt(1.0 + pow(aspect, 2.0));
The aspect ratio used is determined by the rect being presented on (eg. the game window).
Note that this formula makes an assumption that the screen being projected to is planar (ie a monitor).
Camera lookup table
This block lists the different cameras existing in the model. The index in the array is also the type. CameraLookupTable[1] is always the character tab camera.
"-1" type cameras are not referenced.
If nCameras >= 1, then nCameraLookup will be >= 1 regardless of whether any camera will be actually referenced in it. See interface/glues/models/ui_mainmenu_warlords/ui_mainmenu_warlords.m2. A valid block thus may be -1s only. This appears to be an exporter-quirk rather than a requirement.
struct
{
uint16_t camera;
} camera_lookup[];
Attachments
This block specifies a bunch of locations on the body - hands, shoulders, head, back, knees etc. It is used to put items on a character. This seems very likely as this block also contains positions for sheathed weapons, a shield, etc.
struct M2Attachment
{
uint32_t id; // Referenced in the lookup-block below.
uint16_t bone; // attachment base
uint16_t unknown; // see BogBeast.m2 in vanilla for a model having values here
C3Vectorⁱ position; // relative to bone; Often this value is the same as bone's pivot point
M2Track<uchar> animate_attached; // whether or not the attached model is animated when this model is. only a bool is used. default is true.
} attachments[];
Meaning depends on type of model. The following are for creatures/characters mainly:
| ID | Description | ID | Description | ID | Description | ID | Description | ID | Description |
|---|---|---|---|---|---|---|---|---|---|
| 0 | Shield / MountMain / ItemVisual0 | 12 | Back | 24 | Special2 | 36 | Bullet (version: somewhen after alpha) | 48 | RightFoot |
| 1 | HandRight / ItemVisual1 | 13 | ShoulderFlapRight | 25 | Special3 | 37 | SpellHandOmni (version: somewhen after alpha) | 49 | ShieldNoGlove |
| 2 | HandLeft / ItemVisual2 | 14 | ShoulderFlapLeft | 26 | SheathMainHand | 38 | SpellHandDirected (version: somewhen after alpha) | 50 | SpineLow |
| 3 | ElbowRight / ItemVisual3 | 15 | ChestBloodFront | 27 | SheathOffHand | 39 | VehicleSeat1 ≥
|
51 | AlteredShoulderR |
| 4 | ElbowLeft / ItemVisual4 | 16 | ChestBloodBack | 28 | SheathShield | 40 | VehicleSeat2 ≥
|
52 | AlteredShoulderL |
| 5 | ShoulderRight | 17 | Breath | 29 | PlayerNameMounted | 41 | VehicleSeat3 ≥
|
53 | BeltBuckle ≥ 
|
| 6 | ShoulderLeft | 18 | PlayerName | 30 | LargeWeaponLeft | 42 | VehicleSeat4 ≥
|
54 | SheathCrossbow |
| 7 | KneeRight | 19 | Base | 31 | LargeWeaponRight | 43 | VehicleSeat5 ≥
|
55 | HeadTop ≥
|
| 8 | KneeLeft | 20 | Head | 32 | HipWeaponLeft | 44 | VehicleSeat6 ≥
|
56 | VirtualSpellDirected ≥
|
| 9 | HipRight | 21 | SpellLeftHand | 33 | HipWeaponRight | 45 | VehicleSeat7 ≥
|
57 | Backpack ≥
|
| 10 | HipLeft | 22 | SpellRightHand | 34 | Chest | 46 | VehicleSeat8 ≥
|
60 | Unknown ≥
|
| 11 | Helm | 23 | Special1 | 35 | HandArrow | 47 | LeftFoot |
For weapons, usually 5 of these points are present, which correspond to the 5 columns in ItemVisuals.dbc, which in turn has 5 models from ItemVisualEffects.dbc. This is for the weapon glowy effects and such. The effect ID is the last column in ItemDisplayInfo.dbc. They take the ids 0 to 4. Mounts take the id 0 for their rider. Breath (17) is used by CGCamera::FinishLoadingTarget() aswell as some other one. The name above the head of a Unit (CGUnit_C::GetNamePosition) looks for PlayerNameMounted (29), then PlayerName (18).
Attachment Lookup
The index of the array defines, which type that attachment is of. Its the same as the list above. The lookups and the id of the animations point in a circle.
struct
{
uint16_t attachment;
} attachment_lookup[];
Events
These events are used for timing sounds for example. You can find the $DTH (death) event on nearly every model. It will play the death sound for the unit.
The events you can use depend on the way, the model is used. Dynamic objects can shake the camera, doodads shouldn't. Units can do a lot more than other objects.
Somehow there are some entries, that don't use the $... names but identifiers like "DEST" (destination), "POIN" (point) or "WHEE" (wheel). How they are used? Idk.
struct M2Event
{
uint32_t identifier; // mostly a 3 character name prefixed with '$'.
uint32_t data; // This data is passed when the event is fired.
uint32_t bone; // Somewhere it has to be attached.
C3Vectorⁱ position; // Relative to that bone of course, animated. Pivot without animating.
M2TrackBase enabled; // This is a timestamp-only animation block. It is built up the same as a normal AnimationBlocks, but is missing values, as every timestamp is an implicit "fire now".
} events[];
Possible Events
There are a lot more of them. I did not list all up to now.
Bow AnimEvents include $BWA, $BWP, $BWR, $BWS (If present, all of these should be childed to the right hand).
| ID | data | what | Type | seen to be fired on | Description |
|---|---|---|---|---|---|
| $AH[0-3] | — | PlaySoundKit (customAttack[x]) | soundEffect ID is defined by CreatureSoundDataRec::m_customAttack[x] | ||
| $BMD | — | BowMissleDestination | RangedWeapon | Bow Middle | |
| $AIM | Vehicles | CGUnit_C::ComputeMissileTrajectory | Position used as MissileFirePos. | ||
| $ALT | anim_swap_event / DisplayTransition | Unit | CUnitDisplayTransition_C::UpdateState(1) or CUnitDisplayTransition_C::HandleAnimSwapEvent | ||
| $BL[0-3] | — | FootstepAnimEventHit (left) | Unit | Backwards | |
| $BR[0-3] | — | FootstepAnimEventHit (right) | Unit | Backwards | |
| $BRT | — | PlaySoundKit (birth) | soundEffect ID is defined by CreatureSoundDatarec::m_birthSoundID | ||
| $BTH | — | Breath | Unit | All situations, where nothing happens or breathing. | Adds Special Unit Effect based on unit state (under water, in-snow, …) |
| $BWP | — | PlayRangedItemPull (Bow Pull) | Unit | LoadRifle, LoadBow | |
| $BWR | — | BowRelease | Unit | AttackRifle, AttackBow, AttackThrown | |
| $CAH | — | Unit | Attack*, *Unarmed, ShieldBash, Special* | attack hold? CGUnit_C::HandleCombatAnimEvent | |
| $CCH | — | Unit | mostly not fired, AttackThrown | Fishing Pole CEffect::DrawFishingString needs this on the model for getting the string attachments. | |
| $CFM | — | Unit | CGCamera::UpdateMountHeightOrOffset | CGCamera::UpdateMountHeightOrOffset: Only z is used. Non-animated. Not used if $CMA | |
| $CHD | Unit | not fired | probably does not exist?! | ||
| $CMA | — | Unit | CGCamera::UpdateMountHeightOrOffset: Position for camera | ||
| $CPP | PlayCombatActionAnimKit | parry, anims, depending on some state, also some callback which might do more | |||
| $CSD | soundEntryId | PlayEmoteSound | Unit | Emote* | |
| $CSL | — | release_missiles_on_next_update if has_pending_missiles (left) | Unit | AttackRifle, SpellCast*, ChannelCast* | "x is {L or R} (""Left/right hand"") (?)" |
| $CSR | — | release_missiles_on_next_update if has_pending_missiles (right) | Unit | AttackBow, AttackRifle, AttackThrown, SpellCast*, ChannelCast* | "x is {L or R} (""Left/right hand"") (?)" |
| $CSS | — | PlayWeaponSwooshSound | sound played depends on CGUnit_C::GetWeaponSwingType | ||
| $CST | — | release_missiles_on_next_update if has_pending_missiles | Unit | Attack*, *Unarmed, ShieldBash, Special*, SpellCast, Parry*, EmoteEat, EmoteRoar, Kick, ... | $CSL/R/T are also used in CGUnit_C::ComputeDefaultMissileFirePos. |
| $CVS | ? | Data: SoundEntriesAdvanced.dbc, Sound — Not present in 6.0.1.18179 | |||
| $DSE | — | DestroyEmitter | MapObj | ||
| $DSL | soundEntryId | GO | |||
| $DSO | soundEntryId | DoodadSoundOneShot | GO | ||
| $DTH | — | DeathThud + LootEffect | Unit | Death, Drown, Knockdown | """I'm dead now!"", UnitCombat_C, this plays death sounds and more." Note that this is NOT triggering CreatureSoundDataRec::m_soundDeathID, but that is just always triggered as soon as the death animation plays. |
| $EAC | — | object package state enter 3, exit 2, 4, 5 | |||
| $EDC | — | object package state enter 5, exit 3, 4, 2 | |||
| $EMV | — | object package state enter 4, exit 3, 2, 5 | |||
| $ESD | — | PlayEmoteStateSound | Unit | soundEffect ID is implicit by currently played emote | |
| $EWT | — | object package state enter 2, exit 3, 4, 5 | |||
| $FD[1-9] | — | PlayFidgetSound | CreatureSoundDataRec::m_soundFidget (only has 5 entries, so don’t use 6-9) | ||
| $FDX | — | PlayUnitSound (stand) | soundEffect ID is defined by CreatureSoundDataRec::m_soundStandID | ||
| $FL[0-3] | — | FootstepAnimEventHit (left) | Foot Left Forward | ||
| $FR[0-3] | — | FootstepAnimEventHit (right) | Foot Right Forward | ||
| $FSD | — | HandleFootfallAnimEvent | Unit | Walk, Run (multiple times), ... | Plays some sound. Footstep? Also seen at several emotes etc. where feet are moved. CGUnit_C::HandleFootfallAnimEvent |
| $GC[0-3] | — | GameObject_C_PlayAnimatedSound | soundEffect ID is defined by GameObjectDisplayInfoRec::m_Sound[x + 6] ({Custom0, Custom1, Custom2, Custom3}) | ||
| $GO[0-5] | — | GameObject_C_PlayAnimatedSound | soundEffect ID is defined by GameObjectDisplayInfoRec::m_Sound[x] ({Stand, Open, Loop, Close, Destroy, Opened}) | ||
| $HIT | — | PlayWoundAnimKit | Unit | Attack*, *Unarmed, ShieldBash, Special* | soundEntryId depends on SpellVisualKit |
| $KVS | ? | MapLoad.cpp -- not found in 6.0.1.18179 | |||
| $RL[0-3] | — | FootstepAnimEventHit (left) | Running | ||
| $RR[0-3] | — | FootstepAnimEventHit (right) | Running | ||
| $SCD | — | PlaySoundKit (spellCastDirectedSound) | soundEffect ID is defined by CreatureSoundDataRec::m_spellCastDirectedSoundID | ||
| $SHK | spellEffectCameraShakesID | AddShake | GO | ||
| $SHL | — | ExchangeSheathedWeapon (left) | Sheath, HipSheath | ||
| $SHR | — | ExchangeSheathedWeapon (right) | Sheath, HipSheath | ||
| $SL[0-3] | — | FootstepAnimEventHit (left) | Stop, (JumpEnd), (Shuffle*) | Stop | |
| $SMD | — | PlaySoundKit (submerged) | soundEffect ID is defined by CreatureSoundDatarec::m_submergedSoundID | ||
| $SMG | — | PlaySoundKit (submerge) | soundEffect ID is defined by CreatureSoundDatarec::m_submergeSoundID | ||
| $SND | soundEntryId | PlaySoundKit (custom) | GO | ||
| $SR[0-3] | — | FootstepAnimEventHit (right) | Stop, (JumpEnd), (Shuffle*) | Stop | |
| $STx | Mounts | MountTransitionObject::UpdateCharacterData | Not seen in 6.0.1.18179 -- x is {E and B} , sequence time is taken of both, pivot of $STB. (Also, attachment info for attachment 0) | ||
| $TRD | — | HandleSpellEventSound | Unit | EmoteWork*, UseStanding* | soundEffect ID is implicit by SpellRec |
| $VG[0-8] | — | HandleBoneAnimGrabEvent | |||
| $VT[0-8] | — | HandleBoneAnimThrowEvent | |||
| $WGG | — | PlayUnitSound (wingGlide) | soundEffect ID is defined by CreatureSoundDataRec::m_soundWingGlideID | ||
| $WL[0-3] | — | FootstepAnimEventHit (left) | |||
| $WLB | Model Weapon Left Bot | ||||
| $WLT | Model Weapon Left Top | ||||
| $WNG | — | PlayUnitSound (wingFlap) | soundEffect ID is defined by CreatureSoundDataRec::m_soundWingFlapID | ||
| $WR[0-3] | — | FootstepAnimEventHit (right) | |||
| $WRB | Model Weapon Right Bot | ||||
| $WRT | Model Weapon Right Top | ||||
| $WTB | — | Weapons | Bow Bottom, Weapon Trail Bottom position, also used for Bow String | ||
| $WTT | — | Weapons | Bow Top, Weapon Trail Top position | ||
| $WWG | ? | Calls some function in the Object VMT. -- Not seen in 6.0.1.18179 | |||
| DEST | ? | exploding ballista, that one has a really fucked up block. Oo | |||
| POIN | Unit | not fired | Data: ?, seen on multiple models. Basilisk for example. (6801) | ||
| WHEE | ? | Data: 601+, Used on wheels at vehicles. | |||
| BOTT | ? | Purpose unknown. Seen in well_vortex01.m2 | |||
| TOP | ? | Purpose unknown. Seen in well_vortex01.m2 |
References
- 1. Warcraft 3 Art Tools - http://ftp.blizzard.com/pub/war3/other/WarcraftIIIArtTools1.01.zip