ShaderX4的这篇文章主要将的是在设计一个用于的实时绘制Render的时候，如何处理渲染状态的问题。

在渲染中，尤其是多PASS的渲染中渲染状态的管理是一个很重要的议题。由于渲染状态的切换回影响到绘制的效率，所以人们想了很多的方法来尽量减少渲染状态的切换。文中提出，考虑到D3D API调用的开销以及D3D API和GPU Driver的开销，将渲染状态的Restoring操作放到了Fx中进行。通过在fx中添加一个额外的pass，这个pass不渲染任何几何体只进行渲染状态的设置。例如：

    technique tec20 {

        pass POpaque {

            VertexShader = compile vs_1_1 vsMainOpaque();

            PixelShader = compile ps_1_1 psMainOpaque();

            AlphaTestEnable = True;

            AlphaFunc = Greater;

            AlphaRef = 250;

        }

        pass PAlpha {

            VertexShader = compile vs_1_1 vsMainAlpha();

            PixelShader = compile ps_1_1 psMainAlpha();

            AlphaTestEnable = False;

            ZWriteEnable = False;

            AlphaBlendEnable = True;

            SrcBlend = SrcAlpha;

            DestBlend = InvSrcAlpha;

        }

        pass PRestore {

            AlphaBlendEnable = False; // restore alpha blend to standard value

            ZWriteEnable = True; // restore z write to standard value

        }

    }

紧接着，作者花了比较长的笔墨来阐述哪些渲染状态是经常改变的哪些是基本不变的等等。说着写的目的就是为了做一个分类，确定哪些渲染状态是需要在fx文件中使用一个多余的pass还原渲染状态的。

在ShaderX6的一篇文章：A Flexible Material System in Desgin中也有提到关于将渲染状态分类的内容。

接下来，作者阐述了使用上述方法的一个实现思路：那就是引擎读入fx文件后，分析该fx做了哪些渲染状态的改变，然后找出在下一个pass渲染前有哪些渲染状态是需要Restore的。最后动态将需要Restore的渲染状态写到一个新增的pass中去。分析fx中有哪些渲染状态改变的方法可以使用DXSAS语法。

那么如何将一段动态生成的pass代码塞入到已有的fx中去呢？作者提出的方法是使用Effect框架的宏。也就是说，以上面的fx代码为例，在书写fx的时候，这么写：

    technique Foo {

        pass P1 { ... }

        pass P2 { ... }

        RESTORE_PASS

    }

其中RESTORE_PASS是一个宏，这个宏的内容是动态设置进去的，作者利用了D3DXEffect的这样一个特性来进行动态代码的生成。不过这个方法的缺点是需要将fx载入两次，因为必须在创建Effect的时候就将宏提交给D3DX API。

管理渲染状态的另一个有效的方法是，使用D3DX提供的一个接口ID3DXEffectStateManager，使用这个接口需要派生该接口并实现相应的虚函数，就可以在派生类中记录状态切换的的次数以及根据现有的状态进行是否需要进行渲染状态的更改的决策。我依稀记得D3D SDK的Sample中就有一个关于State Manager的示例，有兴趣的朋友可以Check一下。

文中最后提到将渲染物体分类的话题，将渲染物体分类确保使用相同Effect的物体可以不需要切换fx代码渲染。同时文中也给出了一个“准泛型”的设置Shader常量的方法，使用一个对象记录一个fx中的变量名（或者handle）和实际的引擎的值的关系，然后使用这个对象统一设置shader的常量。

在ShaderX3中有一篇文章：Effect Parameters Manipulation Framework，方法和上述如出一辙，不过讲的更加详细一些。另外关于设置Shader常量的文章在ShaderX5中有一篇Transparent Shader Data Binding，不过我认为这篇文章更多的是一篇关于C++函数指针的文章，中心思想是使用C++中的联合进行类型转换，看上去有点像观察者模式的实现。从表面上分析为fx的shader常量设置值的过程很像是设计模式中讲到的观察者模式，但是我认为和观察者模式有一个很大的不同，那就是不管在一帧当中不管fx的shader常量有没有发生变化都要进行shader常量的设置，不能说摄像机的位置没有发生变化就不设置了。所以反正在每帧会之前都需要进行绘制，那么不如老老实实在绘制前统一的进行各种SetXXX调用，这样也利于调试也不会出现编译器的差异的问题，虽然我也承认ShaderX5的那篇文章提到的方法很美丽，不过我实在是没有能够在设计的时候找到需要用到该技术的位置。

