【十一干货】腾讯技术美术师杨拓飞：我们是如何用Houdini技术制作开放世界场景的_游戏陀螺

整理 | 游戏陀螺

9月21日，在腾讯游戏学院举办的第三届游戏开发者大会（TGDC）上，来自腾讯互娱天美工作室的技术美术师杨拓以“善用过程化技术，助力大世界的场景制作”为主题进行了分享。

他提到，在IEG内部的工作室，Houdini技术已是一种被广泛使用的技术，充分利用这项技术对于推进过程化方案，制作开放世界场景十分有效。

以下为游戏陀螺整理的分享实录：

这几年过程化大世界游戏逐渐变成了热点，很多项目组也都自己定制了新的大世界游戏。另外的做法是在上线的游戏项目中加入BR玩法，拓展新玩法。过去一年来我主要的工作是在天美已有的产品线上为他们加入一些开放世界的内容。

我今年开始另外一个工作，主要是服务天美两款新IP的3A级别的开放世界游戏的管线制作和搭建，培训场景美术人员，以及相关的TA人员。

大世界的制作技术其实已经成型很久了，最近逐渐被人重视起来的原因，一是国外3A大厂游戏品质不断提升，在背后推进场景制作技术的发展，特别是Houdini技术逐渐被国内的各个工作室了解和接受——IEG内部每个工作室都有自己的一套Houdini管线，而且大家都在推进过程化的方案。

之所以TGDC邀请我来做演讲，主要的原因也是因为天美通过一套自己对产品线的需求分析，以及对分析得到的过程化技术的方法定义，通过这套方式很好地把Houdini这套管线技术落地到已有的各个项目里，并成功地发布到线上，得到一定的肯定。

接下来根据我为几款重要IP游戏所做的管线分析以及定位，来进行方案的描述。如果你要具体管理一个游戏的开发，或者作为场景主美需要游戏管线，希望这些方法可以为你提供一些建议。如果你是Houdini工具的开发者或者是过程化技术的开发者，希望这次可以帮助你们去梳理管线的一些问题。

当设计开放世界的时候，对场景制作有什么要求？

为什么要用过程化技术？是因为开放世界制作的要求。我们所定义的开放世界类别的场景要求，我分为两部分：

**第一部分，如果大家对吃鸡、BR玩法有所熟悉，通过它的场景可以看到，首先它的区域比较广阔，可能至少是4×4公里或者8×8公里，**而且里面要有树木配合大家躲在树林对着射击的玩法，而且要有密集的草地，可以趴下在地上躲藏；有道路可以通过载具快速移动到不同的区域，以躲避毒；而且要有丰富的建筑，建筑里面可以探索你要的武器、道具，可以进行一些躲避工作。这可能是关卡美术对过程化场景制作的要求。

**第二部分，关卡策划对场景的要求。**传统的策划要求是在场景里面圈一块地方，在这个地方摆一些玩法内容。今年以来有一些新的BR玩法或者开放世界的玩法，除了关卡策划要办法和PVP相关的物件位置以外，还要加入新的场景互动，比如攀爬、跑酷和掩体具体的躲避的玩法。

我先从关卡美术这边来介绍，大家想到的开放世界，**第一点是非常大的地图，而且有非常丰富的地形地貌，**比如对应的不同季节的草地、雪地，包括丘陵、山地、雪地以及平原的效果。以往MMO里面也确实做了这些，IEG过去的游戏并没有做到完全无缝的游戏世界，有时候你去切换一张大地图的时候才会具体替换到新的地貌效果，而现在最新的开放世界要求的是你要把所有的地形地貌集中显示在几公里的范围内。比如《王者荣耀》的BR图，三种地貌显示在1x1公里的场景里，其他的BR游戏是在8x8公里或者4x4公里中，至少实现2-3种地貌的混合。这也是需要我们有一套比较好的过程化工具来对它进行管理。

