于是检查D3DRS_ZENABLE,D3DRS_ZWRITEENABLE, 结果都是TRUE

无奈,只有与我以前正确的Demo对比210个渲染状态. 有部分渲染不同的,使用硬代码强行纠正,结果: 无效

怀疑顶点格式破损, 重新使用以前的模型格式,排除这个可能性, 结果:失败

无奈中,检查设备选项, 突然注意到D3DPRESENT_PARAMETERS 结构体中的EnableAutoDepthStencil 设置是FALSE

因为这次设备类是重写的,对比以前正确代码, 有差异,将其改为

PresentParameters.EnableAutoDepthStencil    = TRUE;
    PresentParameters.AutoDepthStencilFormat    = D3DFMT_D16;

以前翻阅SDK时,注意过这个选项, 这是由D3D帮你管理ZBuffer.

测试, 问题解决.

分析: 如果EnableAutoDepthStencil  = FALSE, 意味着连ZBuffer都没有,那更不要说渲染状态.

正确结果

本文翻译整理总结自http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter05.html

如果喜欢,请购买正版

多流技术在渲染时能对性能和结构有一定好处.但是怎样将模型数据分配到各顶点数据流进行渲染就是一个学问.

对于顶点数据可以分为这么几个大类:

G: 多边形数据, 包含vertex position, normal, and vertex color(s).

T: 纹理映射, 包含多层纹理坐标及tangent vectors等

A: 动画数据, 骨骼动画中的骨骼权重及骨骼索引

I: 用于Instance绘制的用户数据

以下是对一些常用渲染的流搭配:

静态模型

   可以是: G or G + T

骨骼动画模型

   可以是:G + A or G + T + A

Instance绘制的骨骼动画模型

   可以是:G + I or G + T + I 或者动画类型的G + A + I or G + T + A + I

渲染Z-Pass物件

  可以是G, 或者动画类型的G + A or G + I or G + A + I

这里参考了mybios博客中的文章,给CEGUI字符串做一个patch

然后需要找到vs2008的autoexp.dat文件

XP下位于:C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\autoexp.dat

用记事本等工具打开, 在AutoExpand段中像这样添加:

[AutoExpand]
; CEGUI String
CEGUI::String = str =<d_quickbuff,su> length =<d_cplength>

即可在VC调试器中看到CEGUI字符串内容, 不过中文还是暂时无法支持

首先,我们得弃用CPU蒙皮, 虽然兼容性好,但是面对现今多核但并不提高单核速率的情况下,GPU还是王道.而且GPU蒙皮代码可能更简单,不过也有一点小缺点, 对于小引擎来说,Shader必须给静态模型和骨骼动画模型写两套.

其次我们需要加强一个SubSkin的骨骼支持数量. 骨骼动画上的每个SubSkin都是一次Draw, 但是按照传统骨骼动画系统,每个骨头对应一个矩阵传入,那么SM2.0保守计算只能支持50根骨头. 不过在我前段时间的文章中有提到这个技术.并且已经在我的骨骼动画系统及OGRE中实现,效果很好.

美术也许很反感一个人物做1个SubSkin, 他们更新好多个SubSkin,也就是说身体每个部分都是一个SubSkin, 这样方便修改, 同时系统支持的骨骼数量还可以有一定量的上升.不过我们还需要做一个索引工作. 传统的GPU骨骼动画中总是在渲染SubSkin前传入所有这些SubSkin需要用到的骨骼矩阵. 但是每个SubSkin并不一定能用到所有的这些矩阵,这明显是一种浪费. 因此在OGRE中做过一次索引预处理,也就是将每个SubSkin用到的骨骼统计出来, 在渲染这次SubSkin时才重新传到GPU. 很明显,这是用速度还空间和兼容性. 如果在DX10以上,有ConstantBuffer还好. DX9实在太慢了

使用Marker点的换装系统很难处理例如贴身衣物这类物件换装. OGRE中有一种共享骨骼的技术, 可以支持, 不过从代码分析看来,这种技术对CPU端骨骼计算量实在是大的惊人. 因此我们决定将整个SubSkin(也就是SubEntity)换掉,这样由美术根据不同换装类型来将衣服在MAX中直接绑定好后直接替换原始模型中的SubSkin即可达到换装效果.可以说这是从动态计算到静态预处理的转变,效率提升很多.

