pd3dDevice->SetStreamSourceFreq(1, (D3DSTREAMSOURCE_INSTANCEDATA | 1));
pd3dDevice->SetStreamSource(1, g_VB_InstanceData, 0, D3DXGetDeclVertexSize( g_VBDecl_InstanceData, 1));

Stream1中的顶点数据,每g_numInstancesToDraw个顶点处理后递进一个,相当于每Instance递进一次.在HLSL中将Stream1中的数据流还原出来.

OpenGL当前不直接支持Geometry Instance,但是注意到
1.OpenGL的glDrawElements簇函数的消耗比DX的DrawIndexedPrimitives小得多.
2.OpenGL有一项DirectX所没有的能力,设置当前全局顶点数据,如glColor3f,glTexCoord,glMultiTexCoord,而且此类函数的单个调用在Driver和hardware上的消耗都极小,所以可以用glMultiTexCoord传递顶点数据到shader,而不是使用glUniformMatrix4fvARB或glLoadMatrix传递变换矩阵,此类设置GPU寄存器的函数,或者说是改变Vertex shader当前的全局处理状态的函数,很显然将等待当前GPU正在执行的Vertex process完成后才能返回,CPU将等待GPU.

The technique does not scale well to complex mesh rendering techniques like skinning; there
are not enough vertex attributes to store all of the bone transforms for each instance.
但,无论Directx9.0c或OpenGL2.1都无法传递几十个骨骼矩阵这么庞大的顶点数据单位格式(注意是一个顶点数据单位格式,OpenGL没有那么多层的glMultiTexCoord, DirectX没有那么大的顶点声明能容纳几十个矩阵),所以都无法完成带骨骼动画的Geometry Instance,只能是静态物体,或使用CPU作骨骼计算. DX10好像可以,没有显卡,没实践过.

CPU和GPU是并行结构,若使得两者完全并行运行,效率将最大化.若一方为了线性逻辑而不得不去等待另一方,效率将降低,这就好像两个线程间需要同步的数据或逻辑越多,效率就越低下.

Reference:
http://developer.download.nvidia.com/SDK/9.5/Samples/DEMOS/Direct3D9/src/HLSL_Instancing/docs/HLSL_Instancing.pdf
http://developer.download.nvidia.com/SDK/9.5/Samples/DEMOS/OpenGL/src/glsl_pseudo_instancing/docs/glsl_pseudo_instancing.pdf

在程序逻辑上,我比较倾向第2种,因为其逻辑概念比较清晰简单,但其需要额外的数据制作,wmo数据的BSP树是普通的leafy bsp,而非solid leafy bsp,似乎不足以判断一个点是否在BSP整体空间内,而且不能适应2个sector相嵌套的情形,WoW的城内的建筑portal摆放随意性很大,似乎没什么限制.

而判断人物穿过portal,感觉上逻辑比较模糊,脆弱,不稳定.当人物一直在portal边上左右徘徊时,算法是否够强壮?人物初始化时,又通过什么手段得知其初始sector呢?人物从城外进入城内的瞬间,又如何知道进入哪个sector?

WoW使用了哪一种呢?至少穿越portal这方案还可以实现出来,Crystal Space也是这么干的,可惜大部分的资料根本不提这一问题.

1.Data下出现有enUS目录,本地化的资源以后将放在Data下对应的本地化子目录中,原speech.mpq变为enUS\speech-enUS.MPQ,Interface.mpq,dbc.mpq并入enUS\locale-enUS.mpq. 想来是暴雪给每个本地化版本做那个2G多的patch做怕了.

2.Common.mpq 达到了3.49G,把之前的各个分类资源mpq全统一了.

3.M2 格式有变动,骨骼结构被修改,旋转四元数数据被压缩成8个字节的int16 * 4,还原4元数失败.

//  To open the new patch.mpq 
//  Error if mpq file is bigger than 2G
fseek();     //  or
lseek();     //  or
::SetFilePointer(hFile, dwHashTablePos,  0 , FILE_BEGIN);

