我是2010年加入网易盘古工作室，全程参与《天谕》项目，负责客户端引擎的研发负责人。

　　

　　 盘古游戏工作室现在有200多位小伙伴一同奋战在《天谕》这个项目上。

　　

　　 盘古游戏工作室现在有200多位小伙伴一同奋战在《天谕》这个项目上。

　　

　　 从技术的角度来说，要我给《天谕》一个描述，我会用两个词描述，我觉得这是《天谕》最大的特点，第一个词是次世代效果，第二个词是无缝的大世界。是我们的游戏大有可玩，无束缚玩法的核心。

　　

　　 下面通过《天谕》次世代大世界让大家有一个直观的感受，实现了春夏秋冬、日夜24小时光影变换，同时给大家带来非常喜欢的漂亮的人物角色和服装。

　　

　　 但是从技术角度来说，《天谕》最引以为豪的是构建了一个非常非常巨大的游戏世界，在《天谕》中，它最大的一块大陆叫云垂大陆，总的面积是150平方千米。

　　

　　 10千米×15千米=150平方千米，可能大家看到这个数字没有什么感觉，杭州的西湖只有6.39千米，《天谕》相比而言，可以装下23个西湖。在魔兽世界中，估算的卡利姆多大陆面积在100平方千米，所以，天谕的云垂大陆面积比魔兽世界的卡利姆多面积还要大。

　　

　　 从技术角度，做一个"大"世界并不难，难的是如何填充它，我们有非常优秀的策划和美术，他们制作了多样的风土人情，丰富的剧情玩法，让我们的大世界变得非常生动。拿人物来说，我们策划在整个的世界中布置了超过1万个任务。下面我们通过一段视频让大家对《天谕》大世界有一个直观的印象。

　　

　　 整个视觉效果非常震撼，在一个非常巨大的世界中做到各种精细的效果。做到这样震撼的效果，对技术来说有巨大的挑战。接下来我从贴图和模型两个角度讲《天谕》引擎支撑大世界时所遇到的挑战。

　　

　　首先看问题规模，我们用次世代方法做模型的时候，在单一地点，周围可能多达2000MB的贴图，如果用它渲染，需要玩家的显卡有2G的内存，这个要求太高了。

　　这是一个贸易区，美术制作的素材上，角色超过500M的贴图，场景也超过500兆的贴图，还有其他功能性贴图也有200多兆，显然DDS不能在正常玩家的机器上显示，我们怎么处理这些问题而又不损失效果？

　　 场景模型规模，《天谕》在单一视角下，绘制200万面的物体，带来7000个DP。

　　

　　 场景模型规模，《天谕》在单一视角下，绘制200万面的物体，带来7000个DP。

　　

　　我准备从三个角度说这个问题：

　　第一，在项目中期，我们发现制作一款次世代游戏需要这么大资源时，我们执行严格的预算管理系统，我们希望对每一个资源制定严格的上限。对于不同类型的贴图、模型，我们构建符合其特性的LOD系统，来管理这些资源。最后我分享一下我们正在做的Proxy系统，它在天谕制作巨大的城市的时候起到非常大帮助。

　　

　　 先我们看预算管理，一个是Budget的预算，一个是Streaming，流失的加载。

　　

　　 严格的预算上限，对每个资源定义严格的优先级，同时，没有任何资源是特殊的，没有任何资源是一直存在的。为了让无用的资源或者没那么重要的资源尽可能换出，我们要求所有的资源有一个替代的模型或者贴图、方案。因为我们资源非常大，对于这个替代方案，我们希望足够小，多小呢？我们希望能够比原始素材小2个数量级，我们觉得如果增加这些量我们可以完全没有压力地承担了。

　　

　　Budget严格控制上限，把不重要的资源清除出去，同时我们需要一个系统加载回来，这就是Streaming系统。一旦在主线程或者渲染线程中，进行L操作，必定导致卡顿。我们给所有加载资源定义优先级，主要目的是降低重要资源的加载延迟，让重要资源可以插队优先加载出来。

　　在游戏中，除了CPU显卡资源外，磁盘IO也要充分利用。我们认为内存只是一个缓存，希望充分利用内存到磁盘间的L带宽，来保证尽可能多的东西能驻扎在内存中。

　　

　　有了预算管理的理念之后，现在开始构建我们的LOD系统。

　　

　　首先我们看贴图，在控制贴图时，根据我们刚才说的预算管理系统，定义三个重要的要素，一个是贴图预算，我们到底要控制什么东西？现在要控制任何一个地点，玩家周围需要加载贴图的总量上限，替代资源是什么？我后面会讲。还有需要在任何一个地点动态确定每一张贴图的优先级，怎么定义优先级？

　　