HRESULT DrawIndexedPrimitiveUP(

D3DPRIMITIVETYPE PrimitiveType,

UINT MinVertexIndex,

UINT NumVertices,

UINT PrimitiveCount,

CONST void * pIndexData,

D3DFORMAT IndexDataFormat,

CONST void* pVertexStreamZeroData,

UINT VertexStreamZeroStride

);

这里假设我们要绘制一个由2个三角形组成的面,那么参数这样设置

MinVertexIndex = 0;

NumVertices = 4;

PrimitiveCount = 2;

pIndexData = { 0,1, 2, 0, 2, 3}

IndexDataFormat = D3DFMT_INDEX16

pVertexStreamZeroData = { 4个角的位置 }

VertexStreamZeroStride  = { 结构体的跨度 }

我们注意到, 没有任何一个参数用于描述CONST void * pIndexData的size 大小.

但其实你的图元是可以正确绘制的, 但是你并没有在indexdata后面加上例如字符串0的结尾副,那么D3D是怎么知道IndexCount呢?

我们先看下怎么根据VertexCount及 PrimitveType确定 PrimitiveCount

注: D3DPT_TRIANGLEFAN在以后的驱动中已经不再使用,因此不再采用

当使用索引缓冲时, VertexCount = IndexCount

因此在上例中 PrimitiveCount = IndexCount/3

也就是说 IndexCount = PrimitiveCount * 3

代入PrimitiveCount = 2,因此 IndexCount = 6

因此稳定的API的函数参数设计是绝不会浪费任何一个参数的

float4x4 matBoneArray[40]; //  这是传输的瓶颈

VS_OUTPUT vs_main( SkinnedVS_INPUT In )

{

    VS_OUTPUT Out = (VS_OUTPUT)0;

    float4x4 skinTransform = 0;

    skinTransform += matBoneArray[In.BoneIndices.x] * In.BoneWeights.x;

    skinTransform += matBoneArray[In.BoneIndices.y] * In.BoneWeights.y;

    skinTransform += matBoneArray[In.BoneIndices.z] * In.BoneWeights.z;

    skinTransform += matBoneArray[In.BoneIndices.w] * In.BoneWeights.w;

    float4 localpos = mul(In.Position, skinTransform);

    Out.Position = mul( localpos, matViewProj ); 

    Out.TexCoord = In.TexCoord;

    return Out;

}

matBoneArray这个数组是骨骼的LocalRot和LocalTranslation 通过以下函数build出来

    Matrix4& Matrix4::FromTranslationRotation( const Vector3& translation, const Quaternion& rotation )

    {

        float xx = rotation.x * rotation.x * 2.0f, yy = rotation.y * rotation.y * 2.0f, zz = rotation.z * rotation.z * 2.0f;

        float xy = rotation.x * rotation.y * 2.0f, zw = rotation.z * rotation.w * 2.0f, xz = rotation.x * rotation.z * 2.0f;

        float yw = rotation.y * rotation.w * 2.0f, yz = rotation.y * rotation.z * 2.0f, xw = rotation.x * rotation.w * 2.0f;

        m[0][0] = 1.0f - yy - zz; m[0][1] =        xy + zw; m[0][2] =        xz - yw; m[0][3] = 0.0f;

        m[1][0] =        xy - zw; m[1][1] = 1.0f - xx - zz; m[1][2] =        yz + xw; m[1][3] = 0.0f;

        m[2][0] =        xz + yw; m[2][1] =        yz - xw; m[2][2] = 1.0f - xx - yy; m[2][3] = 0.0f;

        m[3][0] =  translation.x; m[3][1] =  translation.y; m[3][2] =  translation.z; m[3][3] = 1.0f;

        return *this;

    }

从这里你可以发现, 本来每根骨头只需要2个float4 传递变换信息的,现在却需要4个float4,也就是一个矩阵来传递,矩阵中还有很多不使用的变量也被传输到GPU中,这里就是优化的点.

重新调整后的Shader代码:

float4x4 BuildFromTransRot( float4 translation, float4 rot )