**第二点是当你的地形做完以后并不代表场景有生机，给场景带来生机勃勃的感觉首先要素是植被和生态系统。**植被和生态系统设计的要求，首先是植被需要去对应到具体的地貌上去的，比如绿地要长绿草，沙土上不能长草，有湖面的地方不能有任何树木生长的，但湖边的地方可能需要要长一些简单的小草，而越靠近沙土的地方草的密度越少，而实际上美术对于根据地形地貌对植被的生长有严格的控制和规则。如果传统的用笔刷的工具去刷的话，或许一次可以用人力来完成，但是一旦你的水面有些变化或者场景有些改动，那么你的美术又要频繁根据你的地形地貌的改变去重新对植被进行修改。这明显是对美术制作体验有非常大的影响，也是需要有工具去解决。

**有了植被和生态环境以后，你想进一步增加活力要素的话，那就要有人群的概念，有人群必定要有人群所居住的环境，也就是城市规划。**城市规划里面跟自然环境最大的区别是自然环境也有自己的规则，但受到环境的影响有一定的随机性，而城镇其实包括从最初的道路的规划到道路划分出的区块，以及区块中的房屋和房屋周围的花园，停车场等等。另外小区房屋之间有些要有通道，而且道路周围要做绿化，可能是按照一定的距离去摆放你的树木和路灯，这些是一层一层的规则叠加下来，这是一整套规则的树状结构。一旦处于规则顶层的道路发生了变化，同样也会引起道路周围每个要素的变化。这个东西也是整个的一套城市建筑的制作方案，也应该一套标准的流程对它进行管理。

**第三点，细化到城市里的某栋建筑或者某个房间或者一栋楼的时候，这时候就关系到美术或者原画需要对这个建筑风格和效果做把控。**通常来说这些都是通过外包来做，我们怎么用更好的方式让外包控制一个风格的同时，能够加快制作效率，能够快速地去铺量的制作一整个城镇，以及城镇的细节变化，这点也是需要有工具能够解决的。这些可能就是说我们要定位我们的过程化工具在美术方面的几个点。

除此之外，前面也提到，关卡策划除了把PVP、PVE玩法相关的，比如设计出生点、对战掩体外，还要有跟场景的交互。

**第一点是像跑酷，场景里面每个花坛、垃圾桶、障碍物，每个房顶，以及房顶与房顶之间要能够跨越，实际上都是依赖于你的建筑之间的摆放的触发器来控制。**当我的角色跑到绿框的时候，触发器才会触发按键提示，玩家确认后角色做出跨越动作，而物件上面的绿框用来辅助提示角色能跨多远，通过参数来控制动画蓝图做出。如果每个建筑物件都要人工配，而实际上一个大世界有成千上万的部件，而且会经常有调整，全靠人力是不可行的。因此我们需要把这些物件进行模块化，通过模块的方式来管理每个物件的触发器。另外一个是要有自动化的工具，根据建筑的形状来自动的把对应的触发器生成出来。

**第二个玩法是攀爬，我们的角色可能不会像蜘蛛侠一样，在场景的任何地方都可以爬、都可以跳。**像《谍中谍》的阿汤哥一样，所有的攀爬都是要基于物理正确性，也就是说建筑哪里能爬、哪里不能爬，这并不是纯粹靠程序或者游戏玩法系统去控制的，而是要由美术在视觉上做提示或者策划在玩法上做限制，有统一的规划。这样才能确定一个人可以通过设置的攀爬线，从房底爬到房顶——红线就是攀爬线，当角色有攀爬线的时候，才能趴在墙边上，玩法程序是说根据攀爬线的位置信息，结合建筑的物理碰撞体，最后得到配合他的动画蓝图的系统，最后得到一个正确的攀爬动作。

**第三点是大世界的核心玩法掩体射击和掩体移动。**角色可以沿着隔离带进行横向移动的。那么角色在一个位置上可以如何去移动，是根据绿框的信息来的确定的，绿框代表着首先会告诉角色的的控制系统，在这个位置我能做什么动作，比如中间我只能横向移动，或者像图中的位置可以进行蹲下的掩体射击动作。如果在建筑的两边可能就是做向外的掩体射击或窥视的动作。而且这套掩体系统不光是玩家角色使用，如果你是PVP游戏，首先机器人AI也是要依赖这套系统；如果做PVE游戏，可能你的队友AI也是要依赖这套系统。其实这可以说是第三人称射击游戏的核心支持的组件。这个东西如果不考虑是程序或者是策划的诉求，而是直接生成或者人工摆放，这也是非常大的影响制作效率的地方。

