博客园_Clayman's Graphics Corner

The Beauty of DirectX 11 (4) -- Append/Consume,Byte Address and Indirect Argument Buffer

2011-10-25T14:42:00Z

The Beauty of DirectX 11 (4) -- Append/Consume,Byte Address and Indirect Argument Buffer

作者：clayman

仅供个人学习使用，请勿转载，勿用于任何商业用途。

Append/Consume Buffers

Append和comsume buffer都是SBV的变体。本质上，他们都是需要UAV绑定的资源，但他们在HLSL中实现了一种类似堆栈的访问行为：使用append()函数把元素push到buffer中，或者用consume()函数拉出元素。对于这两种buffer来说，添加元素的顺序并不重要，但所添加元素的数量很重要。UAV内部会记录添向buffer中添加或者删除的元素数量，因此当不同的GPU线程同时操作这样的buffer时，并不需要同步，大大提高了效率。

我们通过一个简单的例子来介绍这种buffer的用途，一个基于GPU的粒子系统：系统使用2块buffer保存粒子信息，一块保存粒子当前的状态，另一块保存更新过的粒子。运行时，computer shader中的每个一个GPU线程都使用consume()方法读取当前粒子信息，进行更新计算，然后，用append()方法把结果写到另一块buffer中。由于每个粒子的状态都是独立的，所以buffer中粒子的顺序无关紧要，只要保证数量正确即可。

创建A/C类型的buffer约束比较严格，因为buffer需要可同时读写，需要使用D3D11_USAGE_DEFAULT标志，此外绑定标识必须包含3D311_BIND_UNORDERED_ACCESS标识，一般还需要加上D3D11_BIND_SHADER_RESOURCE。创建相应的RV时，数据格式总是DXGI_FORMAT_R32_UNKNOWN，同时无论是append还是comsume buffer都必须用D3D11_BUFFER_UAV_FLAG_APPEND参数。上一部分介绍B/S buffer时曾经说个可以把B/S buffer划分为多个subresource，分别使用不同的RV，但是，对于允许读写操作UAV来说却不行，这样的资源只能作为一个整体。

下面是在HLSL中声明A/C buffer的代码

struc Particle
{

float3 position;

float3 velocity;

float time;

}

AppendStructuredBuffer<Particle> newSimulationState : register(u0);

ConsumeStrucuredBuffer<Particle> currentSimulationState : register (u1);

Byte Address Buffers

BAB为HLSL提供了一种相对低级的方式来访问显存块。与通过索引访问元素的方法不同，BAB使用字节地址访问其中的元素: 字节地址n代表的值为从资源开头偏移n个字节后的4个32位无符号整数的值，注意，n必须为4的倍数，指向的4个32位无符号整数也可以通过转型转义为其他类型的值。这种类型的buffer为HLSL提供了强大的数据管理操作能力，几乎可以用它来实现任意类型的数据结构。

举例来说，一个储存32位颜色值的链表，每个链表节点由一个颜色值和指向下一个元素的标记组成。当添加第一个元素时，颜色值被写到偏移值为0的位置，指向下一个元素的索引为-1。添加第二个元素时，程序首先读取偏移值为0处的2个32位值，然后通过索引，依次找到链表末端，最后完成添加。使用BAB，以前很多只能在CPU上计算的传统算法，都可以能GPU上实现了！当然，由于GPU天生的平行性，实际情况要稍微复杂一些，以后会仔细介绍。

BAB的创建方式与前面介绍的几种资源基本一致，唯一的区别是需要把MiscFlags指定为D3D11_RESOURCE_MISC_BUFFER_ALLOW_RAW_VIEWS。只读的BAB可以通过shader resource view绑定到任意shader阶段；作为UAV使用的可读写BAB则只能绑定到pixel shader和compute shader阶段。两种情况下，RV都必须是DXGI_FORMAT_R32_TYPELESS格式，UAV还必须加上D3D11_BUFFER_UAV_FLAG_RAW标识。

在HLSL中，用以下代码声明BAB资源：

ByteAddressBuffer rawBuffer0;

RWByteAddressBuffer rawBUffer1;

Indirect Argument Buffers

前面介绍的几种buffer主要用于把数据从CPU端传递到GPU端，而IAB的设计理念是允许GPU自己填充数据，并且在后面的计算中使用。IAB主要在以下三个函数中使用：

DrawInstancedIndirect(ID3D11Buffer* pBufferForArgs, UINT AlignedByteOffsetForArgs);

DrawIndexedInstancedIndirect(ID3D11Buffer *pBufferForArgs,UINT AlignedByteOffsetForArgs);

void DispatchIndirect(ID3D11Buffer *pBufferForArgs,UINT AlignedOffsetForArgs);

三个函数都以indirect后缀结尾，与没有indirect后缀的方法相比，虽然参数类型不同，本质却相同，比如DrawInstanced()接受4个参数：vertexCountPerInstance,instanceCount,startVertexLocation和startInstanceLocation。Indirect版本同样需要这4个参数，只不过把他们放到了第一个参数pBufferForArgs中，并且通过第二个参数定位他们在buffer中的位置。因此，必须保证pBufferForArgs在指定偏移位置有4个有效的uint值，并且偏移值必须以4byte对齐的，pBufferForArgs可以在不同位置，包含多组不同的参数值，通过offset选择希望使用的参数。这样的好处在于 buffer数据可由GPU填充，所以CPU完全不需要知道要绘制多少图元！图形管线输出的数据和CPU计算的结果都可以用来更新IAB数据。比如，把compute shader的计算结果保存到AppendStructuredBuffer中，使用ID3D11DeviceContext:CopyStructureCount把AppendStructuredBuffer中的数据复制到IAB中，最后使用DrawInstancedIndirect()把CS计算的数据直接渲染出来，整个过程只需要很少的CPU参与，CPU完全不用知道渲染了多少图形。

创建IAB的方法和前面几种buffer没有太多区别，一般来说，如果希望用GPU填充数据，那么一定要使用default usage，此外，MiscFlags必须是D3D11_RESOURCE_MISC_DRAWINDIRECT_ARGS，最后，byteWidth必须是4byte的n倍。

当由GPU填充IAB数据时，比如通过stream out，render target或者UAV方式，必须和配合相应的resource view一起使用，当由CPU填充数据时，则主要通过UpdateSubresource方法和CopyStructureCount。

至此，我们介绍了DirectX 11中的所有buffer resource，下一部分将讨论texture resource。

------------------------------to be continue----------------------------------------------

再次提醒，已经发了的四篇文章对DX11的介绍都比较抽象，如果觉得看不太懂，那么应该先找一些有demo的DX11的入门教程来看。这系列的文章偏重对DX11 API原理的介绍和梳理，适合作为参考资料，而不是第一本入门教程。未来的内容在介绍完texture resource之后，还主要有以下几个部分：

Rendering Pipeline 介绍流水线的每一个阶段

Tessellation Pipeline

Computation Pipeline 着重介绍DX11中两个最重要的功能

HLSL 5.0

Multithreaded Rendering

本文链接

The Beauty of DirectX 11 (3) --- constant buffer, buffered/structure buffer

2011-10-18T13:24:00Z

The Beauty of DirectX 11 (3) --- constant buffer, buffered/structure buffer

作者：clayman

仅供个人学习使用，请勿转载，勿用于任何商业用途。

Constant Buffer

Constant buffer(cb)是DX10中引入的概念，它取代了DX9时代GPU常量寄存器的概念，允许通过一块大小可变的buffer向shader提供常量数据，而不是之前数量非常受限的n个寄存器，这也是我们遇到的第一种可在shader着色阶段由HLSL访问的资源。管线的每个可编程阶段都能同时访问一个或者几个cb，对于shader代码来说，cb中的数据都是全局常量，作为cb而创建的资源不能绑定到其他*类型*的管线位置，但同一个cb可以同时绑定到管线的多个不同阶段。

