【译】Capcom 自研引擎 Panta Rhei在CEDEC2014上的会议报告

原文：http://www.4gamer.net/games/032/G003263/20140911067/

作者：西川善司    翻译：Traceyang

2014年9月2日，在日本最大的游戏开发者会议「CEDEC 2014」上，Capcom进行了主题为「『deep down』的图形表现的技术解说」的演讲，本文是对Capcom的三嶋 仁氏和阿久澤陽菜氏的演讲概要进行介绍

  另外，这个演讲在CEDEC 2014时说是禁止采访的，不过CEDEC事务局方面的误解了，所以就可以报道了。本文也是经过了Capcom方的谅解和同意后得以发表。

  三嶋 仁氏 Capcom 技术开发室 程序员    阿久澤陽菜氏 Capcom 技术开发室 程序员

Panta Rhei以及deepdown的简介

   Capcom是日本比较早就着眼于游戏引擎的重要性的，并致力于积累自家技术和原创引擎开发的游戏公司。在PlayStation 3&Xbox 360时代，Capcom开发了适合自己游戏品牌开发的游戏引擎MT Framework，最终的对应范围扩大到Wii,PS Vita,和任天堂3DS。最初，MT是定位给Capcom内制项目专用的，因为有游戏开发效率和高性能的评价，外包工作室的项目也可以使用了。

    接下来，Capcom面向PlayStation 4&Xbox One的新引擎项目从2011年开始，和预想的、相反，不仅MT Framework的新版本使用了全新名字 「Panta Rhei」（万物流转的意思），完全新规格开发的引擎也在2013年发布，使得业界震惊。 

    从MTFramework架构革新的Panta Rhei引擎，因为Content开发管线大改，所以MT Framework的兼容性也放弃了，Capcom是打算让Panta Rhei开发的游戏一气提升吧

    作为与「次世代游戏引擎」对应的Panta Rhei，基于它的首款游戏，就是动作RPG「deep down」了。

deep down的开发画面