总结起来是这两款大世界游戏面临的几个综合问题：

**1、巨大的美术工作量会导致外包的数量，**以及有大量要在编辑器里面手工编辑的工作，这是需要解决的；

**2、巨大的工作量会引起游戏包体的膨胀，**现在实际上虽然是做3A手游，还是要受到手机移动端的渲染、内存的压力影响。如果你想说，现在这款游戏能够在国外或者欧美市场上市，那么你的硬件可能只有给你1G内存的使用量，1G内存使用量意味着不可能把非常丰富的资源直接全部加载到场景里，而是需要用模块化、实例化的方案解决。

**3、一旦你加入更多策划性的玩法，实际上就需要在制作场景的时候要有场景美术，要有场景策划，要有具体的场景的渲染人员以及玩法相关的这些开发人员，大家一起讨论这个问题，其实它会导致非常大的沟通成本。**而且这个沟通成本并不仅仅是在上线以前，而是在整个项目的生命周期内，因为上线后会不断开发新的关卡、开发新的玩法和PVP的地图，所以如果不解决的话，它会是长期的成本问题。

基于这些问题所在，我们定义了自己的场景开发管线的方案。我之前提到的过程化技术，过程化技术是什么呢？我通过几个例子来介绍。我解释过程化技术，它是美术提供的一些元素，包括基础的图形参数或轮廓元件，以及提供的一些可以调整的数值，最后加上一个可以抽象出来的公式，就能够到你最后想要的结果。以游戏贴图制作为例，很多美术都用过Substance Designer，这张图最左边是用SD生成的形状，可以理解为是你的过程化的输入项。中间部分颜色是你过程化输入的参数，最右边是你得到的最终结果。只要你修改你的输入项，修改参数就可以得到不同的结果。过程化贴图主要是用在地表贴图和一部分过程化生成的建筑里，比如墙砖和房顶的贴图，可以做四方连续的图，有些会用SD。

“我们的过程化技术其实是以点云为驱动的过程化技术”

接下来要讲的是**过程化建模。**这个东西是Houdini软件和官方主力推的事情。你可以看到这里通过简单的建筑模型加上一定的算法和参数可以把简单的模型变成比较复杂，有一定美术感的场景。这种一个简单的地表平面加入一些参数就可以把它变成类似这种Top Down视角的游戏关卡，我在地形上连上一条曲线，用曲线读取地形信息，得到的是我比较物理正确的去冲击地形的河床以及这个河床所生成的河流效果。目前来看，Houdini官方网站的推广大部分都是这类，可以很方便地帮你通过一些简单的点线面的输入得到最终效果，我们的态度是说这个东西有几大隐患：

1、以河流为例，河流横穿8×8公里的地图，意味着只要你这河流改变一点参数，河流横穿的8×8的地块都是被“污染”掉的，也就是说需要重新构建的。如果有人开发手机游戏就知道我们的游戏每天都做增量构建，每天也做全量构建。如果你的地图所有地块每天做全量构建，对游戏场景开发迭代很不利的。

**2、你创建的资源每次修改都是一个新的资源，新的资源意味着要重新放到引擎里。**如果Unity要重新映射，UE4要把它导入UE4的引擎里面生成一个产品，这些资源的修改在引擎里面是无法做增量判断，任何的修改都是一次新的改变。比如说你过了几天以后要返回一个比较旧的版本，但很抱歉，你不知道改了什么，只能通过Houdini的节点修改来做判断。而且如果你们当初做过游戏，可能有些人会在场景里面拜访一个场景，里面有几百M，大的上G，这时候如果导UE4和Unit，根本无法维护版本的可维护性。因为升级包体和更新包体不可能一次更新几G，最多更新几M和几十M。这个东西对美术的可控性很差——你做一些自然环境也许还可以，但是做建筑类或者做一些特殊艺术性的东西，美术需要有非常强的可控性，除非操作Houdini的人是主美或者非常有艺术素养的人做，可能可以做出好的效果；但如果只是TA或者以前做过特效或者是对Houdini的工具非常熟悉的人，那不一定适合。其实会导致虽然你Houdini做得很快，但效果并没有外包做得快做的好。