虽然cb与DX中shader constant的用法几乎一样，但要特别注意，cb中的数据总是作为一个整体被提交给GPU，这意味着即使cb中只有一个变量改变了，也必须重新提交整个cb。因此，所有关于DX10/11的文章都会强调不要把所有变量都放到一个cb中，而是按照变量改变的频率来组织变量，以尽量减少带宽消耗。比如，把viewMatrix,viewProjMatrix,eyePosition,sunVector等per-frame数据放到cb0中，只要每帧渲染前更新一次即可；把worldMatrix，localLight，objectColor等作为per-object参数放到另外一块cb中，每次渲染物体时更新。游戏总是以每秒30fps以上的速度运行，并且每帧需要渲染大量物体，因此，合理组织cb非常重要！

创建cb的代码和上一次创建vertex buffer的代码类似，大部分参数的用途也一致，选择合适的枚举，以获得最好性能。有三点需要注意的地方，1. cb中的数据结构应该直接对应着HLSL中的数据结构，这样更新cb时，只需要直接复制数据即可；2. cb的大小必须是16byte的n倍(n个float4大小)；3. cb的bind flag只能是D3D11_BIND_CONSTANT_BUFFER，不能与其他位标记组合使用。使用cb时，不需要resource view，可以直接绑定到管线。

因为cb是shader直接可访问的资源，在HLSL中，用以下语法声明cb：

cbuffer Tramsform
{
    matrix worldMatrix;
    matrix worldViewProjMatrix;
    matrix bones[26];
}

cbuffer View
{
   float3 eyePosition;
   matrix viewMatrix;
}

用cbuffer关键字声明cb，cb的名称一般对HLSL没太多用处，而是让C++应用程序端来识别特定cb。可以通过shader reflection API获得每个cb中的数据结构信息，在介绍HLSL的部分会详细讨论。

Buffer/Structured Buffer Resource

接下来的一种资源，根据所保存的数据类型不同，又分为standard(buffered) buffer resouce(扭曲的名字)和structured buffer resource。两者都是类似数组的结构，区别在于BBR的元素是普通内置类型，比如float4，而SBR的元素则是自定义的结构。之所以要做区分，原因是底层在处理数据映射到HLSL时的方式稍有不同。这种类型的buffer特别适合于shader需要访问大量数据的情况。也是目前为止第一种需要通过resource view绑定到管线的资源。所有可编程shader阶段都可访问b/s buffer，在pixel shader和computer shader中还允许写入操作。通过不同的resource view来控制b/s buffer的可访问性，比如shader resource view, unordered access view或者两者一起使用，任何shade都可以使用shader resource view标志，而unordered access view则只能对ps和cs使用。当b/s buffer为只读时，可以同时绑定到管线的多个阶段；允许写入时（使用了uav标志）则只能绑定到一个位置。

B/S buffer有三种典型的用途，第一种，用来保存静态数据，比如预计算的辐射传播(PRT)数据；第二种，运行时，由CPU计算出的数据，比如很多涉及到GPGPU的算法；最后一种则是由GPU计算填充的数据，比如由GPU计算的物理模拟结果。创建b/s buffer时，通常根据这三种用途，选择合适的访问参数。对于structured buffer来说，除了指定buffer大小之外，还需要提供每个结构的大小。以下是创建structured buffer的代码：

ID3D11Buffer* CreateStructuredBuffer(uint count,uint structSize,bool CPUWritable,bool GPUWritable,D3D11_SUBRESOURCE_DATA* pData)
{
         D3D11_BUFFER_DESC desc;
         desc.ByteWidth = count * structSize;
         desc.MiscFlags = D3D11_RESOURCE_MISC_MUFFER_STRUCTURED;
         desc.StructureByteStride = structSize;

         if(!CPUWritable && !GPUWriteable)
         {
             desc.BindFlags = D3D11_BIND_SHADER_RESOURCE;
             desc.Usage = D3D11_USAGE_IMMUTABLE;
             desc.CPUAccessFlags = 0;
         }
         else if( CPUWritable && !GPUWritable)
         {
             desc.BindFlags = D3D11_BIND_SHADER_RESOURCE;
             desc.Usage = D3D11_USAGE_DYNAMIC;
             desc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE;
         }
         else if( !CPUWritable && GPUWritable )
         {
             desc.BindFlags = D3D11_BIND_SHADER_RESOURCE | D3D11_BIND_UNORDERED_ACCESS;
             desc.Usage = D3D11_USAGE_DEFAULT;
             desc.CPUAccessFlags = 0;
         }
         else if ( CPUWritable && GPUWritable)
         {
            //error handling
            //resource acan’t be write by both CPU and GPU simultaneously
         }

         ID3D11BUFFER* pBuffe = 0;
         HRESULT hr = pDevice->CreateBuffer( &desc,pData,&pBuffer);
         if(FAILED(hr))
         {
            return 0;
         }
         return pBuffer;
}

B/S buffer需要通过RV才能绑定到管线上，并且只能是shader resource view或者unordered access view。需要在创建RV时提供buffer的数据格式，BBR的格式必须是DXGI中定义的格式之一，SBR的格式总是DXGI_FORMAT_UNKNOWN。创建RV时，可以指定开始元素(ElementOffset)的位置和元素个数(ElementWidth)，可以选择把整个或者一部分buffer数据包含在view中。对于HLSL来说，绑定到管线的buffer则总是一个下表标从在[0,ElementWidth]之间的数组。

ID3D11ShaderResourceVIew* CreateBufferSRV ( ID3D11Rsource* pResource)
{
         D3D11_SHADER_RESOURCE_VIEW_DESC desc;
         desc.Format = DXGI_FORMAT_R32G32B32_FLOAT;
         desc.ViewDimension = D3D11_SRV_DIMENSION_BUFFER;
         desc.Buffer.ElementOffset = 0;
         desc.Buffer.ElementWidth = 100;

         ID3D11ShaderResourceView* view = 0;
         HRESULT hr = pDevice->CreateShaderResourceView(pResource, &desc, &pView);

         return pView;
}

使用ElementOffset和ElementWidth参数，可以把同一个B/S buffer分成多个子buffer，每个子buffer都可以有独立的RV。创建UAV的方法和SRV类似，但需要额外加一个属性：

desc.Buffer.Flags = D3D11_BUFFER_UAV_FLAG_COUNTER;

为了在shader中访问B/S buffer数据， HLSL中也要用类似一种模板或泛型的语法声明相应的变量，下面是SBR的声明：

struct GridPoint
{
    float height;
    float4 flow;
}

RWStructuredBuffer<GridPoint> newWaterState  :register(u0);
StructuredBuffer<GridPoint> currentWaterState  :register(t0);

可以通过两种方法声明结构化buffer：RWStructuredBuffer<>和StructuredBuffer< >。区别在于前者对应着可读可写的buffer（UAV），后者则是只读的数据（SRV），注意，不同buffer对应的寄存器标识也不一样。声明了HLSL变量以后，就能用普通数组的语法，通过索引访问buffer中的数据了。HLSL中提供GetDimensions()函数，可以返回buffer大小，或者是SBR中的数组元素个数。对于使用UAV绑定的SRB来说，由于指定了D3D11_BUFFER_UAV_FLAG_COUNTER标记，还可以使用IncrementCounter()和DecrementCounter函数管理数据。

-------------------------------------to be continue----------------------------------

本文链接