{

    float4 rotation = rot;

    float xx = rotation.x * rotation.x * 2.0f, yy = rotation.y * rotation.y * 2.0f, zz = rotation.z * rotation.z * 2.0f;

    float xy = rotation.x * rotation.y * 2.0f, zw = rotation.z * rotation.w * 2.0f, xz = rotation.x * rotation.z * 2.0f;

    float yw = rotation.y * rotation.w * 2.0f, yz = rotation.y * rotation.z * 2.0f, xw = rotation.x * rotation.w * 2.0f;

    float4x4 m = { 

    {1.0f - yy - zz,             xy + zw,             xz - yw,         0},

    {xy - zw,              1.0f - xx - zz,             yz + xw,         0},

    {xz + yw,                      yz - xw,     1.0f - xx - yy,         0},

    {translation.x,       translation.y,       translation.z,         1}

    };

    return m;

}

float4x4 GetBoneElement( float index )

{

    return BuildFromTransRot( vecBoneLocalTrans[index], vecBoneLocalRot[index] );

}

VS_OUTPUT vs_main( SkinnedVS_INPUT In )

{

    VS_OUTPUT Out = (VS_OUTPUT)0;

    float4x4 skinTransform = 0;

    skinTransform += GetBoneElement(In.BoneIndices.x) * In.BoneWeights.x;

    skinTransform += GetBoneElement(In.BoneIndices.y) * In.BoneWeights.y;

    skinTransform += GetBoneElement(In.BoneIndices.z) * In.BoneWeights.z;

    skinTransform += GetBoneElement(In.BoneIndices.w) * In.BoneWeights.w;

    float4 localpos = mul(In.Position, skinTransform);

    Out.Position = mul( localpos, matViewProj ); 

    Out.TexCoord = In.TexCoord;

    return Out;

}

我们将骨头的local旋转及偏移传递至GPU,然后在GPU内重组,虽然对GPU性能计算有部分损耗,但是骨骼数量就能保守提高到100个.

http://isdlibrary.intel-dispatch.com/vc/1632/Threading_OGRE3D.pdf

ATI有关多线程效率提升的游戏比较及一些tips

http://developer.amd.com/assets/ATIMThread.pdf

CORE              DLL

ENGINE           DLL

GAME             EXE

D3DRENDER      DLL

其中D3DRENDER是GAME动态载入的，其需要链接CORE,ENGINE

这是一个很常见的模式，但是不好的是，因为CORE和ENGINE均是DLL，代码中的Symbol都被导出才可使用。任何人使用DEPENDENCE工具就可以将DLL中引用的东西查看的清楚，虽然这不至于造成技术泄漏，但从速度和DLL大小来说都是不划算的。

现在很多游戏主exe一般都是10M+甚至20M+的大exe，这都是使用静态链接而成。但是对代码结构也必须做出一定的调整。所有工程必须都是静态库，这样才能保证像CORE这样的静态库中的全局/静态变量不至于被链接2份而造成内存段逻辑错误。

当然，使用全静态库还需要注意一点：所有的lib都是在最后的game工程里来做链接。

UDK是unrealengine develpoment kit 的缩写，简单来说就是大名鼎鼎的虚幻３引擎的免费商业版本．不过虚幻３毕竟还是４年前的dx9的入门级引擎，在商业上取得
巨大成功，技术上也显得落后．目前Epic想榨干虚幻３的最后一点潜力，于是干脆发布了这个免费版本．任何人都可以用ＵＤＫ开发游戏，但是如果游戏牟利的话每年还是要向
Epic交纳一定数量的技术授权费用的．先不管这个，还是来看看它的官方视频教程吧．
　　[attach]44[/attach]
链接如下：　　
http://udn.epicgames.com/Three/VideoTutorials.html
一共５个教程　从引擎配置介绍开始，到关卡和人物编辑器，以及最后一个完整的小游戏的制作，对于入门来说完全足够了．
视频说的还比较详细，听力不好的同学可以对照下开发文档　http://www.udk.com/documentation　里面基本说的很详细．
最后附上ＵＤＫ的下载地址：　March 2010 UDK Beta (548 MB .exe)　
好了，ＵＤＫ对于初学者来说还是比较适合的．对于游戏的开发人员来说引擎的整体架构还是很值得学习的．希望你学的愉快．

OGRE的Compositor其实就是用于解决绘制PostEffect的，简单的说，就是一种RenderTarget的流程控制脚本

这是OGRE compositor文件的片段

compositor Bloom