　　 对贴图替代方案来说，对每一张美术生成的贴图，转成DDS，转的时候把前三层或者前四层根据配置不同砍掉，剩下的缩略图作为替代资源，需要额外1%-2%的资源，给每张贴图一个替代资源，就完成了替代资源的生成。

　　

　　 贴图权重规划。

对贴图来说，我们认为与距离、视觉非常相关，我们认为离镜头越近的模型，它的贴图权重比较高。同时在屏幕上比较大，或者模型比较大的物体，它的贴图权重也会比较高。同时我们还接纳美术同学的观念，他们觉得法线贴图更多代表物体表面很多细节，产生光影，因此我们把法线贴图权重也调得比较高。整体来说是视觉上的权重排序。

　　

　　 对于每个类型的贴图来说有场景贴图和角色贴图，我们确定一个上限不能超过多少兆，一旦这种上限确定后，玩家走到任何一个地点，都对他周围的贴图，根据优先级计算一个权重，根据权重排序，整个系统中从高到低，先加载到所有贴图的大图，当达到我们的总量上限为止，剩下的所有贴图，我们认为是不重要的，全都以缩略图的形式存在。

　　

　　 同时，它带来是收益是非常大的，我们引用这个系统之后，我们在任何一个地点，周围所需的贴图量砍掉了70%，而且是在我们的最高效果下。我们有非常严格的管理系统，当我们玩家选择不是最高档时，我们还会进一步缩减贴图规模，保证性能不是那么高的玩家机器上，也可以运行得更加流畅。

　　

　　 接下来是模型LOD问题，单一视角下的面数太多，带来很多性能上压力，我们要怎么处理这个问题呢？我们又不能生成太多的LOD模型。

　　

　　 场景模型LOD，我们定义三个要素，首先是目标，要控制预算是什么，我们希望在游戏中玩家任何看到的视角，他看到的面数有一个上限，我们希望玩家在任何一个角度看到所有的面数加起来不能超过50万面。替代资源比较麻烦，不可能给场景每一个模型生成替代资源，我们承受不了这样的资源增加，我后面会给大家解释。要去定义每个模型的重要程度，这就更难了，现在换个思路去解决这个问题。

　　

　　 场景模型LOD，我们定义三个要素，首先是目标，要控制预算是什么，我们希望在游戏中玩家任何看到的视角，他看到的面数有一个上限，我们希望玩家在任何一个角度看到所有的面数加起来不能超过50万面。替代资源比较麻烦，不可能给场景每一个模型生成替代资源，我们承受不了这样的资源增加，我后面会给大家解释。要去定义每个模型的重要程度，这就更难了，现在换个思路去解决这个问题。

　　

　　 这个问题就变成了一个规划的问题，我们对所有的场景模型每50米生成一个LOD模型，生成这么多LOD模型，完全不可能全部放在游戏中，我们只能选择其中非常少的一部分，那怎么来选？这是一个规划问题，搜索问题，计算复杂度非常高，我们为了加速计算，我们引用一个收益比的概念。

　　

　　收益比，我们每引入一个LOD模型，它肯定会让玩家看到的平均面数降低，降低的值除以引入这个模型带来的额外的磁盘上内存上的面数增加，我们发现这个比例越高，说明这个模型相对来说，占的空间越小，但是减少的面数越大。所以这是追求最优化收益比的东西。我们会把所有的观测点分为两种情况，一个是玩家看到的面数超过50万面，这种情况下不去加载，按照刚才所说的收益比，逐步生成每一个LOD模型，直到达标（小于50万），如果还有剩余运算空间，我们会对所有20万面到50万面观测点，计算其平均面数，只要还有空间，我们会继续生成高收益比的LOD。

　　

　　 这是我们场景模型LOD的优化前后对比，变化比较显著，做了LOD模型后，外轮廓有一些变化，玩家不进行对比，很难观察到这种小变化。

　　

　　 这是我们场景模型LOD的优化前后对比，变化比较显著，做了LOD模型后，外轮廓有一些变化。但是玩家不进行对比的时候，很难观察到这种小变化。

　　

　　 这是我们场景模型LOD的优化前后对比，变化比较显著，做了LOD模型后，外轮廓有一些变化。但是玩家不进行对比的时候，很难观察到这种小变化。

　　

　　 这是我们场景模型LOD的优化前后对比，变化比较显著，做了LOD模型后，外轮廓有一些变化。但是玩家不进行对比的时候，很难观察到这种小变化。

　　