The Beauty of DirectX 11 (2) --- Resource View & Vertex Buffer

2011-10-09T14:00:00Z

The Beauty of DirectX 11 (2) --- Resource View & Vertex Buffer

作者：clayman

仅供个人学习使用，请勿转载，勿用于任何商业用途。

CPU Access Flag(D3D11_CPU_ACCESS_FLAG)

这是一个位标记，在指定usage flage之后，进一步说明是否允许cpu访问某块资源(其实个人觉得这个枚举稍微有些多余)。这个标记必须配合usage使用，比如只有dynamic和stagin资源能设置为D3D11_CPU_ACCESS_WRITE。如果一块资源不需要被CPU访问，那么必须把值设置为0.

Bind Flags

指定资源可以绑定到pipeline的哪些位置。这同样是一个位标记，因此可以组合起来，允许资源绑定到流水线的多个位置。

D3D11_BIND_FLAG {

D3D11_BIND_VERTEX_BUFFER,

D3D11_BIND_INDEX_BUFFER,

D3D11_BIND_CONSTANT_BUFFER,

D3D11_BIND_SHADER_RESOURCE,

D3D11_BIND_STREAM_OUTPUT,

D3D11_BIND_RENDER_TARGET,

D3D11_BIND_DEPTH_STENCIL,

D3D11_BIND_UNORDERED_ACCESS

}

整个管线只有8种类型的位置可以绑定资源，分别对应D3D11_BIND_FLAG中的一个值。Vertex/index buffer表示资源可以作为input assembler阶段的输入数据；render target和depth stencil表示资源可以接收output merger阶段的数据；stream out表示可以接收来自于pipeline生成的几何数据。这几个枚举分别对应着管线中的一个可绑定点。Constant buffer, shader resource和unorderer access则都可以作为可编程阶段的输入数据。后面会讨论三者之间的区别。

此外Miscellaneous Flags中的枚举值，用来指定一些特别的用途，大部分值都不经常用到，不再仔细介绍，详见文档。唯一值得一提的是D3D11_RESOURCE_MISC_GDI_COMPATIBLE，这个值允许创建与GDI兼容的资源，对于需要用GDI创建文字的程序可能会用到。

Resource View

有两种方法把资源绑定到pipeline，如前所述的8种绑定点中，有一半可以直接绑定资源，分别是vertex/index/const/stream buffer；其他4种类型则必须通过Resource View（RV）绑定。Resource View是在DirectX10时代引入的概念，它实际上是连接resouce和pipeline绑定点之间的一种适配器对象，作用类似翻译。同一种资源可以对应多个不同的RV，允许它被绑定到不同的pipline阶段。

resource type

有四种不同类型的RV，分别对应着pipeline中的4个可绑定位置：

Render target view (ID3D11RenderTargetView)

Depth stencil view (ID3D11DepthStencilView)

Shader resource view (ID3D11ShaderResourceView)

Unordered access view (ID3D11UnorderedAccessView)

第一种就是常见的render target，大家应该很熟悉，没有太多可说的。DSV和RTV的区别在于为了优化性能，可以选择DSV是否可写。不可写的DSV资源既可以绑定为depth stencil buffer做depth stencil test，又能*同时*绑定为SRV使用。SRV其实和之前DX中纹理的作用几乎一样。UVA则稍微有些特别，和SRV类似，UVA也可以为某个shader阶段提供数据，不仅如此，它还允许在同一个shader阶段，同时读取和写入数据，并且能把数据写入到资源的任意位置，灵活性非常高，但只能在pixel shader和compute shader中使用。

Resource View Creation

创建RV的模式和创建资源的模式类似，也通过ID3DDevice的成员函数完成，每个Create函数接收3个参数，第一个是RV所依赖的资源；第三个是所创建的RV对象。第二个参数则是每个类型都不同的一个属性结构，SDK中对这些结构有详细描述，这里不再重复。

Resource in Detail

Buffer Resource

BR是一维的线性内存块，虽然有多种不同的buffer配置选项，但内部数据都是基本的线性布局。Buffer以byte为单位，大小等于每个元素大小乘元素个数，与普通数组类似。接下来将详细介绍每一种buffer。

Vertex Buffer

VB最基本的用途就是保存几何体顶点数据，是一系列格式相同的顶点的集合。当然，也可以把顶点的不同元素分离到不同VB中，比如位置信息储存在vb1，纹理和法线信息储存在vb2，根据渲染时的需要选择使用合适的buffer，也就是常说的multi-stream。此外，VB也可以用来实现instancing rendering(注：后文将把instance翻译为”副本”，而不是常见的”实体”，这样更容易理解)，比如用一块或几块vb保存per-vertex data，也就是普通的顶点数据，再用额外的vb来提供per-instance data，比如每个模型副本的world matrix，color等等，这样便可一次渲染大量图形，减少CPU负载。后面还会详细介绍与instancing rendering相关的内容。

VB主要用于Input Assembler阶段给整个流水线提供顶点数据，也可以用于stream out阶段接收生成的顶点，以便后续渲染使用。

创建VB时，必须使用D3D11_BIND_VERTEX_BUFFER以及可选的D3D11_BIND_STREAM_OUTPUT枚举。再根据程序预期的用途，选择合适的usage。e.g对于静态资源(静态模型，地形数据)，使用D3D11_USAGE_IMMUTABLE枚举，并且使用D3D11_SUBRESOURCE_DATA参数初始化资源；对需要频繁修改的资源使用D3D11_USAGE_DYNAMIC以及D3D11_CPU_ACCESS_WRITE枚举；对于需要作为stream output输出目标的资源，使用D3D11_USAGE_DEFAULT。VB不需要RV就可以绑定到管线。

ID3D11Device* pDevice = 0;
ID3DBuffer* CreateVertexBuffer(uint size, bool dynamic, bool streamout, D3D11_SUBRESOURCE_DATA* pData)
{
    D3D11_BUFFER_DESC desc;
    desc.ByteWidth = size;
    desc.MiscFlags = 0;
    desc.StructureByteStride = 0;

    if(streamout)
        desc.BindFlags = D3D11_BIND_VERTEX_BUFFER | D3D11_BIND_STREAM_OUTPUT;
else
        desc.BindFlags = D3D11_BIND_VERTEX_BUFFER;

    if(dynamic)
    {
        desc.Usage = D3D11_USAGE_DYNAMIC;
        desc.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE
}
else
{
    desc.Usage = D3D11_USAGE_IMMUTABLE;
    desc.CPUAccessFlags = 0;
}

ID3DBuffer* pBuffer = 0;
HRESULT hr = pDevice->CreateBuffer(&desc,pData,&pBuffer);
if(FAILED(hr))
{
    return 0;
}
return pBuffer;
}

Index buffer

Index buffer的基本操作都与vertex buuffer基本类似，详细请参考sdk文档。

-------------------------------------to be continue----------------------------------

本文以及未来文章中的代码都未经编译测试

关于DirectX 11 pipeline流程图，参考这里

本文链接

The Beauty of DirectX 11 (1) --- Device & Resource

2011-10-08T16:39:00Z

The Beauty of DirectX 11 (1) --- Device & Resource

作者：clayman

仅供个人学习使用，请勿转载，勿用于任何商业用途。

这是一系列关于DirectX11的文章中的第一篇，部分内容来自于<<Practical Rendering & Computation with Direct3D 11>>一书(我没有电子版，不要找我要电子版@_@!!如果你感兴趣，这里可以找到此书的源码)，但不是翻译。文章不会介绍常见的基本概念，并且假定读者已经有DirectX9/10或者xna使用经验，并对图形学有一定了解。此外，也不会有太多示例代码，我将会着重介绍DirectX 11中API的新特性和用法，整个pipeline流程以及HLSL 5.0，文章将不定期更新，但不保证最后一定能写完:)

