十年经验端游大厂主美：如何制作畅销榜前五手游的3D场景丨课堂笔记
想把全场景面数控制在15万以下，你需要这些黑科技。作为曾经跻身畅销榜第四的产品，除去经典IP与MMO的完备玩法之外，《天堂2·血盟》的美术也相当接近端游的表现水准，在韩式动作+西方魔幻的同类风格中独树一帜，宏观场景和模型细节也都经得住镜头缩放的考验。
9月13日，在第六期葡萄学院「怎样提高手游3D场景的制作与优化水平」上，《天堂2·血盟》主美札肯以游戏中的因纳得立领地为例，详细分享了单屏批次数与场景面数的标准和控制方法、场景后处理的选择与使用，并解答了学员关于类似问题的种种疑问。以下内容是第六期葡萄学院的精华内容，经葡萄君整理发布：
大家好，我们这期主要以项目里已经完成制作的场景作为案例，进行简单的分享交流。这也是我们项目的重中之重。先请大家看一下游戏里场景的实际截图：
但我们产品刚开始的时候产品表现并不是目前的样子，早期仍旧以锁视角为主，资源优化方式方面考虑的比较多。
项目早期场景效果在锁视角表现方式上面，资源消耗比较集中，比较容易控制，前些年也比较流行这个方式。但随着项目系统功能开发的推进，以及市场调查和NCsoft的沟通，固定斜45度视角不能满足这款游戏的要求，全3D的视角才更加符合MMO的类型。
以上两张图是因纳得立场景的截图。
这是场景的整体布局图。我下面开始说一些场景组成的基本数据，细枝末节的东西暂时就不说了。我们美术制作主要使用的是蜗牛游戏自研的Flexi移动引擎，场景的制作和优化其实和主流引擎并没有本质上的区别，但在便利性和一些特殊性方面有些不同。下图是我们引擎里面的数据，整体是没有超过15万面的。目前iOS设备和安卓设备的资源控制方面的数据网上很多，大家有兴趣可以找出来对比。我们的全场景面数也会控制在15万左右，为后续单屏面数控制提供了可能。
这张图是目前这个产品的单屏批次数，我们基本上普遍控制在了100以下。当然，这和锁视角场景控制的批次数量是不能比的，锁视角场景可以控制在10个甚至5个以下，但全3D产品是做不到的。特别是在场景面积比较大，需要摆放的物件种类、材质种类、动态物体的数量都很多的时候，全3D场景受到视角控制和视距设置影响比较大。
而实现场景面数和批次控制目标的话，我们主要通过以下几个方式：1. 制作物件的时候进行严格的面数控制；2. 严格控制材质数量；3. 对琐碎摆放的模型物件进行合并处理；4. 优化地表，降低地表面数和批次；5. 合理的视距和裁剪设置。下面依次进行说明（建议点开大图进行查看）：
这张图就是我们对场景经常使用的物件进行控制的举例截图，大家放大图片可以看到三角面数。场景内使用的通用、大量出现的物件面数必须严格控制，因为每个物件少一点面，整个场景就会节省很多面，而多余资源就可以用到需要精细制作的主要物件上，比如建筑物，标志物等等。通用物件一定不能浪费。
这张图主要是说明需要严格控制材质数量，因为你的贴图数量基本上就等于你的材质数量。在这个场景制作过程中，我们另外对同类物件进行了贴图合并处理比如大尺寸建筑，通用类的石头，小物件等等，根据摆放和物质属性进行分类处理，然后进行合并。而且尺寸也会影响到场景后续裁剪的设置。琐碎的贴图要尽量合并处理。这里有几张其实是路面、地表和石头的通用贴图文件。有效降低贴图文件可以大量节省材质的数量。另外，对一些使用透贴的植被和其他物件也需要尽量合并处理，因为在产品制作中也需要尽量控制透贴物件的使用。
这种图主要是说要对琐碎摆放的模型物件进行合并处理。在产品制作过程中，我们知道有两种方式可以进行合并。一种是在Max里手动进行模型合并，然后两个导出；另外一种就是像Unity一样，进行静态贴图合并。我们没有使用类似Unity一样的静态的自动静态贴图合并，而是让我们的程序员在Flexi引擎里增加了手动合并物件的功能。大家使用Unity应该知道，自动静态合并会生成很大的数据文件，对包体控制不大好。我们增加了手动处理，你就可以根据物体的种类、尺寸随意选择合并。这个演示主要是我们是相同材质进行处理，这样同一材质就会变成一个批次。
这是因纳得立场景的地表优化方式。Flexi引擎主要是通过LOD的方式对地形进行优化，有效降低了面数。它对地形的优化效率相当高，比Unity要好很多。所以在《天堂2·血盟》的场景里，地形产生的面数基本可以不计。
这张图主要是讲合理的视距和裁剪设置。设置视距裁剪和雾效距离也是作为优化性能的重要方式，特别是在视觉效果等级设置上，使用最为普遍。这就用到了之前我们说物件合并时，关于大小、尺寸方面的合并。因为小尺寸的物体在设置裁剪时可以距离近一点，然后根据尺寸的增大逐渐增大他们的显示距离。下面再简单说一下场景效果后处理的使用。以下这张图主要是说一下Flexi引擎给我们提供了哪些场景效果后处理，基本上适用大部分的主流的处理方式。但是因为硬件设备的限制，我们并没有照单全收。经过一系列的硬件测试之后，我们挑选了一些主要的处理方式。
这张图是容积光和镜头光晕的使用。
这张图是景深效果。
这张图是水体折射的效果。这些效果的确消耗很大，耗电量都比较大，对硬件GPU的要求也很高，所以需要进行筛选处理。这是实时阴影和抗锯齿处理。因为我们是在全3D视角下面看得比较远，所以贴图和其他东西都需要抗锯齿处理，不然远处的噪点会非常大。
这两图是我们使用了一些法线高光的效果。法线高光效果我们把它归到了后处理的一类。这样我们可以根据硬件性能，实时去关闭它。刚才列举的都是接下来会用到的。其他产品有一些比较花哨的后处理，我们并没有使用。
我个人觉得，在画面表现上，基础美术还是要扎实一点，这样可以省去很多后处理的表现。
在效果后处理使用上，要因引擎、项目和设备而异，盲目堆砌只会加重优化负担。主要表现效果应该放在基本场景模型和贴图制作上来。这个就是我们对因纳得立产品基本制作流程的简单说明。刚才说的那些东西，是我们项目在场景制作上面重点注意的地方。但具体操作的细节无法细说，其实很多东西网上也都有。提问环节在性能优化方面，除了批次合并和LOD还有没有其他的手段？另外，如何平衡美术效果和性能优化的关系？在产品性能优化方面，我们主要是地形使用了LOD，物件并没有使用LOD，同时也使用了批次合并。其他的手段就是笨方法，严格控制整个场景的面数，这样单屏的批次和面数才不会超标。另外，如果整个场景面数控制到位，也就不需要使用大量的动态加载了。大家知道的应该明白，手机上面的动态加载效果并不怎么样，特别是安卓手机上面。如何对琐碎物件进行合并处理？主要通过贴图合并和物件合并两种方式。贴图合并主要是在贴图制作时就已经合并了，物件合并则主要通过特殊引擎工具进行手动合并。在游戏场景制作前如何合理地把琐碎物件同材质的放在一张贴图上？每个物件占贴图像素的比例要求是怎样养的？在场景制作过程中，进行琐碎材质和贴图合并的时候，修修补补是很正常的事情，没有办法一次完成。在像素比例分配方面，一般建议分近景、中景、远景，或者在高度上做区分。比如人物行走比较近、低的位置，分配的像素就大一点；地面位置上，建筑比较高、远的位置，就尽量分配少一点，重复率高一点。如果场景制作平庸，如何优化美术效果？如果觉得场景比较平庸，优化我建议找大量参考图和实例进行参考比较，甚至在一些细节塑造、近景处理上对着做。具体的个人技能就没办法说明了。草从植被在合并后、是统一裁剪合适还是分开进行视距裁剪合适？草之类小东西的裁剪，可以根据你整体合并的面积，以及裁剪的需要。比如你整体面数达标，那把整个场景的物体合为一个也没关系，可以一次预加载进来，这样批次还会更少一点。如果面数比较多，那还是要按照设置裁剪距离的需要进行合并。场景的透贴是程序优化的，特效中的大量透贴也需要程序优化吗？我之前用Unity有一些经验，比如用到粒子系统，那就要尽量控制粒子的大小和数量。另外透贴占用的全屏面积也要小一些，而且透贴之间要尽量避免重叠。是不是离摄像机近的时候用精模，远的时候则用粗模？这样的话美术是不是要准备两套以上的模型？我们并不是按照摄像机的远近确定模型精度，而是要视玩家的活动范围而定。我们也没有做出2套或以上的资源，如果单个资源控制得合理，并不需要这么麻烦。即便使用粗模和精模，也只是针对景观的远景和近景。在《天堂2·血盟》中，地图的边缘是如何处理的？《天堂2·血盟》中可到达地图的距离先由策划部门规划，我们需要在实际测试中计算玩家的跑动时间，最终决定出地图的大小。边缘处理主要看资源量，如果整体面富余不多，我们就用贴片来处理；如果富余很多，就用三维物体来遮挡。《天堂2·血盟》的地图很大，是动态加载么？并非动态加载，因为我们把批次和内存消耗都降了下来，所以基本上是一次性加载。因为尺寸很大，所以在很远的地方已经加载完成，即使偶尔是动态加载，玩家一般也感觉不到。场景加载也不会慢，我们单个包体控制得比较合理，程序会预先全部加载进来。只是偶尔会看到一些由于距离裁剪问题导致的动态加载，但不经常出现。大场景的制作如何合理分配人员？不同人员共同制作一个大场景，如何保证效果的统一？大场景主要看时间和地图大小，一般我会安排一个人主要整合场景，另外几个人配合整理一下物件。如果场景过大，那就拆分开来再处理。越复杂的东西就越需要简化处理，简化的方式则是规则。我们一定要有严格的制作流程、基础规范和风格要求等等。我的管理绝不会允许超出我们制作规范以外的事情发生，如果你有额外的想法和方式，我们可以进行单独的讨论。但如果制作人员人人都在东西上面自由发挥，最后的东西就一定会失控。