//  Correct
_lseeki64();    //  or

LARGE_INTEGER li;
li.QuadPart  =  dwHashTablePos;
::SetFilePointer(hFile, li.LowPart,  & li.HighPart, FILE_BEGIN);

So change the every fseek/SetFilePointer in stormlib or libmpq in WowModelViewer source code and recompile, we can open the new patch.mpq in WoW BC which is 2.7G. The mpq format is NOT changed, I am a fool to decode a new format from the begining.

=============================================
http://linghuye.googlepages.com/MyWarCraftStudio_0.9.7z
or
http://www.cnitblog.com/Files/linghuye/MyWarCraftStudio_0.9.rar
1.Fix the bug when reading Burning Crusade's patch.mpq
2.Fix bugs when displaying model on ATI graphic cards
3.M2Import.dli is a 3D Max import plugin for importing m2 file, but only meshs now, no texture, no skeleton animation. I am learning how to write a 3D Max import plugin, this is a byproduct.

骨骼动作混合是作动作过渡的技术基础,目前看到有两种方案,一种简单,一种复杂.
简单的方案应该是起源于Quake,魔兽世界亦采用该方案,即,在骨架数据中预先标识某ID骨骼为上半身的根骨骼,依此标识下半身的根骨骼,手臂的根骨骼,腿的根骨骼.
使用骨骼动画架构可以很容易地,让奔跑的动作帧数据只作用于下本身的骨骼层次,即只作用于整个骨骼层次的子骨骼体系.让挥手或开枪的动作只作用上本身骨骼,最终的结果形成了动作混合.
复杂的方案是Weighted animation blending,为每个动作的每根骨骼标识它的权重,即标识每根骨骼在每个动作中的重要性,可以用1.0标识腿部骨骼在奔跑动作中的权重,用0.0标识上半身在奔跑动作中的权重.
与另一动作混合时,两个动作骨骼分别计算自身当前的骨骼帧运动数据,然后依据动作权重进行插值混合两者的运动数据,Jupiter,Nebula使用了该方案.其复杂不在程序上,而在美工制作上,程序代码上更优雅简单.

奔跑时拉弓就要让下半身保持奔跑动作,上本身从奔跑时的姿势过渡到拉弓姿势.Animation transitioning是要解决两个骨架姿势之间的过渡问题,从一个姿势过渡到另一个姿势,即从一个骨架数据渐转到另一个骨架数据,即在过渡间的人物骨架姿势由两个动作的骨架数据混合而成,一个数据渐增0->1,一个数据渐减1->0,这里的权重作用于整个骨架,称Weighted animation blending.这样的过渡是数据计算出来的,而不是美工设计出来的,有时会有变形出现.

这些方案都基于骨架层次体系,适合组合任意个骨骼动作.帧数据插值混合时,若姿势间相差过大,旋转超过180度,slerp计算会出现混乱.

References:
Quake3 source code
WowModelViewer's animation blending source code
http://www.circlesoft.org/DirectMesh2/DM2Spec/pages/Features.htm
Realtime Character Animation Blending Using Weighted Skeleton Hierarchies (该问题最好的论文)

http://www.wowguru.com/wiki/index.php/Main_Page

使用指令将顶点的骨骼和权重信息作为Generic Attribute属性传入给Shader对象.
GLint indexBone = glGetAttribLocationARB(m_glPrograme, "bone");
GLint indexWeight = glGetAttribLocationARB(m_glPrograme, "weight");
glVertexAttribPointerARB(indexBone, 4, GL_UNSIGNED_BYTE, GL_FALSE, sizeof(MDL_VERTEX), m_arrMdlVertices[0].bones);
glVertexAttribPointerARB(indexWeight, 4, GL_UNSIGNED_BYTE, GL_FALSE, sizeof(MDL_VERTEX), m_arrMdlVertices[0].weights);
glEnableVertexAttribArrayARB(indexBone);
glEnableVertexAttribArrayARB(indexWeight);