当使用DirectX 11时，首先要清楚的就是device拆分为了2个类：device和device context。ID3D11Device负责资源创建，查询硬件功能一些和debug相关的操作。ID3D11Device还引入了一个称为feature levels的概念(和dx9中的Caps类似)，允许DirectX11运行在早期硬件上，比如DX9/10级别的GPU。这意味着开发者可以使用一组统一的接口来开发运行在不同代硬件上的程序。因此，如果你正考虑更新引擎的话，可以直接跳过DirectX10，升级到DirectX11。

所有使用资源，管理渲染流水线的功能，则属于device context的职责，包括绑定资源，shader，设置render state，执行渲染命令等等。Device context的功能通过ID3D11DeviceContext接口实现, 为了支持多线程，又分为immediate context和deferred context两种。前者和之前的DX device类似，每个程序只允许有一个immediate context，它所发出的所有命令都直接由runtime提交到到驱动执行。Dferred context所发出的命令则先缓存在一块command list缓冲中，提交整块缓冲时，才会依次执行其中的指令。这部分会在讲多线程的时候详细讨论。可以通过D3D11CreateDevice和D3D11CreateDeviceAndSwapChain创建设备，SDK对这两个函数，以及所有参数的用法有详细文档，这里不再重复。

接下来，我们将详细讨论DX11中的资源(Resource)，因为它们是所有操作的最基本元素。DX11中的资源分为两类：buffer和texture，每种又有各自的子类型，以及不同的配置参数，基本类关系如下：

ID3D11Resource

|---- ID3DBuffer

|---- ID3D11Texture1D

|---- ID3D11Texture2D

|---- ID3D11Texture3D

如前所述，所有资源都必须通过ID3D11Device创建，所创建的资源可以直接或者间接通过resource view绑定到pipleline的某个阶段。虽然每种创建每种资源的方法不一样，但模式是相同的：所有创建函数都接受3个参数 1. 包含了对所创建资源各种选项描述的结构（resource description）, 2. 指向D3D11_SUBRESOURCE_DATA结构，用来初始化资源数据的指针, e.g 用来初始化vertex buffer的顶点数据。如果希望稍后再填充数据，可以使用null；3，所创建的资源对象。每种资源的resource description都不一样，接下来，我介绍一些常用参数和选项：

Resource Usage Flags(D3D11_USAGE)

资源可以存放在显存和系统内存，可以作为复制操作的数据源或者目标。DX根据这个枚举来选择放置资源的位置以及内部如何操作,e.g 把只有GPU能操作的资源放到显存中，这个参数类似于之前的memory pool，区别在于memory pool是直接指定了资源位置。D3D11_USAGE有四个值，每种的访问级别也不一样

GPU-Read GPU-Write CPU-Read CPU-Write

Default yes yes

Dynamic yes yes

Immutable yes

Staging yes yes yes yes

Immutable 最简单的类型，一旦创建之后数据就不可改变。适合储存静态数据，比如静态常量，顶点索引缓冲等。

Default 对于只需要被GPU操作(读写)的数据来说，这是最优的选项，适合于render target, stream ouput vertex buffer等。这种类型资源通常存在于显存中，效率非常高。

Dynamic 这是一种CPU可以访问的资源，允许CPU写入数据，之后由GPU读取，注意CPU是不能访问已写入输入的，适合于shader constant buffer.

Staging 这种类型的资源提供了一种特别的访问模式，允许GPU写入数据，之后由CPU读出。它存在的主要作用是提供其他3种资源之间的交换，对于GPGPU和stream output 特别有用

下一部分讲继续讨论与资源相关的内容.....

-------------------------------------to be continue----------------------------------

嗯嗯，我还活着，又打算开始写东西了.......

本文链接

DirectX Rendering Pipeline

2010-12-31T10:08:00Z

DirectX 9:

可以在战魂的blog可以下到完整的大图。

以下三张是Wolfgang Engel大师制作的，因为翻墙才能看到，所以转过来了

DirectX 10：

DirectX 11：

DirectComputer：

本文链接

Windows phone开发者们，快来投票啊~~

2010-12-24T07:12:00Z

看来MS markectplace的政策不但让国内开发者很不爽，国外开发者也怨声载道。有人发起了投票，请愿ms对全球开发者开放markectplace。各位国内的开发者也来投上一票吧，只需10秒的时间，并请转发给你认识的开发者，猛击下面地址：

http://www.petitiononline.com/wp7intl/petition.html

本文链接

Working with FBX SDK (2)

2010-12-10T20:07:00Z

Working with FBX SDK (2)

仅供个人学习使用，请勿转载，勿用于任何商业用途

作者：clayman

上一篇文章介绍了fbx sdk的基本用法，接下来我们继续讨论如何取得normal，tangent，binormal和uv信息。先介绍一些关于KFbxLayer对象的概念。KFbxLayer对象是一个容器，对mesh来说，它包含了除控点，多边形信息以外大部分数据，比如normal，tangent，vertex color，uv等等。一个mesh可以包含多个KFbxLayer对象，不同layer之间的元素类型，个数通常都不相同。下面是一个简单的mesh结构关系：

mesh ---- layer 0 { KFbxLayerElementNormal, KFbxLayerElementTangent, KFbxLayerElementUV…..}

|------layer 1 {KFbxLayerElementUV………}

|-- ………………..

|-- layer n

虽然FBX允许有多层layer，但很多软件包括maya和max都只处理包含在第一个layer中的normal等数据！每种保存在KFbxLayer的元素都继承于KFbxLayerElement，比如KFbxLayerElementNormal对应normal数据，KFbxLayerElementTangent对应tangent的数据。可以通过KFbxLayer中定义的各种Get函数，返回需要的KFbxLayerElement，如果为空，则说明当前layer中没有这种元素。KFbxLayerElement还中包含了两个非常重要的属性KFbxLayerElement::EMappingMode和KFbxLayerElement::EReferenceMode。

MappingMode定义了当前类型的元素如何映射到mesh上。举例来说，对于KFbxLayerElementNormal，eBY_POLYGON_VERTEX表示如果一个顶点被n个多边形共享，那么这个顶点就有n条法线与之相对应；eBY_CONTROL_POINT则表示每个顶点无论被几个多边形共享，都只有一条normal；eBY_POLYGON则表示构成多边形的n个顶点只对应着一条normal。某些MappingMode只对特定的KFbxLayerElement有效，请详细参考文档。通常对于有hard edge的模型来说，MappingMode只能是eBY_POLYGON_VERTEX，而平滑模型则可以是eBY_CONTROL_POINT。

ReferenceMode定义了如何访问相关的数据。同样举例来说，每个KFbxLayerElement内部通常可能包含两个数组，分别称为DirectArray和IndexArray。如果reference mode为eDIRECT，则第i个控点相对的element元素就在DirectArray的第i位置(第i个控点的normal在KFbxLayerElementNormal.DirectArray[i]中) ，此时IndexArray为空。eINDEX_TO_DIRECT通常和eBY_POLYGON_VERTEX一起使用，因为一个控点可能对应多个值，所以这时必须用多边形顶点索引（也就是GetPolygonVertexCount()返回的值）来获得某个多边形顶点所对应的值： KfbxLayerElement.DirectArray[ IndexArray[vertexIndex]]。下面代码演示了如何遍历所有layer，获得每个顶点/控点对应的法线:

