gdc13上面的分享（可以在gdcvault上面查看），ubi和刺客信条无需介绍了。
由于是发展了多年的引擎，所以主要是介绍在这一代有什么进化，相当不错，实用性很强。
由于需要member身份才能看，所以我这里多截一些图好了。
天气
除了正常使用particle系统来做的天气效果以外，对于一些特有的效果，使用其他的方式可以更高效和更好的来做：
cylinder based effect
使用cylinder来做一些volumetric的效果.
height based fog
这个倒不是cylinder based的，就是普通的计算height fog， 但是里面有和阳光相关的参数：
雨：
近处是particle，远处是cylinder based scrolling uv 做的雨。
雪
只有particles
雨雪遮挡
可以看出此代console机能的无奈。
surface上的潮湿和积雪效果
- 根据normal的方向来进行积累和潮湿效果的调整
- 潮湿就调整gloss
- 积雪就是调整diffuse颜色
踩出来的雪的痕迹
这个是这代游戏的一个重要特性：
- 效果惊艳
- 影响gameplay--应该是可以根据这个来追踪
- 主角和动物都会有
- 地形是地形，上面的雪是有专门的雪的mesh
- 在做雪痕的时候，是把雪的mesh在index buffer上面做调整，中间挖出洞
- 补上一个displacement map+tessellated triangle做出雪痕的形状
- tessellation这部分比较直接，在可以r2vb的A卡上面可以直接做这个
个人觉得这个应该是为了lod来做，使用terrain渲染上面常用的geometry morphing应该也可以。
光照
早期的AC系列使用一个比较简单的lightmap，
左边是高度，右边是光照信息，这样的方式来记录光照，然后每个物件到这两个贴图中来sample获取光照信息。
品质上还是不太好，没有光的方向等信息。
那么改进版：
这个用法有点意思，的确不错，那个第二个贴图的HUE就是光的颜色亮度信息。
AO
原先ac使用bake在vertex上的ao，它的缺点也是比较多的：
- 内存消耗大
- 顶点数量很影响ao质量
新的ao方式是ssao+预处理的一个world ao
ssao的缺陷是很明显的：
- 产生ao的信息就是来屏幕空间能够反算出来的world position的很小一个范围，这个限制直接导致voxel cone tracing（link）产生的ao质量要好得多
ac的ao做法是：
本质上就是构建了一个非常简化的世界mesh的voxel信息，只是这个是在2d texture里面存的。
多人渲染
多人战斗阶段有上千人，城镇里面有300到400人，这样的规模如何在ps3/xbox360上达到？
- instancing， 32一个batch，把vertex buffer复制32份（内存消耗也是32倍）
- 这个应该主要是限制于console平台的原因，如果pc平台加vertex texture应该就不用去复制32份，不过需要instancing的也不会是很精细的人物，所以尚可
- 渲染阶段：
- 能r2vb就r2vb
- 360上面是cpu计算骨骼数据，然后vertex texture
- ps3上面使用spu直接算出最后skinning好的mesh
水渲染
基于的论文是tessendorf的经典论文（最开始用于泰坦尼克号的海水渲染，略晦涩：笔记）。
然后使用论文中的方法，来预计算3个频率的波：
水上的泡沫是每帧逐渐积累和消散的，在render target上面每帧做这个。
也是有高频和低频数据。
光照效果方面比较正常。
综合一下：
NodeBasedShaderSystem
就是unreal引擎那种连节点生成material的方式，ac使用了，但是其他项目使用ac引擎的时候都给去掉了。
这一块是图形编程方面争议最多的，有用的有不用的。
ac这里把争议部分列了出来。
对于我们，可能很多人看见unreal使用了，就觉得这个是更好的方式（或者说是最好的方式），但是其实应该说不是这样的。
这里首先是NodeBasedShaderSystem好的一面：
美术易于控制和创造效果，在创造prototype阶段，效率无可比拟。
商业引擎这样选择显然是更好的：不需要程序员进行深度介入的情况下，让项目组能够快速做出好的东西，否则一开始可能就没人去使用了。
在程序员可以深入介入的情况下，手写shader的比率还是相当高的。
然后就是不好的一面：
- 容易失控：效率，内存，复杂度
在使用这样的引擎的时候，如果自己肆意发挥，很容易导致严重的性能问题，在后期举步维艰。
这个就看团队的实力，尤其是程序员，TechArt对于资源的控制了，这还是可以搞定的问题，就像使用手写预制shader的灵活性问题也可以克服一样。
带着解决问题的态度，可能是两者结合是更合理的方法，使用NodeBasedShaderSystem，并且有程序员手写替代的功能，这样在prototype和效率上可以达到一个比较好的平衡。
DX11
首先到dx11，实际也就意味着是更强的平台，直接各种lod都拉高。
里面两大块比较特别：高质量的AO和阴影
AO是使用mssao（multi resolution screen space ao，在ssao基础上，加了多分辨率，这样就可以高效的取得更大范围内的ao信息）和hbao的结合体，起名字是：MHBAO。
在全resolution和1/2 resolution的使用mssao，在1/4 resolution上面使用hbao。
shadow
ac console版是poisson disc filter，在之前crytek一个ppt里面有提到。
但是这个在边缘就是比较花，这里ac使用了叫octagonal filter，其实是sample了更多的点，在lightspace里面以8角的方式移动，加上lightview camera本身就是会有snapping按照texel为单位移动，所以这个做出来就是更加平滑稳定，sample数量达到了25tap：
关于dx11的建议：
一顿大实话，概括起来就是dx11好像没什么用，但是ac似乎在dx11上面开展的不多，大杀器direct compute没有提根本。
deferred context由于是driver控制，不如是dx9上面自己做多线程的方式可控性高，效率更好一些。
d3d query，各个厂商实现不同，一种显卡上ok，另一种上面就跪了可能最好不要用太多
tessellation，特有用的地方不多，少用吧。
多和厂商联系。