**正常的方法是什么？我们定义为模块化点云方案。**现在所有市面上的产品，特别是国外3A的产品其实大部分使用也是基于点云。点云是什么呢？这里介绍《使命召唤》移动版的场景里面植被点云生成的流程，你可以看到我通过把地形地貌的坡度信息、高度信息以及它的地形图层的信息总和生成在Houdini里面，把它转成一些点。

你可以看到Houdini的实例图里面，第一个例子，这些点包含的是这棵树或者这种树的大小和缩放信息和旋转信息，这些信息的包体量大概多大，一百棵树可能就几K的数据量，而且这个东西通过渲染引擎的实例化方案，一个批次可以完全渲染完。这样的方法可以说以第二个CODM的草体来说，同屏的草体是多少？同屏的草体可能是十万级，而这十万级真正用到的是两种草、两种花、一种石头，我的包体可能就是这5种资源加几百万级的点云信息，而且这种数量信息除了位置信息大家知道在MAX编辑里面，U位置信息是是小数点后多少位，旋转信息可能只是以30度或者15度为Snap单位旋转，旋转信息是可以压缩优化的，你的缩小信息是可以压缩优化的。这可以保证你的场景是非常小的数据组成。最后导入到场景里的话，比如我要换另外一种植被效果，只要换一棵草的样子，整个场景的草都换了；换树也是，只需要修改一棵树。优化下来觉得性能不好，要降低草的密度，我只要点一个参数就全部改变。用这种方法我们就可以很快不断迭代、不断尝试，真正适合不同手机平台的场景的植被的复杂度。

第二个例子，这是我们做的建筑的实例，其实是欧式建筑。**这个欧式建筑的组件是10-20个，我们还是一样，先通过点云组织位置信息，每个点实际上是一个建筑模块，我们把建筑模块和这些点云信息组织完了以后再做细化的替换。**这个楼房也是，如果我想改变楼层只需要调参数就可以，如果要改变大小也是调参数，如果我们觉得这个楼房的内存量太大，可以优化缩减每个单元模块的面数、贴图的使用，这样就是给予了我们场景非常便利的优化条件。

通过这种方式，我们整个游戏场景就是一些点云的组成，树、植被、建筑包括所有的道路都是点云构成，这些点云导入虚幻引擎或者Unity引擎里面，通过实际化渲染，一个批次就可以全部渲完。这个东西优化起来直接调参数就可以优化，不是每次要改什么东西还要反复调。

这些建筑都是用同一套点云生成方案组成。通过一些简单模型就可以把外型确定出来，具体的效果会在UE4里面替换不同的材质球，得到不同的表现效果。如果材质球可以合批成到一个材质球上，整个楼可以保证几个批次就完全渲完。

**总结一下，我们的过程化技术其实是以点云为驱动的过程化技术。**正是因为有点云的组织结构，我们所有的操作、所有的变化是可以通过一个EXCEL表就知道我加了什么、减了什么，也可以通过分析EXCEL表或者数据表的格式，知道某个单位内我们的美术资源量到底消耗了多少。也是通过这种方式我才有可能把非常大密度的建筑或者社区手机平台上渲染出来。接下来我会基于点云系统才可以给予游戏的可迭代性。

融合Houdini与点云系统，实现产品的高效迭代

什么是美术游戏开发的可迭代性？这是大家作为美术人员都很了解，场景开发是从概念设计开始，做顶式图；然后关卡策划和关卡美术加入，一起把灰盒搭建出来，当灰盒测试完成以后再发包把整个灰盒的场景真正做成有细节、有色彩、有美术艺术效果的场景，而且这个时候如果我们需要对场景做变化，我们可以通过SD的方式修改材质球和贴图，最后打光得到一个效果。