KFbxLayerElementNormal* leNormal = pMesh->GetLayer(0)->GetNormals();
if (leNormal)
{
    switch (leNormal->GetMappingMode())
    {
        case KFbxLayerElement::eBY_CONTROL_POINT:
            switch (leNormal->GetReferenceMode())
            {
            case KFbxLayerElement::eDIRECT:
                KFbxVector4 normal = leNormal->GetDirectArray().GetAt(lControlPointIndex));
                break;
            case KFbxLayerElement::eINDEX_TO_DIRECT:
                {
                    int id = leNormal->GetIndexArray().GetAt(lControlPointIndex);
                    KFbxVector4 normal = leNormal->GetDirectArray().GetAt(id));
                }
                break;
            default:
                break; // other reference modes not shown here!
            }
            break;

        case KFbxLayerElement::eBY_POLYGON_VERTEX:
            {
                //polygonID = triange 1,2,3.....n
                //positionId = 1,2,3 for triange

                //vertex!!!!
                int vertexIndex = pMesh->GetPolygonVertex(polygonID,positionId);
                switch (leNormal->GetReferenceMode())
                {
                    case KFbxLayerElement::eDIRECT:
                    case KFbxLayerElement::eINDEX_TO_DIRECT:
                        {
                            Display2DVector(header, leUV->GetDirectArray().GetAt(vertexIndex))
                        }
                        break;
                    default:
                        break; // other reference modes not shown here!
                }
            }
            break;
    }
}

为了避免混淆，再强调一下控点和顶点的区别。首先，控点只包含位置信息，顶点则包含了位置，法线，纹理坐标等信息。如果mesh中所有layer中的所有元素MappingMode都是eBY_CONTROL_POINT，则控点数量和顶点一一对应。如果是eBY_POLYGON_VERTEX，则有可能需要分裂控点。比如一个控点被n个多边形共享，则对应着n条法线，需要分裂成n个顶点，但是，控点所对应的n条法线中有些可能是相同的（none hard edge）------所以eBY_POLYGON_VERTEX通常和eINDEX_TO_DIRECT配合使用----- 因此最终分裂出来的顶点数有可能小于n。Tangent，bionormal，vertex color的访问与此类似，而且一般来说，只需要读出第一个layer中的数据即可。如何根据不同的normal等信息分裂控点，组合顶点，需要我们自己来实现，这里不详细讨论。

UV的访问方式和上面提到的方法类似，但稍稍有些区别。前面说过，虽然每个mesh都允许多个layer，但通常只会有一组normal，tangent等数据，uv则可能有多组（比如一组uv用于普通贴图，另外一组用于lightmap），并且有可能保存在同一layer中，也有可能分别保存在多个layer中。但是fbx文件中有一个奇怪的问题，很多模型虽然只有一组UV，但会被识别出多组UV出现在不同layer中，并且不是每个layer中存在的数据都相同或者有效！！

上图中，第一个文件是正确的，2组UV分别在两个layer中；下面的文件则多出了2层只含UV的layer，注意多余的uv名称都是map1. FBX论坛上好像有人也遇到了同样的问题，不过都没有官方的解释，文档中也没有讨论。解决方法是我们可以通过检查每组UV的名称来确定某组UV是否是重复：