在每帧在CPU中计算骨骼矩阵,并将计算好的骨骼矩阵数组传入Shader对象.
GLint indexBoneMatrices = glGetUniformLocationARB(m_model.m_glPrograme, "boneMatrices");
for(unsigned int i = 0; i < m_animSkeleton.m_vecBones.size(); i++)
{ 
 CM2Bone* pBone = m_animSkeleton.m_vecBones[i];
 glUniformMatrix4fvARB(indexBoneMatrices + i, 1, GL_TRUE, pBone->m_transformMatrix);
}

搞定,运行,发现wow的兽人模型竟然有128个骨骼,而N6200的shader的Uniform Matrix参数最多只给60个,还得考虑低端机器,玻璃渣是怎么做的?发现DX的实现从来就是送入硬件处理的,节省了额外的顶点内存,加快了速度,确实是不二的选择.
结论:
1.模型中的LOD是硬件LOD,即匹配给各层次的显卡使用的,最小LOD的动画都只需十几根骨骼,这对美工的要求很高.
2.可以直接传入UNSIGNED_BYTE的骨骼权重,让显卡去运算到float的mapping.
3.uniform mat4 boneMatrices[60];显卡能力不同将导致这里实际的60数值不同.
4.低端显卡不支持for循环控制流,要拆开手写.

attribute vec4 bone;
attribute vec4 weight;
uniform mat4 boneMatrices[32];

void main()
{    
    vec4 blendVertex = vec4(0, 0, 0, 0);
    
    for(int i = 0; i < 4; i++)
    {    
    blendVertex += boneMatrices[int(bone[i])] * gl_Vertex * weight[i];
    }
    
    gl_Position = gl_ModelViewProjectionMatrix * blendVertex;
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_FrontColor = gl_Color;
    
    vec4 ecPos = gl_ModelViewMatrix * blendVertex;
    gl_FogFragCoord = abs(ecPos.z);
}

MyWarCraftStudio's DBCCraft, support:

1.DBC data browse
2.Data field sort by clicking column title.
3.Data search by text
4.Data export to csv
5.Data field define by change the Cnfg\DBCRecordDef.xml

http://www.linghuye.nease.net/Tools/MyWarCraftStudio_DBCViewer.rar

linghuye software

XML UI排版实现思考
1.每个UI元素要根据其父元素的既定位置进行对齐偏移,所以在代码逻辑上父元素应在自身导入完备后,再行导入其子元素.(两阶段载入,good solution)
2.由于一个复合元素内的子元素来源不同,继承而来,组合而来,组合继承而来,导致确定子元素最终位置的复杂性.
3.文字的渲染性质与纹理类同,而纹理的Size由脚本数据预指定,文本的Size则在初始化时动态计算决定,设置可变文本在每次文字变化时需再次计算决定,然后这两个类同逻辑应在同一个加载阶段完成,以保证逻辑的协调.
4.a.虚元素的属性的有效性取决于InheritPropertyFrom函数实现.
  b.逻辑上,虚元素只能定义元素的样式,大小,对齐偏移,而不能定义具体位置,或具体文本内容.
  c.无大小定义的纹理,其大小决定于其所依附的元素.
5.对于虚组合元素,如按钮等,它的所有子元素均为第2层虚元素.
6.对于多重复合继承,依靠严格遵循如上准则,多重组合继承应该在逻辑上自然实现.

虚元素的逻辑定义层次
1.只有样式,没有对齐偏移和Size的虚元素为第1层.
2.有对齐偏移或Size的虚元素定义的虚元素为第2层.
3.组合了其他虚子元素的虚组合元素为第3层,如一个虚的按钮的NormalText元素也是个虚元素,同时NormalText又继承于某个FontString元素.
4.复合的Frame元素为第4层.

