关于骨骼动画及微软示例Skinned Mesh的解析

骨骼动画是D3D的一个重要应用。尽管微软DXSDK提供了示例Skinned Mesh，但由于涉及众多概念和技术细节，示例相对于初学者非常复杂，难以看懂。在此，提供一些重要问题评论，以使初学者走出迷局，顺利上手。文中所述都是参照各种资料加上自己的理解，也有可能出些偏差，有则回贴拍砖，无则权当一笑。

一 骨骼动画原理
原理方面在网上资料比较多，大家都基本明白。在此说一下重点：
总体上，绝大部分动画实现原理一致，就是“提供一种机制，描述各顶点位置随时间的变化”。有三种方法：
1.1 关节动画：由于大部分运动，都是皮肤随骨骼在动，皮肤相对于它的骨骼本身并没有发生运动，所以只要描述清楚骨骼的运动就行了。用矩阵描述各个骨骼的相对于父骨骼运动。(大多运动都是旋转型) 易知，从子骨骼用矩阵乘法累积到最顶层根骨骼，就可以得到每个子骨骼相对于世界坐标系的转换矩阵。
  这种动画，只须用普通Mesh保存最初始的各顶点坐标，以及一系列后续时刻所对应的各骨骼的运动矩阵。不用保存每时刻的顶点数据，节省了大量存储空间。而且比较灵活，可以利用关键帧插值运算，便于通过运算调节动作。缺点是在两段骨骼交接处，容易产生裂缝，影响效果。

1.2 渐变动画：通过保存一系列时刻的顶点坐标来完成动画。虽然比较逼真，但占用大量空间，灵活性也不高。

1.3 骨骼蒙皮动画(skinned Mesh)
  相当于上面两方法的折中。现在比较流行。
  在关节动画的基础上，利用顶点混合(Vertex Blend)技术，对于关节附近的顶点，由影响这些顶点的两段（或多段）骨骼运动，分别赋以权值，共同决定顶点位置。相当于在骨骼关节上动态蒙皮，有效解决了裂缝问题。

  这里，引入一个D3D技术概念：“Vertex Blending”---顶点混合技术。比如说，你肯定用过SetTransform(D3DTS_WORLD,....)，但SetTransform(D3DTS_WORLDMATRIX(i),....)是不是很奇怪？这个问题后文会讲到。 你也可以在微软的DXSDK的帮助文件中搜索“Geometry Blending”主题，有裂缝及其解决办法图示。

二 X文件如何保存骨骼动画

理解X文件格式，对用好相关的DX函数是非常重要的。

不含动画的普通X文件，有一个Mesh单元，保存了各顶点信息、各三角面的索引信息、材质种类及定义等。

动画X文件，则在这个单元中增加了“各骨骼蒙皮信息”、“骨骼层次及结构信息”、“各时刻骨骼矩阵信息”等。

2.1 网格蒙皮信息：首先，在Mesh{}单元中，在原有的普通网格顶点数据基础上，新增了XSkinMeshHeader{}结构，以及多个SkinWeights{}结构。用以描述各个骨骼的蒙皮信息。

其中，XSkinMeshHeader是总括，举一实例，如下：

XSkinMeshHeader
{
2,//一个顶点可以受到骨骼影响的最大骨骼数,可用于计算共同作用时减少遍历次数
4,//一个三角面可以受到骨骼影响的最大骨骼数。这个数字对硬件顶点混合计算提出了基本要求。
35 //当前Mesh的骨骼总数。
}

由于每个骨骼的蒙皮信息都需要用SkinWeights结构去描述，所以有多少块骨骼，在Mesh中就有多少个SkinWeights对象。
注意，一般把SkinWeights视作Mesh的一部分。这种Mesh又称Skinned Mesh (蒙皮网格)

SkinWeights 结构如下：
{
  STRING      transformNodeName;      //骨骼名
  DWORD       nWeights;               //权重数组的元素个数，即该骨骼相关的顶点个数
  array DWORD vertexIndices[nWeights];//受该骨骼控制的顶点索引，实际上定义了该骨骼的蒙皮
  array float weights[nWeights];      //蒙皮各顶点的受本骨骼影响的权值
  Matrix4x4   matrixOffset;           //骨骼偏移矩阵，用来从初始Mesh坐标，反向计算顶点在子骨骼坐标系中的初始坐标。
}
在有的书中，把上面的matrixOffset叫骨骼权重矩阵，是不恰当的。应该称为骨骼偏移矩阵比较合适。

[问题] 在整个动画过程中，子骨骼运动矩阵的数值是不断变化的。上面的骨骼偏移矩阵变化吗？有没有必要重新计算？它在什么时候使用？
答：各骨骼的偏移矩阵matrixOffset专门用来从原始Mesh数据计算出各顶点相对于骨骼坐标系的原始坐标。在绘制前，把它与当前变换矩阵相乘，就可以得到该骨骼的当前的最终变换矩阵。 总之，骨骼偏移矩阵是与原始Mesh顶点数值相关联的，在整个动画过程中是不变的，也不应该变。在动画过程中变化是当前骨骼变换矩阵，可由.X中的AnimatonKey中的各时刻矩阵得到。这个矩阵乘法在示例中的对应代码如下：
D3DXMatrixMultiply( &matTemp, &pMeshContainer->pBoneOffsetMatrices[iMatrixIndex], pMeshContainer->ppBoneMatrixPtrs[iMatrixIndex] );

即，D3DXMatrixMultiply(输出最终世界矩阵, 该骨骼的偏移矩阵, 该骨骼的变换矩阵)

2.2 骨骼层次信息

在X文件中，Frame是基本的组成单元。又称框架Frame。 一个.x可以有多个Frame。(注意此处的Frame不是帧，与帧没什么关系)

框架Frame允许嵌套，这样就存在父子框架了。而并列的框架，称为兄弟框架。这两种关系组合在一起，即可以纵深，又可以并列，形成一种层次结构。这种结构，可用二叉树描述。

每个框架结构的最前面，有一个FrameTransformMatrix矩阵数据，描述了该框架相对于父框架的变换矩阵。也就是说，该框架中的坐标，与该矩阵相乘，可转换为父框架坐标系的坐标。
这种层次结构，使得X文件能描述许多复杂的物体。如地形场景。

在骨骼动画文件中，框架结构可直接拿来描述人物骨骼的层次结构。框架的名字通常为对应的骨骼名。
如“左上臂->左前臂->手掌->手指”就形成一个父子骨骼链。而左上臂与右上臂是并行关系。

数据示例： D:\D9XSDK\Samples\Media\tiny.x