{

    technique

    {

        // Temporary textures

        texture rt_output target_width target_height PF_R8G8B8

        texture rt0 target_width_scaled 0.25 target_height_scaled 0.25 PF_R8G8B8

        texture rt1 target_width_scaled 0.25 target_height_scaled 0.25 PF_R8G8B8

        target rt_output

        {

            // Render output from previous compositor (or original scene)

            input previous

        }

        target rt0

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BrightPass2

                input 0 rt_output

            }

        }

        target rt1

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BlurV

                input 0 rt0

            }

        }

        target rt0

        {

            // Start with clear texture

            input none

            // Horizontal blur pass

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BlurH

                input 0 rt1

            }

        }

        target_output

        {

            // Start with clear output

            input none

            // Draw a fullscreen quad

            pass render_quad

            {

                // Renders a fullscreen quad with a material

                material Ogre/Compositor/BloomBlend2

                input 0 rt_output

                input 1 rt0

            }

        }

    }

}

大概我们知道，一个Compositor分为资源定义与绘制步骤（target xxx）

而一个绘制步骤又分别定义：

1. （输入）绘制的是什么东西？

2. （效果）绘制成什么样子？

3. （输出）往哪里绘制？

输出方式在这个例子有2种：纹理（RT）和屏幕

输入方式有2中：纹理及场景

我们可以使用一个回调来对一个绘制步骤提供绘制输入

绘制效果就是一大堆的Shader，这些shader都是基于一个quad来做的，也就是一个矩形，使用变换后的顶点和一个纹理坐标作为顶点定义

不过这里是不需要做vertexshader的，仅仅ps足矣。

绘制的最后，是将前面绘制的RT（纹理）混合起来

当然，如果步骤比较多和复杂时，RT之间跟寄存器一样，可以反复使用

显示茶壶法线的场景加上 Blur 的PostEffect

<?xml version="1.0" encoding="gb2312" ?>

<Compositor name = "bloom" >

  <Resource>

    <RenderTarget name ="rt_source" size="screenquad" />

    <RenderTarget name ="rt0" size="screenquad" />

    <RenderTarget name ="rt1" size="screenquad" />

  </Resource>

  <Step target="rt_source">

    <Geometry type ="callback" callback = "rt_input"/>

  </Step>

  <Step target="rt0">

    <Geometry type = "screenquad"/>

    <Effect name ="material\blurH.xml">

      <Texture name ="mTexture" value ="rt_source" />

    </Effect>

  </Step>

  <Step target="rt1">

    <Geometry type = "screenquad"/>

    <Effect name ="material\blurV.xml">

      <Texture name ="mTexture" value ="rt_source" />

    </Effect>

  </Step>

  <Step>

    <Geometry type = "screenquad"/>

    <Effect name ="material\combine.xml">

      <Texture name ="mTexture1" value ="rt0" />

      <Texture name ="mTexture2" value ="rt1" />

    </Effect>

  </Step>

</Compositor>

同样适用我的文本设计图标准(+为包含,  <为派生)

RenderTexture

      RenderTarget

          <ScreenTarget(引擎启动时，初始化屏幕大小的Viewport)

          +RenderView (对于一个RT，可以是屏幕，可以是纹理RT，所以可以拥有 1~n个切分视图 )

               +Camera

               +Viewport

以下是多View绘制的类XNA伪代码

Engine.Run()

{

    Device.Clear()

    // 保存当前全屏Viewport

    ScreenViewport = Device.CurrentViewport

    Device.BeginScene()    

    // 遍历当前屏幕RT下的所有View

    foreach RenderView in ScreenRT

    {

        // 未激活的View不用绘制

        if RenderView not active then continue

        // 将View对应的Viewport提交到设备        

        RenderView.CommitViewport()

        // 渲染回调

        foreach RenderEventListener in RenderEventListenerList

        {

            RenderEventListener.OnRenderFrame()

        }

    }

    Device.EndScene()

     Device.Present()

    Device.CurrentViewport = ScreenViewport // 恢复全屏viewport

}

以下是RT间嵌套绘制的伪代码：

RenderView.SwitchRenderTarget(stage, RenderTarget)

{

    // 保存绘制前的RT

    PreTarget = Device.GetRenderTarget()

    // 设置为当前的RT

    Device.SetRenderTarget( RenderTarget )

    // 更新RT摄像机

    RenderTarget.UpdateCamera()    

    // 清空RT

    Device.Clear()

    // 绘制回调

    RenderTarget.OnRender( )

    // 恢复之前的RT

    Device.SetRenderTarget( PreTarget  );

}