foreach layer
{
    int uvSetCount = layer->GetUVSetCount();
    if(uvSetCount > 0)
    {
        //iterate all uv channel indexed by element_texture_type
        for (int textureIndex = KFbxLayerElement::eDIFFUSE_TEXTURES;textureIndex<KFbxLayerElement::eLAST_ELEMENT_TYPE;textureIndex++)
        {
            KFbxLayerElement *uvElement = layer->GetUVs(KFbxLayerElement::ELayerElementType(textureIndex));
            if(!uvElement)
                continue;
            uvSetsName =  uvElement->GetName();
            if(!CheckUVSetsNameExists(uvSetsName))
            {
              //process uv data
            }

}

GetUVs (KFbxLayerElement::ELayerElementType type) 返回对应type类型的UV，不存在则返回NULL。这里的type是KFbxLayerElement::ELayerElementType枚举中eDIFFUSE_TEXTURES 到eDISPLACEMENT_TEXTURES 之间的值。可以把这个枚举理解为UV的通道标识符，比如GetUVs(eDIFFUSE_TEXTURES)返回diffuse texture通道的纹理，注意，这里eDIFFUSE_TEXTURES并不指这组UV只能用于diffuse map，而只是一个标识符！对于只有一组uv的模型来说，纹理数据通常都在这个通道中。

我们已经基本解析出模型中的几何信息。接下来看如何获得材质，特别是纹理信息。与前面的元素不同，material不保存在layer中，而是保存在node里，一个node可以包含多个材质。SDK文档中关于材质，纹理之间关系的介绍非常让人迷惑，有些接口也很常奇怪。虽然Layer中有一个名为GetMaterials()的方法，但其返回的KFbxLayerElementMaterial对象中GetDirectArray()只会返回空值，也就是说无法通过它获得真正表示材质的KFbxSurfaceMaterial对象。下面的代码展示了如何取得材质，以及相应的数值类参数。

for(int lIndex=0; lIndex < lNode->GetMaterialCount() lIndex++)
{
    KFbxSurfaceMaterial *lMaterial = lNode->GetMaterial(lIndex)
    //convert to proper sub type
    if(lMaterial->GetClassId().Is(KFbxSurfaceLambert::ClassId) )
    {
        ((KFbxSurfaceLambert *)lMaterial)->GetAmbientColor()
        ((KFbxSurfaceLambert *)lMaterial)->GetDiffuseColor()
        ...
    }
    else if(lMaterial->GetClassId().Is(KFbxSurfacePhong::ClassId))
    {
        ((KFbxSurfacePhong *) lMaterial)->GetAmbientColor()
        ((KFbxSurfacePhong *) lMaterial)->GetDiffuseColor()
        ...
    }
}

逻辑上来说，KFbxSurfaceMaterial其实是个抽象类，需要把它转换为合适的两个子类，才能得到实际材质参数。纹理则要更特别一些（注意，虽然layer中也有GetTextures()，但我测试的时候总返回空值）。一个材质会包含多个纹理通道，每个通道同样以KFbxLayerElement::ELayerElementType中关于纹理的枚举作为标识符，每个通道可以包含多个KFbxTexture或者KFbxLayeredTexture，其中，KFbxTexture就对应着一张纹理，而KFbxLayeredTexture则又包含了多个KFbxTexture对象，类似如下结构：

KFbxSurfaceMaterial : contains one or more textureProperty, identified by KFbxLayerElement::ELayerElementType

textureProperty : contains one or more texture/layerTexture;

layerTexture: contains more than one texture

下面的代码展示了如何获得纹理信息。

void FbxImporter::ParseMaterial(KFbxNode* fbxNode,HamsterEngine::Node *node)
{
    //iterate all material
    for (int i = 0;i<fbxNode->GetMaterialCount();i++)
    {
        KFbxSurfaceMaterial *mat = fbxNode->GetMaterial(i);
        if(mat)
        {
            //iterate all texture channel
            for (int textureIndex = 0;textureIndex< KFbxLayerElement::LAYERELEMENT_TYPE_TEXTURE_COUNT;textureIndex++)
            {
                //get current texture channel
                KFbxProperty property = mat->FindProperty(KFbxLayerElement::TEXTURE_CHANNEL_NAMES[textureIndex]);
                //has channel?
                if(property.IsValid())
                {
                    //layered texture?
                    if(layerCount > property.GetSrcObjectCount(KFbxLayeredTexture::ClassId);)
                    {
                        //iterate all layered texture
                        for (int layerId=0;layerId<layerCount;layerId++)
                        {
                            KFbxLayeredTexture *layeredTex = KFbxCast<KFbxLayeredTexture>(property.GetSrcObject(KFbxLayeredTexture::ClassId,layerId));
                            int numTex = layeredTex->GetSrcObjectCount(KFbxTexture::ClassId);
                            //iterate all texture in this layer
                            for (int texId=0;texId<numTex;texId++)
                            {
                                KFbxTexture* tex = KFbxCast<KFbxTexture>(layeredTex->GetSrcObject(KFbxTexture::ClassId,texId));
                                if(tex)
                                {
                                    std::cout<<"Texture  name:"<<tex->GetName()
                                        <<"    fileName:"<<tex->GetFileName()
                                        <<"    uvSet:"<<tex->UVSet.Get();
                                }
                            }
                        }
                    }
                    else
                    {
                        int numTextures = property.GetSrcObjectCount(KFbxTexture::ClassId);
                        ////iterate all simple texture
                        for (int texId = 0;texId<numTextures;texId++)
                        {
                            KFbxTexture *tex = KFbxCast<KFbxTexture>(property.GetSrcObject(KFbxTexture::ClassId,texId));
                            if(tex)
                            {
                                std::cout<<"Texture  name:"<<tex->GetName()
                                    <<"    fileName:"<<tex->GetFileName()
                                    <<"    uvSet:"<<tex->UVSet.Get();
                            }
                        }
                    }
                }
            }
        }
    }
}

KFbxTexture.UVSet.Get()返回当前纹理所绑定的UVSet名称，可以由此获得纹理和UV的绑定关系。

之前所说的KFbxLayerElementMaterial并不是完全没用，还必须用它获得mapping mode，对材质来说，最常见的两个值是：eALL_SAME和eBY_POLYGON，前者表示整个mesh的材质都相同，没太多可说的；后者表示材质只应用到mesh中的部分多边形，这就比较麻烦了，上图中第二个文件就是这种情况。不同材质意味着纹理或者shader改变，我们必须把eBY_POLYGON的mesh根据材质划分为不同子mesh才能导入到DirectX程序中。幸运的是sdk提供了这样的函数，让我们不用自己计算：

KFbxGeometryConverter lConverter(pSdkManager)
lConverter.SplitMeshPerMaterial(lMesh)

注意：

before and after the call to SplitMeshPerMaterial, you should see a difference in the number: there will be the old mesh, plus one new mesh (node attribute) for each material.

It will work only on mesh that have material mapped “per-face” (Mapping Mode is KFbxLayerElement::eBY_POLYGON). It does NOT work on meshes with material mapped per-vertex/per-edge/etc.It will create as many meshes on output that there are materials applied to it.If one mesh have some polygons with material A, some polygons with material B,and some polygons with NO material, it should create 3 meshes after calling this function.The newly created meshes should be attached to the same KFbxNode that hold the original KFbxMesh.The original KFbxMesh STAY UNCHANGED.Now, the new mesh will have Normals, UVs, vertex color, material and textures.

以上介绍了模型导入时从fbx文件中提取，常见数据的方法，也还有很多方面没有讨论，比如skin info和animation。对skin来说，相应的权重等信息保存在KfbxDeformer对象中，可以通过KFbxNode获得。至于动画目前我暂时还没有时间研究，如果有好心人实现了，不妨也写篇教程顺便告诉我一声:）。另外最先说过，fbx是一种可扩展的格式，可以通过UserProperties属性添加很多自定义属性，这里介绍了如何在maya和max中添加自定义属性，SDK中的UserProperties sample则介绍了如何取得这些属性。文章中所涉及的函数只介绍了基本用法，详细信息请参考文档。另外文档中虽然没有太多示例代码，但sdk中附带的ImportScene Sample是一个非常好的例子，展示了解析fbx文件的方方面面，值得仔细研究。

本文链接

Working with FBX SDK (1)

2010-12-09T22:40:00Z

Working with FBX SDK (1)

仅供个人学习使用，请勿转载，勿用于任何商业用途

作者：clayman

模型导入是所有3D程序最基本的功能，但常常也是让很多新手最头疼的问题之一。DirectX虽然提供了直接加载.x文件的功能，不幸的是多年以来，很少有主流建模软件提供了对它的直接支持，各种各样的格式转换程序之间又多多少有些小bug存在，加上近年来ms也逐渐不再使用.x文件，因此，为了将来程序开发更加灵活方便，任何稍有规模的程序都必须重新发明轮子，自己实现模型导入。

当选择支持什么类型的模型文件时，最重要的因素就是交换性----即这种格式是否能被大多数三维软件支持，是否能方便的和其他格式转换；有良好定义以及可扩展性。在各种模型文件中，目前最能满足这三个条件的就是fbx和Collada，本文主要讨论前者。需要说明的是，无论选择什么格式，这些格式都不应该是图形引擎直接读取的格式。虽然我们也可以这么做，但无论fbx，collada或者其他很多格式都是以数据交换为目的而设计的，比如collada本质就是xml文件，因此不适合游戏引擎这类对性能有较高要求的程序。理想的解决方案是把这些格式作为数据来源，通过预处理转换为为特定引擎设计的格式，最后引擎直接读取特有的自定义格式。如果熟悉XNA的话，XNA中的content pipeline就是完成了这样的工作，把模型，纹理转换为特殊设计的xnb格式，加速运行时的读取速度。引擎只需要有读取一种文件的能力即可，而另外有一些列的importer/converter可以把其他格式的文件在预处理阶段，转换为引擎可识别的格式。

如何设计适合自己引擎的文件格式超了本文讨论范围，不过这里举一个小小的例子，说明自定义格式的必要性。以fbx文件为例，假设用记事本打开一个只包含一个mesh模型文件，可以看到数据大概是按以下方式组织的：

vertex { position data…..}

normal {normal data……}

UV {UV data……}

引擎如果直接读取这样的文件，需要在运行时把数据重新解析组织为硬件可以直接使用的格式:从不同位置抽出position，normal，uv数据合成顶点，再把顶点组织为数组，最后放入vertex buffer中。而如果自定义文件话，可以直接就把数据以vertex array的格式保存，比如：

vertexData{ (pos,nol,uv),(pos,nol,uv),……}

这样在读取文件之后，可以直接把数据放入vertex buffer，效率自然是前者不可比的。当然，实际的文件不仅包含顶点数据，还会有很多其他内容。

说了那么多，现在回到正题。本文不会，也不可能详细讨论解析fbx的所有数据，只重点讨论如果解析出游戏引擎最常用到的信息：如何访问mesh，读取相应的顶点，材质以及模型结构（Hierarchy）信息。

先介绍一点关于fbx的基本知识，fbx是Autodesk开发的文件格式，其开发目的就是为了实现Autodesk旗下软件之间的数据交换。鉴于Autodesk已经把主流建模软件公司买的差不多了（maya，3ds max，softimage，motionbuilder…..），几乎所有主流三维建模软件都能导出\导入fbx文件，Autodesk也提供了的专门的软件fbx convert可以把其他流行格式（包括collada）转换为fbx文件。Fbx文件格式本身是不公开的，而是通过FBX SDK实现对fbx文件的读取以及写入，这也是我选择fbx的一个重要原因，作为开发者可以不必关心实际的数据储存细节（用记事本打开ascii码的fbx文件，还是能大概了解实际的数据格式），把文件看做一个数据源对象，通过特定函数就能访问数据源中的特定数据。而稍后我们就会看到，fbx sdk设计的也非常易用。

我们要做的第一步就是从autodesk网站下载FBX SDK（需要先填写一个简单的表格才能下载，嗯嗯，可以乱填)，最新版本是2011.3，windows下的安装包大约有450m。安装之后，需要在工程里进行一些简单的设置才能使用。对于visual Studio来说，请**仔细**按照文档Downloading and installing部分的介绍进行配置，除17以外，其他都是必须的，特别注意在16步时，选择正确的lib文件。特别提醒，虽然2011.3包含了的vs2010下的lib，但是有重大bug，会在导入某些fbx文件时，出现” debug assertion failed”错误(坑爹啊，浪费了我两天)，推荐在vs2005/2008下开发。

接下来，就可以动手写代码了。使用fbx sdk时，最先遇到的两个对象就是KFbxSdkManage和KFbxScene。Fbx sdk中大部分类的命名都以KFbx开头（为什么是k呢….？）。KFbxSdkManage是sdk中的中心类，负责了整个sdk内部状态的管理，很多其他对象创建也依赖于KFbxSdkManage，程序中只需要有一个KFbxSdkManage类的实例即可。KFbxScene如其名所示，代表了一个场景，而这里的场景就是fbx文件中包含的所有信息，fbx文件导入以后，在程序中就是一个KFbxScene对象。可以用以下代码完成这两个对象的创建。

init sdk
KFbxScene *scene;
KFbxSdkManager *sdkManager;

void FbxImporter::Init()
{
    sdkManager = KFbxSdkManager::Create();
    KFbxIOSettings* ios = KFbxIOSettings::Create(sdkManager,IOSROOT);
    sdkManager->SetIOSettings(ios);
    scene = KFbxScene::Create(sdkManager,"");
}

注意，示例代码省略了必要的错误检查。上面代码中出现了KFbxIOSettings类，这是一个用来配置KFbxSdkManage的对象，可以通过这个对象设置一些导入导出时的行为，比如可以选择不导入材质，动画等等。有了这两个对象之后，下一步就可以导入fbx文件了，这需要用到KFbxImporter对象，他会自动解析fbx文件中的数据，并保存到KFbxScene对象中。实际上除fbx以外KFbxImporter还能导入一些其他格式的文件。实例代码如下：

void FbxImporter::LoadScene(const char* fileName)
{
    KFbxImporter* sceneImporter = KFbxImporter::Create(this->sdkManager,"");
    sceneImporter->Initialize(fileName,-1,this->sdkManager->GetIOSettings());
    sceneImporter->Import(scene);
    sceneImporter->Destroy();
}

文件加载之后，接下来就是用相应的方法，找出我们需要的数据。这里要稍微补充一点fbx组织数据的方式。前面说过，当用sdk来处理fbx文件时，它更像是一个数据源或者说一个对象，所以你应该以对象的方式来看待fbx，而不是文件的角度。如果你对scene graph/tree有所了解的话，fbx其实就是一个scene graph/tree！KFbxScene是根节点，包含了一系列子节点KFbxNode，每个KFbxNode又有其自己的子节点。KFbxNode包含了坐标变换信息，可以通过一系列get函数取得，其他数据作为KFbxNodeAttribute对象，包含在KFbxNode内部，这里的其他数据是指mesh，Nurbs，skeletion，camara，light等定义在KFbxNodeAttribute：：EAttributeType中的类型。一个KFbxNode可以有多个子KFbxNode，~~但只能有一个KFbxNodeAttribute对象~~，可以通过KFbxNodeAttribute的GetAttributeType()方法，确定当前node的所包含的实际数据类型:

更正：又仔细看了文档，KFbxNode可以有多个KFbxNodeAttribute对象，GetNodeAttribute()返回默认的attribute对象。

void FbxImporter::WalkHierarchy()
{
    KFbxNode* root = scene->GetRootNode();
    for (int i=0;i<root->GetChildCount();i++)
    {
        WalkHierarchy(root->GetChild(i),0,&(this->root));
    }
}

void FbxImporter::WalkHierarchy(KFbxNode *fbxNode, int depth)
{
    KFbxNodeAttribute* nodeAtt = fbxNode->GetNodeAttribute();
    if(nodeAtt == NULL)
    {
        ss<<"Name:"<<fbxNode->GetName()<<"  NodeType:"<<"None";
    }
    else
    {
        switch (nodeAtt->GetAttributeType())
        {
        case KFbxNodeAttribute::eMARKER:                  break;
        case KFbxNodeAttribute::eSKELETON:                break;
        case KFbxNodeAttribute::eMESH:   ProcessMesh(nodeAtt)  break;
        case KFbxNodeAttribute::eCAMERA:                  break;
        case KFbxNodeAttribute::eLIGHT:                   break;
        case KFbxNodeAttribute::eBOUNDARY:                break;
        case KFbxNodeAttribute::eOPTICAL_MARKER:          break;
        case KFbxNodeAttribute::eOPTICAL_REFERENCE:       break;
        case KFbxNodeAttribute::eCAMERA_SWITCHER:         break;
        case KFbxNodeAttribute::eNULL:                    break;
        case KFbxNodeAttribute::ePATCH:                   break;
        case KFbxNodeAttribute::eNURB:                    break;
        case KFbxNodeAttribute::eNURBS_SURFACE:           break;
        case KFbxNodeAttribute::eNURBS_CURVE:             break;
        case KFbxNodeAttribute::eTRIM_NURBS_SURFACE:      break;
        case KFbxNodeAttribute::eUNIDENTIFIED:
        }

    }

    //process children
    for (int i=0;i<fbxNode->GetChildCount();i++)
    {
        WalkHierarchy(fbxNode->GetChild(i),depth+1);
    }
}

说到这里，我们已经解决了第一个问题：获得场景结构信息。所有KFbxNode构成的树就是场景结构。而其中KFbxNodeAttribute为skeletion的节点组成的树，可能就是某个模型的骨骼。下图是解析两个不同文件得到的节点关系：

根据模型师建模习惯的不同，导出节点顺序是不一样的，比如上面的文件把骨骼单独作为一个树，下面的文件则用了一种混排的方式，一个node下同时有子骨骼节点和mesh节点。接下来，看如何读出顶点信息，注意下面仅以mesh为例，介绍一些常见操作。首先，用以下代码获得一个node中所包含的mesh数据：

void ProcessMesh(KFbxNodeAttribute* nodeAtt)
{
   if(nodeAtt->GetAttributeType() == KFbxNodeAttribute::eMESH)
   {
    KFbxMesh *mesh = dynamic_cast<KFbxMesh*>(nodeAtt);
    if(!mesh->IsTriangleMesh())
    {
        KFbxGeometryConverter converter(sdkManager);
        // #1
        converter.TriangulateInPlace(fbxNode);
        mesh = dynamic_cast<KFbxMesh*>(fbxNode->GetNodeAttribute());
        // #2
        //mesh = converter.TriangulateMesh(mesh);
    }

    std::cout<<“TriangleCount:" <<mesh->GetPolygonCount()
        <<"  VertexCount:"<<mesh->GetControlPointsCount()
        <<"  IndexCount:"<<mesh->GetPolygonVertexCount()
        <<"   Layer:"<<mesh->GetLayerCount()
        <<"  DeformerCount:"<<mesh->GetDeformerCount(KFbxDeformer::eSKIN)
        <<"  MaterialCount:"<< fbxNode->GetMaterialCount();
   }
}

Fbx文件中包含的mesh不一定是由三角形组成，还可能是四边形，五边形等等，因此，要做的第一步，就是三角化mesh，可以用以上两种方法实现。TriangulateMesh和TriangulateInPlace区别在于前者返回一个三角化之后的新mesh，后者则是对当前数据进行三角化。注意TriangulateInPlace之后需要重新获取mesh指针，否则代码会出错。Mesh类的大部分成员函数用途都一目了然，只是有一些概念需要注意：

1． GetPolygonCount() 返回三角形数量；

2． GetControlPointsCount() 返回控点数量，这里控点的概念和DirectX中常说的顶点非常类似，但不完全一样，更像是只包含了position的顶点。也就是说如果这个顶点被n个多边形共享（比如立方体八个角的点），而在每个多边形上又有不同的纹理坐标或者法线，那么稍后将分裂或者说生成n个包含position，normal，uvs等信息的顶点；

3． GetControlPoints () 返回控点数组指针；

4． GetPolygonVertexCount() 这是个迷惑人的名字，这个函数返回的其实是大家熟悉的vertex index count，对triange list来说，其实就是GetPolygonCount() * 3；

5． GetPolygonVertices() 返回索引数组指针；

下面的代码演示了如何把从fbx文件中读取的顶点，索引数据保存到一个非常简单的文件中：

save data
save model
vertex = mesh->GetControlPoints();
vertexCount = mesh-> GetControlPointsCount();
..........

void SaveData(const char *fileName,KFbxVector4* vertex,int vertexCount,int *indices,int indicesCount)
{
    //convert kfbxvector4[] to float[],notice we only use the first 3 element(x,y,z) of a  kfbxvector4
    float *verts = new float[vertexCount*3];
    float *pV = verts;
    for (int i=0;i<vertexCount;i++)
    {
        *pV = static_cast<float>(vertex[i][0]);
        pV++;
        *pV = static_cast<float>(vertex[i][1]);
        pV++;
        *pV = static_cast<float>(vertex[i][2]);
        pV++;
    }

        //create file
    std::ofstream fs(fileName,std::ios_base::out|std::ios_base::binary);

    //write geometryInfo: vertex and index count;
    int geometryInfo[2] = {vertexCount,indicesCount};
    fs.write(reinterpret_cast<const char*>(geometryInfo),sizeof(int)*2);

    //write vertex data
    fs.write(reinterpret_cast<const char*>(verts),sizeof(float)*vertexCount*3);

    short *sIndices = NULL;
    //convert to 16 bit index if possible to save memory
    if(vertexCount < 65535)
    {
        sIndices = new short[indicesCount];
        short *currentIndex = sIndices;
        for (int i=0;i<indicesCount;i++,currentIndex++)
        {
            *currentIndex = indices[i];
        }
        //write index data to file
        fs.write(reinterpret_cast<const char*>(sIndices),sizeof(short)*indicesCount);
    }
    else
    {
        fs.write(reinterpret_cast<const char*>(indices),sizeof(int)*indicesCount);
    }

    fs.close();
    delete[] verts;
    if(*sIndices != NULL)
    {
        delete[] sIndices;
    }
}

下面的XNA代码演示了从刚才保存的文件中读出数据并渲染：

read model
class ModelReader
{
    int vertexCount;
    int indexCount;

    VertexBuffer mVertexBuffer;
    IndexBuffer mIndexBuffer;

    public void LoadFile(GraphicsDevice graphics,string fileName)
    {
        //open file
        FileStream fs = new FileStream(fileName, FileMode.Open);
        BinaryReader br = new BinaryReader(fs);

        vertexCount = br.ReadInt32();
        indexCount = br.ReadInt32();

        //read vertex data
        VertexPositionOnly[] verts = new VertexPositionOnly[vertexCount];
        for (int i = 0; i < vertexCount; i++)
        {
            verts[i] = new VertexPositionOnly(new Vector3(
                br.ReadSingle(), br.ReadSingle(), br.ReadSingle()));
        }
        //create vertex buffer
        VertexDeclaration vd = new VertexDeclaration(new VertexElement(0, VertexElementFormat.Vector3,VertexElementUsage.Position, 0));
        mVertexBuffer = new VertexBuffer(graphics, vd, vertexCount, BufferUsage.None);
        mVertexBuffer.SetData(verts);

        //read index data
        short[] indices = new short[indexCount];
        for (int i = 0; i < indexCount; i++)
        {
            indices[i] = br.ReadInt16();
        }
        //create index buffer
        mIndexBuffer = new IndexBuffer(graphics, IndexElementSize.SixteenBits, indexCount, BufferUsage.None);
        mIndexBuffer.SetData(indices);

        HashSet<short> hash = new HashSet<short>();
              br.Close();
        fs.Close();
    }

    public void Draw(GraphicsDevice graphics)
    {
        graphics.SetVertexBuffer(mVertexBuffer);
        graphics.Indices = mIndexBuffer;
        graphics.DrawIndexedPrimitives(PrimitiveType.TriangleList, 0, 0, vertexCount, 0, indexCount / 3);
    }
}

目前我们已经从fbx文件中导出了最基本的信息，下次继续讨论如何获取noraml，uv，material等信息.........

本文链接

C++/CLI程序启动时_CrtIsValidHeapPointer(pUserData)错误

2010-12-03T19:57:00Z

奇怪的错误，坑死个人啊！！当C++/CLI程序引用了native lib顺利编译之后，程序启动有可能出现以下错误：

这是ms的一个已知bug，原因：

The reason why you get this error is that a winforms application has a managed entry point. The initialization of the native global objects is done by the CRT (C RunTime) startup routine. Since in this case there is no CRT startup routine the MyBoard global object fails to initialize correctly.

IDE is specific the entry of ManagedApp as "main". However, using "main" will bypass a lot of CRT's startup initialization.

解决方法：

右键点击项目--->properties--->link--->advanced

把Entry Point从main改为 "?mainCRTStartupStrArray@@$$FYMHP$01AP$AAVString@System@@@Z"

原理：

That should re-enable the CRT startup code which initializes the internal CRT variables.That symbol is really the mangled name for "int __clrcall mainCRTStartupStrArray(cli::array<class System::String ^ >^)".

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

为这问题白白浪费了一晚上，内牛满面啊T_T.............

本文链接

Make it Looks more Cinematic

2010-11-02T11:06:00Z

Make it Looks more Cinematic

作者：clayman

仅供个人学习使用，请勿转载，勿用于任何商业用途。

计算机图形设计师和图形程序员最大的区别是什么？前者偏向通过参数调节达到所希望的效果，后者则偏重于通过算法改进增强画面效果。虽然前者有很大局限性，但很多方法对程序员来说也是很有用的，人人都爱那些不用花费太多精力就能显著改变画面效果的小技巧。

拿游戏论坛里程序员个人demo的截图和一般商业游戏相比，模型，特效上的差异肯定是巨大的，但除此之外，个人demo画面风格通常让人感觉很“硬”，没有气氛。固然个人开发者可能没有时间和精力对场景做预处理，烘焙等等，但还有一个原因也许就是程序员们都不会“打光”。如果你已经看过Shawn的这篇文章，就知道我在说什么了。刚开始学图形的人，想到灯光颜色，就总认为应该是0~255之间的一个灰度值，这样做当然没错，但放眼看看电影和动画，通常优秀的视觉设计师绝对不会只用明暗变化体现场景光照，还必须加上色调变化。所谓的gooch shading，就是用暖色代表光较强的部分，冷色表似乎阴影部分的一种算法，gooch shading虽然是一种卡通化的着色手法，但烘托场景氛围，远比普通的明暗变化给力。Shawn所说的方法就是普通明暗变化与gooch shading结合的打光手法，让画面既不太卡通，氛围感也增强。我们所要做的，只是修改灯光参数罢了，不用额外付出任何代价，就能让画面看起来更上一个层次。

下图中间是神界2 light-pre pass渲染出的光照图，除了几处明显的黄色point light以外，整个场景的光线变化就是上面所说的方法，给人一种比较温暖的感觉。左边则是我在ps里去饱和之后的效果，氛围感完全没有了。

本文链接