Panta Rhei的基于物理渲染（Physically Based Rendering）

   Panta Rhei采用了基于物理的渲染（Physically Based Rendering，以下PBR）

    所谓PBR，是表现各种材质（Material）时，遵从入射光的能量和从材质发出的出射光以及被材质吸收的光的能量总和相等，[能量守恒定律]的渲染方法。在处理材质表现时，表达入射光向什么方向扩散经常要使用到BRDF（Bidirectional Reflectance DistributionFunction 双向反射分布函数）。

    三嶋氏说明，Panta Rhei为了达到「材质表現质感的高品位化和品质的統一化」而采用了PBR。MT Framework时代，是通过环境贴图的组合等等来实现材质的表现，[特定场景以外就不能再使用的专业技巧]的特性突出，而Panta Rhei不管谁来制作，都可以获得一定的质量，为了创建能在所有场景都可以使用的牢固的材质系统，所以采用了PBR。

    这个概念，并不是Capcom特有的，是会成为PS4&Xbox One时代游戏图形设计思想的共通理念。

    那么，关于PantaRhei具体的Shading Model，diffuse部分采用了「Oren-Nayar法」，Specular反射部分采用「GGX（Cook-Torrance）」。据三嶋氏所说，去年在TGS展出时的Specular反射使用的是正规化的「Blinn-Phong」，之后调整为了GGX。

   Oren-Nayar作为diffuse的Shading方法是计算负荷比较高的模型，但相对的有根据视线变化的高光的特性，也可以再现像粘土一样的材质。

    GGX法是，高光的显示方式并不是简单的渐变，而是中心角附近尖锐，再向周围流畅的减少的特性。根据表现对象的不同，比Blinn-Phong变得更真实，本世代的游戏图形采用它的事例也在增加。

    另外，Blinn-Phong也并不是那么差，实际上「Forza Motorsport 5」的基于物理的渲染引擎采用的就是Blinn-Phong的方法。

    GGX和Blinn-Phong的质感有差异。高光的显示方式有很大区别。

    关于人的肌肤shading，diffuse部分使用的是「Pre-integrated SkinShading」方法，Specular部分使用的是GGX。

   Pre-integrated Skin Shadingd的方法，是基于皮肤的入射光在[哪个范围]做[怎样颜色分布]来出射的profile来进行shading的。这个方法是为了降低计算负荷，关于profile，是把法线normal, light vector, 曲率curvature （1/radius）各种组合对应的计算结果预先datatable化。因为curvature相关的计算也很昂贵，3D模型各部分的curvature分布通常会预计算存放到texture里。

    但PantaRhei的3D模型的curvature并不是预先计算得到，而是美术直接在shader里作为参数来构造的，这种明显的细小设定的控制也可以说是日系流派的实现方式

   Pre-integrated Skin Shading方法。这种技术在「BATTLEFIELD3」中也被采用。图的右侧,被称为Skin Diffusion Map

    在PantaRhei的PBR的材质显示参数（parameter）如下

    作为基于物理渲染引擎的参数成员，和其他公司采用物理渲染引擎的共通点也是很多的。现世代的游戏图形都是以这种参数构成为主流了吧。

    还有，「Glossiness」是和Silicon Studio的「Mizuchi」引擎里的「Shininess」类似，与一般作为PBR使用的Roughness参数一样。表示自发光部分的「Emissive」有些特色，是为了反射光（BRDF）以外的透过光或自发光考虑的，由渲染方程式完成。自发光在很多的系统中大多是被省略的项目。一般认为是用来制作萤光等的表现。

    据三嶋氏所说，Panta Rhei在人类一样的有机体上，做成只对Albedo（diffuse反射率）添加颜色，不对Reflectance（Specular发射率）添加颜色的模式，金属物质则是不对Albedo添加颜色，而在Reflectance上添加颜色。用现实的材质来比喻的话，光打在人的皮肤上，光泽的高光色是光源的颜色，另外，像黄金不论打上什么颜色的光，都是接近黄色的光泽。这种特性在Panta Rhei里也实现了

    这种很有道理的实现，在以Unreal Engine 4为首的很多图形引擎里也使用了类似的结构。

    还有，PantaRhei加入了「Reflectance越高，就会强制使Albedo的支配率变弱」的调整，这样材质感变得更靠近现实世界。

    据说为了可以使用这种新的材质系统，材质设计的管线也革新了，这也曾让deep down团队的美术们不知所措，为此，在「3D-Coat」和「Maya」上构筑了，可以一边实时的确认Panta Rhei显示质感一边工作的模式。

    三嶋氏也提及了Panta Rhei的shader制作。

    MTFramework的时候，美术的工作风格是把程序制作的shader parts进行组合，并调节参数。不过Panta Rhei采用的是从0开始开始制作shader，制作的东西可以立即编译，并在预览画面确认阴影等显示的方式。

    实际美术制作shader的例子

    shader是以NodeLink的方式来维系

    制作shader时可以实时的预览

    下面的视频，是实际美术自作水的怪兽shader的例子，要美术自己制作了3d模型上摇摆各个顶点流动的表现，而MT Framework时代是必须是由程序制作这种表现，如果使用PantaRhei的shader制作系统，美术也可以制作。

     这种美术使用的shader制作系统，即便是屏幕空间的posteffect的shader也可以制作，例如下面的视频，可以看到从玩家位置向远处一边发光一边描绘的世界的表现。

    这种是把背景的深度值作为关键，读出背景交叉的特效用的3D texture，一边对3d模型应用这个特效一边显示就实现了。

    「因为是消费很高的效果，不能经常使用， 不过如果是One Point Effect使用允许的话，在deep down正编也会被使用 」，美术说到这样的Post effect表现可以制作的非常独特。  

     三嶋氏介绍到，Panta Rhei也提供了复数材质在3D模型上使用layer Mask进行分配设定的模式。

    例如，衣服和铠甲在一些部分的材质差异，铠甲的金属材质的破损处可以看到锈迹的不同的质感细节的表现，通过这个系统再现了。

    这种LayerMask的模式在Capcom内部称呼为「DetailLayer」

    三嶋氏，到这里做了汇总，对美术可以应对游戏本篇细节表现和关键表现以及shader的设计的Panta Rhei的特性，列出了优点和问题。      

    优点就是美术可以自己一边确认结果一边有效率的制作，试行错误也可以快速进行，可以得到和真机同样表现的制作画面，得到了美术的高度评价，让人感到自豪。

    列举的的问题是，美术高自由度任意制作的结果，追求过多表现的话，也是非常高的负荷，最终在游戏真机上加载时的消耗程度，也是美术很难预见的部分。

    新shader制作系统的优点和问题。