我的矩阵定义跟OGRE的没什么区别

        union 

        {

            struct

            {

                float m11, m12, m13, m14;

                float m21, m22, m23, m24;

                float m31, m32, m33, m34;

                float m41, m42, m43, m44;

            };

            float m[4][4];

        };

   乘法也跟OGRE的一模一样，但在将view及project乘好的矩阵送给HLSL时，却必须转置下，才能得到正确的结果

mSkinnedEffect.mMatrix.mValue = (camera.mViewMatrix * camera.mProjectMatrix).Transpose();

shader:

float4 localpos = mul(In.Position, skinTransform);

    OGRE中有这么一段代码及注释:

    const Matrix4& AutoParamDataSource::getProjectionMatrix(void) const

    {

        if (mProjMatrixDirty)

        {

            // NB use API-independent projection matrix since GPU programs

            // bypass the API-specific handedness and use right-handed coords

            if (mCurrentRenderable && mCurrentRenderable->getUseIdentityProjection())

            {

                // Use identity projection matrix, still need to take RS depth into account.

                RenderSystem* rs = Root::getSingleton().getRenderSystem();

                rs->_convertProjectionMatrix(Matrix4::IDENTITY, mProjectionMatrix, true);

            }

            else

            {

                mProjectionMatrix = mCurrentCamera->getProjectionMatrixWithRSDepth();

            }

            if (mCurrentRenderTarget && mCurrentRenderTarget->requiresTextureFlipping())

            {

                // Because we're not using setProjectionMatrix, this needs to be done here

                // Invert transformed y

                mProjectionMatrix[1][0] = -mProjectionMatrix[1][0];

                mProjectionMatrix[1][1] = -mProjectionMatrix[1][1];

                mProjectionMatrix[1][2] = -mProjectionMatrix[1][2];

                mProjectionMatrix[1][3] = -mProjectionMatrix[1][3];

            }

            mProjMatrixDirty = false;

        }

        return mProjectionMatrix;

    }

貌似是跟左右手这个恶心的东西有关系

回看DirectXSDK中提供的BasicHLSL例子

        mWorld = g_mCenterWorld * *g_Camera.GetWorldMatrix();

        mProj = *g_Camera.GetProjMatrix();

        mView = *g_Camera.GetViewMatrix();

        mWorldViewProjection = mWorld * mView * mProj;

        V( g_pEffect->SetMatrix( "g_mWorldViewProjection", &mWorldViewProjection ) );

shader：

Output.Position = mul(vAnimatedPos, g_mWorldViewProjection);

丝毫无需转置矩阵,Effect接口中也提供有SetMatrixTranspose这类方法。所以排除内部有自动转置的嫌疑。

询问过野猪这个问题，野猪答曰:"转置后传输至需要传3个vector, 最后一个是[0 0 0 1]”

有达人知道的，可以指点下迷津 :)

MAX插件导出的模型资源分：Mesh/Skin, Skeleton, Animation

不同动作按照不同的动画文件保存

ResourceHandle 包含基本id
        >NamedResourceHandle 带有名称资源，包含hashA, hashB， 使用暴雪hash函数生成
        >ModelHandle       
        >MeshHandle           
        >SkeletonHandle       
        >AnimationHandle

获取资源，如果资源不存在时，自动加载
ModelMaster.ManualCache( &ModelHandle )

直接资源访问：
RawSkeleton = ModelMaster.ManualCache( &SkeletonHandle("a.skl") )
RawSkeleton->GetMarker(...)

异步资源加载，异步id保存于ModelHandle中，在callback中根据id确认
ModelMaster.AsyncCache( &ModelHandle )

获取资源指针，未加载时，返回空
ModelResource = ModelMaster.Fetch( &ModelHandle )

模型资源加载器
    在模型句柄中绑定对应加载器
    可以自行编写带换装的ModelLoader，通过读取自己的配置文件，自行加载资源后生成RawModel
ModelLoader
    ModelHandle         ---mapping--->    ModelLoader         ---generate--> RawModel
    MeshHandle          ---mapping--->    MeshLoader             ---generate--> RawMesh
    SkeletonHandle     ---mapping--->    SkeletonLoader      ---generate--> RawSkeleton
    AnimationHandle    ---mapping--->    AnimationLoader   ---generate--> RawAnimation

引用计数类   
ModelResource
    >RawModel
    >RawMesh
    >RawSkeleton
    >RawAnimation