这个流程是瀑布式的流程，优秀的美术团队可以做到第一步到最后一步一次性不做任何修改的完成，问题是一旦你的关卡策划对这个场景有变化，小的变化还好说，可能我这里面要加一个东西、减一个东西，这里面要放新的东西，你做微小的修改就可以。大的变化是整体场景风格的变化，比如这是一个平原，哪天觉得这个游戏玩法好，要变成山地，这不是美术做简单修改的问题，而是重新考虑你的建筑和你地形融合的问题。这时候你用过程化技术，用Houdini生成地形，通过Houdini与这套地形和点云系统做融合，你就可以很方便给予迭代性。

**另一个影响的主要基点是适配性的问题：**比如我的整个建筑都已经做完以后，把它发包放到手机上，这时候手机测试说哪个国家那边的手机都是三年前的机器，东西跑不动，但是我要它上线，那要削减每个美术资源，把面数做减法、贴图做减法，全基于模块化组成，首先你只要改一个模块的面数，整个场景里面所有用到这个模块的地方都会削减。**如果你通过点云的方式去维护场景的细节，比如说你一个建筑周围有些花草、有些小的摆放物，你直接说因为我的包体不允许把这些摆放物隐藏掉，也需要删除点云就可以。**美术的手工操作是没有任何的操作的。

这是模块化的例子，首先我们也是说先做一些白模模块，把模块通过Houdini工具去把它进行组合，然后通过去修改不同贴图和材质的效果就可以做出不同风格的变化。另外像这种模块我的另外一个用途是，比如掩体系统可以直接在模块上制作出掩体信息，跑酷信息和攀爬信息做出来，点云组合的时候，也根据合并逻辑把信息再进行加减法，比如两个墙壁反过来叠加肯定是做不了掩体。这些我们在Houdini里面用算法进行了判断。

**可迭代性的价值在于，我认为是关卡美术把关卡策划以及玩法程序之间的工作剥离出来。**从关卡美术来说，关卡美术我只需要前期把每个模块的基础单元提供给关卡策划和玩法程序就可以，我自己就放心的去做外包、做我的设计，而且我所有的建筑构成是通过点云、通过Houdini的组建方式拼的，我只要按照这种方式拼肯定可以达到最终的效果。而且这时候关卡策划可以通过简单的模型先搭建玩法，验证设计的方式。而玩法程序也是一样，拿到最简单的模型和最简单的导航线和攀爬线各种数据，就可以自己组。

等到美术回包以后，大家在一个阶段把所有资源全部替换成新的美术资源，这个阶段都是无缝的，不会影响到每个行业的操作。如果到了某个程度，这个关卡策划要改规则，大家也就一样，重新回到最原始的模块的规则修改，美术什么都不需要改，而关卡策划和关卡程序只需要修改模块的生成规则。导致所有的修改量是可控的，保证在非常小的范围内。

这张图，如果做过Houdini你们就应该了解，它实际上是Houdini怎么最后运行到UE4里面的过程，我把它理解为是我们天美过程化管线进化的过程。最左边是我直接在Houdini里面做一些操作，在Houdini里面连节点、生成东西，生成点云，自己随便写一个工具导进来。更好的方法是通过Houdini引擎，直接在Unity或者UE4里面读到Houdini面板，我通过调整面板，然后在底层调Houdini的库，调HDA，然后重新生成。最终形态是说我直接把Houdini里面的算法以及它的节点内容直接翻译成的Python或者C++这种程序的语言，就可以得到一个高度集成的工具。而原始的的方法，大家在Houdini做完后在统一导入到UE，Houdini里面看到的东西和引擎里面看到的东西不一样，你要想办法说我需要这个开发人员有一定的这种从抽象能力到渲染最终效果模拟的能力。不然就很难把需求做好。

我们在推行Houdini的过程中，很多美术也有这种诉求，你这个工具越集成到编辑器里面，美术的接受度和可承受度也会越高。所以天美现在的方法，最初的时候我们会用Houdini去做游戏的原形开发，所有的算法没有用任何Houdini的功能节点，所有算法是基于Vex和Python进行，Houdini另外优势是这套Vex的参数调整模板，可以方便控制点云和生成简单的几何体，当时机成熟以后会把整个Vex体系移植到UE4里面，过程化方法不光是离线技术，还可以做到直接实时加载、实时生成、实时组织。这点也是我们能够真正推进天美把Houdini真正推进下来的原因。

