一直以来，我都记不住向量叉乘的结果，每次都要查询。其根本原因在于，我没有去研究过叉乘是如何推导出来的。于是，这次想彻底解决一下。首先要感谢维基百科，它已经把所有问题都描述清楚了。
http://en.wikipedia.org/wiki/Cross_product
而下面的文字，只是我的读书笔记，以加深自己的印象。
首先我们知道 ，对于向量u和v, u x v的结果，是得到一个既垂直于u又垂直于v的向量,假设记作n.
则有下面公式
n = u x v;
而n的方向，是由右手法则决定的。 即伸出右手，四个手指方向从u绕到v. 此时，大姆指的方向，就是n的方向。 我们通常叫做右向量。
引用一下维基百科的图来说明问题，有兴趣的兄弟可以照图比划一下。 （注：图中向量是用的a x b来表示）
有了上面的知识，我们继续向下看。
我们假设向量 u,v,n分别用三个标量来表示。即
u = (Xu,Yu,Zu)
v = (Xv,Yv,Zv)
n = (Xn,Yn,Zn)
则，它们的关系为
Xn = Yu*Zv – Zu*Yv;
Yn = Zu*Xv – Xu*Zv;
Zn = Xu*Yv – Yu*Xv;
即 n = (Yu*Zv – Zu*Yv,Zu*Xv – Xu*Zv,Xu*Yv – Yu*Xv);
而为了验证n与u和v的垂直性，可以使用点乘进行
点乘法则比这个简单多了， u*v = (Xu*Xv + Yu*Yv + Zu*Zv) = dotUV;
如果两个向量垂直，则dotUV = 0;
代入验证一把
u*n = (Xu*(Yu*Zv – Zu*Yv) + Yu*(Zu*Xv – Xu*Zv) + Zu*(Xu*Yv – Yu*Xv));
= Xu*Yu*Zv – Xu*Zu*Yv + Yu*Zu*Xv – Yu*Xu*Zv + Zu*Xu*Yv – Zu*Yu*Xv;
把正负号的因式仔细比对一下，发现刚好可以低消。 结果为0.
v*n 同理可证。
于是，也验证了n与u,v垂直的特性。
如果只是为了应用的话，走到这一步就可以停下了。后面的知识，只是为了满足一下好奇心。
那我们就来看看，这个结论是怎么来的呢？ 我们接着来推导。
为了更好地推导，我们需要加入三个轴对齐的单位向量。
i,j,k.
i,j,k满足以下特点
i = j x k; j = k x i; k = i x j;
k x j = –i; i x k = –j; j x i = –k;
i x i = j x j = k x k = 0; (0是指0向量）
由此可知，i,j,k是三个相互垂直的向量。它们刚好可以构成一个坐标系。
这三个向量的特例就是 i = (1,0,0) j = (0,1,0) k = (0,0,1)。
好，那对于处于i,j,k构成的坐标系中的向量u,v我们可以如下表示
u = Xu*i + Yu*j + Zu*k;
v = Xv*i + Yv*j + Zv*k;
那么 u x v = (Xu*i + Yu*j + Zu*k) x (Xv*i + Yv*j + Zv*k)
= Xu*Xv*(ixi) + Xu*Yv*(i x j) + Xu*Zv*(i x k) + Yu*Xv*(j x i) + Yu*Yv*(j x j) + Yu*Zv*(j x k) + Zu*Xv*( k x i ) + Zu*Yv(k x j) + Zu*Zv(k x k)
由于上面的i,j,k三个向量的特点，所以，最后的结果可以简化为
u x v = (Yu*Zv – Zu*Yv)*i + (Zu*Xv – Xu*Zv)j + (Xu*Yv – Yu*Xv)k;
于是，在i,j,k构成的坐标系中。集就是上面的结果。
当i = (1,0,0) j = (0,1,0) k = (0,0,1)时，我们通常省略i,j,k的写法。最终也就得到了我们的右向量。
叉乘的意义
叉乘表示垂直于uxv的右向量。
使用的地方
可以通过叉乘，修正向量关系，从而构建坐标系。 常见的有 摄相机矩阵和TBN空间转换矩阵的构建。
叉乘的矩阵表示法。
很多书上，包括 3D游戏大师编程技巧 上面，都是用的矩阵表示法来说明叉乘。
如下。
它对应的矩阵表示法为
求其代数余子式，可以表示为如下
有了这个，那我们合并公因式i,j,k，则可以得到矩阵表示法
到此，叉乘的内容基本OK了。 值得说明的是，如果对方程组表示成矩阵不熟悉，就会感到不习惯，但是如果多多练习，我想应该是会习惯成自然吧。。。
终于决定，还是通过wow model viewer起手，研究一下WOW的数据类型，从另一个角度，体验一把这个唯一让我充过值的游戏。
这将是一系列随笔，即在读代码的时候，顺便记录，以理清思路和加深映象。 其中会有很多让人费解的地方，如果有幸被某位兄弟看见
，请勿见笑。
这都是第四篇关于M2文件格式的文章了，但是，对MD2文件格式的理解却还是九牛一毛，冰山一角。 仔细思考了一下，发现是不是自己一
开始走的路不对，因为是从半腰上分析的。 今天决定把文件头补上。 因为文件头可以大概看出一个文件是如何组织数据，以及包含哪些
数据的。
在此，给出WotLK的头文件定义
char id[4];
uint8 version[4];
uint32 nameLength;
uint32 nameOfs;
uint32 GlobalModelFlags; // 1: tilt x, 2: tilt y, 4:, 8: add another field in header, 16: ; (no other flags as
of 3.1.1);
uint32 nGlobalSequences; // AnimationRelated
uint32 ofsGlobalSequences; // A list of timestamps.
uint32 nAnimations; // AnimationRelated
uint32 ofsAnimations; // Information about the animations in the model.
uint32 nAnimationLookup; // AnimationRelated
uint32 ofsAnimationLookup; // Mapping of global IDs to the entries in the Animation sequences block.
//uint32 nD;
//uint32 ofsD;
uint32 nBones; // BonesAndLookups
uint32 ofsBones; // Information about the bones in this model.
uint32 nKeyBoneLookup; // BonesAndLookups
uint32 ofsKeyBoneLookup; // Lookup table for key skeletal bones.
uint32 nVertices; // GeometryAndRendering
uint32 ofsVertices; // Vertices of the model.
uint32 nViews; // GeometryAndRendering
//uint32 ofsViews; // Views (LOD) are now in .skins.
uint32 nColors; // ColorsAndTransparency
uint32 ofsColors; // Color definitions.
uint32 nTextures; // TextureAndTheifAnimation
uint32 ofsTextures; // Textures of this model.
uint32 nTransparency; // H, ColorsAndTransparency
uint32 ofsTransparency; // Transparency of textures.
//uint32 nI; // always unused ?
//uint32 ofsI;
uint32 nTexAnims; // J, TextureAndTheifAnimation
uint32 ofsTexAnims;
uint32 nTexReplace; // TextureAndTheifAnimation
uint32 ofsTexReplace; // Replaceable Textures.
uint32 nTexFlags; // Render Flags
uint32 ofsTexFlags; // Blending modes / render flags.
uint32 nBoneLookup; // BonesAndLookups
uint32 ofsBoneLookup; // A bone lookup table.
uint32 nTexLookup; // TextureAndTheifAnimation
uint32 ofsTexLookup; // The same for textures.
uint32 nTexUnitLookup; // L, TextureAndTheifAnimation, seems gone after Cataclysm
uint32 ofsTexUnitLookup; // And texture units. Somewhere they have to be too.
uint32 nTransparencyLookup; // M, ColorsAndTransparency
uint32 ofsTransparencyLookup; // Everything needs its lookup. Here are the transparencies.
uint32 nTexAnimLookup; // TextureAndTheifAnimation
uint32 ofsTexAnimLookup; // Wait. Do we have animated Textures? Wasn't ofsTexAnims deleted? oO
Sphere collisionSphere;
Sphere boundSphere;
uint32 nBoundingTriangles; // Miscellaneous
uint32 ofsBoundingTriangles;
uint32 nBoundingVertices; // Miscellaneous
uint32 ofsBoundingVertices;
uint32 nBoundingNormals; // Miscellaneous
uint32 ofsBoundingNormals;
uint32 nAttachments; // O, Miscellaneous
uint32 ofsAttachments; // Attachments are for weapons etc.
uint32 nAttachLookup; // P, Miscellaneous
uint32 ofsAttachLookup; // Of course with a lookup.
uint32 nEvents; //
uint32 ofsEvents; // Used for playing sounds when dying and a lot else.
uint32 nLights; // R
uint32 ofsLights; // Lights are mainly used in loginscreens but in wands and some doodads too.
uint32 nCameras; // S, Miscellaneous
uint32 ofsCameras; // The cameras are present in most models for having a model in the Character-Tab.
uint32 nCameraLookup; // Miscellaneous
uint32 ofsCameraLookup; // And lookup-time again, unit16
uint32 nRibbonEmitters; // U, Effects
uint32 ofsRibbonEmitters; // Things swirling around. See the CoT-entrance for light-trails.
uint32 nParticleEmitters; // V, Effects
uint32 ofsParticleEmitters; // Spells and weapons, doodads and loginscreens use them. Blood dripping of a blade?
Particles.
};
在说明之前，有几个约定需要讲解一下，以便简单。 结构体中的 nXXXXX表示，有多少个这样的数据单元
而ofsXXXXXX表示，在哪里读取这个数据。 而每一个数据单元具体的大小和信息，则需要由额外的地方来定义。
在解释的时候，就不对nXXXXX和ofsXXXX多作解释了。
下面逐一说明各变量的作用的含意
id： 必然是 'M' 'D' '2' '0'
version： 用来检查文件版本的。 可以是以下值
// 10 1 0 0 = WoW 5.0 models (as of 15464)
// 10 1 0 0 = WoW 4.0.0.12319 models
// 9 1 0 0 = WoW 4.0 models
// 8 1 0 0 = WoW 3.0 models
// 4 1 0 0 = WoW 2.0 models
// 0 1 0 0 = WoW 1.0 models
nameLength和nameOfs 在WMV中，除了看到拿来检测数据合法性外，没有看到拿来读取数据的地方
GlobalModelFlags 模型的全局标志位，在WMV中除了看到用于输出外，没有看到有其它地方使用
nGlobalSequences和ofsGlobalSequences 一个全局数据序列，数据单元类型为UINT32
nAnimations和ofsAnimations 动画数据信息，数据单元类型由ModelAnimation定义，此定义在WMV中如下。
struct ModelAnimation
{
uint32 animID; // AnimationDataDB.ID
uint32 timeStart;
uint32 timeEnd;
float moveSpeed;
uint32 flags;
uint16 probability;
uint16 unused;
uint32 d1;
uint32 d2;
uint32 playSpeed; // note: this can't be play speed because it's 0 for some models
Sphere boundSphere;
int16 NextAnimation;
int16 Index;
};
它主要是定义一个动画的相关参数，比如ID，开始结束时间等等。
nAnimationLookup，动画数据查看表，主要是给外部提供一个查询的便利性，数据单元类型为UINT16
nBones，ofsBones 骨骼数据，数据单元类型为ModelBoneDef 其定义大致如下
struct ModelBoneDef {
int32 keyboneid; // Back-reference to the key bone lookup table. -1 if this is no key bone.
int32 flags; // Only known flags: 8 - billboarded and 512 - transformed
int16 parent; // parent bone index
int16 geoid; // A geoset for this bone.
int32 unknown; // new int added to the bone definitions. Added in WoW 2.0
AnimationBlock translation; // (Vec3D)
AnimationBlock rotation; // (QuatS)
AnimationBlock scaling; // (Vec3D)
Vec3D pivot;
};
可以看出，每个骨头都有一个ID，以及一些标志位，同时记录了其父骨骼的索引。 而骨骼本身，则有平移，旋转，缩放和锚点等数据。
nKeyBoneLookup也是一个提供快速查询的数据。 M2中很多对应的信息，都提供了这样的LOOK UP TABLE。 典型的以空间换时间的做法。
nVertices，ofsVertices 顶点信息，其数据单元定义如下
struct ModelVertex
{
Vec3D pos;
uint8 weights[4];
uint8 bones[4];
Vec3D normal;
Vec2D texcoords;
int unk1, unk2; // always 0,0 so this is probably unused
};
每一个顶点数据，有一个位置信息，4个骨骼索引和对应的权重 （其实貌似权重存3个就可以了。） 法线（法线貌似也只存两个FLOAT就
可以了。） 纹理坐标 以及两个没有摸索出用途的INT。 值得注意的是，WOW中的坐标用的是Z向上，Y向里的坐标。 如果要将WOW中的坐
标转换到左手坐标系（D3D默认）中。 则 X0,Y0,Z0 = X,Z,Y 若转换成右手坐标系（OPENGL默认） 则 X0，Y0,Z0 = X,Z,-Y. 这个在
前面分析数据的时候有说过。 因为在WMV中，就有转换坐标系相关的操作。
nViews， 此值表示模型有多少个LOD数据。 在WotLK版本以后，LOD数据全部被放入了 *.skin文件中。 不再在M2文件中读取。
假设一个模型为 ooxx.m2 那其对应的LOD文件信息可以为 ooxx00.skin ooxx01.skin ooxx02.skin ooxx03.skin，而此M2模型的具体子
模型划分等细节，都在skin文件中了。
nColors，ofsColors 此模型用到的颜色序列，用于实现模型动态变色效果 其数据单元定义为
struct ModelColorDef {
AnimationBlock color; // (Vec3D) Three floats. One for each color.
AnimationBlock opacity; // (UInt16) 0 - transparent, 0x7FFF - opaque.
};
struct AnimationBlock {
int16 type; // interpolation type (0=none, 1=linear, 2=hermite)
int16 seq; // global sequence id or -1
uint32 nRanges;
uint32 ofsRanges;
uint32 nTimes;
uint32 ofsTimes;
uint32 nKeys;
uint32 ofsKeys;
};
nTextures，ofsTextures定义了此模型用到的纹理序列，其结构定义如下
#define TEXTURE_MAX 32
struct ModelTextureDef
{
uint32 type;
uint32 flags;
uint32 nameLen;
uint32 nameOfs;
};
关于纹理相关的内容，得专门有一篇文章讲解一下才行。这个内容有点多，但是思路却很清楚清晰
nTransparency，ofsTransparency用于实现透明变化效果，其读取结构定义如下
struct ModelTransDef
{
AnimationBlock trans; // (UInt16)
};
AnimationBlock的定义上面已经给出
nTexAnims 纹理动画，结构体定义如下
struct ModelTexAnimDef {
AnimationBlock trans; // (Vec3D)
AnimationBlock rot; // (QuatS)
AnimationBlock scale; // (Vec3D)
};
这个表示在不同的情况下，纹理矩阵作用的效果，一些爆布，火盆上的火焰或者流动的岩浆就是通过这个实现的。
nTexReplace 字面上是可替换的纹理，在WMV中没有发现具体的用法。
nTexFlags 纹理标记位，在WMV中没有发现具体用法
nBoneLookup 骨骼查询表，在WMV中，除了拿来显示以外，没有看到特别的作用。
nTexLookup 纹理查询表，用于快速定位一个nTextures中读出来的纹理。
nTexUnitLookup 纹理单元查询表，和上面的功能类似，貌似CTM版本就没有使用到了。
nTransparencyLookup 透明信息查询表
nTexAnimLookup 纹理信息查询表
collisionSphere 碰撞球
boundSphere 包围球
nBoundingTriangles 构成包围网格的三角形数据 每个数据单元是UINT16
nBoundingVertices 构成包围网格的顶点数据 每个数据单元是Vec3D，即三个FLOAT
nBoundingNormals 构成包围网格的法线数据 数据同上
nAttachments挂接点的信息 每个挂接点的信息定义如下
struct ModelAttachmentDef
{
uint32 id; // Just an id. Is referenced in the enum POSITION_SLOTS.
uint32 bone; // Somewhere it has to be attached.
Vec3D pos; // Relative to that bone of course.
AnimationBlock unk; // (Int32) Its an integer in the data. It has been 1 on all models I saw. Whatever.
};
nAttachLookup 挂接点查询表，用于快速定位某个挂接点
nEvents 动画播放时的事件触发，用于完成一些特殊的，比如音效的播放，攻击方与受击方的动画吻合等。 定义如下
struct ModelEventDef
{
char id[4]; // This is a (actually 3 character) name for the event with a $ in front.
int32 dbid; // This data is passed when the event is fired.
int32 bone; // Somewhere it has to be attached.
Vec3D pos; // Relative to that bone of course.
int16 type; // This is some fake-AnimationBlock.
int16 seq; // Built up like a real one but without timestamps(?). What the fuck?
uint32 nTimes; // See the documentation on AnimationBlocks at this topic.
uint32 ofsTimes; // This points to a list of timestamps for each animation given.
};
关于ID的值，WMV中列出了一些摸索到的。
/*
There are a lot more of them. I did not list all up to now.
ID Data Description
DEST exploding ballista, that one has a really fucked up block. Oo
POIN unk something alliance gunship related (flying in icecrown)
WHEE 601+ Used on wheels at vehicles.
$tsp p is {0 to 3} (position); t is {W, S, B, F (feet) or R} (type); s is {R or L} (right or left); this is
used when running through snow for example.
$AHx UnitCombat_C, x is {0 to 3}
$BRT Plays some sound.
$BTH Used for bubbles or breath. ("In front of head")
$BWP UnitCombat_C
$BWR Something with bow and rifle. Used in AttackRifle, AttackBow etc. "shoot now"?
$CAH UnitCombat_C
$Cxx UnitCombat_C, x is {P or S}
$CSD SoundEntries.dbc Emote sounds?
$CVS SoundEntriesAdvanced.dbc Sound
$DSE
$DSL SoundEntries.dbc Sound with something special. Use another one if you always want to have it playing..
$DSO SoundEntries.dbc Sound
$DTH UnitCombat_C, death, this plays death sounds and more.
$EMV MapLoad.cpp
$ESD Plays some emote sound.
$EWT MapLoad.cpp
$FDx x is {1 to 5}. Calls some function in the Object VMT. Also plays some sound.
$FDx x is {6 to 9}. Calls some function in the Object VMT.
$FDX Should do nothing. But is existant.
$FSD Plays some sound.
$GCx Play gameobject custom sound referenced in GameObjectDisplayInfo.dbc. x can be from {0 to 3}: {Custom0,
Custom1, Custom2, Custom3}
$GOx Play gameobject sound referenced in GameObjectDisplayInfo.dbc. x can be from {0 to 5}: {Stand, Open,
Loop, Close, Destroy, Opened}
$HIT Get hit?
$KVS MapLoad.cpp
$SCD Plays some sound.
$SHK SpellEffectCameraShakes.dbc Add a camera shake
$SHx x is {L or R}, fired on Sheath and SheathHip. "Left/right shoulder" was in the old list.
$SMD Plays some sound.
$SMG Plays some sound.
$SND SoundEntries.dbc Sound
$TRD Does something with a spell, a sound and a spellvisual.
$VGx UnitVehicle_C, x is {0 to 8}
$VTx UnitVehicle_C, x is {0 to 8}
$WxG x is {W or N}. Calls some function in the Object VMT.
------- ---------------------------------- - Old documentation (?) ----------------------------------------------
$CSx x is {L or R} ("Left/right hand") (?)
$CFM
$CHD ("Head") (?)
$CCH ("Bust") (?)
$TRD ("Crotch") (?)
$CCH ("Bust") (?)
$BWR ("Right hand") (?)
$CAH
$CST
*/
nLights 光照信息，标记了，模型的哪个骨骼上，挂接了灯光。 结构定义如下
struct ModelLightDef {
int16 type; // 0: Directional, 1: Point light
int16 bone; // If its attached to a bone, this is the bone. Else here is a nice -1.
Vec3D pos; // Position, Where is this light?
AnimationBlock ambientColor; // (Vec3D) The ambient color. Three floats for RGB.
AnimationBlock ambientIntensity; // (Float) A float for the intensity.
AnimationBlock diffuseColor; // (Vec3D) The diffuse color. Three floats for RGB.
AnimationBlock diffuseIntensity; // (Float) A float for the intensity again.
AnimationBlock attenuationStart; // (Float) This defines, where the light starts to be.
AnimationBlock attenuationEnd; // (Float) And where it stops.
AnimationBlock useAttenuation; // (Uint32) Its an integer and usually 1.
};
nCameras 真的不是太懂这个。 结构体定义如下
struct ModelCameraDef {
int32 id; // 0 is potrait camera, 1 characterinfo camera; -1 if none; referenced in CamLookup_Table
float fov; // No radians, no degrees. Multiply by 35 to get degrees.
float farclip; // Where it stops to be drawn.
float nearclip; // Far and near. Both of them.
AnimationBlock transPos; // (Vec3D) How the cameras position moves. Should be 3*3 floats. (? WoW parses 36 bytes
= 3*3*sizeof(float))
Vec3D pos; // float, Where the camera is located.
AnimationBlock transTarget; // (Vec3D) How the target moves. Should be 3*3 floats. (?)
Vec3D target; // float, Where the camera points to.
AnimationBlock rot; // (Quat) The camera can have some roll-effect. Its 0 to 2*Pi.
};
nCameraLookup 摄相机信息查询表
nRibbonEmitters 此模型身上的多边形轨迹（缎带）效果数目。 结构体定义如下
struct ModelRibbonEmitterDef {
int32 id;
int32 bone;
Vec3D pos;
int32 nTextures;
int32 ofsTextures;
int32 nUnknown;
int32 ofsUnknown;
AnimationBlock color; // (Vec3D)
AnimationBlock opacity; // (UInt16) And an alpha value in a short, where: 0 - transparent, 0x7FFF - opaque.
AnimationBlock above; // (Float) The height above.
AnimationBlock below; // (Float) The height below. Do not set these to the same!
float res; // This defines how smooth the ribbon is. A low value may produce a lot of edges.
float length; // The length aka Lifespan.
float Emissionangle; // use arcsin(val) to get the angle in degree
int16 s1, s2;
AnimationBlock unk1; // (short)
AnimationBlock unk2; // (boolean)
int32 unknown; // This looks much like just some Padding to the fill up the 0x10 Bytes, always 0
};
最后一个值unknown是WotLK版本后新增的，不知道拿来干什么。 但可以肯定，WLK版本，加强了这个效果类型的表现力。
nParticleEmitters 粒子系统，结构体定义如下。
struct ModelParticleEmitterDefV10
{
int32 id;
int32 flags;
Vec3D pos; // The position. Relative to the following bone.
int16 bone; // The bone its attached to.
int16 texture; // And the texture that is used.
int32 nModelFileName;
int32 ofsModelFileName;
int32 nParticleFileName;
int32 ofsParticleFileName; // TODO
int8 blend;
int8 EmitterType; // EmitterType 1 - Plane (rectangle), 2 - Sphere, 3 - Spline? (can't be bothered to find one)
int16 ParticleColor; // This one is used so you can assign a color to specific particles. They loop over all
// particles and compare +0x2A to 11, 12 and 13. If that matches, the colors from the dbc get applied.
int8 ParticleType; // 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)
int8 HeaderTail; // 0 - Head, 1 - Tail, 2 - Both
int16 TextureTileRotation; // TODO, Rotation for the texture tile. (Values: -1,0,1)
int16 cols; // How many different frames are on that texture? People should learn what rows and cols are.
int16 rows; // (2, 2) means slice texture to 2*2 pieces
AnimationBlock EmissionSpeed; // (Float) All of the following blocks should be floats.
AnimationBlock SpeedVariation; // (Float) Variation in the flying-speed. (range: 0 to 1)
AnimationBlock VerticalRange; // (Float) Drifting away vertically. (range: 0 to pi)
AnimationBlock HorizontalRange; // (Float) They can do it horizontally too! (range: 0 to 2*pi)
AnimationBlock Gravity; // (Float) Fall down, apple!
AnimationBlock Lifespan; // (Float) Everyone has to die.
int32 unknown;
AnimationBlock EmissionRate; // (Float) Stread your particles, emitter.
int32 unknown2;
AnimationBlock EmissionAreaLength; // (Float) Well, you can do that in this area.
AnimationBlock EmissionAreaWidth; // (Float)
AnimationBlock Gravity2; // (Float) A second gravity? Its strong.
ModelParticleParams p;
AnimationBlock en; // (UInt16), seems unused in cataclysm
int32 unknown3; // 12319, cataclysm
int32 unknown4; // 12319, cataclysm
int32 unknown5; // 12319, cataclysm
int32 unknown6; // 12319, cataclysm
};
可见WOW在粒子这块的处理还是比较用心的，毕竟很多装备上都是这种效果，特别是武器，肩膀，头盔，盾牌等装备上的效果。
后面CTM中新增的4个INT，可能是为了加强效果用的。 说明WOW还在继续增强粒子系统的表现力。 也就是说，WOW中装备的表现力还是将会通过粒子系统来实现。
哇靠，又一点了。 发贴睡觉。。。。。
终于决定，还是通过wow model viewer起手，研究一下WOW的数据类型，从另一个角度，体验一把这个唯一让我充过值的游戏。
这将是一系列随笔，即在读代码的时候，顺便记录，以理清思路和加深映象。 其中会有很多让人费解的地方，如果有幸被某位兄弟看见
，请勿见笑。
今天来说一下M2中的LOD的数据
WOW中，为了降低远处模型的渲染开销，为模型做了LOD，即远处的模型，使用更少的顶点，更粗略的材质。 比如远处的模型在渲染的时
候，面片数量减少，关闭光照，不渲染挂接的特效等等。
因此，不用证明也知道，M2中，材质是存在每一个LOD信息中的。
哎，也就写这几句的时候顺手些，其实不用分析，也是这个结果。因为我们自己的引擎就是这样做的，何况是WOW这种大师级的作品呢。
从WMV的解析代码下手，看看它是如何解析的吧。
首先，它使用了这样一行代码
int16 *transLookup = (int16*)(f.getBuffer() + header.ofsTransparencyLookup);
读取了一串用于透明值的查找数组。 不过暂时没有使用，后面材质构建的地方才会用到。
接下来，就是读取相关数据了。 在WLK以后，所有的这些数据，被分离到了.skin文件里面，不知道是咱想的，以后再来作讨论。 但是在
WLK之前，这个数据还是被放在了一起的。
通过模型的名字我们组合上.skin，就是当前所要的渲染数据了。
这个组合是这样的。
假如我们一个模型是 humanmale.m2
那么它的四个LOD数据分别就是 humanmale01.skin humanmale02.skin humanmale03.skin humanmale04.skin
当我们得到了这个数据后，就可以通过MPQFile加载想要的数据了。
OK，假设上面的过程，我们已经完全搞定了，此时，我们就得到了一个skin的数据。有了这个数据，我们就可以为所欲为了，嘿嘿。有点
夸张了。 在这个数据的最前面，肯定是数据头了。 数据头在WMV中本来一直是以xxxxHeader来定义的，不过在这里，它一改风格，定义
了一个叫ModelView的东西。
我们来看看这货的定义
struct ModelView
{
#ifdef WotLK
char id[4]; //巫妖王版本新增的一个标记位，必须是 'S' 'K' 'I' 'N'
#endif
uint32 nIndex; //这个表示此LOD有多少个INDEX
uint32 ofsIndex; //这个表示此LOD的INDEX从模型的哪里开始数
uint32 nTris; //这个表示此LOD有多少个构建成三角形的索引
uint32 ofsTris; //三角形个数
uint32 nProps; //额外的顶点属性
uint32 ofsProps; //顶点属性读取
uint32 nSub; //有多少个子部件 后面定义的ModelGeoset表示一个子部件，其包括了MESH数据，材质，渲染状态等内容
uint32 ofsSub; //
uint32 nTex; //纹理
uint32 ofsTex; // ModelTexUnit, material properties/textures
int32 lod; // LOD bias? WMV作者也打了问号。
};
有了这个数据头以后，我们就可以无脑的先读取上面的数据，然后再进行构建。
索引数据
uint16 *indexLookup = (uint16*)(g.getBuffer() + view->ofsIndex);
构成三角形的顶点索引序列
uint16 *triangles = (uint16*)(g.getBuffer() + view->ofsTris);
当前模型在渲染时候的索引数目
nIndices = view->nTris;
重新分配索引
wxDELETEA(indices);
indices = new uint16[nIndices];
将本地索引转换成全局索引
for (size_t i = 0; i<nIndices; i++)
{
indices[i] = indexLookup[triangles[i]];
}
索引数据总算是完了，下面就得准备子模型和材质相关的事情。
大家都知道，在渲染管线中，一次渲染提交只能提交具有相同渲染状态和纹理的模型。 于是，我们的模型如果具有不同的材质，就需要
先做分割处理。 这是所有WOW这样的3D MMORPG引擎都需要处理的问题。
在WMV中，模型渲染状态相关的数据，使用了ModelGeoset来表示，纹理相关的，使用了ModelTexUnit来表示
先看看ModelGeoset的定义
/// Lod part, One material + render operation
struct ModelGeoset
{
uint32 id; // mesh part id?
uint16 vstart; // first vertex, Starting vertex number.
uint16 vcount; // num vertices, Number of vertices.
uint16 istart; // first index, Starting triangle index (that's 3* the number of triangles drawn so far).
uint16 icount; // num indices, Number of triangle indices.
uint16 nSkinnedBones; // number of bone indices, Number of elements in the bone lookup table.
uint16 StartBones; // ? always 1 to 4, Starting index in the bone lookup table.
uint16 rootBone; // root bone?
uint16 nBones; //
Vec3D BoundingBox[2];
float radius;
};
由上可知，它定义了渲染相关的顶点，以及骨骼，和包围盒信息，最后一个是作为构建包围球用的。
/// Lod part, A texture unit (sub of material)
struct ModelTexUnit
{
// probably the texture units
// size always >=number of materials it seems
uint16 flags; // Usually 16 for static textures, and 0 for animated textures.
uint16 shading; // If set to 0x8000: shaders. Used in skyboxes to ditch the need for depth buffering.
See below.
uint16 op; // Material this texture is part of (index into mat)
uint16 op2; // Always same as above?
int16 colorIndex; // A Color out of the Colors-Block or -1 if none.
uint16 flagsIndex; // RenderFlags (index into render flags, TexFlags)
uint16 texunit; // Index into the texture unit lookup table.
uint16 mode; // See below.
uint16 textureid; // Index into Texture lookup table
uint16 texunit2; // copy of texture unit value?
uint16 transid; // Index into transparency lookup table.
uint16 texanimid; // Index into uvanimation lookup table.
};
而上面这个结构，是纹理相关的信息。
上面的信息，都是一些索引和ID值，真正的数据是放在全局信息中的。
读取完上面的数据后，LOD信息基本上就大功造成了。 而这些索引是如何使用的，只有下一次再研究了。今天又很晚了。
由此可知，WOW中的数据组织和一般的引擎没有太多区别。 即HEADER信息用于分割数据区域。
整个模型要使用的数据，放在了最上层，然后，不同的LOD和子MESH要使用数据的时候，只需要保存一些索引值，再到全局数据里去查询就可以了。
暂时到此吧，下次继续。。。。
终于决定，还是通过wow model viewer起手，研究一下WOW的数据类型，从另一个角度，体验一把这
个唯一让我充过值的游戏。
这将是一系列随笔，即在读代码的时候，顺便记录，以理清思路和加深映象。 其中会有很多让人费
解的地方，如果有幸被某位兄弟看见，请勿见笑。
上次弄到nAttachLookup就不行了，这次继续弄。
最近四川地震了，所以弄得比较慢。
好吧，我们接着nAttachLookup说。
读完挂接数据后，我们接着读了堆nAttachLookup个的uint16数据。这串数据最后被存了下来。在
WMV中用了一个uint16的数组来存储，叫attLookup
经过多方面分析，这个attLookup正如其名字一样，是用来查询挂接点的。
而attLookup的值可以是以下枚举成员
enum POSITION_SLOTS
{ // wxString Attach_Names[]
ATT_LEFT_WRIST = 0, // Mountpoint
ATT_RIGHT_PALM,
ATT_LEFT_PALM,
ATT_RIGHT_ELBOW,
ATT_LEFT_ELBOW,
ATT_RIGHT_SHOULDER, // 5
ATT_LEFT_SHOULDER,
ATT_RIGHT_KNEE,
ATT_LEFT_KNEE,
ATT_RIGHT_HIP,
ATT_LEFT_HIP, // 10
ATT_HELMET,
ATT_BACK,
ATT_RIGHT_SHOULDER_HORIZONTAL,
ATT_LEFT_SHOULDER_HORIZONTAL,
ATT_BUST, // 15
ATT_BUST2,
ATT_FACE,
ATT_ABOVE_CHARACTER,
ATT_GROUND,
ATT_TOP_OF_HEAD, // 20
ATT_LEFT_PALM2,
ATT_RIGHT_PALM2,
ATT_PRE_CAST_2L,
ATT_PRE_CAST_2R,
ATT_PRE_CAST_3, // 25
ATT_RIGHT_BACK_SHEATH,
ATT_LEFT_BACK_SHEATH,
ATT_MIDDLE_BACK_SHEATH,
ATT_BELLY,
ATT_LEFT_BACK, // 30
ATT_RIGHT_BACK,
ATT_LEFT_HIP_SHEATH,
ATT_RIGHT_HIP_SHEATH,
ATT_BUST3, // Spell Impact
ATT_PALM3, // 35
ATT_RIGHT_PALM_UNK2,
ATT_DEMOLISHERVEHICLE,
ATT_DEMOLISHERVEHICLE2,
ATT_VEHICLE_SEAT1,
ATT_VEHICLE_SEAT2, // 40
ATT_VEHICLE_SEAT3,
ATT_VEHICLE_SEAT4
};
上面这个枚举成员，定义了WOW中一个带动画的模型可以挂接物体的位置。又可以说，是骨头ID。在
先前我们的ModelAttachment或者ModelAttachmentDef结构体中定义的id，就正好是上面的枚举值中
的一个。
读完挂接信息以后，就是颜色和透明度数据了，WOW的模型中，一个模型可以持有由若干颜色和透明
度组成的序列，在每帧渲染的时候，动态插值计算出当前的值。 即可以实现颜色闪烁和透明度变化
的效果。 幽灵虎和凤凰什么的，就是用到了这个。
//这是颜色结构体的定义，可以看出，它定义了一个颜色值，和一个16位的透明度值
struct ModelColorDef {
AnimationBlock color; // (Vec3D) Three floats. One for each color.
AnimationBlock opacity; // (UInt16) 0 - transparent, 0x7FFF - opaque.
};
//这是透明度结构体的定义，也是一个16位的透明度值。
struct ModelTransDef {
AnimationBlock trans; // (UInt16)
};
这两个定义，导致了模型透明度的重复。 而在WMV中的代码，也确实是这样写的。先将颜色进行了
插值，而后又用透明队列的值对颜色中的ALPHA通道进行修改。
读取完了上面的数据后，接下来的，就是模型的LOD数据。 LOD中则包含了对应的材质数据。 在WMV
中，只读取了LOD0的模型。
读取完LOD后，WMV对模型的顶点数据建立了一个索引。
if (nIndices) {
IndiceToVerts = new size_t[nIndices+2];
for (size_t i=0;i<nIndices;i++){
size_t a = indices[i];
for (size_t j=0;j<header.nVertices;j++){
if (a < header.nVertices && origVertices[a].pos == origVertices[j].pos){
IndiceToVerts[i] = j;
break;
}
}
}
}
今天暂时写到这里，改天继续。。。