deep down的渲染管线（rendering pipeline）

    接下来三嶋氏对deep dwon的光照技术和渲染管线进行了解说

deep dwon的渲染管线

    deepdown的texture配置，基本上使用了新时代的BC4以上的纹理压缩，不过，一部分为了节省内存使用S3TC方式的「BC1」（DXT1），单通道texture是BC4，normalmap等等是BC7，HDRTexture压缩使用BC6H

    因为deepdown是在程序化生成的洞窟里冒险为主题的，不是美术来设计地图，采用了游戏世界自动生成的系统，因此，不能使用预计算的lightmaptexture。基本上，全部的光照运作都是实时的进行。

    光照是在运行时实时的进行的

   deep down也有科幻的设定部分，那种很接近未来的场景制作，有使用lightmap。

    渲染方法基本上是Tile Base「Deferred Rendering」，半透明对象和之前提到的皮肤材质等作为特例使用的「Forward Rendering」

    所谓的Tilebase Deferred Rendering，把是画面划分成若干个Tile，再进行Deferred Rendering的方法，还有，它和ImaginationTechnologie的PowerVR的硬件使用的技术同名，注意是不一样的。

    那么为什么要特意划分成Tile来进行？

   Deferred Rendering拥有可以放置无数动态光源的优点，对屏幕空间的全部像素， 去判断是否受到场景内放置的动态光源的影响，再进行shading过于冗长。「哪个光源影响到屏幕哪个Tile」这种事先调查制作对应列表，就是Tile Base  Deferred Rendering的基本构思。

   deep down进行的，是把画面(view frustum)分割为16×16的TBDR，因为是从视点向深度方向分割为32个空间的实现风格，也可以说成是[立体的Tile风格DeferredRendering]。算是和ray tracing的Voxel分割或者Chalmers University of Technology的Ola Olsson氏发表的「Clustered Deferred Shading」里的技术接近。

   deep down的TBDR,是生成立体的Tile来制作有效光源的列表。

    在三嶋氏的演讲里，对这种立体Tile的有效光源列表的做成算法进行了详细的解说，说明图示在下面的动画里。

    可以看到，立体Tile是根据深度方向按1，2，3，……32来分割的，判断各个光源在哪个立体的Tile上，出现在Tile上[光源编号]是多少，就把对应编号的位数值设置为[1]来记录的机制。另外，这个处理是在「Compute Shader」(GPGPU)里进行的。

     光源1号是在Tile 27，28，29上，把对应的位数编号设置为1来标记出光源列表，光源3号也做同样处理，光源2号因为没有在立体Tile上，就从有效光源列表里剔除。

    据说实际的Shading处理也不是在Pixel Shader，而是在Compute Shader上进行的，对16×16的Tile并行执行，从有效光源列表里取得光源并进行shading。

    还有，为了提高并行执行的效率，点光源，平行光，聚光灯等各种光源都是分类处理的，最初作成的是一个循环里处理所有类型光源的程序构造，而按光源种类分别循环，GPU核心的并行执行率提高，性能也提高了

    shading是在computeShade里进行计算的

    特别的材质，具体的想处理皮肤一样的变透明物体时，就要执行前面提到的Forward Rendering，Panta Rhei以外的基于Deferred Rendering的渲染引擎，为了特殊材质也加入了ForwardRendering Pass。

    生成立体Tile制作立体的有效光源列表，也可以用在特殊材质的Forward Rendering上。根据这个，只能使用有效光源进行特例材质的shading。前面生成的有效光源列表可以用在Forward Rendering的概念，说不定是从AMD提出的「Forward＋ Rendering」的架构中吸取了一部分。

    特殊材质的渲染使用的是Forward Rendering

    画面本体的RenderTarget，采用的是各通道16位浮点数（FP16）的64bitBuffer，在没有gammer校正的线性空间进行渲染的（为了在显示器或电视上显示，ToneMapping要压缩在gamma空间）

    另外，DeferredRendering里，lighting或shading必要的中间变量，称为「G-Buffer」的缓冲要进行渲染，deep down使用下面的配置。

   RenderTarget是FP16，渲染方法是PS4＆XboxOne世代采用事例最多的方式，现代的主流技法

    G-Buffer的配置

    虽然感觉在材质系统已经提到，不过还是有几个特色的东西。

    三嶋氏花时间解说道，关于diffuse部分的Albedo，Specular部分的Reflectance。deep down是为了减少在G-Buffer里写入的数据，采用了电视和视频映像的传输方式中的色差表现YCbCr方式。总之，亮度值Y是全解析度记录，颜色信号的色差信号，是像素线的偶数线和奇数线交互记录蓝色差（Cb）和红色差（Cr）的方式。

    这个格式用视频用语称为YCbCr=4:2:0，与Blu-ray软件和地面数字电视等一样的格式。降低颜色解像度是针对人类视觉组织对亮度解析度敏感，对色彩情报迟钝的缘故。不过游戏图形采取这个方式相当的独特。

    由于数据量被消减了，遇到了在HDRRrendering高亮度值的地方，靠近黑色的地方暗色不能正确显示的「伪色」问题。

    三嶋氏分析到，伪色的发生是因为[可能是量化误差（Quantization Error）没有被正确吸收]的缘故。deep down里，Albedo是经过RGB（材质输入）→YCbCr（G-Buffer）→RGB（在Deferred Rendering中复原Albedo）的变化处理输出，考虑到最后RGB各8bit的输出，可能是精度不足引起的。

    为了回避这种伪色现象，据说最后是通过调整材质和纹理方面颜色，或对颜色编码（encode）部分修补来应对，三嶋氏陈述道[适当的加入四舍五入来改善计算精度不是也能降低么]。

    三嶋氏开玩笑的回顾到[说不定使用RGB是最好的]，提到[说不定一边使用RGB来消减G-Buffer数据量，并采用『Metallic』的想法更好]的描述，对Metallic这个关键词稍作补充说明也是有必要的

   Metallic的想法，在Unreal Engine 4和Mizuchi中也被导入，对应金属度（Metallic度）参数值有多高，Specular的色彩会就多少借鉴到base color里。

    试着看下除此以外的G-Buffer的内容，PreLighting的R，G，B，是岩浆或水晶等自发光表现使用的参数，在lightmap使用的场景里，保存的是lightmap值与Albedo值相乘的结果。

    还有，Options的部分，是写入Decal Texture或之前的皮肤材质的特殊处理的情报。Reflectivity放入的是反射率，还有为0时是关闭光照的特殊处理。

    直接光照使用的光源，不光是古典的点光源，也有拥有大小的面光源可以使用，这个也可以是说是新世代游戏引擎的新标准采用的部分。现状是虽然只有球形的面光源对应，但强度，大小可以定制，支持遵从物理法则的按距离的平方衰减。

    支持球形的面光源，另外除了球形外，胶囊（Capsule）和四边形的面光源也做出来了。