到此，文章结束。纵观全文，作者的思想是建立在设计一个基于fx文件驱动的引擎。这个引擎的特点是基于一堆写好的shader的基础上的。在渲染状态管理方面，作者将渲染状态Restore的工作交给了GPU来进行，同时通过实现ID3DXEffectStateManager接口将多余的渲染状态设置过滤掉。这个方法看上去似乎很好但是，假如2个物体接受相同的光照，有相同的纹理只是因为一个是透明的一个不是透明的，那么渲染这2个物体就需要使用2个不同的fx文件，这就意味着向GPU提交了2次fx代码，而这个消耗肯定比D3D API的消耗要大。如果把渲染状态全部放在CPU端管理，通过D3D API来设置，那么就能够最大限度的将材质差不多的物体使用一个fx代码来渲染。

以上只是我的浅薄的看法，如果有不同的看法欢迎留言。如果想看这篇Paper的朋友可以去http://aras-p.info/texts/d3dx_fx_states.html，这是同一个作者写的这篇内容几乎和ShaderX4上的这篇内容一模一样，只有少许差别。

另外，作者也提供了他的一个引擎的源码，地址是http://dingus.berlios.de/

其中包含了上述思想的详细实现，代码可读性很强。

似乎经常有人被这个问题转晕。向量有两种表达形式，行向量和列向量，对应的矩阵也有行矩阵和列矩阵。采用哪种形式和左右手系无关。

下面按照文中的章节标题进行摘要性的叙述：

Assigning Shaders to Geometry

　　文中提到，将物体的shader分成2种，一种是静态物体的材质例如毛皮，凹凸等等，一种是动态环境例如动态光影，体积雾等等。在进行动态shader的计算的时候如果动态环境是具有体积效果的话，需要找出受动态环境影响的可渲染物的集合。

Rendering Order

　　文中将渲染基本的纹理贴图和静态光照称为Base Pass。将其他的动态效果或者是其他shader的渲染称之为Effect Pass。

　　在进行渲染的时候，常识是先进行不透明物体的渲染，再进行透明物体的渲染。但是在多pass渲染的情况下这个方法就不那么灵验了。多pass的情况下使得渲染顺序的复杂度剧增，为了解决这个问题，并能够协调诸如钩边，体积雾等技术，文中提出了以下解决方法：

Code
 1void RenderLoop3()
 2{
 3  RenderEffects(OPAQUE,PRE_BASEPASS);
 4  RenderBasePass(OPAQUE);
 5  RenderEffects(OPAQUE,POST_BASEPASS);
 6
 7  RenderEffects(TRANSLUCENT,PRE_BASEPASS);
 8  RenderBasePass(TRANSLUCENT);
 9  RenderEffects(TRANSLUCENT,POST_BASEPASS);
10}

 　　将Effect Pass的渲染分为了Pre-Base Pass和Post-Base Pass。例如要进行卡通渲染的钩边，常用的做法是在VS中根据normal进行，这一步放在Pre-Base中进行。而使用Blend方式的渲染动态光源则放在了Post-Base Pass中进行。有时候在同一个阶段可能会存在多个需要渲染的pass，例如动态光照和体积雾的渲染，都是放在Post-Base Pass中进行，这个时候可以给shader加上一个sort key，这样就可以保证体积雾的绘制始终在动态光照绘制之后进行。

shader callback functions

 　　文中提到，在进行每帧渲染前以及每个批次的几何体渲染前分别提供回调函数，以进行渲染前的最后修改。这点倒是和Gamebryo的实现很像，Gamebryo的Render系统的设计中也是提供了这样的一组回调函数，用意也和本文观点一致。

