规则解读（二）| 本地资源检测 For Unreal

在UWA推出的适用Unreal项目的本地资源检测版本中，项目团队可以将其作为规范和完善项目资源品控流程的重要一环，添加到Unreal项目的研发持续集成、持续交付流程中，实现本地资源检测的“资源场景全覆盖，一键式自动扫描”。

在《规则解读（一）| 本地资源检测 For Unreal》中，我们为大家介绍了Unreal版本地资源检测的部分规则。本文中，我们将针对“基本资源”模块中的更多规则，以及“场景检测”模块内的规则，为大家进行讲解。

Part1、基础资源检测

1. 面片数过大的StaticMesh

在Unreal项目中，物体或者说模型，是由若干个三角形面片组成。三角形面片，则是由最基本的“顶点—连线—成面”组成。

面片数的多寡，很大程度上决定了整体展示效果的优劣。如下图，《FF7》蒂法在游戏内的人物形象变迁，其实很好地反映了面片数的数量对展示效果的影响。

但网格的面片数量是把双刃剑，虽然大量的三角形面片能够达成非常好的展示效果，可是一旦三角形面片的数量过大，则会对项目的内存占用和加载耗时、以及渲染方面的性能开销上造成不容忽视的压力。

影响面片数多寡的因素有很多，比如在模型的设计和修改阶段就产生了较多的冗余，又或者在本该作为模糊背景的地方应用了复杂精细的模型等。

本条规则会对物体各个LOD层级内的StaticMesh进行判断，筛选出超过阈值的StaticMesh资源。建议团队在追求展现效果而采用大量面片去设计网格的同时，也要考虑由此带来的内存、加载和渲染性能上的消耗，争取达到性能与效果的平衡。

2. Collision总面片数过大的StaticMesh
为了模拟现实的物理规则，Unreal提供了一整套用于模拟现实质量、重力和碰撞等的设置与机制，使项目内的对象能模拟出更真实的物理交互。

其中对于碰撞效果的实现，需要开发者为对应的静态网格模型，去设置“碰撞网格体”，即为物体添加上相应的碰撞体后，相关的物体就会有一个“碰撞范围”，当另一个物体接触到这个范围，才会触发这个物体的物理效果反馈。

在引擎中，构成物体的“网格”需要承担两方面的功能：显示与物理计算。对于同一物体，用于显示的网格与用于物理计算的网格可以相同也可以不同。用于物理计算的网格就是上文所说的“碰撞网格”。

如上图，外界不需触碰到里面那个球形网格，只要接触到了立方体网格的范围，就会触发对应的位移、击飞或滚动等物理效果。“眼见不为实”，出于性能与实用性考虑，碰撞体网格常常是用于显示的网格的“简化版本”。

但如果项目中某些物体需要实现更为精准的物理碰撞反馈，比如者人物与家具的互动。此时就需要使用复杂的碰撞网格体。

复杂的碰撞网格体带来的更精确的物理特征，是以更大的物理运算开销为代价的。所以，在筛选出结果后，可以根据自身项目的实际使用需求，把那些不需要高精准物理反馈的物体，选择性地换用更简单的碰撞体，从而降低物理计算开销。

3. 包含UV Channel 2及更多UV通道的StaticMesh
UV通道是静态网格体中的一组数据，它将网格体的每个顶点映射到2D空间中的坐标。这些映射定义了在渲染网格体时2D纹理贴图是如何围绕3D几何体进行包裹的。

在Unreal项目中，UV Channel的常见使用主要可以分为两类：材质中的纹理坐标、光照贴图。

纹理方面，UV通道提供了一套用于确立模型表面的各个顶点的颜色采样与纹理上具体位置的对应关系，通俗来讲就是当一张图贴在模型表面时，使得我们可以从“纹理”这块调色板上找到正确的颜色，来绘制模型。

光照方面，UV通道会用于存储和应用光照贴图。光照贴图是一种特殊的纹理，它为静态网格体存储预先计算好的光照信息。所以其实和上述差不多，也是提供了网格模型和光照之间的对应关系。