RawModel中不保留Handle，只保留指针
RawModel
    +MeshVB    从模型文件中直接读取顶点格式，包含 静态,GPU,CPU类型顶点
        +RawMesh
        +MeshIB        一次性填充IB
        >GPUMeshVB    一次性填充VB
        >CPUMeshVB    每帧计算
    +Animation            运行期数据（时间/帧）
        +RawAnimation    原始动画内容
    +Skeleton
        +RawSkeleton

1. ASM Shader是最元老的也是DX8主要使用Shader

2. fxc编译器可以同时编译ASM,HLSL和fx脚本,其中HLSL和fx可以查看编译后的GPU汇编代码

3. D3D9中，fx是HLSL的一种渲染脚本，简化了HLSL设置及常量绑定，并且附带RenderStateBlock及设置

但只能用于制作简单的Shader

4. DirectXSDK中有一个概念混淆：C++例子中的BasicHLSL使用的其实还是fx，HLSLwithoutEffects例子才是真正的纯HLSL

5.fx与HLSL程序鉴别：

使用fx程序必定含有：D3DXCreateEffectXXX 系列函数， ID3DXEffect对象，渲染中能看到SetTechnique，BeginPass，EndPass之类的字眼

使用纯HLSL程序含有：D3DXCompileShader，ID3DXConstantTable对象，GetConstantByName，GetConstantDesc之类的字眼

6. 在fx中包含有 VertexShader，PixelShader代码及profile，entry，RenderState设置及简单的绘制过程(pass)。一次编译后，VS,PS,Texture,Sampler及常量都是在ID3DXEffect对象中自动完成，无需手动设置。

7. HLSL可以将VS及PS代码写入1个.hlsl文件。注意，以下这种代码可以在HLSL中编译过，但实际没有任何效果

   1:  sampler_state

   2:  {

   3:      Texture = <tex>;

   4:      MipFilter = LINEAR;

   5:      MinFilter = LINEAR;

   6:      MagFilter = LINEAR;

   7:  };

这点可以参考AMD RenderMonkey中只在shader中使用sampler而忽略texture。

8. fx中往shader设置纹理使用的是ID3DXBaseEffect::SetTexture下的这个函数

   1:  HRESULT SetTexture(

   2:    D3DXHANDLE hParameter,

   3:    LPDIRECT3DBASETEXTURE9 pTexture

   4:  );

但是在HLSL中，这点就变得很麻烦，需要手动设置，可以参考这篇文章

Shader代码片段：

   1:  sampler Samp0 = sampler_state

   2:  {

   3:      Texture = <Tex0>;

   4:      MipFilter = LINEAR;

   5:      MinFilter = LINEAR;

   6:      MagFilter = LINEAR;

   7:  };

编译HLSL代码后得到ConstantTable，然后取出句柄：

   1:  ScalarHandle = pixelConstTable->GetConstantByName(0, "Scalar");

   2:   

   3:  Samp0Handle = pixelConstTable->GetConstantByName(0, "Samp0");

   4:   

   5:  Samp1Handle = pixelConstTable->GetConstantByName(0, "Samp1");

再从句柄取出symbol的描述：

   1:  UINT count;

   2:   

   3:  pixelConstTable->GetConstantDesc(Samp0Handle, & Samp0Desc, &count);

   4:   

   5:  pixelConstTable->GetConstantDesc(Samp1Handle, & Samp1Desc, &count);

通过上面的描述，将纹理变量的寄存器偏移作为纹理的stage

8.  优化常量设置速度的方法一般就是根据字符串取出句柄，以后每次渲染时，只通过句柄设置。但ID3DXConstantTable最后还是通过

IDirect3DDevice9::SetPixelShaderConstantX 系列函数来实现的

   1:  HRESULT SetPixelShaderConstantF(

   2:    UINT StartRegister,

   3:    CONST float * pConstantData,

   4:    UINT Vector4fCount

   5:  );

9. HLSL将一段包含VS和PS代码编译完成后，将得到VS和PS两个单独的ID3DXConstantTable

最近在写D3D9模拟D3D10接口的渲染系统中碰到大量的渲染状态对象，不仅成员多，枚举也多的要命。

    struct CORE_API RasterizerState : ResourceHandle            
    {
        eFillMode            mFillMode;        
        eCullMode            mCullMode;
        bool                mFrontFaceCCW;
        float                mDepthBias;
        float                mSlopeScaledDepthBias;
        bool                mDepthClipEnable;
        bool                mScissorEnable;
        bool                mMultisampleEnable;

        RasterizerState();
    };