**最后就是我们对整个过程化管线的定义，它到底是什么呢？**我觉得分三部分：

1. 对美术要帮助美术提高效率，同时解决以往美术大场景开发时候的迭代问题；

2. 在玩法方面要支持玩法和关卡策划的各种需求，而且是需要能够配合关卡策划、关卡程序一起做事情；

3. 另外在渲染上是必须要保证渲染效率在手机上达到3A品质的同时，不影响帧率，同时你的包体不管是做更新还是做全量还是做日常迭代，这套流程不能影响到整个每天的生成的规则。

也正是因为天美是以这套方案或者这个景愿在推进Houdini技术，它才能在短短一年内在三款线上项目里面把Houdini技术落地，以及在最新和大厂的合作中让大家接受用这套方案推进自己的开放世界游戏。

实操：过程化技术落地项目的实践

第三部分我是具体讲几个我们现有的例子，举两个例子，自然环境，地貌加植被，另外一个是建筑管线。

**1、地貌制作。**大家用过UE4地貌，你才知道UE4地形是有图层的概念的，因为渲染的采样数16次限制，导致一个地形，实际上一个地块上最多只能支持4个图层，包括现在很多线上项目，每个地块上只能有4个图层，这里面绿地、斜坡、沙土以及道路是四层。这四层如何做迭代呢？每个层有自己的权重，通过权重值的混合，得到最终的结果。这会有什么问题？首先，严格限制地形最基础的组件，只能使用4层图层，如果我想要用更多图层怎么办？有些项目是创建多个材质球，这边用这4种图层的材质球，那边用另外4种图层的材质球，这确实是一种办法。如果10层以内可以用这种办法。另外一种方法是直接用Virtual texture或者基于TexAray的虚拟贴图方式，确实也可以解决一部分采样数限制的问题，但是权重的总数还是会受到限制。这是我们现在项目的一个最初原形遇到的问题，2公里范围内用50张贴图，这是UE4 连了50个Layer，首先它编辑Shader，如果不联机编译Shader的话，光编译就要等30分钟，我只要地形上刷一笔，它都要重新组织图层，肯定涉及重新编译shader，哪又是等待时间。这种方案美术根本没有办法使用的。

现在的方案，首先我们把40-50张贴图atlas到在一张图上，这是fallback的方案，另外一个方案是用基于TexArray的Virtual Texture的方法，就是动态的来组合altas，两个方法对美术的感官上是一样的。那每个图层是什么？以前一个层是0-255的值，是一个权重，可以是0~1之间，是根据255的值做权重，两个层之间会根据权重值做混合算法。如果一个像素上有4个层，就是4个层的权重一起混合。这会导致一个问题是，美术需要考虑控制权重总数，超过4层以后，权重总数怎么控制？或者地图编辑上刷一笔以后，这个层变成5层，导致shader变不过去怎么办？现在的新的方法是每个象素上只有一层layer，你可以看到这两张图的象素要么是0、要么是1，不可能出现0.1到0.5，或者一半这个元素、一半那个元素。这样的好处是不会因为混合导致这个层的颜色会受到污染。我们以前做这种产品经常遇到的问题，比如有一张沙子图或者绿草图，把这两张图按0.5的比例混合，得到一张黄草图，得到黄草图之后，玩家观察的时候黄草图上长绿草，玩家会认为这个效果不对。这种方案除了短暂的过度，大部分地方都是保证贴图的唯一性，像素上肯定只用这一个层。

**2、植被系统生成。**它是参考这几年GDC上的视频，用过的话看到这个界面就会很熟悉。我们读取地表的每层参数，比如坡度、地表的高度、AO信息，把所有的信息输出到一张表里，通过修改这张表，我们自己写了一套自己的Houdini的插件，这比原生插件的好处是不需要拖节点进去才能生成东西。我们把一组植被通过复杂的参数封装简化以后就是一组植被的节点，这是Houdini里面的效果，直接一个树、一个生成叠加起来，每个树的优先级和权重都不一样，叠出来就是比较丰富的植被效果，而这个效果不需要走Houdini，直接通过Houdini引擎管线直接调用就可以实现。