光源的大小使得高光的显示变化，面光源的导入，实际也是新世代游戏图形的特征之一。

deep down的间接照明

  关于间接照明（全局照明），使用了「Irradiance Volume」和「Parallax CorrectedCubeMaps」以及「Screen Space Reflection」（Realtime Local Reflection）。

    关于间接照明的diffuse部分， 优先度从高开始为「Irradiance Volume」，「Parallax Corrected CubeMaps」，[普通的CubeMap]（没有视觉修正的无限远使用的环境贴图），「其他可用的」来实现算法

    Specular同样，优先度从高开始「Screen Space Reflection」Parallax CorrectedCubeMaps」，[普通的CubeMap]，「其他可用的」来组成。

   deep down的间接照明的要素使用的优先顺序 　

   Irradiance Volume，是从Valve的「Half-Life 2」时代开始就使用化的古典的间接照明技术，把场景用立方体分割，预先计算这个立方体顶点单位的全方向的照明信息，运行时利用这个全方位的照明信息来进行shading。

    因为deepdown的游戏地图是动态生成的，没法在制作游戏时预先计算Irradiance Volume ，所以在运行生成地图的时候，来计算Irradiance Volume。

    这个顺序是，首先把场景分割为256×256×256的固定的Voxel，渲染游戏世界的直接光照。从渲染结果的颜色信息和occlusion信息列表化的保存到对应的Voxel，另外准备128×128×128个Irradiance Volume观测点（probe），从点到周围12个方向进行「VoxelCone Tracing」。Cone Tracing的对象，就是之前256×256×256个Vexel。

    关于ConeTracing的详细信息，简单的解说的话，是ray tracing的一种，因为ray tracing发射的是光“线”，获得的照明信息（lighting结果）的范围狭小。相对的，Cone Tracing使用的是圆锥（Cone）。因为发射的光线扩展了，可以获取更广阔范围的照明信息。虽然光线变的粗糙，基于「diffuse的间接照明使用光照信息即便粗糙也不会有造成实际损害」的判断而使用了。

    这样处理后的Irradiance Volume是存放在128×128×128的3DTexture里，记录格式是保存相互垂直的4个方向的颜色信息，关于采用这种形式的理由，三嶋氏说明是「因为的数据的使用和质量的平衡很好」。

    首先场景做256×256×256的Voxel化，把直接光照的结果写入到每个Voxel

   Voxel的信息使用128×128×128个probe，从位置向周围12个方向执行Cone Tracing,制作 Irradiance Volume

    直接照明（上）与  添加Irradiance Volume间接照明效果的结果（下）的对比，可以看出中距离部分在亮度上的差异

    ScreenSpace Reflection是在屏幕坐标系的局部进行ray tracing，制作比较鲜明正确的镜像的技术，是Crytek发明，很快就被业界采用了。deep down是用靠近水面等完全镜面反射的部分使用。

    CryENGINE 3上的Screen Space Reflection的demo

   deep down的是Screen Space Reflection 是对靠近水面等镜面的部分使用。

   Parallax Corrected CubeMaps，是最近很多事例都采用的必有的技术。

    所谓的ParallaxCorrected CubeMaps，是在某个位置预先制作出来的应用在每个对象上的环境贴图，是从描绘的对象位置看到映像表现，不会有不自然的修正的环境贴图的技术。    

    从CubeMap吸取光源的「Image Based Lighting」是必须的技术，是由现任EA DICESenior RenderProgramer的Sebastien Lagarde推广的的

   deep down是在不使用Irradiance Volume或Screen Space Reflection的地方，diffuse和specular都使用「ParallaxCorrected CubeMaps」。

    在deepdown里，1个场景设计为可以防止96个CubeMap,分辨率为128x128Texel，使用MIP-MAP有64×64,32×32,……2×2Texel的缩小版

    根本deepdown,1场景中96个环境地图为使能放被设计,那个分辨率是128×128tekuseru。根据MIP-MAP有64×64,32×32,……2×2tekuseru的缩小版。

    从高分辨率到低分辨率生成的理由是，为了恰当的应对材质表面的粗糙度（G-Buffer的Roughness）的表现 ，要显示漂亮镜像的滑滑的材质就使用高分辨率，光泽感不强的粗糙材质就使用低分辨。

    直接光照（上）和添加了使用Parallax Corrected CubeMaps的间接照明效果的对比，可以看到金属感的贡献很大

    环境贴图携带MIP-MAP是IBL的标准方式  

