老久没更新，发点吧，让前面一篇降下去。

    * 在D9下，SetStreamSource/DrawIndexedPrimitive，这几个参数的意思，久了经常忘记。
    OffsetInBytes: 设置VB的数据从哪一个位置开始，即IB里的第0个顶点，从这个地址开始算起。
    BaseVertexIndex: IB里的每个索引，加上这个数值，比如设置了2，则IB里的5会变成7。。。不太常用，但有时候会有意想不到的作用。
    MinVertexIndex: 告诉D3D，使用到的顶点从VB里的第几个开始，设置之后，对渲染无影响，只是帮助D3D在某些时候改进性能。。。
    NumVertices: 告诉D3D，本次DP，用了多少个顶点，设置之后，对渲染无影响，要注意的是这个跟MinVertexIndex没啥关系，并不是从MinVertexIndex开始算起的，只是帮助D3D在某些时候改进性能。。。
    startIndex: 与OffsetInBytes类型，设置IB的数据从哪一个开始读起。

    * Cry的地形并不是用一张图来算每一层的Alpha，而是用顶点中的color的256级来表示，每一个数值表示一个层。因此它不能表示半透明的层，只能在边缘1格的地方由1降到0。

    * D3DFORMAT MAKEFOURCC('N', 'U', 'L', 'L')格式的Target并没有必要设置成1x1(cry中是这么搞的)的大小。这个target无论多大，都不会消耗显存，并且draw的时候写入的像素也是0，速度也没啥变化。

    * 简易骨骼动画：

    Mesh当前帧顶点 = Mesh绑定时顶点 * 绑定时骨骼的变换到本帧骨骼的变换的改变量。

                           = Mesh绑定时顶点 * 绑定时骨骼的变换的逆矩阵 * 本帧的骨骼变换。

                           = Mesh绑定时顶点 * 绑定时骨骼的变换的逆矩阵 * 本帧的骨骼相对父节点的变换 * 本帧父骨骼的变换。

    其中，

    Mesh绑定时顶点：由Max导出。

    绑定时骨骼的变换的逆矩阵：从Max的Skin Modifier的GetBoneInitTM中取得(或者Physique Modifier的GetInitNodeTM中取得)矩阵。

    本帧的骨骼相对父节点的变换：从Max的骨骼的NodeTM和父骨骼的NodeTM得到，注意对于行矩阵，矩阵顺序是 ParentToChild = ChildToWorld * Inverse(ParentToWorld)。列矩阵则相反，根节点则直接保存NodeTM即可。帧之间的插值也主要是对这些数据做插值，在两帧之间没有很大变化的时候，四元数加向量和矩阵视觉上并没有很大差别。

    本帧父骨骼的变换：由前面从根节点累加。

    * deferred shading中light画volume的简单方法。
    眼睛在volume外，用CCW直接画volume；眼睛即将进入volume或在volume中时，用CW画，并且将volume轻微放大一些包含住camera。除了修改下cullmode，渲染流程完全不用变。

    * CSM中，如果shadowmap用atlas放到一张图中的时候，比如4个slice放到一张图的时候，计算shadow receive时，可以用一张很小的(64x64)的图，来选择slice的UV。比直接计算快。

    http://advances.realtimerendering.com/。crytek总是能发现一些别人没发现的东西。

之前我也发过http://www.cnblogs.com/linyizsh/archive/2009/05/30/1492314.html

说过些packnormal的东西。但是从直觉上，无论哪种方法，总是觉得不怎么完美，一个是计算量太大，

一个是存储bit数太多，如果使用类似deferred lighting的方式，存深度，normal和specular power，

如果希望只用64bit来存，在pc d3d上不考虑扩展情况下，深度通常32bit不可少(当然16bit不是不可以，就像sc2

，但是sc2情况特殊，它没有太远的场景，500米内，16bit通常够用，但是如果希望能够看到更远，16bit

就不够了，如果做ssao之类深度效果，在远处影响就很大)，剩下normal和specularpower，specularpower

至少也要8bit，剩下24bit给normal，如果按之前的pack方式，这是很难的，直接存取更不用说，质量太差。

    无数人做过无数方法去弄这个pack问题，但是都忽视一个非常简单的问题，24bit能够存的是一个volume，

有256*256*256个可能的值，直觉上这么多的值，应该是可以保证精度才是，为什么直接存却不行呢，因为