第二个例子是建筑管线的制作实例。前面说到所有建筑都是全模块化设计，在通过一个工具对它进行点云的管理，这个点云分为两部分：一是街区模块的点云，你可以看到这里做的圆形，如果街区做细分以后，我是可以在这里面生成很多点。具体的位置应该放什么楼、放什么东西，并不是通过自己计算它的位置得到的，而是通过筛选些生成的点得到这个位置能生成什么楼，然后根据美术和策划提的要求，这个位置需要有多少个高楼、需要多少平房或者某个楼一定要生产出来，那么最后通过这些点得到了正好塞到这个区块里面的楼房就得到规划比较好的城镇的规划。这就是简单街道的规划。

街道与街道之间，一个区块内部之间的规划，有一部分是需要我们用下一步过程化工具，我们会根据建筑周围的一些规则生成一些垃圾堆，在道路周围生成一些电灯泡、电线杆或者阻挡物，这些东西的生成是按层数走的，就是最底层的街道到下面建筑的分层以及建筑周围掩体的分层，每套楼层之间独立，不会出现点一下以后整个场景都变了，不会的。因为每个阶段就是一套点云，一个楼是一个点云，对应的楼自己所有建筑组件又是一个点云。最后，我们通过这个过程化生成一条街，然后生成一个城镇楼房的组合，然后导到UE4里面的效果。

简单介绍我们现在建筑的结构，这其实是我们结合合作方的方案去制定的，这等于所有的楼房都是基于这套面板做的，这套面板的主要功能是什么呢？首先这套面板原始的用Houdini做楼，可能拉一条曲线，通过曲线把地基弄出来。而我们的面板上描述的是整个轮廓的走向，当第一层轮廓确定以后，你可以调整它的层数，让它不断往上叠，中间部分可以增加拷贝的变化。另外当整个楼层确定以后，还有房顶部分，所有的部分的走势并不是通过曲线或者放几何体确定，我们的每个走向，包括房屋的拐角都是面板里面的节点确定的。这么做的好处是，我的节点可以覆盖所有的楼，包括高楼、矮楼和所有的房子，只要你有这种轮廓的现代建设方式制作的，你就是可以用这套节点涵盖。

这可以看到一个例子，红色部分是节点上面的一个建筑的标记，实际整个楼的每个部件都是对应有节点上的设置。当多个节点进行组合以后就可以做出各种丰富的建筑出来，而且所有的建筑、所有的楼都是通过一个节点制作。这样不会出现一个建筑是一个做法，另外一个建筑是另外一个人做的有另外一种做法的情况，没有这样的，我们的建筑是统一的做法，任何人做的楼，其他人都可以维护，而且这些都是基于Vex语言制作，随时移植到UE4里面，可以摆脱Houdini对我们的控制。

Q：UE4开发移动端3A品质场景的关键点是什么？

**A：**这个关键点我个人翻译成两点：1、细节。以前一个建筑或者玩过IEG BR游戏，它的建筑就是简单的图。到3A品质以后建筑要有更加复杂的轮廓结构，包括有些一楼可能要通过内置贴图的算法把细节做出来，首先质感、建筑的细节是要能表现出来。

2、整个建筑的数量，你需要把真实的城镇做出来，像深圳重要的商业区整个物量非常高，压力不仅是美术的制作，压力还在渲染制作，等于你做3A级品质的时候要充分考虑到制作的这条管线能否支撑移动端的要求以及对内存的要求，制作管线的时候需要有充分的可控性。比如一个30层的楼，30层楼横排10个窗户就是300个窗户，300个窗户用实例化渲染还是存300个窗户的数据量，如果这个楼在很高的地方，其实不需要用300个建筑做。可能把4×4或者9×9做成更大的单元更好一点，那就需要在工具里面提供这种合并实例的功能，这样能保证你在具体的3A品质上让你的品质在3A移动平台上跑起来。你确实要有类似PC 3A制作的理念，另外你还要充分考虑到移动端的硬件的压力，你需要留足够给程序做优化的可能。我们现在的方案考虑了很多，如果最新实例化渲染GPUDriven的剔除不行的时候该怎么做。