// M2文件头部信息结构
struct M2_HEADER // 336 bytes, 84 DWORDs.
{
DWORD dwIdent; // M2 File Identity
DWORD dwVersion; // version: 256

DWORD nModelNameSize; // strlen(szModelName) + 1
DWORD nModelNameOffset; // always 336(header size), points to ModelName.

DWORD dwUnk1; // All 0s, occasionally 1,3(World\SkillActivated\Containers\TreasureChest01: 3)

DWORD nGlobalSequences;
DWORD nGlobalSequencesOffset; // points to array of DWORD
    
DWORD nNumAnimations;
DWORD nAnimationsOffset; // points to M2_ANIMATION_INFO

DWORD nUnkIndices;
DWORD nUnkIndicesOffset; // points to array of unsigned short

DWORD nUnkLongs;
DWORD nUnkLongsOffset; // points to array of longs

DWORD nBonesCount;
DWORD nBonesOffset; // points to M2_BONE_DATA

DWORD nUnkIndices2;
DWORD nUnkIndicesOffset2; // points to array of unsigned short

DWORD nNumVertices;
DWORD nVerticesOffset; // points to M2_Vertex!!!

DWORD nNumGeoMeshs;  
DWORD nGeoMeshsOffset; // Points to M2_GEOMETRY_MESH!!!

DWORD dwMagic[2]; // 0s

DWORD nNumTextures;
DWORD nTexturesOffset; // points to M2_TEXTURE_INFO.

DWORD dwUnk6[10]; // Other chunks

DWORD nGroupBoneIDs; // Bone groups data
DWORD nGroupBoneIDsOffset; // points to array of unsigned short which is bone id.

DWORD nNumMaterials;
DWORD nMaterialsOffset;

DWORD nStruct1Count; // 16 bytes, only 1. 
DWORD nStruct1Offset;

DWORD nStruct2Count; // 16 bytes, only 1.
DWORD nStruct2Offset;

DWORD nStruct3Count; // 16 bytes, only 1.
DWORD nStruct3Offset;

vec3_type vMinBox; // Bounding box
vec3_type vMaxBox;

float fUnk4; // Unknown but it's right before min box when former mdx format.

float fUnk[5];
DWORD dwUnk8; // Unknown 0
float fUnk9;

DWORD dwUnk10;   // Always 36
DWORD dwUnk11[5];

DWORD nAttachments;
DWORD nAttachmentsOffset;

DWORD dwUnk12;
DWORD dwUnkOffset12;

DWORD nNumEvents;
DWORD nEventsOffset; 

DWORD dwUnk13;
DWORD dwUnkOffset13;

DWORD nCameras1;
DWORD nCameras1Offset;

DWORD nCameras2;
DWORD nCameras2Offset;
DWORD dwUnk14;

DWORD dwUnk15[6];
};       

// 纹理信息结构
struct M2_TEXTURE_INFO
{
DWORD nReplaceableId; // 非0时,表示换装(Creature/Character部分全部为换装类型).
DWORD dwUnk2; // 换装参数?
DWORD nNameSize; // 字符串长度,为1则空.
DWORD nNameOffset; // 字符串偏移位置
};

// 顶点信息结构 
struct M2_VERTEX // 48 bytes
{
vec3_type      v;
unsigned long  bwgt; // ?
unsigned short bidx; // ? 
unsigned short gndx; // ?
vec3_type    n;
vec2_type    u;
unsigned long  unk[2]; // Reserved 0 until now 1.12
};

// 几何 Mesh 信息结构
struct M2_GEOMETRY_MESH // 44 bytes
{
DWORD nNumIndexedVertices; // Indexed vertices count
DWORD nIndicesOffset; // Vertices indices array, points to unsigned shorts.
DWORD nPrimitivesCount; // Primitives count, Triangle's count * 3
DWORD nPrimitivesOffset; // Points to primitive vertex indices, MDL_TRIANGLEs. 
DWORD nNumGroupIndices; // Group indices count
DWORD nGroupIndicesOffset; // M2_4GROUP_INDICES array correlative with vertex.
DWORD nNumGeoParts; // per 32 bytes
DWORD nGeoPartsOffset; // points to M2_GEOMESH_GROUP_DATA
DWORD nUnk; // per 24 bypes
DWORD nUnkOffset; // points to M2_GROUP_BONE_DATA
DWORD dwUnk3; // one of 256, 75, 53, 21 
};