deep down的阴影生成

    deep down采用的阴影生成方法是ShadowMap（DepthShadow），先全方向发光的点光用使用6方向的CubeMap的ShadowMap生成，聚光灯用1方向的ShadowMap生成

    另外，方向光这种把场景整个范围生成印象的场合，使用从近到远，分割成3张ShadowMap生成阴影的CascadedShadowMap。

    关于SoftShadow使用的filter，CSM是「PoissonDisk Sampling」，其他的SM使用的是「Percentage-CloserFilter」（PCF）

    右侧侧截图是实际ShadowMap的内容，生成阴影用的ShadowMap都保存在一张大图上，再进行使用的配置。

    据三嶋氏所说，如果全部对象都严格的生成阴影会造成相当高的负荷，要摸索最佳的优化方案

   deep down是，着眼于游戏里的静态光源，把静态光源中明显静止对象的阴影写入专用的临时缓冲保存，把它拷贝到生成阴影用的shadowmap，进行动态物体阴影的生成。静态物体的ShadowMap渲染，只要从临时缓冲拷贝就可以，达到了高速化。

    还有，光源有增减变化时，就要重新生成静态对象的ShadowMap，为了慎重起见，一帧只有一个光源可以向临时缓冲生成阴影。

    对ShadowMap的生成做最优化处理