　　 效果非常好，在人非常密集的场景中，可以把玩家整个渲染面数从183万面直接降到48万面，这样带来性能提升是非常巨大。

　　

　　 Proxy系统。

　　

　　 Proxy系统。

　　

　　 在我们做完这么多事情，这么多优化后，到我们面对美术时，还是发现力不从心，我们发现把所有的LOD技术、所有自动化距离判断技术、材质排序等各种技术用上好，场景性能还是非常差。在一台相当好的机器上，它只能跑到30兆，这对我们来说是不合格的。即便我们做了这么多优化，它的DP数量太多，显卡根本没有跑满，我们怎么处理这个问题？

　　

　　 我们发现在非常好的机子上，FPS只能跑到30帧，对于我们来说是不合格的。即便我们做了那么多的优化，DP数量还是太多，从而造成了CPU的瓶颈。

　　

　　 我们引入了Proxy系统，它会做空间的划分，首先水平上把空间分为100米×100米格子，对每一个高度每隔100米再进行划分，这个空间及中间包含的所有模型，称之为Proxy分组，我们还剔除中间包含数量太小的分组，对其他合格的Proxy分组，会对每一个Proxy分组，生成一个Proxy Model，我们简单把Proxy分组所有模型的三角形焊接在一起，形成一个巨大的模型，进行一个简单的LOD处理，就只需要一个DP。

　　

　　但是光有这样一个模型也不行，因为贴图很分散，我们每个模型有自己的shader，参数，这么多事情怎么办？我们不得不写一套烘焙系统，把每一个模型，自己用到的贴图和参数等标准化后，烘焙到一张巨大的贴图上。我们有了模型、贴图，就可以渲染整个Proxy分组。

　　当我们离Proxy分组比较近的时候，把里面每一个模型画出来，DP还是那么多。

　　

　　 当我们走到稍微远一点的距离后，在我们的《天谕》实践过程中，这个距离一般300米左右，我们希望Proxy模型切出来，完成DP缩减。实际过程中，立方体够大，对角线170多米，很多时候消失距离并不能那么好匹配。一个模型在300米处消失了，在300米距离处，虽然我们做了一些预留空间，但是有可能出现A模型消失了，在切Proxy的时候它又显示出来，对玩家来说很奇怪，是一个BUG。当Proxy分组中任何一个模型消失的时候，我们会主动把这个Proxy模型切出来替换掉，这样会让整个Proxy模型切换稍微早一点，可能影响一点点视觉效果。

　　

　　 这是Proxy LOD切换，随着距离变远，对于面数很大的模型，我们会在做几级LOD。

　　

　　 当距离远到Proxy分组中每一个模型都超出显示距离后，会把Proxy的分组消失掉。

　　

　　 这是Proxy优化前后效果，首先有一些细微视觉上的差异，优化前和优化后，我们Proxy切换不是那么精确，有时候把本来应该消失的模型又显示了，我们发现做了优化后，建筑显示效果更好了。

　　

　　 这是Proxy优化前后效果，首先有一些细微视觉上的差异，优化前和优化后，我们Proxy切换不是那么精确，有时候把本来应该消失的模型又显示了，我们发现做了优化后，建筑显示效果更好了，更加密集了。

　　

　　 采用Proxy技术后，我们直接把星纪城首都的DP砍了一半，帧率立马提升了一倍。我们生成40个Proxy模型，占用不到9兆的空间，这个收益是非常大。

　　

　　 简单的总结，《天谕》引擎支撑次世代大世界过程中，首先是基础低年，我们在项目中期做次世代大世界引擎时，任何东西都必须严控上线，同时充分利用好我们的Streaming，充分利用磁盘IO。第二点，我们对每一种类型的资源，都会非常精细的定制LOD系统，它的目前是我们刚才限定死的预算内，尽可能从视觉重要的角度，让视觉重要的模型有更多的机会显示出来，达到更好的效果。最后我们引入Proxy模型，是更高阶的概念，为什么更高阶？之前所有的优化方案都是针对单个模型，Proxy可以跳到更高层次上，可以对一组模型进行优化。

　　我们相信随着Proxy系统向美术的推广，我们整个美术制作整个世界的时候，更加理解我们Proxy系统，我们的《天谕》可以做出更大的世界和更恢弘的主城。

　　

　　 感谢我们整个引擎组，做一款次世代客户端引擎，需要的不是一个人，需要大家一起努力，才能把这件事情做好，希望大家把掌声送给我们整个引擎组。

　　我的分享到此结束，谢谢大家！