struct M2_ANIMATION_INFO // 68 bytes
{
DWORD   nAnimationClass; // Refer to AnimationData.dbc's first field.
DWORD nFrameBegin;
DWORD nFrameEnd;
float fMoveSpeed;
int bNonLooping;
int nUnk1;
DWORD   nUnk2;
DWORD   nUnk3;
DWORD   nUnk4;   
vec3_type vMins; // Unsure?
vec3_type vMaxs;
float   fBoundsRadius;
DWORD   nUnk5;
};  

struct M2_ANIM_FRAME_SEQUENCE // Animation Frame Sequence
{
short wType;
short wFlags;
DWORD dwLineTypeCount; // Interpolate type?
DWORD dwLineTypeOffset;
DWORD nFramesCount; // num of frame indices
DWORD nFramesOffset; // points to frame indices array 
DWORD nMtDataCount; // num of frame matrix transform data(translate/rotate/scale)
DWORD nMtDataOffset; // frame matrix transform data offset 
};

struct M2_BONE_DATA
{
int   nParentID;
short wObjTag;
short wUnk;
short nGeosetAnimID;
short nGeosetID;
M2_ANIM_FRAME_SEQUENCE infoTranslate;
M2_ANIM_FRAME_SEQUENCE infoRotate;
M2_ANIM_FRAME_SEQUENCE infoScale;
vec3_type vPivotPoint;
};

struct M2_TRANSLATE_DATA
{
vec3_type vTrans;
};

struct M2_ROTATE_DATA
{
quaternion_type qRotate;
};

struct M2_SCALE_DATA
{
vec3_type vScale;
};

struct M2_GEOMESH_GROUP_DATA
{
DWORD dwUnk;
unsigned short nUnk0;
unsigned short nNumVertices;
unsigned short nUnk2;
unsigned short nPrimitivesCount;
unsigned short nGroupCount;
unsigned short nUnk4;
unsigned short nUnk5;
unsigned short nUnk6;
vec3_type vUnk;
};

struct M2_GROUP_BONE_DATA
{
short dwUnk[12];
};

struct M2_4GROUP_INDICES
{
unsigned char idx[4];
};

HTML UI解决方案
1.使用纯HTML网页界面.(XML描述C++图形界面系统)
2.使用javascript脚本.(Lua 脚本)
3.使用window.external提供COM服务体系入口.(Lua 脚本引擎环境)
4.使用动态绑定IDispatch技巧将一个普通的C++类暴露为动态COM对象.
5.使用执行函数脚本达到事件回调的效果.(Lua脚本执行)

http://www.wowwiki.com
http://www.cosmosui.com/forums/
http://vnboards.ign.com/WoW_UI_Customization/b22852/
http://forums.worldofwarcraft.com/board.aspx?fn=wow-interface-customization

1.Version 0.6在www.Blizzhackers.com上发布。

2.解析出所有数据格式。

==== 2004-07-20 ========
1.加入保存纹理图像格式功能.
2.加入信息操作对话框机制.
3.加入人物纹理

==== 2004-07-18 ========
1.同时支持解析魔兽争霸和魔兽世界的MPQ档案,Blp图像纹理,Mdx物体模型.
2.魔兽世界的MPQ档案分布在其主目录的Data下,物体模型model.MPQ,图像纹理texture.MPQ.
3.人物模型的可变更纹理系统尚未解析完全,人物无纹理,World节点下的模型比较有观赏性.
4.BLP2's format is cracked by Technetium's Blpdecode.dll.
5.Most important, ALL credits due to the shadowflare's sfmpq.dll, TheProphet's Warcraft 3 Viewer, Technetium' Blp2decode and DevIL library. I just learn it and code it in my way.