deep down的身体毛发表现

    最后，阿久澤氏，进行了关于在deep down中登场的怪物身体毛发表现的解说。    

     毛发表现，最初是对累积毛发的横截面来渲染的Shell方法，或则植入polygon头发的fin方法（banana leaf方法）进行了研究，不过因为shell法如果视线从层积的毛下方来看能看到断层，而fin法的polygon植入太麻烦而放弃了。

    结果，利用DirectX11时代GPU特有的功能，Tessellation Stage，采用了线段来生成Polygon的方法。使用Tessellation Stage来实现毛发的例子有SquareＥｎｉｘｅ的「Agni's Philosophy」

   deep down，现在可以在美术制作怪兽模型时，进行[位置]，[密度]，[长度]毛发生成的设定，实际在建模阶段并不能植入毛发。

    而是在运行时，读取怪物时，使用Compute Shader计算生成「怪物的表皮上的毛发的发生源」，渲染时，把这些发生源在Tessellate使用，在用线段（PolyLine）生成polygon（实际是Quad）时来生成毛发。

    利用TessellationStage，采用线段生成体毛的方法

    毛发的发生源是在创建怪物3D模型时的Polyon单位进行的。

    怪物的动画姿势变化使部位扭曲时，毛发的发生源也会随之移动

    因为毛发是半透明的对绘制顺序要求很严格的材质，因此，要从后向前排序后再进行渲染。

    在TessellationStage对基于PolyLine的毛发排序后进行绘制。

    实际光照，因为毛发是半透明对象，毛发重叠不能进行Culling。这种方法在Pixel Shader进行Shading，构成毛发的Pixel要重复的Pixel Shader里的运行。注意到这样会有较大性能影响的阿久澤氏，选择了在 TessellationStage的domain Shader进行lighting的的方法。

    在VertexShader进行lighting太粗糙，在PixelShader进行lighting负荷高又要重复使用，在可以对Tessellate细分化的多边形做各种处理的Domain Shader里进行lighting.

    导入这个优化方法，虽然高光显示的细节下降，但因为性能提升，据说被最后的配置采用了。

    为了lighting的高速化，停止在PixelShader里lighting,转换为在Domain Shader里lighting

    PixelShader的lighting和Domain Shader的lighting的对边，可以看到高光显示的差异，一眼看去分辨不出品质的好坏。反而是DomainShader版的柔软阴影获得了美术们的好评。

    这种一簇簇毛茸茸的毛可以一个个的种植了，为了能看起来的更真实，阿久澤氏考虑配合怪物身体的动作使毛发运动。

    如果要看起来足够的真实，阿久澤氏决定致力于简单模拟的实现，作为毛发生成位置的3D模型上各点的坐标，通过前一帧位置坐标和当前帧的位置坐标单纯做差分来计算移动距离，把它作为模拟的速度。

     把这里计算出的速度，对Tessellation Stage生成的毛发在Domain shader里进行位置坐标的更新，于是，显示出毛发随着身体动作出被翻弄一样的三次元的动作，外观效果惊人的提高了。

    跟随怪物运动的体毛，由于没有毛发相处碰撞的处理，毛发之间无视重叠的运动的。不过只是怪物的毛发，并不是超长的头发，所以这样也就可以了。    

   deep down，使用Capcom自豪的次世代游戏引擎Panta Rhei想当多效果的。还有，最近也渐渐了解，Capcom深入研究日本其他公司的自制引擎，也有对海外游戏引擎采用的今世代游戏图形倾向的研究，Capcom向我们传达了为了更容易的使用而如何去改善，改良并加以吸收。