发一下牢骚和主题无关：
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方法是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和阴影
在全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，特有用的地方未几，少用吧。
多和厂商联系。
文章结束给大家分享下程序员的一些笑话语录：
开发时间
项目经理: 如果我再给你一个人,那可以什么时候可以完工?程序员: 3个月吧!项目经理: 那给两个呢?程序员: 1个月吧!
项目经理: 那100呢?程序员: 1年吧!
项目经理: 那10000呢?程序员: 那我将永远无法完成任务.