Frame ...{
  .....

  Frame Bip01_R_Calf { //子骨骼
      
       FrameTransformMatrix {
        1.000000,-0.000691,-0.000000,0.000000,0.000691,1.000000,-0.000000,0.000000,0.000000,0.000000,1.000000,0.000000,119.231522,0.000021,-0.000011,1.000000;;
       }

        Frame Bip01_R_Foot {//--孙子骨骼
      
        FrameTransformMatrix {
         0.988831,0.124156,0.082452,0.000000,-0.122246,0.992109,-0.027835,0.000000,-0.085257,0.017445,0.996206,0.000000,119.231476,-0.000039,0.000023,1.000000;;
        }

        ....缩进
    }
}

[问题]查看示例tiny.x文件，发现只有根框架下有一个Mesh，包含了所有顶点信息。其它各个Frame都没有Mesh数据。怎么理解？
答： 一般来说，每个动画文件只有一个Mesh网格，包含物体所有顶点信息。
     其它Frame，只是借用来描述各骨骼的层次信息,没必要再定义骨骼网格。每块骨骼对应的蒙皮顶点信息，由根Mesh中的相应骨骼的SkinWeights中蒙皮顶点索引描述的。在动画过程中，各个顶点的新坐标，要借助SkinWeights中的顶点索引来进行重新计算。

2.3 动画信息：
由一系列AnimatonKey组成，数据示例如下：

  AnimationKey {
   4;--动画类型 4表示矩阵
   62; --动画帧数，即下面矩阵个数
   0;16;1.000000,-0.000691,-0.000000,0.000000,0.000691,1.000000,0.000000,0.000000,0.000000,-0.000000,1.000000,0.000000,119.231514,-0.000005,0.000001,1.000000;;,
   80;16;0.992696,-0.120646,-0.000000,0.000000,0.120646,0.992696,0.000000,0.000000,-0.000000,-0.000000,1.000000,0.000000,119.231514,0.000002,-0.000002,1.000000;;,

   ..上面红数字表示时刻tick,兰数字表示数值的个数。
   ...其它各时刻矩阵...

   { Bip01_R_Calf }--对应的骨骼对象引用
  }

注意：
(1)每块骨骼都有一个AnimationKey{}.
(2)在上面数据结构中，主要保存了各典型时刻的该骨骼相对于父的变换矩阵.
(3)在0时刻的矩阵，与该骨骼对应的前面的Frame所对应的矩阵是相同的。如Frame Bip01_R_Calf{}中的变换矩阵，与Bip01_R_Calf所对应的AnimationKey 的第0时刻矩阵是一样的。这说明，在以后动画运行时，DX会提供一种功能，用AnimatonKey中的对应数据刷新初始的变换矩阵(也可能启用关键帧插值算法)。这个功能对应于示例中的m_pAnimController->SetTime(...)语句。

三 怎样从X文件加载骨骼动画信息？
3.1 负责加载的函数：
  可能有多种加载方式，在此以SDK中的示例为准，叙述一种标准加载方式，需要用到DX函数D3DXLoadMeshHierarchyFromX(),函数字面意思是读取Mesh层次信息。
HRESULT WINAPI
    D3DXLoadMeshHierarchyFromX(
        LPCSTR Filename,                 //.x文件名
        DWORD MeshOptions,               //Mesh选项，一般选D3DXMESH_MANAGED
        LPDIRECT3DDEVICE9 pD3DDevice,    //指向D3D设备Device
        LPD3DXALLOCATEHIERARCHY pAlloc,  //自定义数据容器
        LPD3DXLOADUSERDATA pUserDataLoader,  //一般选NULL
        LPD3DXFRAME *ppFrameHierarchy,       //返回根Frame指针，指向代表整个骨架的Frame层次结构
        LPD3DXANIMATIONCONTROLLER *ppAnimController //返回相应的动画控制器
);

这个函数后面的两个输出参数很重要，也很好理解，但输入参数中的自定义数据容器是怎么回事呢？
原来，鉴于动画数据的复杂性，需要你配合完成加载过程。比如你是否用到自定义扩展结构，Mesh等数据保存在哪里，怎样使用户自己创建容器，自己决定卸载等等。
DX提供了ID3DXALLOCATEHIERARCHY接口，提供了这个自定义的机会，你重载这个接口的虚函数，在加载过程中，它就像回调函数那样运作。

你需要像下面这样建立一个自定义数据容器类：
class CAllocateHierarchy: public ID3DXAllocateHierarchy
{
public:
    STDMETHOD(CreateFrame)(THIS_ LPCTSTR Name, LPD3DXFRAME *ppNewFrame);
    STDMETHOD(CreateMeshContainer)(THIS_ LPCTSTR Name, LPD3DXMESHDATA pMeshData,
                            LPD3DXMATERIAL pMaterials, LPD3DXEFFECTINSTANCE pEffectInstances, DWORD NumMaterials,
                            DWORD *pAdjacency, LPD3DXSKININFO pSkinInfo,
                            LPD3DXMESHCONTAINER *ppNewMeshContainer);
    STDMETHOD(DestroyFrame)(THIS_ LPD3DXFRAME pFrameToFree);
    STDMETHOD(DestroyMeshContainer)(THIS_ LPD3DXMESHCONTAINER pMeshContainerBase);
    CAllocateHierarchy(CMyD3DApplication *pApp) :m_pApp(pApp) {}
public:
    CMyD3DApplication* m_pApp;
};

[问题]上面的STDMETHOD是什么意思？
答：相当于virtual   HRESULT   __stdcall 的宏。<评论> 因为这种类要与D3D的COM接口打交道，不仅仅在C++内部使用，所以，所有类方法必须做成stdcall的，可对外开放的。
#define   STDMETHOD(method)               virtual   HRESULT   STDMETHODCALLTYPE   method  
#define   STDMETHODCALLTYPE               __stdcall  
这样当写一个函数STDMETHOD(op1(int   i))      
展开后成为：     virtual   HRESULT   __stdcall   op1(int   i);  

3.2 自定义数据容器以及具体的读取过程:
根据.X文件，在加载过程中，主要有两方面数据需要保存，一个是骨架Frame信息，一个是网格蒙皮Mesh信息。这两个信息保存在如下结构中。

框架信息(对应于骨骼)
typedef struct _D3DXFRAME
{
    LPSTR                   Name;
    D3DXMATRIX              TransformationMatrix; //本骨骼的转换矩阵

    LPD3DXMESHCONTAINER     pMeshContainer;       //本骨骼所对应Mesh数据

    struct _D3DXFRAME       *pFrameSibling;       //兄弟骨骼
    struct _D3DXFRAME       *pFrameFirstChild;    //子骨骼
} D3DXFRAME, *LPD3DXFRAME;

自定义数据容器,其数据来源由上面接口的CreateMeshContainer()函数提供
typedef struct _D3DXMESHCONTAINER
{
    LPSTR                   Name;       //容器名
    D3DXMESHDATA            MeshData;   //Mesh数据,可创建SkinMesh取代这个Mesh
    LPD3DXMATERIAL          pMaterials; //材质数组
    LPD3DXEFFECTINSTANCE    pEffects;  
    DWORD                   NumMaterials;//材质数
    DWORD*                  pAdjacency;  //邻接三角形数组
    LPD3DXSKININFO          pSkinInfo;   //蒙皮信息,其中含.x中的各个skinweight蒙皮顶点索引及各骨骼偏移矩阵等。
    struct _D3DXMESHCONTAINER *pNextMeshContainer;
} D3DXMESHCONTAINER, *LPD3DXMESHCONTAINER;

[评论]
.在动画文件中，框架通常用来描述骨骼。可以把Frame视做骨骼，所以不细加区分。
.在上面D3DXFRAME结构中,pFrameSibling, pFrameFirstChild两个指针，常用于递归函数中，遍历整个骨架。
.在D3DXFRAME结构中有一个pMeshContainer指针，难道框架与Mesh是一一对应的吗？
有一个框架(骨骼)就有一个Mesh吗？怎么.X文件中只有一个Mesh?难道加载时拆开存放?
答:从D3DXFrame结构上看，每个Frame都有一个pMeshContainer指针。这就有三种解释：
   第一种，加载到内存后所有的pMeshContainer都指向同一个全局Mesh
   第二种，加载到内存后，只有一个主框架的pMeshContainer不为空，其它Frame的pMeshContainer均为NULL，因为在.X中，它们没有定义自己的Mesh
   第三种，加载到内存后，D3D将Mesh拆分，分开到各骨骼所对应的Frame，每个Frame都有自己的Mesh。
   这个问题我以前也不是很清楚，通过查看示例源码及跟踪发现，正确解释应该是第2种。唯一的一个全局Mesh存放在Frame "body"下的无名Frame中。而其它Frame由于没有自己专门的Mesh而指向NULL. 应该大致如此。这个问题之所以让人困绕，是因为从后续代码上看，在渲染DrawFrame时，是遍历每一个frame分别绘制它们对应的Mesh. 如果对应于同一个mesh，就绘制多遍。如果对应各自mesh，那么变换矩阵怎么组织运算等等。所以，根据第二种解释，由于只有一个pMeshContainer不为NULL，所以参与绘制及蒙皮的只有这一个MeshContainer，人体所有顶点数据及蒙皮信息都在这个mesh中。
所以，读取tiny.x文件后，会产生多个D3DXFRAME对象，但只有一个D3DXMESHCONTAINER对象。

在示例代码的CMyD3DApplication::InitDeviceObjects()中，有:
    hr = D3DXLoadMeshHierarchyFromX(strMeshPath, D3DXMESH_MANAGED, m_pd3dDevice, &Alloc, NULL, &m_pFrameRoot, &m_pAnimController);
    if (FAILED(hr))
        return hr;
其中的Alloc是就自定义的数据容器对象。m_pFrameRoot是根骨骼，对遍历很重要。m_pAnimController是动画控制器，对刷新矩阵很重要。

你在运行完这句话后，下一个断点，观察m_pFrameRoot，会发现如下内容：

m_pFrameRoot 0x00c59380 {Name=0x00c53630 "Scene_Root" .....} //根框架
pMeshContainer 0x00000000
pFrameSibling 0x00000000
pFrameFirstChild 0x00c59428 {Name=0x00c53ca8 "body" pMeshContainer=0x00000000...}//子框架 骨骼body
   +---  pMeshContainer 0x00000000
           +---  pFrameSibling 0x01419f00 {Name=0x00c5ffd8 "Box01" pMeshContainer=0x00000000 ...}//兄弟框架
      +---  pFrameFirstChild 0x00c594d0 {Name=0x00000000 pMeshContainer=0x00c59828 //子框架---该框架就是.x中含有唯一全局Mesh的无名框架

可见,在内存中的Frame布局是与.x中一一对应的。除了pFrameFirstChild 0x00c594d0这个地方的Frame中的pMeshContainer不为空，其它框架的这个mesh指针都是空值。
另外一点可以看出，并不是每个Frame都对就一块骨骼，有的是别的用途。也就是说Frame对象的个数可能多于骨骼数。

3.3 分析CAllocateHierarchy类
下面继续研究自定义数据容器CAllocateHierarchy，顾名思义，该类是在加载过程中自行分配层次数据空间。它有4个成员，都是重载D3D的接口虚函数。
它的成员CreateFrame()是用来创建D3DXFrame对象的，而CreateMeshContainer()是用来创建Mesh数据对象的。你可以在这两个函数中下断点，发现CreateFrame会运行多次，而CreateMeshContainer只运行一次，再次验证了上面的说法。

值得注意的是，示例对上面的D3DXFRAME，D3DXMESHCONTAINER两个结构做了扩展，分别代之以D3DXFRAME_DERIVED结构和D3DXMESHCONTAINER_DERIVED结构，以集中存储数据方便程序处理。

CreateFrame()处理比较简单，你只是new一个Frame对象空间，填入传进来的Name，其它内容由DX负责维护填充。

CreateMeshContainer()较为复杂。它的任务一是保存传入的网格数据数据，二是根据这些数据及蒙皮信息调用GenerateSkinnedMesh()函数生成蒙皮网格。只有这个新的BlendMesh才能在Render()时支持顶点混合，完成蒙皮的显示。在D3DXMESHCONTAINER_DERIVED结构中，用pOrigMesh保存旧的Mesh普通网格信息。而Meshdata.Mesh则指向新产生的BlendMesh

在这个函数中，多次用到了AddRef()，对COM不熟悉的新手容易困惑。D3D是COM组件，它在服务进程中运行，而不在当前的客户进程中。在DX组件运行过程中，要创建一系列接口对象，如CreateDevice()返回接口指针，这些接口及其占用内存什么时候释放，要通过“引用计数”的技术来解决。AddRef()给这个接口指针的计数加1，而Release()会将之减1。一旦减到0，表示没有客户使用了，相关的接口就释放了。 由此可知，每次调用Rlease()后，并不一定会释放内存，而是当引用计数归0时释放内存。
这样，对接口指针的使用，就像维护堆栈的平衡一样，要仔细，而且按照某种约定规则使用。

但平时D3D编程中，怎么不用AddRef()呢？这是由于一个接口指针，如ID3DDevice，或VertexBuf指针，都是D3DXCreate出来的,在Create时候，在内部已经事先AddRef()了，你就不需要再做这工作了。只要你在不用时，调用 p指针->Relase()就释放了。一般编程，特别是小型示例程序，都是初始化时建立一次，关闭时释放，都遵守了这种约定，所以不存在这种问题。

但在CreateMeshContainer()函数中，以多种方式使用了指针，在局部指针变量中来回传递，所以问题复杂化了。在COM编程中约定，任何时候地接口指针赋值(复制)，都要AddRef()，在指针变量结束生命期前，再Release(). 但许多程序员都不是严格这么做。因为在局部变量用完就废了，先AddRef()增加计数再Release()减少，和直接使用最后是等效的。几乎是多此一举。这与编程习惯有关系。一旦引用计数不对，如果没有统一的习惯，不好排查。在CreateMeshContainer()中，对接口指针的使用有三种方式，例举如下：

方式一：不使用AddRef()。和普通指针一样，临时变量是左值，接口指针是右值，直接赋值使用。如:
        pMesh = pMeshData->pMesh;
        这是由于pMesh是局部变量，它只是临时引用一下，没必要为它先AddRef()，后Release()。

方式二：隐式的使用AddRef()。 由于用到了一些内部有AddRef()动作的函数，就要按照COM约定，在子程序结束前Release()
        pMesh->GetDevice(&pd3dDevice);//此处d3d设备引用计数已经加1
        ....
        SAFE_RELEASE(pd3dDevice);//--此处将引用计数减1，并不是真的释放d3d设备
        在本例中，pd3dDevice在GetDevice()中已经Addref()过了，所以，在退出CreateMeshContainer()前，必须pd3dDevice->Release()

方式三：显式的使用AddRef()。 如果一个指针值，不是由D3DXCreate出来的，而是通过赋值方式复制给一个全局变量或长期变量的。 所以，可以通过AddRef()的方式来延迟该对象的释放。因为，如果不AddRef()，极有可能在函数返回该对象就可能释放了。它就像一个加油站，使得传入对象的寿命延长至自己控制范围内。用了AddRef()，就要在相关的Destroy中添加Release()。

在本函数，有三处这样的语句：
        pMeshContainer->MeshData.pMesh = pMesh;
        pMeshContainer->MeshData.Type = D3DXMESHTYPE_MESH;
        pMesh->AddRef();
         ....
        pMeshContainer->pSkinInfo = pSkinInfo;
        pSkinInfo->AddRef();

        pMeshContainer->pOrigMesh = pMesh;
        pMesh->AddRef();
         ....

        将来在DestroyMeshContainer()中，要释放这些指针：
        ....
        SAFE_RELEASE( pMeshContainer->MeshData.pMesh );
        SAFE_RELEASE( pMeshContainer->pSkinInfo );
        SAFE_RELEASE( pMeshContainer->pOrigMesh );

        由于这些指针值的创建、更改等都是用户自己经营的，所以务必要加前后吻合，在CreateMeshContainer()中AddRef()，在DestroyMeshContainer()中Release().

再来看数据的保存部分。
在CreateMeshContainer()的传入参数中，有pMeshData,pMaterials,pEffectInstances,NumMaterials,pAdjacency,pSkinInfo
你需要把这些数据保存到自己的D3DXMESHCONTAINER对象中。并且其中的所有数组所需的空间都要在全局堆中new出来。所以在该代码中，有如下new:
pMeshContainer = new D3DXMESHCONTAINER_DERIVED;//自定义的扩展数据容器对象
memset(pMeshContainer, 0, sizeof(D3DXMESHCONTAINER_DERIVED));//初始化pMeshContainer,清0
    ...
pMeshContainer->pMaterials = new D3DXMATERIAL[pMeshContainer->NumMaterials];//准备保存材质
pMeshContainer->ppTextures = new LPDIRECT3DTEXTURE9[pMeshContainer->NumMaterials];//准备创建纹理对象。它声明在扩展部分。
pMeshContainer->pAdjacency = new DWORD[NumFaces*3];//准备保存邻接三角形数组,NumFaces = pMesh->GetNumFaces();

然后，对数据进行memcpy保存。pEffectInstances由于在绘制中不需要，并没进行保存。对于没有贴图的赋以默认材质属性。
值得注意的是，所有这些new，必须在DestroyMeshContainer()时进行delete.

接下来的处理中，如果发现Mesh的FVF中没有法向量，要用CloneMeshFVF()重建Mesh，计算顶点平均法向量。以备光照处理。

最后，我们看看蒙皮信息pSkinInfo的处理。这是重头戏。
如果发现pSkinInfo!=NULL，就准备着手从各个蒙皮骨骼信息创建SkinMesh.
首先，用扩展容器结构D3DXMESHCONTAINER_DERIVED中的各属性保存原Mesh指针值，pMeshContainer->pOrigMesh = pMesh, 因为接下来我们要创建SkinMesh替代原Mesh.然后，把SkinInfo中的各骨骼的偏移矩阵保存到pMeshContainer->pBoneOffsetMatrices中
      cBones = pSkinInfo->GetNumBones();
      pMeshContainer->pBoneOffsetMatrices = new D3DXMATRIX[cBones];
      .....
     每个“骨骼偏移矩阵”pBoneOffsetMatrices,在将来DrawMeshContainer()中是必须要用的。因为原始Mesh中的顶点数据乘以“骨骼偏移矩阵”，再乘以“变换矩阵”，才能求得各骨骼顶点在世界坐标系中的坐标。 即：
    骨骼上各点在世界坐标系中的新坐标=初始网格中的各点坐标*骨骼偏移矩阵*骨骼当前的变换矩阵
    其中，“初始网格中的各点坐标*骨骼偏移矩阵” = 骨骼上各点初始时刻在该骨骼坐标系中的局部坐标

做了以上工作后，调用GenerateSkinnedMesh(pMeshContainer)，创建SkinMesh. 接下来，我们看看GenerateSkinnedMesh()做了哪些工作。

3.4 怎样生成蒙皮网格SkinMesh? GenerateSkinnedMesh()分析

由于要重定义pMeshContainer->MeshData.pMesh，所以先SAFE_RELEASE( pMeshContainer->MeshData.pMesh ); 释放原pMesh

在这个函数中，是根据当前绘图方式设置进行加载数据的。因为顶点混合，有无索引的顶点混合，有含索引的顶点混合，所使用的函数和对应的SkinMesh数据内容也有所不同。
在示例中，自定义了枚举m_SkinningMethod，主要分为D3DNONINDEXED和D3DINDEXED，以有纯软件渲染等。运行示例后，你可以选择菜单中的Options选择不同的渲染方式。

我们着重分析一下带索引的蒙皮网格。在程序中，就是D3DINDEXED相关的部分。
if (m_SkinningMethod == D3DINDEXED){ ....}

注意! 示例默认工作在D3DNONINDEXED下,如果要跟踪D3DINDEXED部分的代码,必须选择菜单中的Options选择indexed!

最主要的，要通过DX的ConvertToIndexedBlendedMesh()函数，生成支持“索引顶点混合”的SkinMesh.有关索引顶点混合的技术，你可以在DXSDK帮助文件中搜索“Indexed Vertex Blending”主题，对着英文和插图将就看，确有收获。

要想用硬件对顶点进行混合，那么参与混合者不能太多。也就是说同时影响一个顶点的骨骼数不能多。我们假定一个顶点最多同时受4个骨骼的影响（也就是同时最多有4个骨骼矩阵参与加权求和），那么同时影响一个三角形面的骨骼数最多就是3*4=12个。
我们用NumMaxFaceInfl表示影响一个三角面的最多骨骼矩阵数，那么，通过调用pSkinInfo->GetMaxFaceInfluences()获取这个数值，一般也就3-4。如果这个数值太大，我们强制使用NumMaxFaceInfl = min(NumMaxFaceInfl, 12);来最多取值12。

用NumMaxFaceInfl 这个数值干什么呢？ 我们用来它分析当前的显卡倒底行不行。

if (m_d3dCaps.MaxVertexBlendMatrixIndex + 1 < NumMaxFaceInfl)//如果显卡达不到该要求
{
      //很奇怪。2005年底买的GeForce 6600GT显卡，竟然m_d3dCaps.MaxVertexBlendMatrixIndex=0, 不支持索引顶点混合！是驱动问题还是怎么了？
      //但它支持非索引混合。或者，也许要用HLSL支持混合。看起来，3D编程要多考虑。
       ..
      pMeshContainer->UseSoftwareVP = true;//用软件渲染顶点。显然不实用。
}
else
{
      pMeshContainer->NumPaletteEntries = min( ( m_d3dCaps.MaxVertexBlendMatrixIndex + 1 ) / 2,
                                                     pMeshContainer->pSkinInfo->GetNumBones() );//--什么意思？
      pMeshContainer->UseSoftwareVP = false;//采用硬件顶点混合。
      Flags |= D3DXMESH_MANAGED;
}

[评论]在上面有一行代码:
     pMeshContainer->NumPaletteEntries = min( ( m_d3dCaps.MaxVertexBlendMatrixIndex + 1 ) / 2,pMeshContainer->pSkinInfo->GetNumBones() );
尽管作者加了大段注释，还是让人一头雾水。其实，我们做一个实验，反尔更能理解它的用途。
第一步，你在这句话后面下一个断点，看一下在你机器上这个数值。我的ATI 9550显卡机器上是19。比tiny.x中的骨骼数35少很多。
第二步，你将上面=右边瞎填一个大于4的数字，比如6。编译后照样运行。而且效果上几乎看不出任何差别。
为什么会这样呢？ 我们在绘制代码部分，看看这个数值起什么作用。
在DrawMeshContainer()代码中，我们查找D3DINDEXED相关的部分。在mesh各子集的DrawSubset()之前，有如下代码：
      for (iAttrib = 0; iAttrib < pMeshContainer->NumAttributeGroups; iAttrib++)
      {
                // first calculate all the world matrices
                for (iPaletteEntry = 0; iPaletteEntry < pMeshContainer->NumPaletteEntries; ++iPaletteEntry)
                {
                    iMatrixIndex = pBoneComb[iAttrib].BoneId[iPaletteEntry];
                    if (iMatrixIndex != UINT_MAX)
                    {
                        D3DXMatrixMultiply( &matTemp, &pMeshContainer->pBoneOffsetMatrices[iMatrixIndex], pMeshContainer->ppBoneMatrixPtrs[iMatrixIndex] );
                        m_pd3dDevice->SetTransform( D3DTS_WORLDMATRIX( iPaletteEntry ), &matTemp );
                    }
                }
       ...
      }
下面仔细评估一下这些代码.
先注意看其中奇怪的D3DTS_WORLDMATRIX()宏，我们以前还没这样用过。它是做什么用的呢？通过查DXSDK帮助，我们在Geometry Blending主题中找到相关说明，并在"Indexed Vertex Blending"主题中给出了内部实现原理。原来，当你用m_pd3dDevice->SetRenderState(D3DRS_INDEXEDVERTEXBLENDENABLE, TRUE);开启了索引顶点混合后，在硬件上就启用了“palette of matrices”，即矩阵寄存器组，它最多支持同时256个索引。就像过去用256色调色板来表现彩色一样。D3DTS_WORLDMATRIX()宏就是有256-511这256个数表示矩阵索引号。

这些矩阵参与如下计算：

V最终顶点位置=V*M[索引值1]*权重1 + V*M[索引值2]*权重2 + ....+V*M[索引n]*(1-其它权重和)

这个公式的来源，相信大家在众多资料上见过，不赘述。 当然，我们也可以用程序完成这个蒙皮计算过程，但逐个读顶点却很麻烦。现在是由硬件代劳了。我们只设矩阵就行了。
我们用m_pd3dDevice->SetTransform( D3DTS_WORLDMATRIX( iPaletteEntry ), &matTemp );这种方式设定各索引对应的矩阵。

那么权重呢？我们怎么设？原来在上面所说的DX提供的ConvertToIndexedBlendedMesh()函数中，生成SkinMesh时，各网格顶点格式FVF已经有变化了，增加了新格式，D3DFVF_XYZB2，D3DFVF_LASTBETA_UBYTE4，用以记录顶点对应的权重值以及矩阵索引。如下
struct VERTEX
{
    float x,y,z;
    float weight;
    DWORD matrixIndices;
    float normal[3];
};
#define D3DFVF_CUSTOMVERTEX (D3DFVF_XYZB2 | D3DFVF_LASTBETA_UBYTE4 |D3DFVF_NORMAL);

D3DFVF_LASTBETA_UBYTE4对应于DWORD数值，用于矩阵索引时，每个字节表示一个索引，最多可以允许4个索引，同时有4个矩阵参于该点的混合。如果一次绘制中涉及了9块骨骼矩阵，你可以把这9个矩阵全部用SetTransform设置到矩阵寄存器中，但每个顶点在渲染时，最多使用其中的4个。由此可知，pMeshContainer->NumPaletteEntries这个数值，确定了一趟DrawSubset绘制所用到的矩阵个数，个数越多，在一趟绘制中就可以纳入的更多顶点。所以，当我们减少pMeshContainer->NumPaletteEntries这个数值时，pMeshContainer->NumAttributeGroups数值就会增加。也就是说，一趟绘制中所允许涉及的骨骼数越少，那么子集的数量NumAttributeGroups就会增加，需要多绘几趟。
你可以在此下断点观察，当NumPaletteEntries=19时，NumAttributeGroups=3 当NumPaletteEntries=6时，NumAttributeGroups=12 当NumPaletteEntries=4时，NumAttributeGroups=31，几乎和无索引时的分组一样多了。

顶点中的权重weight存放了它当前骨骼的权重。（一个顶点对应的多个骨骼权重怎么存放？是不是在当前子集中有多个同样的顶点，权重不同，对应的矩阵索引不同，然后混合）

由上所述，ConvertToIndexedBlendedMesh()是一个很重要函数，由DX自动将Mesh顶点分组成多个子集，以便DrawSubset. 你必须把它的返回参数都记录下来，在绘制时使用。

四. 怎样绘制显示动画？

DrawFrame()用来绘制整个X框架。它遍历各个框架，找到Mesh不为空的进行绘制。（其实整个.x中通常只有一个不为空，见上文所述）
DrawMeshContainer()是绘制函数。

4.1 怎样开启顶点混合？
注意应用有关的Vertex Blending技术。如在索引方式的绘制中，
m_pd3dDevice->SetRenderState(D3DRS_VERTEXBLEND, pMeshContainer->NumInfl - 1);
其实是设定了D3DVBF_2WEIGHTS或D3DVBF_3WEIGHTS
注意要m_pd3dDevice->SetRenderState(D3DRS_INDEXEDVERTEXBLENDENABLE, TRUE);

4.2 矩阵的刷新：
首先，在FrameMove()调用m_pAnimController->SetTime()设置当前时间(或在DX9.0c中用AdvanceTime()设置时间差)，从而刷新各个pFrame->TransformationMatrix，即骨骼转换矩阵
其次，调用UpdateFrameMatrices()做乘法累积，计算出各骨骼坐标系到根世界转换矩阵。
最后，在绘制前，将该转换矩阵左乘偏移矩阵，得到最终的转换矩阵。
      D3DXMatrixMultiply( &matTemp, &pMeshContainer->pBoneOffsetMatrices[iMatrixIndex], pMeshContainer->ppBoneMatrixPtrs[iMatrixIndex] );

由此可见，你如果注释掉了m_pAnimController->SetTime，画面肯定停了。

4.3 绘制输出 是在DrawMeshContainer()中，调用SkinMesh的DrawSubset进行绘制。一些细节内容如D3DTS_WORLDMATRIX(),在上面已经有说明，不再罗嗦。

4.4 关于示例中多种绘制方式分析
在示例中，用到了多种渲染方式，包括传统的非索引顶点混合，还有新兴的HLSL方式。而且我发现，ATI RADEON 9550 显卡MaxVertexBlendMatrixIndex=37，而价格更高的Gefoce 6600GT MaxVertexBlendMatrixIndex竟然为0，不支持index vertex blending！
所以，还是有必要分析一下该示例中各种vertex blending方式的处理，以便掌握多种绘制方式适应不同显卡。
经测试，示例中所涉及的多种方式，由慢到快，依次是以下几种：
    SOFTWARE,
    D3DNONINDEXED,
    D3DINDEXED,
    D3DINDEXEDVS,
    D3DINDEXEDHLSLVS,

从最慢的SW到最快的HLSL，大约相差20%，有时会大到40%。 差别不是特别悬殊的原因，主要是顶点混合并不是瓶颈。

关于顶点处理方式，是在创建D3D设备时指定的。共有三种方式：
   D3DCREATE_SOFTWARE_VERTEXPROCESSING 软件顶点运算  (简记 sw vp)
   D3DCREATE_HARDWARE_VERTEXPROCESSING 硬件顶点运算。必须有这项才支持有HAL (简记 hw vp)
   D3DCREATE_MIXED_VERTEXPROCESSING 混合顶点运算，即硬件+软件 (简记 mixed vp)

一旦用D3DCREATE_HARDWARE_VERTEXPROCESSING方式创建设备，就只能在硬件方式下进行顶点处理。如果调用m_pd3dDevice->SetSoftwareVertexProcessing(TRUE)来切换到软件顶点处理，HRESULT会返回失败。
  所以，如果你对客户的显卡没有足够的信息，就用D3DCREATE_MIXED_VERTEXPROCESSING方式创建设备。它默认工作方式是HAL。一旦发现进行某种绘制时硬件能力不够，就可以调用调用m_pd3dDevice->SetSoftwareVertexProcessing(TRUE)切换到软件模式。在示例中就是这么做的，启动示例后，运行在mixed模式下。

在Gefoce6600GT显卡中，由于D3DINDEXED方式不支持，采用了软件混合方式，在这种方式下速度甚至比SOFTWARE慢。HLSL还好，还是最快。

要确定设备的硬件顶点处理能力，可以参考D3DCAPS9结构的VertexProcessingCaps成员。可以获取下列属性
MaxActiveLights，MaxUserClipPlanes，MaxVertexBlendMatrices，MaxStreams，MaxVertexIndex

(1)D3DNONINDEXED方式：

首先看GenerateSkinnedMesh()中怎样创建蒙皮网格的。
这种方式下，用ConvertToBlendedMesh()建立蒙皮网格，而不是ConvertToIndexBlendedMesh()

为了绘制蒙皮，在这个函数中对Mesh各子集的顶点再次进行的分组。分组的标准是各顶点（或三角面）所涉及的骨骼矩阵个数不超过pMeshContainer->NumInfl个。(这个数字是由在ConvertToBlendedMesh()时，由参数pMaxFaceInfl返回的)。一个Mesh子集可能被拆开成多个分组。 最后，分组的属性保存在pBoneCombinationBuf中，如子集ID,该子集的各骨骼ID，起始三角面，三角面个数等供绘制时使用，分组的个数保存在pMeshContainer->NumAttributeGroups中。

接下来检查每个分组所涉及的骨骼数，是不是超过硬件允许的最大混合矩阵数---MaxVertexBlendMatrices。如果超过了就把所有分组截为两大部分，前一部分用硬件混合，后一部分采用软件混合。而且，一旦发现有需要软件混合，要采用CloneMeshFVF(D3DXMESH_SOFTWAREPROCESSING|...)的方式重新生成网格。

再来看绘制部分DrawMeshContainer()

用pBoneComb指向骨骼分组属性，扫描各分组。找出其中骨骼数满足硬件性能的用进行绘制。
然后开启软件顶点渲染m_pd3dDevice->SetSoftwareVertexProcessing(TRUE)，对那些骨骼数超出硬件性能的进行绘制。
SetSoftwareVertexProcessing()需要当前d3d设备以D3DCREATE_MIXED_VERTEXPROCESSING方式创建。

(2)D3DINDEXED，这种方式上面分析过了，从略。用pMeshContainer->UseSoftwareVP表示是否采用软件绘制。
值得注意的是在这种方式下，一旦硬件性能不足，会彻底使用软件顶点渲染，而不是像上面一样拆为两部分。

(3)D3DINDEXEDVS，D3DINDEXEDHLSLVS
这种情况下使用了着色器和高级着色语言。超出本文主旨，讨论从略。

(4)SOFTWARE--软件方式？ 让人有些迷惑，与上面的m_pd3dDevice->SetSoftwareVertexProcessing(TRUE)有何区别？

从代码看，这种方式下反而比较简单。GenerateSkinnedMesh()中，
先直接从原始Mesh克隆一个Mesh,然后读取它的材质属性数组。开辟一个空间m_pBoneMatrices，用以存放各块骨骼的转换矩阵。

在绘制时，从pMeshContainer中的变换矩阵乘以偏移矩阵，放在pBoneMatrices中。把这个矩阵数组，以原Mesh的顶点作为源顶点，以新克隆的MeshData.pMesh做为目标顶点，调用pSkinInfo->UpdateSkinnedMesh()，用软件方式计算各骨骼顶点的新位置(相当于软件计算方式蒙皮)。

然后调用MeshData.pMesh->DrawSubset()绘制。

可见，在SOFTWARE方式下，最终顶点的渲染还是HAL方式的，只不过蒙皮计算是由软件完成的。它和上面的m_pd3dDevice->SetSoftwareVertexProcessing(TRUE)直接设置软件顶点渲染还是有区别的。

D3DXPLANE   planeNew;
D3DXPLANE   plane(0,1,1,0);
D3DXPlaneNormalize(&plane, &plane);

D3DXMATRIX  matrix;
D3DXMatrixScaling(&matrix, 1.0f,2.0f,3.0f); 
D3DXMatrixInverse(&matrix, NULL, &matrix);
D3DXMatrixTranspose(&matrix, &matrix);
D3DXPlaneTransform(&planeNew, &plane, &matrix);

D3DXPLANE * D3DXPlaneFromPoints(
  D3DXPLANE * pOut,
  CONST D3DXVECTOR3 * pV1,
  CONST D3DXVECTOR3 * pV2,
  CONST D3DXVECTOR3 * pV3
);

上面的PV1 PV2 PV3则是平面上的三个点。这个函数可以很容易地求得一个三角形所在的平面。

D3DXPLANE * D3DXPlaneFromPointNormal(
  D3DXPLANE * pOut,
  CONST D3DXVECTOR3 * pPoint,
  CONST D3DXVECTOR3 * pNormal
);

pPoint为平面上的一个点。 pNormal是平面的法线方向。
比如，你想创建一个水平平面，并且朝上。 则可以将pPoint传入0，0，0  而pNormal传入0,1,0即可。

--------------------------------------------------------------------------------

d:\microsoft directx 9.0 sdk (october 2004)\include\d3d9types.h(1385) : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss

--------------------------------------------------------------------------------
要修正这个问题，不必要存为UTF8的文件，而是搜索_D3DDEVINFO_VCACHE，然后会看到：

typedef struct _D3DDEVINFO_VCACHE ...{
    DWORD   Pattern;                    /**//* bit pattern, return value must be FOUR_CC(慍? 慉? 慍? 慔? */
    DWORD   OptMethod;                  /**//* optimization method 0 means longest strips, 1 means vertex cache based */
    DWORD   CacheSize;                  /**//* cache size to optimize for  (only required if type is 1) */
    DWORD   MagicNumber;                /**//* used to determine when to restart strips (only required if type is 1)*/
} D3DDEVINFO_VCACHE, *LPD3DDEVINFO_VCACHE;
那四个乱码的去掉就可以了

参考了http://gamep.mmoh.jp/e39255.html

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/SONIC3D/archive/2007/11/01/1861794.aspx

其实只要你能完美理解D3DLOCK、D3DUSAGE、D3DPOOL、LOST DEVICE、QUERY、Present（）、BeginScene（）、EndScene（）等概念，就算是理解D3D9了， 不知道大家有没有同感。有如下几个问题，如果你能圆满回答就算过关：）。
1、       D3DPOOL_DEFAULT、D3DPOOL_MANAGED、D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH到底有何本质区别？
2、       D3DUSAGE的具体怎么使用？
3、       什么是Adapter？什么是D3D Device？HAL Device和Ref Device有何区别？Device的类型又和Vertex Processing类型有什么关系？
4、       APP（CPU）、RUNTIME、DRIVER、GPU是如何协同工作的？D3D API是同步函数还是异步函数？
5、       Lost Device到底发生了什么？为什么在设备丢失后D3DPOOL_DEFAULT类型资源需要重新创建？

在D3D中有三大对象，他们是D3D OBJECT、D3D ADAPTER和D3D DEVICE。D3D OBJECT很简单，就是一个使用D3D功能的COM对象，其提供了创建DEVICE和枚举ADAPTER的功能。ADAPTER是对计算机图形硬件和软件性能的一个抽象，其包含了DEVICE。DEVICE则是D3D的核心，它包装了整个图形流水管线，包括变换、光照和光栅化（着色），根据D3D版本不同，流水线也有区别，比如最新的D3D10就包含了新的GS几何处理。图形管线的所有功能由DRIVER提供，而DIRVER分两类，一种是GPU硬件DRIVER，另一种是软件DRIVER，这就是为什么在D3D中主要有两类DEVICE， REF和HAL，使用REF DEVICE时，图形管线的光栅化功能由软件DRIVER在CPU上模拟的，REF DEVICE从名字就可以看出这个给硬件厂商做功能参考用的，所以按常理它应该是全软件实现，具备全部DX标准功能。而使用HAL DEVICE时，RUNTIME则将使用HAL硬件层控制GPU来完成变换、光照和光栅化，而且只有HAL DEVICE中同时实现了硬件顶点处理和软件顶点处理（REF DEVICE一般不能使用硬件顶点处理，除非自己在驱动上做手脚，比如PERFHUD）。另外还有个一个不常用的SOFTWARE DEVICE，用户可以使用DDI编写自己的软件图形驱动，然后注册进系统，之后便可在程序中使用。

检查系统软件硬件性能。
在程序的开始我们就要判断目标机的性能，其主要流程是：
确定要用的缓冲格式
GetAdapterCount()
GetAdapterDisplayMode

GetAdapterIdentifier //得到适配器描述
CheckDeviceType //判断指定适配器上的设备是否支持硬件加速
GetDeviceCaps //指定设备的性能，主要判断是否支持硬件顶点处理(T&L)
GetAdapterModeCount //得到适配器上指定缓冲格式所有可用的显示模式
EnumAdapterModes //枚举所有显示模式
CheckDeviceFormat
CheckDeviceMultiSampleType
详细使用请参考DX文档。

WINDOWS图形系统的主要分为四层：图形应用程序、D3D RUNTIME、SOFTWARE DRIVER和GPU。此四层是按功能来分的，实际上他们之间界限并不如此明确，比如RUNTIME中其实也包含有USER MODE的SOFTWARE DRIVER，详细结构这里不再多说。而在RUNTIME里有一个很重要的结构，叫做command buffer，当应用程序调用一个D3D API时，RUNTIME将调用转换成设备无关的命令，然后将命令缓冲到这个COMMAND BUFFER中，这个BUFFER的大小是根据任务负载动态改变的，当这个BUFFER满员之后，RUNTIME会让所有命令FLUSH到KERNEL模式下的驱动中，而驱动中也是有一个BUFFER的，用来存储已被转换成的硬件相关的命令，D3D一般只允许其缓冲最多3个帧的图形指令，而且RUNTIME和DRIVER都会被BUFFER中的命令做适当优化，比如我们在程序中连续设置同一个RENDER STATE，我们就会在调试信息中看到如下信息“Ignoring redundant SetRenderState - X”，这便是RUNTIME自动丢弃无用的状态设置命令。在D3D9中可以使用QUERY机制来与GPU进行异步工作，所谓QUERY就是查询命令，用来查询RUNTIME、DRIVER或者GPU的状态，D3D9中的QUERY对象有三种状态，SIGNALED、BUILDING和ISSUED，当他们处于空闲状态后会将查询状态置于SIGNALED STATE，查询分开始和结束，查询开始表示对象开始记录应用程序所需数据，当应用程序指定查询结束后，如果被查询的对象处于空闲状态，则被查询对象会将查询对象置于SIGNALED状态。GetData则是用来取得查询结果，如果返回的是D3D_OK则结果可用，如果使用D3DGETDATA_FLUSH标志，表示将COMMAND BUFFER中的所有命令都发送到DRIVER。现在我们知道D3D API绝大部分都是同步函数，应用程序调用后，RUNTIME只是简单的将其加入到COMMAND BUFFER，可能有人会疑惑我们如何测定帧率？又如何分析GPU时间呢？对于第一个问题我们要看当一帧完毕，也就是PRESENT()函数调用是否被阻塞，答案是可能被阻塞也可能不被阻塞，要看RUNTIME允许缓冲中存在的指令数量，如果超过额度，则PRESENT函数会被阻塞下来，如何PRESENT完全不被阻塞，当GPU执行繁重的绘制任务时，CPU工作进度会大大超过GPU，导致游戏逻辑快于图形显示，这显然是不行的。测定GPU工作时间是件很麻烦的事，首先我们要解决同步问题，要测量GPU时间，首先我们必须让CPU与GPU异步工作，在D3D9中可以使用QUERY机制做到这点，让我们看看Accurately Profiling Driect3D API Calls中的例子:
IDirect3DQuery9* pQueryEvent;

//1.创建事件类型的查询事件
m_pD3DDevice->CreateQuery( D3DQUERYTYPE_EVENT, &pQueryEvent);
//2.在COMMAND BUFFER中加入一个查询结束的标记，此查询默认开始于CreateDevice
pQueryEvent->Issue(D3DISSUE_END);
//3.将COMMAND BUFFER中的所有命令清空到DRIVER中去，并循环查询事件对象转换到SIGNALED状态，当GPU完成CB中所有命令后会将查询事件状态进行转换。
while(S_FALSE == pQueryEvent->GetData( NULL, 0, D3DGETDATA_FLUSH) )
     ;
LARGE_INTEGER start, stop;
QueryPerformanceCounter(&start); 
SetTexture();
DrawPrimitive(); 
pQueryEvent->Issue(D3DISSUE_END);
while(S_FALSE == pQueryEvent->GetData( NULL, 0, D3DGETDATA_FLUSH) )
       ;
QueryPerformanceCounter(&stop); 

1.第一个GetData调用使用了D3DGETDATA_FLUSH标志，表示要将COMMAND BUFFER中的绘制命令都清空到DRIVER中去，当GPU处理完所有命令后会将这个查询对象状态置SIGNALED。
2.将设备无关的SETTEXTURE命令加入到RUNTIME的COMMAND BUFFER中。
3.将设备无关的DrawPrimitive命令加入到RUNTIME的COMMAND BUFFER中。
4.将设备无关的ISSUE命令加入到RUNTIME的COMMAND BUFFER中。
5.GetData会将BUFFER中的所有命令清空到DRIVER中去，注意这是GETDATA不会等待GPU完成所有命令的执行才返回。这里会有一个从用户模式到核心模式的切换。
6.等待DRIVER将所有命令都转换为硬件相关指令，并填充到DRIVER BUFFER中后，调用从核心模式返回到用户模式。
7.GetData循环查询 查询对象 状态。当GPU完成所有DRIVER BUFFER中的指令后会改变查询对象的状态。

如下情况可能清空RUNTIME COMMAND BUFFER，并引起一个模式切换：
1.Lock method（某些条件下和某些LOCK标志）

2.创建设备、顶点缓冲、索引缓冲和纹理
3.完全释放设备、顶点缓冲、索引缓冲和纹理资源
4.调用ValidateDevice
5.调用Present
6.COMMAND BUFFER已满
7.用D3DGETDATA_FLUSH调用GetData函数

对于D3DQUERYTYPE_EVENT的解释我不能完全理解（Query for any and all asynchronous events that have been issued from API calls）明白的朋友一定告诉我，只知道当GPU处理完D3DQUERYTYPE_EVENT类型查询在CB中加入的D3DISSUE_END标记后，会将查询对象状态置SIGNALED状态，所以CPU等待查询一定是异步的。为了效率所以尽量少在PRESENT之前使用BEGINSCENE ENDSCENE对，为什么会影响效率？原因只能猜测，可能EndScene会引发Command buffer flush这样会有一个执行的模式切换，也可能会引发D3D RUNTIME对MANAGED资源的一些操作。而且ENDSCENE不是一个同步方法，它不会等待DRIVER把所有命令执行完才返回。 

D3D RUTIME的内存类型，分为3种，VIDEO MEMORY（VM）、AGP MEMORY（AM）和SYSTEM MEMORY（SM），所有D3D资源都创建在这3种内存之中，在创建资源时，我们可以指定如下存储标志，D3DPOOL_DEFAULT、D3DPOOL_MANAGED、D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH。VM就是位于显卡上的显存，CPU只能通过AGP或PCI-E总线访问到，读写速度都是非常慢的，CPU连续写VM稍微快于读，因为CPU写VM时会在CACHE中分配32或64个字节（取决于CACHE LINE长度）的写缓冲，当缓冲满后会一次性写入VM；SM就是系统内存，CPU读写都非常快，因为SM是被CACHE到2级缓冲的，但GPU却不能直接访问到系统缓冲，所以创建在SM中的资源，GPU是不能直接使用的；AM是最麻烦的一个类型，AM实际也存在于系统内存中，但这部分MEM不会被CPU CACHE，意味着CPU读写AM都会写来个CACHE MISSING然后才通过内存总线访问AM，所以CPU读写AM相比SM会比较慢，但连续的写会稍微快于读，原因就是CPU写AM使用了“write combining”，而且GPU可以直接通过AGP或PCI-E总线访问AM。 

如果我们使用D3DPOOL_DEFAULT来创建资源，则表示让D3D RUNTIME根据我们指定的资源使用方法来自动使用存储类型，一般是VM或AM，系统不会在其他地方进行额外备份，当设备丢失后，这些资源内容也会被丢失掉。但系统并不会在创建的时候使用D3DPOOL_SYSTEMMEM或D3DPOOL_MANAGED来替换它，注意他们是完全不同的POOL类型，创建到D3DPOOL_DEFAULT中的纹理是不能被CPU LOCK的，除非是动态纹理。但创建在D3DPOOL_DEFAULT中的VB IB RENDERTARGET BACK BUFFERS可以被LOCK。当你用D3DPOOL_DEFAULT创建资源时，如果显存已经使用完毕，则托管资源会被换出显存来释放足够的空间。 D3DPOOL_SYSTEMMEM和D3DPOOL_SCRATCH都是位于SM中的，其差别是使用D3DPOOL_SYSTEMMEM时，资源格式受限于Device性能，因为资源很可能会被更新到AM或VM中去供图形系统使用，但SCRATCH只受RUNTIME限制，所以这种资源无法被图形系统使用。 D3DRUNTIME会优化D3DUSAGE_DYNAMIC 资源，一般将其放置于AM中，但不敢完全保证。另外为什么静态纹理不能被LOCK，动态纹理却可以，都关系到D3D RUNTIME的设计，在后面D3DLOCK说明中会叙述。

D3DPOOL_MANAGED表示让D3D RUNTIME来管理资源，被创建的资源会有2份拷贝，一份在SM中，一份在VM/AM中，创建的时候被放置L在SM，在GPU需要使用资源时D3D RUNTIME自动将数据拷贝到VM中去，当资源被GPU修改后，RUNTIME在必要时自动将其更新到SM中来，而在SM中修改后也会被UPDATE到VM去中。所以被CPU或者GPU频发修改的数据，一定不要使用托管类型，这样会产生非常昂贵的同步负担。当LOST DEVICE发生后，RESET时RUNTIME会自动利用SM中的COPY来恢复VM中的数据，因为备份在SM中的数据并不是全部都会提交到VM中，所以实际备份数据可以远多于VM容量，随着资源的不断增多，备份数据很可能被交换到硬盘上，这是RESET的过程可能变得异常缓慢，RUNTIME给每个MANAGED资源都保留了一个时间戳，当RUNTIME需要把备份数据拷贝到VM中时，RUNTIME会在VM中分配显存空间，如果分配失败，表示VM已经没有可用空间，这样RUNTIME会使用LRU算法根据时间戳释放相关资源，SetPriority通过时间戳来设置资源的优先级，最近常用的资源将拥有高的优先级，这样RUNTIME通过优先级就能合理的释放资源，发生释放后马上又要使用这种情况的几率会比较小，应用程序还可以调用EvictManagedResources强制清空VM中的所有MANAGED资源，这样如果下一帧有用到MANAGED资源，RUNTIME需要重新载入，这样对性能有很大影响，平时一般不要使用，但在关卡转换的时候，这个函数是非常有用的，可以消除VM中的内存碎片。LRU算法在某些情况下有性能缺陷，比如绘制一帧所需资源量无法被VM装下的时候（MANAGED），使用LRU算法会带来严重的性能波动，如下例子：

BeginScene();
Draw(Box0);
Draw(Box1);
Draw(Box2);
Draw(Box3);
Draw(Circle0);
Draw(Circle1);
EndScene();
Present();

假设VM只能装下其中5个几何体的数据，那么根据LRU算法，在绘制Box3之前必须清空部分数据，那清空的必然是Circle0……，很显然清空Box2是最合理的，所以这是RUNTIME使用MRU算法处理后续Draw Call能很好的解决性能波动问题，但资源是否被使用是按FRAME为单位来检测的，并不是每个DRAW CALL都被记录，每个FRAME的标志就是BEGINSCENE/ENDSCENE对，所以在这种情况下合理使用BEGINSCENE/ENDSCENE对可以很好的提高VM不够情况下的性能。根据DX文档的提示我们还可以使用QUERY机制来获得更多关于RUNTIME MANAGED RESOURCE信息，但好像只在RUNTIME DEBUG模式下有用，理解RUNTIME如何MANAGE RESOURCE很重要，但编写程序的时候不要将这些细节暴露出来，因为这些东西都是经常会变的。最后还要提醒的是，不光RUNTEIME会MANAGE RESOURCE，DRIVER也很可能也实现了这些功能，我们可以通过D3DCAPS2_CANMANAGERESOURCE标志取得DRIVER是否实现资源管理功能的信息，而且也可以在CreateDevice的时候指定D3DCREATE_DISABLE_DRIVER_MANAGEMENT来关闭DRIVER资源管理功能。  

D3DLOCK探索D3D RUNTIME工作

如果LOCK DEFAULT资源会发生什么情况呢？DEFAULT资源可能在VM或AM中，如果在VM中，必须在系统内容中开辟一个临时缓冲返回给数据，当应用程序将数据填充到临时缓冲后，UNLOCK的时候，RUNTIME会将临时缓冲的数据传回到VM中去，如果资源D3DUSAGE属性不是WRITEONLY的，则系统还需要先从VM里拷贝一份原始数据到临时缓冲区，这就是为什么不指定WRITEONLY会降低程序性能的原因。CPU写AM也有需要注意的地方，因为CPU写AM一般是WRITE COMBINING，也就是说将写缓冲到一个CACHE LINE上，当CACHE LINE满了之后才FLUSH到AM中去，第一个要注意的就是写数据必须是WEAK ORDER的（图形数据一般都满足这个要求），据说D3DRUNTIME和NV DIRVER有点小BUG，就是在CPU没有FLUSH到AM时，GPU就开始绘制相关资源产生的错误，这时请使用SFENCE等指令FLUSH CACHE LINE。第二请尽量一次写满一个CACHE LINE，否则会有额外延迟，因为CPU每次必须FLUSH整个CACHE LINE到目标，但如果我们只写了LINE中部分字节，CPU必须先从AM中读取整个LINE长数据COMBINE后重新FLUSH。第三尽可能顺序写，随机写会让WRITE COMBINING反而变成累赘，如果是随机写资源，不要使用D3DUSAGE_DYNAMIC创建，请使用D3DPOOL_MANAGED，这样写会完全在SM中完成。

普通纹理（D3DPOOL_DEFAULT）是不能被锁定的，因为其位于VM中，只能通过UPDATESURFACE和UPDATETEXTURE来访问，为什么D3D不让我们锁定静态纹理，却让我们锁定静态VB IB呢？我猜测可能有2个方面的原因，第一就是纹理矩阵一般十分庞大，且纹理在GPU内部已二维方式存储；第二是纹理在GPU内部是以NATIVE FORMAT方式存储的，并不是明文RGBA格式。动态纹理因为表明这个纹理需要经常修改，所以D3D会特别存储对待，高频率修改的动态纹理不适合用动态属性创建，在此分两种情况说明，一种是GPU写入的RENDERTARGET，一种是CPU写入的TEXTURE VIDEO，我们知道动态资源一般是放置在AM中的，GPU访问AM需要经过AGP/PCI-E总线，速度较VM慢许多，而CPU访问AM又较SM慢很多，如果资源为动态属性，意味着GPU和CPU访问资源会持续的延迟，所以此类资源最好以D3DPOOL_DEFAULT和D3DPOOL_SYSTEMMEM各创建一份，自己手动进行双向更新更好。千万别 RENDERTARGET以D3DPOOL_MANAGED 属性创建，这样效率极低，原因自己分析。而对于改动不太频繁的资源则推荐使用DEFAULT创建，自己手动更新，因为一次更新的效率损失远比GPU持续访问AM带来的损失要小。 

不合理的LOCK会严重影响程序性能，因为一般LOCK需要等待COMMAND BUFFER前面的绘制指令全部执行完毕才能返回，否则很可能修改正在使用的资源，从LOCK返回到修改完毕UNLOCK这段时间GPU全部处于空闲状态，没有合理使用GPU和CPU的并行性，DX8.0引进了一个新的LOCK标志D3DLOCK_DISCARD，表示不会读取资源，只会全写资源，这样驱动和RUNTIME配合来了个瞒天过海，立即返回给应用程序另外块VM地址指针，而原指针在本次UNLOCK之后被丢弃不再使用，这样CPU LOCK无需等待GPU使用资源完毕，能继续操作图形资源（顶点缓冲和索引缓冲），这技术叫VB IB换名（renaming）。 

很多困惑来源于底层资料的不足，相信要是MS开放D3D源码，开放驱动接口规范，NV / ATI显示开放驱动和硬件架构信息，这些东西就很容易弄明白了。

顺便做个书的广告 《人工智能：一种现代方法》中文版 卓越网已经有货，AI巨作，不过阅读需要相当的基础，对思维非常有启迪，想买的朋友不要错过。后面我会将学习重点从图形转到AI上来，对AI有兴趣的朋友一起交流。

API Changes

// New sampler state (DWORD) 新的采样器状态
// If this is nonzero, the texture is linearized on lookup.

如果它非0，纹理在查询是线性化。
D3DSAMP_SRGBTEXTURE       // Default FALSE   默认为假
// New render state (DWORD)

新的渲染状态
D3DRS_SRGBWRITEENABLE     // Default FALSE 默认为假
// New usage flags

新的使用标志
D3DUSAGE_QUERY_SRGBWRITE
D3DUSAGE_QUERY_SRGBREAD

窗口下的交换链

为了进行正确的融合操作，应用程序保存他们的交换链在线性空间中的后台缓冲区是非常必要的。因为桌面通常情况下是不在线性空间的。所以需要在后台缓冲区内容显示前进行Gamma校正。

应用程序可以通过新增额外的缓冲区来自我校正，并把他自已正确的结果从线性空间复制到后台缓冲区。当驱动将Gamma校正作为部分显示的时候，是可以避免使用额外的缓冲区的。

D3DPOOL

Defines the memory class that holds the buffers for a resource.
这句不用翻译

typedef enum D3DPOOL
{
D3DPOOL_DEFAULT = 0,
D3DPOOL_MANAGED = 1,
D3DPOOL_SYSTEMMEM = 2,
D3DPOOL_SCRATCH = 3,
D3DPOOL_FORCE_DWORD = 0x7fffffff,
} D3DPOOL, *LPD3DPOOL;

Constants 常量

D3DPOOL_DEFAULT

Resources are placed in the memory pool most appropriate for the set of usages requested for the given resource. This is usually video memory, including both local video memory and AGP memory. The D3DPOOL_DEFAULT pool is separate from D3DPOOL_MANAGED and D3DPOOL_SYTEMMEM, and it specifies that the resource is placed in the preferred memory for device access. Note that D3DPOOL_DEFAULT never indicates that either D3DPOOL_MANAGED or D3DPOOL_SYSTEMMEM should be chosen as the memory pool type for this resource. Textures placed in the D3DPOOL_DEFAULT pool cannot be locked unless they are dynamic textures or they are private, FOURCC, driver formats. To access unlockable textures, you must use functions such as IDirect3DDevice9::UpdateSurface, IDirect3DDevice9::UpdateTexture, IDirect3DDevice9::GetFrontBufferData, and IDirect3DDevice9::GetRenderTargetData. D3DPOOL_MANAGED is probably a better choice than D3DPOOL_DEFAULT for most applications. Note that some textures created in driver-proprietary pixel formats, unknown to the Direct3D runtime, can be locked. Also note that - unlike textures - swap chain back buffers, render targets, vertex buffers, and index buffers can be locked. When a device is lost, resources created using D3DPOOL_DEFAULT must be released before calling IDirect3DDevice9::Reset. For more information, see Lost Devices.

When creating resources with D3DPOOL_DEFAULT, if video card memory is already committed, managed resources will be evicted to free enough memory to satisfy the request.


资源被放入内存池中多半是为了给被请求的资源腾出使用的空间。 通常是显存，包括显卡道内存中的AGP部分。D3DPOOL_DEFAULT 是从MANGED和SYSTEMMEM中分离出来的。它指明了被放入此中的资源是用来被设备访问。注意，D3DPOOL_DEFAULT 没有意味着MANAGED或SYSTEMMEM将会被选择用来存储资源，这是一个独立的部分。放入D3DPOOL_DEFAULT 中的纹理不可以被LOCK除非是动态纹理或是私有纹理。FOURCC，驱动格式，为了访问未锁定的纹理，我们必须用IDirect3DDevice9::UpdateSurface, IDirect3DDevice9::UpdateTexture, IDirect3DDevice9::GetFrontBufferData, and IDirect3DDevice9::GetRenderTargetData.函数。显然，对于许多应用程序来说，MANAGED是更好的选择。
注意，许多纹理是以私有的格式创建的。运行时D3D并不知道。是可以被加锁的。同时应该注意，不像纹理，交换链后台缓冲区，渲染目标，顶点缓冲，索引缓冲是可以被加锁的。当设备丢失的时候，使用D3DPOOL_DEFAULT 创建的资源必须要在调用Reset之前释放。可以参看D3D的LostDevice.
当使用D3DPOOL_DEFAULT 创建资源，并且显卡的内存有限的时候，MANAGED中的资源将会被清除以释放足够的内存来满足需求。

D3DPOOL_MANAGED

Resources are copied automatically to device-accessible memory as needed. Managed resources are backed by system memory and do not need to be recreated when a device is lost. See Managing Resources for more information. Managed resources can be locked. Only the system-memory copy is directly modified. Direct3D copies your changes to driver-accessible memory as needed.

在MANAGED中的当有需要的时候，会被自动复制到设备的可访问内存。MANAGED资源在系统内存中是有备份的，于是当设备丢失的时候，不需要重新创建。参见Managing Resources 。MANAGED资源可以被加锁，只有系统内存中的备份是直接被修改的。当有必要的时候，D3D复制你所修改的内容到系统可访问区

D3DPOOL_SYSTEMMEM

Resources are placed in memory that is not typically accessible by the Direct3D device. This memory allocation consumes system RAM but does not reduce pageable RAM. These resources do not need to be recreated when a device is lost. Resources in this pool can be locked and can be used as the source for a IDirect3DDevice9::UpdateSurface or IDirect3DDevice9::UpdateTexture operation to a memory resource created with D3DPOOL_DEFAULT.

被放置在SYSTMMEM中的资源是典型地不可被3D直接访问的。这种内存分配消耗系统的RAM但是不减少RAM的可用页。在设备丢失的时候，这些资源不需要再次创建。在这个内存池中的资源可以被加锁，可以被用来让IDirect3DDevice9::UpdateSurface or IDirect3DDevice9::UpdateTexture 去操作以D3DPOOL_DEFAULT. 方式创建的资源

D3DPOOL_SCRATCH

Resources are placed in system RAM and do not need to be recreated when a device is lost. These resources are not bound by device size or format restrictions. Because of this, these resources cannot be accessed by the Direct3D device nor set as textures or render targets. However, these resources can always be created, locked, and copied.

这种资源被放在系统的RAM中，设备丢失时候不用重新创建。这种资源不受设备大小和格式的限制。为此，这种资源不能被D3D访问，也不能设置为纹理或渲染目标。但是，这种资源总是可以被创建，加锁和复制。

D3DPOOL_FORCE_DWORD

Forces this enumeration to compile to 32 bits in size. Without this value, some compilers would allow this enumeration to compile to a size other than 32 bits. This value is not used.

强制编译器使用32位来编译这个枚举量。若没有这个值，一些编译器将允许这个枚举以非32位的方式编译。这个值未被使用。

Remarks 评论

All pool types are valid with all resources. This includes: vertex buffers, index buffers, textures, and surfaces.
所有的内存池类型对所有的资源有效。包括：顶点缓冲，索引缓冲，纹理，表面。


剩下的一些内容就是各种类型的资源对各种渲染目标的效性。参见SDK


以下为FancyBit对D3DUSAGE的翻译，由于和D3DPOOL关联较强，故贴在此里，十分感谢FancyBit
他的主页是：http://hi.baidu.com/148332727 希望大家多多交流，共同进步

在DX8中，对多窗口的支持是通过创建更多的Swap Chains来提供的。SDK中没有相关的例子而且文档也只是泛泛而谈。这篇文章就是为了解决这个问题，它将向您展示应当如何一步步地实现在多个分离窗口中渲染多个视图。

Step 1 - Setting Up The Parent Frame

第一步：设置父框架窗口

In an application with multiple views, we start with a top level frame that will contain child windows in its client area to display various views. Once the parent frame parent frame has been created, we create our Direct3D device interface, specifying windowed mode and setting the top level window handle as the focus window:

在多视图的应用程序中，我们需要从最高层次的框架——这个框架将包含所有在他用户区之内的子视图窗口——开始我们的旅程。当父框架创建的时候，我们需要创建Direct3D Device接口，为其指定使用窗口模式，而且设置这最高层次的窗口句柄作为“焦点窗口”的句柄：

g_pD3D=Direct3DCreate8(D3D_SDK_VERSION);

if (!g_pD3D) return -1;

D3DPRESENT_PARAMETERS d3dpp;

ZeroMemory( &d3dpp, sizeof(d3dpp) );

d3dpp.Windowed = TRUE;

d3dpp.SwapEffect = D3DSWAPEFFECT_COPY;

// Use the current display mode. 使用当前的显示模式

D3DDISPLAYMODE mode;

if(FAILED(g_pD3D->GetAdapterDisplayMode(D3DADAPTER_DEFAULT , &mode))) {

    SAFE_RELEASE(g_pD3D);

    return -1;

}

d3dpp.BackBufferFormat = mode.Format;

d3dpp.BackBufferWidth = mode.Width;

d3dpp.BackBufferHeight = mode.Height;

d3dpp.EnableAutoDepthStencil=TRUE;

d3dpp.AutoDepthStencilFormat = D3DFMT_D16;

// m_hWnd is handle to top level window    m_hWnd是最高层窗口的句柄

if( FAILED( g_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, m_hWnd,

                                  D3DCREATE_SOFTWARE_VERTEXPROCESSING,

                                  &d3dpp, &g_pd3dDevice) ) ) {

    SAFE_RELEASE(g_pD3D);

    return -1;

}

Note that for simplicity the above code does not test depth format, instead choosing a fixed format. Your application should determine a compatible depth format for the format of the rendering target.

注意上面代码处于简单考虑并没有去测试深度缓存的格式（？depth format），而只是选择了一个确定的格式（D3DFMT_D16）。您的程序应该为需要渲染的Render Target选择一个可接受的深度缓存格式。

The device has a frame buffer, which the child views will be rendered into, as well as a depth buffer which will be shared among the views. The frame buffer and depth buffer are sized to the full screen resolution, to allow for the fact that the window may later be resized. Otherwise, window size changes would require resetting the device and re-creating the swap chains.

Device都需要有帧缓存，这样子视图才能进行渲染，同时，深度缓冲也应当被不同的视图进行共享。帧缓存和深度缓存都被设置为全屏幕大小，以考虑到可能窗口会被改变大小的情况。如果不的话，窗口改变大小的时候，就需要Reset Device和重新创建Swap Chain。

Step 2 - Setting Up View Windows

第二步：设置子视图窗口

Now we are ready to create our view windows, and associate them with swap chains that can be rendered to the device. Once the windows have been created, the following code generates a swap chain for the child window:

现在我们可以准备创建我们的子窗口也就是视图窗口，并把它们与交换链关联以使得他们可以被渲染到Device上。当窗口创建后，下面的代码将为子窗口创建一个交换链：

D3DPRESENT_PARAMETERS d3dpp;

ZeroMemory( &d3dpp, sizeof(d3dpp) );

d3dpp.Windowed = TRUE;

d3dpp.SwapEffect = D3DSWAPEFFECT_COPY;

// Use the current display mode. 使用当前的显示模式

D3DDISPLAYMODE mode;

g_pD3D->GetAdapterDisplayMode(D3DADAPTER_DEFAULT , &mode);

d3dpp.BackBufferFormat = mode.Format;

// m_hWnd contains child window handle m_hWnd储存子窗口的句柄

d3dpp.hDeviceWindow=m_hWnd;

// m_pSwapChain is IDirect3DSwapChain *   m_pSwapChain是一个IDirect3DSwapChain*对象

g_pd3dDevice->CreateAdditionalSwapChain(&d3dpp, &m_pSwapChain);

After executing this code, the m_pSwapChain variable will contain a pointer to an IDirect3DSwapChain interface, which contains a frame buffer corresponding to the client area of the child window. This process is performed for each view window, so that that there is a swap chain for each view window.

经过这些代码之后，m_pSwapChain变量就储存了IDirect3DSwapChain接口的指针，这个接口将储存子窗口视图区所对应的帧缓冲。

Step 3 - Rendering a View

第三步：渲染视图

Prior to rendering each view, we must direct the device to render to the appropriate frame buffer, using the SetRenderTarget() method. We pass the back buffer from the window's swap chain, while using the depth buffer that was originally created with the device:

在渲染每个视图窗口之前，我们必须使得Device来渲染对应的帧缓冲，这我们就需要用到SetRenderTarget方法。我们向其中传入子窗口SwapChain交换链的后备缓冲BackBuffer，以及使用最开始跟着Device一起创建的深度缓冲。

LPDIRECT3DSURFACE8 pBack=NULL,pStencil=NULL;

m_pSwapChain->GetBackBuffer(0,D3DBACKBUFFER_TYPE_MONO,&pBack);

g_pd3dDevice->GetDepthStencilSurface(&pStencil);

g_pd3dDevice->SetRenderTarget(pBack,pStencil);

pBack->Release();

pStencil->Release();

Note that we release the stencil and backbuffer pointers after we use them, because the GetBackBuffer() and GetDepthStencilSurface() functions call AddRef() on these interfaces to increment their reference counters. Failing to release them would lead to a memory leak.

注意我们必须Release掉Stencil和BackBuffer的指针，因为GetBackBuffer和GetDepthStencilSurface这两个函数都会调用COM的AddRef方法，来增加相应COM接口的引用计数，因此如果不删除它们，将会导致内存泄露。

We are now ready to render the view. Rendering is performed within a scene in the normal manner, except that we call Present() on the swap chain interface rather than the device interface:

我们现在已经做好准备渲染视图窗口了。渲染的方法看起来和我们平常用的方法差不多，只是有一点：我们现在需要调用Swap Chain的接口，而不是Device的接口。

g_pd3dDevice->Clear(0,NULL,D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER,0x00000000,1.0,0);

if (SUCCEEDED(g_pd3dDevice->BeginScene())) {

    // rendering code goes here 渲染代码写在这里

    g_pd3dDevice->EndScene();

}

m_pSwapChain->Present(NULL,NULL,NULL,NULL);

Step 4 - Handling Resize of Child Views

第四步，子窗口的Resize问题

DirectX will automatically deal with changes in the child view by using a stretch blit to present the swap chain if the dimensions have client area is not the same size as the swap chain's frame buffer. However, this may not be desirable, as it will cause aliasing if the client area is increased in size.

如果窗口的视图区大小和SwapChain的大小不一，那么DirectX将通过Stretch Blit来自动处理图像的伸缩变化。尽管这可能并不令人期待，因为这在视图区变大的时候将导致图像的模糊。

http://www.cnblogs.com/flying_bat/

渲染到纹理是D3D中的一项高级技术。一方面，它很简单，另一方面它很强大并能产生很多特殊效果。 比如说发光效果，环境映射，阴影映射，都可以通过它来实现。渲染到纹理只是渲染到表面的一个延伸。我们只需再加些东西就可以了。首先，我们要创造一个纹理，并且做好一些防范措施。第二步我们就可以把适当的场景渲染到我们创建的纹理上了。然后，我们把这个纹理用在最后的渲染上。
　　?main.cpp
　　首先我们得声明所需要的对象。当然我们需要一张用来渲染的纹理。此外，我们还需要两个Surface对象。一个是用来存储后台缓冲区，一个用来当纹理的渲染对象。后面我再详细介绍它们。另外我们还需要两个矩阵，一个是用来当纹理的投影矩阵，另一个是存储原来的矩阵。
　　LPDIRECT3DTEXTURE9 pRenderTexture = NULL;
　　LPDIRECT3DSURFACE9 pRenderSurface = NULL,pBackBuffer = NULL;
　　D3DXMATRIX matProjection,matOldProjection;
　　现在我们来创建纹理。前两个参数是纹理的宽度和高度，第三个参数是纹理的多级渐进纹理序列参数，在这里是设为1，第四个参数非常重要而且必须设为D3DUSAGE_RENDERTARGET，表明我们所创建的纹理是用来渲染的。剩下的参数就是指纹理格式，顶点缓冲区的内存位置，和一个指向纹理的指针。当纹理是用来当渲染对象时，顶点缓冲区的内存位置必须设为D3D_DEFAILT。
　　g_App.GetDevice()->CreateTexture(256,256,1,D3DUSAGE_RENDERTARGET,D3DFMT_R5G6B5,D3DPOOL_DEFAULT,&pRenderTexture,NULL);
　　为了访问纹理内存对象，我们需要一个Surface对象，因为D3D中的纹理是用这样的一个Surface来存储纹理数据的。为了得到纹理表面的Surface,我们需要调用方法GetSurfaceLevel() 。第一个参数我们设为0，第二个参数为一个指向surface对象的指针。
　　pRenderTexture->GetSurfaceLevel(0,&pRenderSurface);
　　下一步就是创建一个适合纹理维数的投影矩阵，因为纹理的横纵比和后台缓冲区的不一样。
　　D3DXMatrixPerspectiveFovLH(&matProjection,D3DX_PI / 4.0f,1,1,100);
　　在我们的循环渲染之前，我们必须保存后台缓冲区和它的投影矩阵。
　　g_App.GetDevice()->GetTransform(D3DTS_PROJECTION,&matOldProjection);
　　g_App.GetDevice()->GetRenderTarget(0,&pBackBuffer);
　　渲染循环函数可以分为两个部分。第一部分是渲染到纹理的过程。因此，渲染对象必须设为纹理表面。然后我们就可以把东西渲染到这个对象上了。渲染到另一个表面上和正常地渲染到后台缓冲区差不多。只有一点不同，那就是先不调用Prensent（）函数，因为纹理上的内容并不需要显示在屏幕上。象平时一样，我们先要重置表面颜色缓冲区，并且调用BeginSence()和EndSence()方法。为了能够适当的渲染，我们必须设置和纹理表面相符的投影矩阵。否则最后的图象可能被扭曲
　　//render-to-texture
　　g_App.GetDevice()->SetRenderTarget(0,pRenderSurface); //set new render target
　　g_App.GetDevice()->Clear(0,NULL,D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER,D3DCOLOR_XRGB(100,100,100),1.0f,0); //clear texture
　　g_App.GetDevice()->BeginScene();
　　g_App.GetDevice()->SetTexture(0,pPyramideTexture);
　　D3DXMatrixRotationY(&matRotationY,fRotation);
　　D3DXMatrixTranslation(&matTranslation,0.0f,0.0f,5.0f);
　　g_App.GetDevice()->SetTransform(D3DTS_WORLD,&(matRotationY * matTranslation));
　　g_App.GetDevice()->SetTransform(D3DTS_PROJECTION,&matProjection); //set projection matrix
　　g_App.GetDevice()->SetStreamSource(0,pTriangleVB,0,sizeof(D3DVERTEX));
　　g_App.GetDevice()->DrawPrimitive(D3DPT_TRIANGLELIST,0,4);
　　g_App.GetDevice()->EndScene();
　　渲染循环的第二部分就是渲染最后场景的过程（也就是显示到屏幕上的过程）。渲染对象重新设为后台缓冲区，投影矩阵重新设为原来的投影矩阵。由于纹理已经准备好了，所以它和纹理层0相关联。
　　//render scene with texture
　　g_App.GetDevice()->SetRenderTarget(0,pBackBuffer); //set back buffer
　　g_App.GetDevice()->Clear(0,NULL,D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER,D3DCOLOR_XRGB(0,0,0),1.0f,0);
　　g_App.GetDevice()->BeginScene();
　　g_App.GetDevice()->SetTexture(0,pRenderTexture); //set rendered texture
　　g_App.GetDevice()->SetTransform(D3DTS_WORLD,&matTranslation);
　　g_App.GetDevice()->SetTransform(D3DTS_PROJECTION,&matOldProjection); //restore projection matrix
　　g_App.GetDevice()->SetStreamSource(0,pQuadVB,0,sizeof(D3DVERTEX));
　　g_App.GetDevice()->DrawPrimitive(D3DPT_TRIANGLESTRIP,0,2);
　　g_App.GetDevice()->EndScene();
　　g_App.GetDevice()->Present(NULL,NULL,NULL,NULL);
　　最后我们通过调用Release()方法释放Surface对象。
　　pRenderSurface->Release();
　　pRenderSurface = NULL;
　　pBackBuffer->Release();
　　pBackBuffer = NULL;
　　渲染到纹理能让你做很多事情，但是你必须注意一些限制。首先深度缓冲区必须总是大于或等于渲染对象的大小。此外，渲染对象和深度缓冲区的格式必须一致。

首先看看雾化的方程

Color = f * Color(scene) + (1-f) * color(fog)

Color(scene):背景色
Color(fog): 雾色
f:雾化参数，随观察点的距离的增大而减小，从而可知最后得到的颜色，当观察点越远时，雾色占的比例越大。

雾有四种方式
D3DFOG_NONE 禁用雾化效果
D3DFOG_EXP  雾化效果随指数增加 f = 1/(e^density)
D3DFOG_EXP2 同上，不过公式变为 f = 1/(e^(density^2))
D3DFOG_LINEAR 线性雾 f = (end-d)/(end-start) d 为当前计算点与观察点距离

现在我们来看如何实现雾化
首先开启雾化效果
Device->SetRenderState(D3DRS_FOGENABLE,true);
然后我们要设置雾化的模式和公式
Device->SetRenderState(DEDRS_FOGTABLEMODE,D3DFOG_LINEAR);
这里我将其设置成了像素雾和线性，同样可以将其换成上面介绍的其它模式和公式
接下来我们就要设置雾化参数了
Device->SetRenderState(D3DRS_FOGCOLOR,oxffffffff);//设置成白色

设置start end
float start= 50,end = 400;
Device->SetRenderState(D3DRS_FOGSTART,*(DWORD*)&start);
Device->SetRenderState(D3DRS_FOGEND,*(DWORD*)&end);
设置浓度
float density = 0.001f;//0.0 -- 1.0
Device->SetRenderState(D3DRS_FOGDENSITY,*(DWORD*)&density);

这样,我们的设置就完了,只要将雾化设置放入我们渲染场景中,就可以看到雾化效果了.
但应该注意以下几点
-----------------------------------------line
   A          B          C
    \          |             /
     \                     /
       \       |         /
        \              /
         \    d     /
          \        /
           \   |  /
            \   /
              P
------------------------------------------
雾化效果是以刚刚上面讲的 d 作为计算标准,所以,我们从P点看到A ,B ,C三点的雾化效果是一样的,而按常理,A ,C的雾应该更浓才对.
很显然,这让我们想到,D3D会有对应的处理办法.
D3D提供了基于发散的雾化效果,雾化随观察点的距离增大而增大,就像点光源,不过,这要求我们的硬件支持,所以在设置前应该检查
D3DCAPS9 caps;
Device->GetDeviceCaps(&caps);

if(caps.RasterCaps&D3DPRASTERCAPS_FOGRANGE)
 Device->SetRenderState(D3DRS_RANGEFOGENABLE,true);

把这个增加到雾化设置中即可~~~

已经12点了,估计人有点晕,也讲不明白些什么东西了,到此为止

D3DMULTISAMPLE_4_SAMPLES

终于成功地把天空盒，公告板，MESH，纹理等一起用在了一个工程中，哈哈，虽然比较白啦，但还是很有成就感。

alpha测试根据当前像素是否满足alpha测试条件（即是否达到一定的透明度）来控制是否绘制该像素，图形程序应用alpha测试可以有效地屏蔽某些像素颜色。与alpha混合相比，alpha测试不将当前像素的颜色与颜色缓冲区中像素的颜色混合，像素要么完全不透明，要么完全透明。由于无需进行颜色缓冲区的读操作和颜色混合，因此alpha测试在速度上要优于alpha混合。

比如一棵树，我们将它的背景ALPHA值设置为小于1。0，那么，我们可以将ALPHAREF 设置为1。0 即0x000000ff 然后ALPHAFUNC 设置为GREATEREQUAL （>=） 所以，只有当ALPHA值大于等于1的部份被渲染，这样树的背景就不用画了！
*/

 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE,   TRUE );//开启ALPHA混合功能
 g_pMyd3dDevice->SetRenderState( D3DRS_SRCBLEND,  D3DBLEND_SRCALPHA);//设置源混合因子为（As,As,As,As)
 g_pMyd3dDevice->SetRenderState( D3DRS_DESTBLEND, D3DBLEND_INVSRCALPHA);//设置目标混合因子为（1-As,1-As,1-As,1-As);

 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHATESTENABLE, TRUE );//开启ALPHA测试功能
 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHAREF,        0x0f );//设置ALPHA测试参考值
 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHAFUNC,D3DCMP_GREATEREQUAL );//设置APLHA测试比较规则


//在此处加载纹理和渲染


在渲染完毕后，不要忘了关闭开启的功能

 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHATESTENABLE, FALSE );
 g_pMyd3dDevice->SetRenderState( D3DRS_ALPHABLENDENABLE, FALSE );

   D3DXMatrixInverse(&matBillboard,NULL,&matBillboard);//求其逆矩阵
   matOutput = matBillboard * matInput;
   //公告板结束
}

函数说明：
返回值：void
Device 是一个IDirect3DDevice9* 类型的参数
&matInput 是一个D3DXMATRIX 类型的参数
&matOutput 是一个D3DXMATRIX 类型的参数

功能，将传入的matInput 矩阵，与摄相机矩阵的Look方向矩阵相乘，得到matOutput

用法
D3DXMATRIX matWorld;
D3DXMatrixIdentity(&matWorld);

D3DXMatrixTranslation(&matWorld,1,1,1); //对matWorld 进行必要的变换 如translation ，rotation 之类的。

Billboard(g_pDevice,matWorld,matWorld);

g_pDevice->SetTransform(D3DTS_WORLD,&matWorld);

接下来就可以进行材料，纹理设置、绘制等工作了！   
虽然是很简单的技术，但却很实用。