Q：Houdini的软件在你们的项目和制作管线中的具体定位是什么？

**A：**天美对Houdini的定位，首先是原形系统，我做任何过程化工具的时候先在Houdini里面做，它的优点确实很快，一个TA可能一天制作一个非常复杂的面板。程序在UE4里面做界面，大家也知道这个很难，Unity可能会好一点。第二点，我们对里面的节点使用有非常严格的控制，如果不用那种循环我们尽量不会用，如果能够用简单的脚本语言或者算法语言，基于Vex把你的工具能完成，我们不推荐使用Houdini里面的节点，这样保证这个功能将来可以移植到UE4里面去的，而且有些功能将来可能直接做成Round Time的特性实现，否则如果不这么控制，每个美术或者每个Houdini的TA在Houdini里面维护自己一套节点，这就和UE4里面做材质球一样。UE4特效可能可以做一个材质球，特殊的需求可以做材质球，大部分材质球还是要基于材质模板，否则每个人连这种图，到最后会发现连这种图的除了用的人，其他人根本不了解它怎么做的。而且像复杂的植被，如果不能抽象成一个节点，会导致你到后面的维护节点的成本和Houdini带来的红利完全不成正比，会花很多时间在维护Houdini上。其实UE4自己也在不断地更新它的地形系统、更新它的植被系统，所以做过程化的另外一个风险是，如果你的工具链不够完善，就被UE4或者Unity原生的功能超车，这块要充分考虑到未来会不会有这种可能性。

现在的几点，首先我们的节点全是Vex做的，我们的节点布局是Python控制，我们所有节点布局可以通过Python脚本和类似的文件描述。如果我们想要一套节点是读一个脚本，自动化把所有节点创造出来，把每个语言的功能块做成VEX单元组合起来，你可以理解我们的Houdini是全程序化控制，不需要美术做任何参数，美术的需求是他们提要求，我们继续提供最后的方案。

Q：过程化管线推进方面有什么心得？怎么更方便让这个技术落地到项目里？

**A：**你用过程化或者用到Houdini就要发挥它的优点，优点就是快。用一个功能让美术等三天或者一个星期，实际上是有问题的。我之前举的例子，包括王者、CF、CODM，给Houdini管线的时间只有两三个月，我们从定制管线到最终做完以及上线只用几个月时间，特别是CFM和CODM，我们去年10月份开始做，11月份CFM的管线已经做完了植被就可以上线。剩下这些人直接跑到CODM继续开发，CODM两个月之后场景完成，结果是如果你想落地，第一点要做到的是赶上产品制作的流程，不管方法是不是优雅，你想用上它就得尽力让它在这个时间点支持你的项目。很多项目组也推广他们自己的Houdini，但都没有天美落地的顺畅。他们统一的问题都是一个，实际上这个东西不是你做了好看的工具或者感觉非常花哨的功能，这个东西就有用。实际上是需要考虑到美术的诉求。

另外，Houdini为什么能够迅速在上面三款项目落地？因为Unity的编辑器很烂，这三款老的游戏都是用Unity5的，如果用Unity，到Unity2018以后，2019的地编功能就非常强了。UE4也是一样，UE4目前的版本不能很好的支持超过10层以上的地形图层的管理，40层以后没有办法管。那图层的修改、维护就得进到Houdini里面做，很大的缘故是当你的技术或者当你的需求、当你的引擎没有办法去替它做更多的支持的时候，其实Houdini确实是很好的软件。包括以前日本很多游戏公司直接拿Maya、Max做编辑器也是这个道理，当你的人员没有办法支持到项目的需求，项目又想在某个点上能够有自己的突破或者是爆发的时候，那么Houdini确实是一个非常方便的工具，因为只要有策划、只要有美术，它自己就可以搞定事情，不需要程序做过多的干预。

关注微信公众号：游戏陀螺（shouyoushouce）,定时推送，游戏行业干货分享、爆料揭秘、互动精彩多。