pack都是按照normalized之后的向量去pack的，相当于xyz的关系是确定的，这些xyz构成的是一个球面，

这样给自己下了一个限制，这个球面的空间占这个volume的比例还不到2%。。。浪费了其它n多的空间，精度

当然是相当低的，best fit的方式就是利用这些空间，先把所有256*256*256的各个方向的

向量长度bake到一个图里，去掉对称的和重复的，之后放入一个2d图里。在生成gbuffer的时候，通过normal来查找到

最接近的texel，也就是找到对应的向量长度，然后直接将这个长度的normal，scale到0-1就行了，使用的时候只要scale

回来，然后normalize一下就可以了，可谓方便之极，完全可以到处使用。

    这种方法给存储normal指了另一条明路，如何来利用这256*256*256个值，crytek的方式感觉上还是有些麻烦，

压缩normal的过程在ps3.0下需要18条指令，也许以后还有更简单的方式。

    个人觉得，只有normal能够存入24bit并保证精度，deferredlighting才能真正比较实用，best fit的方式应该是最好的

办法了。

一个容易疏忽的问题。

图：

    模型的边缘有个碍眼的白边，这个是由于计算水下的caustic的时候用了深度来计算某个tex的uv，结果产生这个白边。(图压缩后变难看了。。。)

这个不是算法错，也不是什么数据问题。而是由于使用的tex带有mipmap，但由于uv从深度算来，因此在ps里，边缘相邻两个像素的uv有个跳变，使gpu在这个地方出现lod计算错误，因此取了一个错误的值。

    解决的办法有两个，一个是自己计算lod，可以通过采样边缘的像素，在xy方向选深度差最小的那个相邻像素来计算ddx ddy。

另一个办法是tex如果尺寸比较小的话可以不要用mipmap，总是用0层，则不会出现问题。

解决后的图：

    这个问题其实存在的地方并不少，只要使用有突然跳跃的数值(比如这里的深度)来计算mipmap tex的uv，则都有可能会出现，不过有些情况下这个问题不太明显。

不解决其实也没啥问题，作为游戏来讲用户也不一定注意，所以这个问题也容易被疏忽，不过如果追求完美的图像的话，就总觉得有些别扭。

    试了mlaa，后处理的aa。

    最初的文档是intel发布http://visual-computing.intel-research.net/publications/papers/2009/mlaa/mlaa.pdf，只有cpu实现。

    后来有人做了gpu版本http://igm.univ-mlv.fr/~biri/mlaa-gpu/，有篇paper，不过跟没有差不多，似乎还有个siggraph的talk，但是网上找不到，总之这个版本

有一定的简化，Z shape简化为L shape。不过对于一般游戏来讲效果已经足够。

    mlaa应该是后处理方式的aa，能达到的最好的效果了，越来越多的游戏用了这个东西，包括战神3，不过它用的是ps3的spu。

    我刚开始看上面那个gpu版本被他那些flag弄迷糊了。于是自己根据intel那个山寨了一个，回头再来看终于容易多了。。。

    gpu实现，不过在我的垃圾显卡(9400)上要花将近10ms，相信在最新的机器上应该可以勉强跑的起来，因为效果确实不错。

    先看看效果，上面没开，下面开：

对比可以看到，下面的边缘平滑的非常好，而且对于整体的颜色粗糙部分也有一定的改善，但这种改善会造成原有的信息有一些偏差，不过对于游戏通常这个偏差可以忽略。

过程如下：

首先第一步生成边缘图，红线是横线，绿线是竖线，那个gpu版本是将颜色转换到lab空间判断，我这里直接用rgb分别判断：

第二步分别生成横线和竖线的长度信息，我没有按照上面那篇gpu版本的方法分level做，而是直接做几次循环来取：

然后根据上面几张图判断shape类型，生成上下左右四个像素的比例图：

最后一步就blend到最终target上，也就是上面的效果了。

    虽然mlaa目前来讲耗的时间还是比较多，但是在延迟渲染上，比起硬件msaa和ssaa(supersample)，还是要快很多，估计以后应该会有些变形，提高些速度。

    mlaa对于边缘的过滤非常漂亮了，但是缺点是由于是后处理，因此在光栅化的时候丢弃的信息就无能为力了，比如屏幕上的断断续续的细线之类。