所以当本条规则检测出那些包含3个、4个乃至更多UV通道的网格时，就需要进行进一步地确认，查看是否在模型导入时带入了不必要的信息，或者去除那些对最终展示效果影响不大的通道，从而有效降低模型所占空间资源。

4. 包含UV Channel 1的StaticMesh
如上一条规则中的描述，网格模型上的UV通道过多，往往可能是在导入时带入了错误或者不必要的信息，需要团队重点关注。

针对网格上带有UV 0和UV 1两个通道的情况，这既有可能是不必要的冗余，也有可能是正常的通道使用，所以本条规则更侧重于为团队提供提醒，对检测出来的资源进行二次甄别，排查出那些隐藏在正常使用的“漏网之鱼”。

5. 预估总内存过大的StaticMesh
UWA设置本条规则，是结合“StaticMesh自身的大小” 、“StaticMesh采用的材质大小” 、 “材质直接依赖的纹理贴图大小” 和“材质的子Material的纹理贴图”作为计算标准，统计出网格模型可能占据的总内存大小，让团队对开发过程中网格内存的改动与预估有了更为直观地了解，从而更好地把控后续开发进程。

Part2、场景检测

1. Actor上挂载的光照组件数大于1
Unreal工程内提供了5种光照组件：天空光源、定向光源、点光源、矩形光源和聚光源组件。

简单来讲，这几种光照组件，都分别为场景内提供了各自对现实中光照情况的模拟，即阴天时的光亮、晴空万里的阳光、白炽灯的刺眼和手电筒的照射等。

通常情况下，不同光照组件所适用的环境都相对独立，所以一个Actor上挂载一个光照组件，就能满足当前场景或区域的光照需求。除了部分极特殊的情况会要求多种光照组件在同一个Actor上同时作用外，大部分情况下，Actor上挂载光照组件不会超过1。

建议团队对本条规则的筛选结果进行仔细检查，避免不必要的性能开销。

2. 场景中带阴影的实时光数量较大
带阴影的实时光能够为场景提供接近现实真实条件下的光影效果，其对游戏的表现效果和拟真性有着重要的作用。

但这种对真实光照效果的展现，是以对阴影进行大量计算和性能消耗为代价的。带阴影的实时光越多，对阴影的总计算量就越大，对性能的影响也会越发明显，从而导致可能的发热、卡顿等现象。

所以在对规则筛选结果进行排查时，团队在必要情况下需要进行果断的取舍，在表现效果和项目性能之间努力找到最佳平衡点。

3. 场景总面片数过大&总顶点数过大
在Unreal中，“点”与“线”的组合就构成了这个虚拟世界的基础。就算是一个看上去无比圆润的球体，究其根本也是由大量“点—线”组合的三角形面片构造而成。

一般来讲，如果对场景的质量要求越高，那么场景中的元素就会越多、模型也会越精细。相应地，团队就需要使用更多的面片去构建地形、角色模型等，用更多更复杂的做法来渲染相应的元素，以满足场景内高质量的需求。

一方面，大量的顶点与面片为场景带来了不可忽视的内存和渲染压力；另一方面，由于没有在这种数量上有个明确的“红线”，一些很明显的优化做法也容易被忽略。例如：对作为背景的远处物体，本可以通过降低三角面数的做法来减少性能开销；一些数量大但非必要的场景物体，某些情况下甚至可以不用模型，转去用平面纹理也达到同样效果等。

所以借助这两条规则，团队可以对场景内的元素与复杂程度有个较为明确的概念。针对筛选出来的场景资源，要根据实际的性能需求去对相关的顶点、面片使用做精简。

以上，便是对“基本资源”以及“场景检测”模块内规则的讲解，希望能对大家在Unreal项目的本地资源检测使用带来帮助。下期，我们将介绍“全局设置”模块下的规则，敬请期待。