而要从配置文件中读取数据并填充到这个结构体，对于C++来说完全就是吃力不讨好的，写出来的代码也是极为过程，修改和扩展极为麻烦的。

因此决定使用反射的方法来填充数据，先总结一下我的C++反射系统

class RTTIObject // 动态类型识别对象基类，对象通过一些宏后可以很方便的通过字符串创建出类实例，并且可以查询注册时的类型和其他绑定信息
class NameRef  // 名字表，类似于虚幻中的FName，可以定义Const和普通Name，比较和拷贝只是一个dword耗费的时间
value_parse，value_tostring，value_typename // 一系列类型模板函数，提供对类型的ToString，Parse及类型名查询

首先需要处理的是枚举查询，这里将枚举通过宏做成一个个枚举对象，并可以通过名字创建实例

#define DECLARE_ENUMOBJECT( TEnum ) \
    struct EnumObject_##TEnum : EnumObject\
    {\
    DECLARE_RTTIOBJECT( EnumObject_##TEnum );\
    EnumObject_##TEnum( );\
    };


#define IMPLEMENT_ENUMOBJECT_BEGIN( TEnum, TEnum_prefixoffset, TMember_prefixoffset ) \
    IMPLEMENT_RTTIOBJECT_STRING( EnumObject_##TEnum, #TEnum + TEnum_prefixoffset, #TEnum + TEnum_prefixoffset, "EnumObject" )\
    EnumObject_##TEnum::EnumObject_##TEnum(){ const int member_prefixoffset = TMember_prefixoffset;

#define ENUMOBJECT_ADD( enumkey ) AddMember( #enumkey + member_prefixoffset, (dword)enumkey );

#define IMPLEMENT_ENUMOBJECT_END }

#define ENUMOBJECT_STATICINIT( TEnum ) EnumObject_##TEnum::StaticInit();

EnumObject 中通过宏将枚举的名称和值保存在这个对象中

IMPLEMENT_ENUMOBJECT_BEGIN( eFillMode, 1, 3 )  // 这里的1，3是将eFillMode及FM_Point转成字符串后去掉前缀
    ENUMOBJECT_ADD( FM_Point )
    ENUMOBJECT_ADD( FM_Line )
    ENUMOBJECT_ADD( FM_Fill )
IMPLEMENT_ENUMOBJECT_END

// 注册到RTTIObject系统

ENUMOBJECT_STATICINIT( eFillMode )

 

// 通过枚举对象可以查找到字符串对应的值
dword v;
EnumObject::GetEnumValue( "FillMode", "Point", v )

下一步是将结构体成员信息记录

    void SettingObject::BindMember( const NameRef& objname, void* instancePtr, void* dataPtr, SettingProxy* proxy )
    {
        proxy->mOffset = dword(dataPtr) - dword(instancePtr);

        MemberList& memberlist = mSettingMap[ objname ];
        memberlist[ proxy->mName ] = proxy;
    }

这里记录的是结构体成员的内存偏移

使用大量的宏，可以让结构体绑定变得漂亮

#define BIND_SETTINGOBJECT_BEGIN( TClass ) \
    { const NameRef& soname = TClass::StaticGetClassInfo()->mClassName;TClass soobj;

#define BIND_SO_MEMBER( TMemberType, TMember ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingElement<TMemberType>(#TMember + 1 ) );

#define BIND_SO_MEMBER_NAME( TMemberType, TMember, TName ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingElement<TMemberType>(TName) );

#define BIND_SO_ENUM( TEnumType, TMember ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingEnum(#TMember + 1, #TEnumType + 1) );

#define BIND_SO_ENUM_NAME( TEnumType, TMember, TName ) \
    so.BindMember( soname, &soobj, &soobj.TMember, new TSettingEnum(TName, #TEnumType + 1) );

#define BIND_SETTINGOBJECT_END }

绑定代码如下

        BIND_SETTINGOBJECT_BEGIN( RasterizerState )
            BIND_SO_ENUM    ( eFillMode    , mFillMode )
            BIND_SO_ENUM    ( eCullMode    , mCullMode )
            BIND_SO_MEMBER    ( bool        , mFrontFaceCCW )
            BIND_SO_MEMBER    ( float        , mDepthBias )
            BIND_SO_MEMBER    ( float        , mSlopeScaledDepthBias)
            BIND_SO_MEMBER    ( bool        , mDepthClipEnable)
            BIND_SO_MEMBER    ( bool        , mScissorEnable)
            BIND_SO_MEMBER    ( bool        , mMultisampleEnable)
        BIND_SETTINGOBJECT_END

所有结构体的信息被记录在SettingObject中，读取配置文件填充结构体的任务就变得异常的简单了

    SettingObject settings;
// 将所有的结构体信息记录
    InitRenderStateObjectSetting( settings );

    const NameRef& rzname = DepthStencilState::StaticGetClassInfo()->mClassName;

    DepthStencilState a;
 // 这里就是将配置文件的信息填充到结构体
    settings.SetMember( rzname, &a, "BackFace.StencilFunc", "Equal" );

1. 去掉Effect系统，改用HLSL + 渲染脚本

2. 优化渲染接口，使用材质统一shader和渲染状态

随即参考了DirectX SDK的Graphics部分文档：DirectX9 时代的Effect系统纯粹只是一个HLSL的简单渲染脚本实现，除了DXUT，FXComposer等极少程序使用这套东西外，大型的引擎很少使用这种半成品系统。到了DirectX10甚至11，因为架构更改，去掉固定管线，因此Effect成为较为高效和便捷的渲染脚本，如果不是要求较高的3d引擎，一般的游戏使用DirectX10的Effect渲染脚本还是很不错的。

DX10的fx脚本与DX9的差异在于

渲染状态，采样器状态等都变为对象，并与API高度统一

在脚本与API中均可以设置

DepthStencilState EnableDepth
{
    DepthEnable = TRUE;
    DepthWriteMask = ALL;
    DepthFunc = LESS_EQUAL;
};

BlendState NoBlending
{
    AlphaToCoverageEnable = FALSE;
    BlendEnable[0] = FALSE;
};

technique10 Render
{
    pass P0
    {

        SetDepthStencilState( EnableDepth, 0 );
        SetBlendState( NoBlending, float4( 0.0f, 0.0f, 0.0f, 0.0f ), 0xFFFFFFFF );
    }
}

本人觉得，这样的设计让图形API更为敏捷与归类化，另外，也便于StateManager或者自己做渲染状态转移及差异比较时更为高效

Vista操作系统推出很久后，DX10的显卡也占有了大量的市场份额。但是由于DX10仍然是一个过渡API（类似于DX8)，因此，很多3D游戏要么仍然支持DX9，要不然即支持DX9也支持DX10，甚至DX11.

   看博客上有达人组团编写类似DX10接口和系统的软渲染，DX10的设计是优秀的。因此，在DX9 HLSL基础上，结合自己编写的渲染脚本会是非常好的选择。

    渲染脚本我的设计思路是这样的：

1. 只是一种预处理脚本，并非实时运行脚本。

编译器将文本解析后，转化为一些运行指令，比如：本pass使用一块小纹理，下一pass的target是这个纹理，并且开启哪些渲染状态。

2. 自定义格式的解析脚本。

使用lua，python等脚本其实也是可以的。但是在出现错误时，报出的错可能会让不熟悉这个脚本语言的人莫名其妙。

使用松鼠sq脚本语言？可惜其在lua基础上，对table的slot初次赋值时必须使用<-而不是统一使用=，因此会让你的脚本稀奇古怪

XML脚本？ XML可以避免复杂的语法检查，写完就是归整的，但也是罗嗦的，本来Texture[2]可以表达完毕的，非要<Texture index = 2/>来罗嗦下。

OGRE的compositor脚本和材质脚本就是自己解析的，不过出乎预料的使用了BNF范式这类较为正规的方法。这就是说，需要先解析BNF表达式，然后再输入脚本解析，编写过程和系统复杂度会变得异常复杂。

最终选择还是使用自己解析的脚本，使用一些具体代码结构来替代BNF这类高深的东西

决定以后，下一步需要制定渲染脚本具体各部分及制作过程

1. 基本lexer

   从文本得到各种token

1. 渲染状态对象

   照着DX10抄就好

2. Shader导入口

     shader文件来自于何处，入口怎样定义

3. 渲染脚本VM及指令

  决定一个纹理怎样设置，RenderTarget怎样使用等的指令