　　文中举出了2个使用回调函数的例子，一个是进行光照渲染的时候，使用回调函数计算几何体受哪些光影的影响，另一个例子是在渲染毛皮的时候，使用到摄像机的距离选择毛发的shell长度。

Reducing Overhead for State Setup

 　　为了减少渲染状态的切换，文中提出的方法有：对透明以及不透明物体进行排序；在shader对象中提供接口，能够查询shader使用了哪些特殊的纹理，例如光照贴图，法线贴图等等，对这些使用特殊纹理的shader设置需要的渲染状态，否则不进行渲染状态的绘制。另外再进行渲染状态设置前，查询当前的渲染状态，如果和要设置的状态一致的话，就不进行API的调用，毕竟调用改变渲染状态的API耗时还是比较多的。

 Texture

　　文中提到，为了灵活的使用程序生成的纹理（CPU端生成的过程纹理）和通过美术制作的纹理，使用另一种叫做纹理修改器的技术，纹理修改器是一个函数，接受一个纹理，然后通过某种算法将纹理中的像素转化为想要的效果，例如转化为灰度图，添加alpha通道等等。纹理修改器提供给了使用引擎的人一定的灵活性，用户可以自定义修改器，来进行纹理的修改，在某些运行时的情况下，这种功能是很方便的。

inline DWORD F2DW( float f ) { return *((DWORD*)&f); }

m_pD3DDevice->SetRenderState(D3DRS_SLOPESCALEDEPTHBIAS, F2DW(1));

m_pD3DDevice->SetRenderState(D3DRS_DEPTHBIAS, F2DW(0.001));

总之，奇怪的api。

　　planar shadow通过一个矩阵M将物体的每个顶点“压扁”，矩阵M的推导过程在http://www.cnblogs.com/Pointer/archive/2004/07/26/27305.html以及http://www.csie.ntu.edu.tw/~r89004/hive/shadow/page_1.html中有很详细的过程。思想是，已知一个顶点Q和投射阴影的方向K以及接受阴影的平面L，求Q点被光线K投影到L上的点P的过程。

Instancing 渲染

在渲染重复的顶点数目很少的小物体时，使用Instancing渲染方法能大量减少对绘制函数的调用，从而达到提高效率的目的。在GPU GEMS2中以及DX9 SDK的Sample中对该方法有详细的描述。

在GPU GEMS2中将Instancing渲染技术分成了4个种类：

l 静态批次

l 动态批次

l 顶点常量实例化

l 几何体实例API批次

书中对4中技术阐述的十分清楚，以下只针对DX SDK中的Sample中的三种做法进行叙述。

Stream Instancing

Stream Instancing使用2个VB Buffer，1个IB。一个存放数据的顶点，一个存放所有实例的属性。以绘制1000个立方体为例，一个VB存放一个立方体24个顶点（6个面，每个面4个顶点），一个IB存放36个索引（6个面，每个面2个三角形，每个三角形3个顶点）。另外一个VB存放所有1000个立方体的实例数据，包括：颜色，位置，方位角等等。

设置好各个Buffer后即可渲染。渲染的时候一次只能渲染一个立方体，每次DrawIndexedPrimitive之前都需要调用SetStreamSource设置实例在第二个VB中的偏移量即可。显然对于每个物体都调用DrawIndexedPrimitive的做法肯定对效率影响很大。

这种方法算是一种比较静态的方法，不过和GPU GEMS2中的静态方法不太一样。GPU GEMS2中的静态方法只使用一个大的VB和一个大的IB，这个VB中存放转换好的几何实例信息，IB中存放每一个实例的索引，然后使用一个DrawIndexedPrimitive绘制出所有的几何体。这种方法需要耗费大量的储存器且不能支持骨骼运算，对CPU的消耗十分的大。

Shader Instancing

