[gdc13]《刺客信条3》渲染技术

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，特有用的地方不多，少用吧。

多和厂商联系。