效果信息[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，特有用的地方未几，少用吧。

    

多和厂商联系。

    

    

文章结束给大家分享下程序员的一些笑话语录： 开发时间
　　项目经理: 如果我再给你一个人,那可以什么时候可以完工?程序员: 3个月吧!项目经理: 那给两个呢?程序员: 1个月吧!
项目经理: 那100呢?程序员: 1年吧!
项目经理: 那10000呢?程序员: 那我将永远无法完成任务.