Shader Instancing需要一个大的VB和一个大的IB以容纳所有的实例的顶点和索引。另外几何体实例的所有信息存放在系统的内存中。和前面的方法不同的是，并不需要在创建VB的时候将几何体实例的信息Lock到VB中去，而是在渲染的时候通过顶点常量传递进去。由于顶点常量的个数有限，所以一批几何体可能需要渲染几次才能全部完成。

这个方法和GPU GEMS2中的顶点常量实例化的方法很相似，不过由于GPU GEMS2中的这个方法将所有的顶点常量拿来做Instancing运算，无法进行骨骼运算。为了解决这个问题DX SDK中的Sample中并没有使用全部的顶点常量。

HW Instancing

这种方法是DX SDK里面强烈推荐的方法，不过需要硬件支持vs3_0。前面2种方法都只是需要硬件支持vs1_1即可。

HW Instancing的方法和前面说的Stream Instancing的方法如出一辙，所不同的是，HW Instancing使用了DX SDK提供的API：SetStreamSourceFreq()。通过这个API，就可以不需要在渲染的时候指定实例在VB中的偏移量，所以使用这个方法可以自动的将所有的实例使用一个DrawIndexedPrimitive绘制完毕。

     随便用搜索引擎在网上找了下，基本上没发现关于球面环境贴图的内容，本来想找个简单的shader直接来用的，没想到的是找了半天也没找到，于是只能自己动手写了。以下文章是我参考了一些资料加上我自己的理解写成的，如果有错误的地方还望大家指正。

     环境映射是一种近似，它基于这样的假设：相对于光洁物体的大小而言，环境中的物体离光洁物体很远，也就是说，将一个很小的光洁物体放在大房间中。对于物体表面上的点，假设有一条从眼睛到该点的光线，这条光线被反射出去的方向决定该点的颜色。在一个二维纹理图中对各个方向的颜色进行编码，相当于将一个光洁度非常高的球体放在环境中央，然后在很远的地方用带长焦镜头的相机拍摄球体。从数学上说，镜头的焦距为无限长，相机位于无穷远处。因此，需要进行编码是纹理图的内切圆形区域，该圆形区域外的纹理值没有影响，因为进行环境印射时没有使用它们。（摘抄自OpenGL红宝书）

     根据这段来自红宝书中的文字，在一个环境中生成球面贴图的时候，由于环境相对于球体而言无限大，所以可以把球体看成是一个单位球体。同时，有由于相机位于无限远处，所以相机到球体上的各个点的向量可以看成是相互平行的。

     于是很容易的想到：

     1、生成视线向量V。

     2、根据顶点法线生成反射向量R。

     3、查找R和球面的交点。

     4、根据交点求出UV坐标。

     R可以很容易的求出。为了求出UV，需要求出R和球面的交点E在球面的位置。这个时候回到生成球面纹理图时候的场景，由于球面是单位球面，利用单位球面的一个性质：球面上的点的归一化法线就是该点在球面上的位置。

     我们只需要知道在生成球面纹理图的时候，在球面上相同的点，当反射向量也为R的时候该点的法线为多少即可。

     根据向量加法原则，法线是视线向量和反射向量的和。为了模拟视点位于无限远处的情况，可以假象生成球面纹理图的过程是位于View Space，这样的话，Eye Vec就总是(0,0,1)。于是只需要把反射向量也转化到View Space就可以得出球面的法线向量。

     还剩下最后一个问题，求出来的法线每个分量的值域是[-1,1]，而uv要求的值域是[0,1]，所以需要转换一下。以下是关键的VS代码片段：

Code
 1  //world normal 
 2 
 3    float3 normalWorld=OUT.WorldNormal; 
 4 
 5    //world space eye vec 
 6 
 7    float3 eyeVecWorld=OUT.WorldView; 
 8 
 9    //world reflect vec 
10 
11    float3 reflectWorld=reflect(eyeVecWorld,normalWorld); 
12 
13    //eye space relect vec 
14 
15    float3 reflectView=mul(reflectWorld,matViewIT); 
16 
17    //unit sphere normal in view space 
18 
19    float3 SphereNormal=float3(0,0,1)+reflectView; 
20 
21    SphereNormal=normalize(SphereNormal); 
22 
23    float2 newUV=SphereNormal.xy; 
24 
25    newUV.x=newUV.x*0.5+0.5; 
26 
27    newUV.y=newUV.y*0.5+0.5; 
28 
29    OUT.UV=newUV; 
30 
31 

     后记：写这篇文章以前，我参考过DirectX SDK中文档的内容，文档中说，只需要把顶点的法线转换到Camera Space然后除以2加上0.5即可。我使用这个方法在FxComposer中实验，没有得到正确的结果，我不知道是否是哪写错了。SDK的文档中也没有详细说明这个方法的来龙去脉，不知道有没有知道的朋友。

2、如何使用dotnet 的ListView? 

声明： dotNetControl lv_objects "System.Windows.Forms.ListView" pos:listBoxPos width:485 height:459

添加项：      

      local li = dotNetObject "System.Windows.Forms.ListViewItem" (submat.MaterialName)
      li.ImageIndex =0
      lv_objects.Items.Add li

on lv_objects DoubleClick arg do
 (
  --取0是因为不允许多选 所以直接取0
  local doubleItemIdx=lv_objects.SelectedIndices.item[0]

     ... ...
  )

关于IGame

IGame是Max提供给游戏开发的一个用于导入导出的接口。在Max的help里面这个东西叫做3ds Max Data Exchange Interface。有了这个接口，可以大大的简化导入导出工作的工作量。

如果有经历过用MAX SDK导出关键帧动画以及骨骼动画，Skin，Modifier等等的经历的话，我想肯定会记忆深刻。IGame的作用就是把复杂的Max的概念简化，封装。

建立IGame:

IGameScene * m_pIgame= GetIGameInterface()

坐标系：

前面我提到的导出的文章都没有提这个问题，所有的坐标都是用的MAX本身的坐标系，及Z轴向上。在游戏中坐标系可能千奇百怪，IGame考虑到这点提供了指定坐标系的功能：

IGameConversionManager * cm = GetConversionManager();

cm->SetCoordSystem(IGameConversionManager::IGAME_D3D);

m_pIgame->InitialiseIGame(true);

其中IGAME_D3D就是指定的坐标系，同样也可以自定义坐标系：

  UserCoord WhackySystem = {

     1,   //Right Handed

     1,   //X axis goes right

     4,   //Y Axis goes in

     3,   //Z Axis goes down.

     0,   //U Tex axis is left

     1, //V Tex axis is Down

   };  

   IGameConversionManager * cm = GetConversionManager();

   cm->SetUserCoordSystem(WhackySystem);

IGame要点：

GetTopLevelNodeCount：获得顶级的Node数目，不包括Root。

GetRootMaterialCount：获得所有的材质数目

GetTopLevelNode(i)：获得指定Node

GetIGameObject()：获得Node中包含的Object

GetLocalTM()：获得Node的矩阵

IGameMesh ：：GetVertex(i)：获得顶点

IGameMesh ：：GetFace(i)；获得面

IGameMesh ：：GetNormal(i)：获得法线

至于其他就依次类推了，从函数的命名，到概念的简化，无疑都比原始的MAXSDK进步了很多。有了IGame接口，大大减轻了程序员的负担，我相信没有哪个愿意把大把的时间花在数据的导入导出上。

花了几十分钟简单的试用了一下IGame写了个小小的导出插件，只导出了顶点，面，材质，法线以及矩阵，感觉基本上没什么阻碍。不过IGame最大的功能还是用在骨骼动画，关键帧动画上面，仅仅只是简单的几何体导出并不能体现出IGame的功效。

最后还是附上代码和工程吧。不得不提示一下，由于种种曲折的原因，我这个工程是在MAX8 SDK和 MAX8下 完成的，其间省略上千字曲折的经历，不过在MAX9下应该可以通过编译。编译完成后，记得在Max 中选择Export Selected而不是试用Export。