您需要 登录 才可以下载或查看，没有账号？注册
x
先是文章相关的视频文件、ppt文件和机器翻译文档的下载链接：
价格：10 元素币
百度网盘
收益：20元素币 销量：2 提醒使用【余额支付】需要： ￥1 余额
《幽灵行动：荒野》地形技术和工具
下面是一个震撼的大世界创作过程和技术演示视频-请登陆后支付1元素币 大型地图技术是近年来3A大作常用技术，所有厂商都在这里不计成本，重点开发 大世界技术也是当前游戏开发的重要技术壁垒，谁掌握的好就能甩对手很远 UBI在本作的地形技术耗时3年研发工具和制定流程，绝对是刷新大世界游戏最高高度的技术 这个视频是从GDC官方原版1小时的视频，剪辑出来5分钟，全部是精华和干货，有加速，有语音 因为文章有翻译，所以不用担心听不懂，感谢龚挺的翻译以及文章分享
龚挺
--今天给大家带来一个技术向的翻译文章。 我觉得对地编和制作游戏的各位来说这是个宝贵的资料。 虽然我知道大部分就是和我一样喜欢傻看图，图越多越好最后要网盘链接。 但是！有些事情总得人做，我们对翻译的龚挺这位朋友表示由衷的感谢，当然，同样感谢原作者大神！
文档翻译自GDC 2017的技术演讲文档：《GhostRecon Wildlands Terrain Technology and tools》； 文档其中穿插了若干视频演示，此文中以链接的形式给出；一些技术术语保留了原文以便于理解；以下为原文档的翻译：
主讲人为育碧的GuillaumeWerlé和Benoit Martinez；
GuillaumeWerlé是负责《幽灵行动：荒野》（以下简称《荒野》）地形系统技术相关的图形程序员，同时也是Demoscene社区的活跃成员；
BenoitMartinez是项目主美和技术美术总监，负责管理关卡美术和Houdini内容团队； 早在2011年就加入了育碧的《幽灵行动：未来战士》项目，并且是《荒野》项目的早期核心人员； 4年忙碌的过程中除了负责项目还要照顾两个项目期间出生的孩子。。。
《荒野》是育碧制作的有史以来最大型的开放世界动作冒险类游戏，使用了4层32k*32k的Heightmap；
游戏背景设定在玻利维亚，游戏场景有着很高的多样性，包括了11种完全不同的生物群落；
包括了湖泊、河流小溪的16平方公里的大地形，其顶点数将近9百万；
自然环境主要是由大量的森林组成，包含成千上万的树木、灌木和岩石等；
还拥有长达600多公里的公路和更多的小路；
以及贯穿了整张地图的铁路系统；
一共有200处左右的营地、地标性建筑、前哨基地，还有58个完全脚本化构建的村庄；
程序化开发工具及技术摘要： l 第一个原型 - 2012年开始制作 l 地形工具 - Guillaume将要谈到他创建的工具，以及地形渲染的一些细节问题 l 程序化工具 - Benoit将要谈到场景的创建工具和流程
https://vimeo.com/207479227 原型展示视频；
在《幽灵行动：未来战士》完成后开始尝试制作更大的地形； 配合world machine使用现实世界的数据获得相关DEM文件； 然后结合Houdini开发了一些工具如： l 自动生成自带LOD的Tiled Mesh； l 根据基于斜坡、高度、粗糙度和来自World Machine的其它蒙板如flowmap制定的一些规则，来定义材质分配的splatting mask； l 通过坡度，高度，材质，密度，树木之间的距离等一系列规则来获得植物的散布点； 原型只由4个美术和1个图形程序员花了若干个月做出来；
制作这个原型，先使用了《幽灵行动：未来战士》遗留下来的引擎：Yeti； 虽然我们用Yeti取得了一些不错的成果，但其还是不能满足我们的需求和野心，我们决定更换引擎：Anvil，刺客信条的分支引擎；
这个原型让我们认识到了两点： l 我们必须改进自己的地形制作流程；如处理模型需要在编辑器和各种DCC软件中来来回回，很不方便；因此需要新的地形制作技术：方便美术的编辑和满足运行时很好的性能； l Houdini被证明是一个非常灵活和高效的工具：技术美术可以在没有专门开发人员的情况下创建工具；
4年前加入育碧公司《幽灵行动：未来战士》团队的Guillaume Werlé，在原型开发的几个月后，就开始投入到了地形编辑器的研发工作；
在这几个月中，美术团队开发出了一套基于WorldMachine生成Heightmap的流程管线； 地形编辑器的主要目标则是使用这张高精度的而且不带任何材质信息的Heightmap，转化成一个逼真且多样化的世界：
上面的截图即来自于开发提交前几个星期，描绘了我们所想达到的目标； 我们需要近距离观看时的海量细节和令人惊叹的远景，且两者完美融合； 当调高图形选项时，像素比可以达到10texels/cm 和1 triangle/2 cm；玩家在游戏中可以到达任何位置，意味着整个世界都要达到以上的质量标准；
我们开发的第一个功能就是Heightmap雕刻工具；基于GPU开发有几个原因， 首先当然是快，我们需要能编辑巨大地图中的区域，一个简单的点击就能刷出一整座山； 还有就是在编辑地形时这是最好的能提供准确视觉化反馈的方法； Heighmap和笔刷混合在一个浮点渲染目标中（floating point render target），并且能被游戏Shader直接使用；
制作游戏是一个迭代过程； 我们需要在游戏中尝试各种新的创意并且不想在还原的时候花费太多时间； 所以我们想到了层的概念； Worldmachine的输出被保存在我们称为<base>的层，编辑器中的每次修改结果放在<macro>层；当不满意修改结果时，<macro>层中的内容可以被轻易抹掉还原成原始的heightmap； 以下是这个雕刻工具的展示视频：
https://vimeo.com/207479248
我们还建立了一个Houdini生成修改的专用层（<DCC>层），这是个非常重要的功能，之后会由Benoit在第二部分详细说明；简而言之，利用Houdini，技术美术获得了对地形完全的读写控制权；
最后一个层（<micro>层）包含了不能使用Houdini的关卡设计相关的修改；
现在开始说明材质分配流程；
刚才已经说到，我们需要一个看起来很真实、质量标准统一的世界；考量到地图的尺寸很快能得出结论：全手工去刷地形材质的话，就太惨了；我们需要一个半自动的流程，因此决定用程序化的方式来生成材质；
地形编辑工具中依靠法线方向给heightmap着色的方法就是一个很好的办法，根据这个简单的规则，已经能生成大效果不错的山顶了，我们决定扩展这个概念；
取而代之的是，在满足规则的条件后，显示的是有全特性的材质而不是纯色；我们设计了若干个判断条件，它们基于拓扑结构、噪点和能在pixel shader中实时求值的简单核函数（Simple kernels）；
上图是我们的编辑器设置界面截图； 可以看到其中的每一个设置都由若干个堆叠在一起的规则然后由尾部至顶部进行计算；最后一个计算规则成功的材质才被显示出来；
https://vimeo.com/207479253
现在一个简单的点击就可以刷出设置好的材质，但是材质间的渐变还是要花很多功夫去让其看起来自然； 我们决定扩展依靠“规则”的思路，来智能判断笔刷的透明度； 以下为一个展示视频：
https://vimeo.com/207479279
材质分布的结果之后被存储在2张贴图中； 第一张我们称为<splatting>，其包含了heightmap每个元素（entry）对应的材质索引；
第二张称为<Vista>贴图，看上去像是谷歌地图的截图；作用为渲染远景时作为albedo map；
所有东西都被切割为块（tiles），并被压缩成四叉树（quadtree）；这个简单的框架非常便于LOD的生成和patch的剔除； 根据剔除的结果和摄像机的距离，四叉树的每个节点都有个小的荷载由加载的进程流入或流出；
在开始讲渲染之前，简单的描述一下我们的材质相关；
游戏中的每个材质中的高精度贴图都使用Zbrush和Substance工具按PBR标准制作；
每个材质都含有置换贴图（displacementmap）； 基于曲面细分的置换帮我们在制作原型的时候达到了所期望的“次世代”效果； 这种非常好的结果让我们愿意投入更多的时间在GPU相关的工作上；
假如设定简单，大部分的地形同时使用4个材质就绰绰有余了； 但我们的地形太多样化，最后使用了143个不同的材质在地形上； 在一开始就全部加载它们显然不可能；
我们把离玩家最近的32个材质缓存在一个贴图数组（texturearray）中； 然后使用一个indirectiontable把全局splatting索引转换为本地缓存索引； 渲染近景的时候，我们直接从缓存中采样纹理；
了解了以上之后，开始讲我们的渲染流程；
这是近景shader的最终效果； 为了让大家更好的了解到其过程，我做一个步骤拆分展示；
在一开始我们获得splatting的索引； 把其转化为本地缓存索引； 然后我们从缓存中采样所有的PBR纹理；
为了获得所有材质间的良好过渡效果，我们再做了3次双线性插值（bilinear interpolation ）；
为了避免拉伸问题我们为斜坡使用了双平面投射（biplanar projection ）； 每个轴一遍，那么就意味着我们要把这些都做2遍；
第一个版本的shader取得了很好的视觉效果但性能消耗却很大； 太多贴图需要在pixel shader和domainshader中获取并混合在一起；复杂shader产生非常低的波前占有率（wavefront occupancy）导致了寄存器的高压力（register pressure）； 我们急需简化一些东西；
在做优化时，我们发现完全平坦或完全倾斜的地方不需要混合太多不同的材质； 因此可以为以上的特例做特定的shader；
这是我们对4个相邻材质做了双线性插值；
对斜坡做了双平面投射；
最后，在过渡区域我们仍然需要获取所有材质；
把地形分割成各个单独小块（patches）将会非常耗费磁盘空间；我们的解决方法是使用compute shader在运行时尽快生成进入Viewport的部分； 对性能的提升显而易见，现在大约80%的地形获取的是4个材质而不是之前的12个；
这时我们开始关注到另外一个挑战：道路网！ 运行时生成的话简直是技术上的噩梦，我们很怕假如要存储在蓝光盘上空间会不够用； 我们决定直接把道路嵌入到地形，而不是用传统的模型制作；但是这会产生一些问题，比如粗糙的材质过渡和明显缺少细节；
屏幕空间的贴花（screen spacedecals）看起来是个不错的解决方法；
但它们产生了过多的overdraw而很快被停用；还有就是它们不能影响置换拓扑；
在我们的案例中，Virtualtexturing技术似乎会是一个很好的优化方案；
这将大大减少材质混合的预计算和所有贴图集中decals的映射所需要获取的贴图数量；Virtual texturing技术已经在一些其它著名游戏中成功使用过，我想GDC在座的大多数人已经很熟悉其概念，所以我就不讲相关细节了；
每种渲染技术都有其缺点，virtualtexturing也不例外；我们尝试在以下几点改进这个传统技术；
最简单决定哪一部分需要virtualtexture的方法就是在离屏面（offscreen surface）中光栅化场景，然后在CPU中读取内容； 但这样非常耗费性能，特别是游戏在4k级别显示的情况下； 当我们的地形渲染使用曲面细分并且用较低的分辨率渲染目标显示细小的三角面时，会损失太多细节；
我们在Gbuffer通道绑定了一个额外的3D纹理作为渲染目标而不是使用专用的通道；当我们渲染地形时，使用UV和miplevel作为输出的坐标系来直接指定virtual texture的显示部分；
然后compute shader分析纹理内容和记录缺失的部分；之后结果信息（大小只有几个字节）会在CPU上读取；
当用最高的图形质量运行游戏时，virtualtexture显示达10 texels/cm 的像素比； 假如预处理并压缩，这些需要大约2Pb的容量；
所以我们决定在运行时生成这些内容，材质和decals在离屏面混合然后使用AsyncCompute管线实时压缩；但驾车飞驰时需要地图块的大量更新，很快就会帧率狂降这样的帧间低一致性（low frame-to-frame coherency）的情况处理起来很棘手； 多帧间的Virtual texture更新不得不做时间切分，以及还要做很多让高帧率和低潜伏期（latency）达到平衡的调整工作；
我们尝试成功的去把很费的近景shader替换成virtualtexturing； 幸运的是我们在开发前期就做出了这个决定，结果调整了内存的预算； 如大家所看到的，游戏在1080p的情况下运行时，存储atlas图大概需要200MB多一点；原生4k的情况下，会达到1GB左右； 译者注：把所有要混合的贴图做成一张贴图，这张图称为Atlas；
我展示一些xbox one上运行的性能数据来结束我的演讲；如上图；
（演讲人换为Benoit Martinez） Guillaume已经给大家讲了地形相关的方方面面，我来讲讲我们的程序化工具：它们是什么，如何工作以及其背后的理念；
规模 l 工具适合从大到小的各种规模的场景； l 编辑范围从最小的岩石到最大的山峦是制作这个工具的准则； 协作性 l 一整个巨大的关卡； l 两个在不同地点的制作团队：巴黎和布加勒斯特； 迭代性 l 我们需要能修改需求； l 试验新的想法； l 工具即为数据：工具的创建和存储与世界上任何其它实体完全一样；工具是生成自身实体的元实体； 当然最重要的是：每天都必须能保持其可游玩性；
l 基于规则的工具：使用者编辑参数和调整规则就能产生相关内容； l 确定性：相同的输入产生相同的结果； l 离线性：没有任何东西是在运行时生成；所有的都是在制作时烘焙的； l Houdini：世界创建流程管线和所有的制作的工具使用Houdini； l CPU：自从我们开始使用Houdini大部分工具都基于CPU（Houdini的最新版本能更好的支持GPU，但我们制作时并非如此）；依赖CPU并不是问题：CPU很便宜，但我们需要更多内存，一些工具非常占用内存！
什么是Houdini： l SideFX公司的DCC（Digital Content Creation，数字内容创作）软件； l 在特效领域大量使用（但不关我们的事）； l 我们用来进行场景创作； 我们用Houdini来做什么？ l 原型：很好的能快速实现想法的工具集； l 工具创建：创作相关内容； l 视觉预览数据/获取统计数据/处理数据/优化数据； 为什么使用Houdini而不是C++/GPU工具？ l 快速迭代； l 没有编译时间：工具是HDA（Houdini digital assets）- 在HDA中做修改或修复Bug -> 发布给团队 -> 每个人可以马上使用； l 性能问题？专用的工具当然会更快一些，但Houdini有无可取代的灵活性； Houdini团队： l 一个技术美术总监（Benoit Martinez）和三个技术美术创建了所有的工具并设置了流程管线； l 30个场景构建人员（由关卡美术和关卡策划组成）在开发过程中使用了这些工具； 我们所使用的SideFX产品？ l Houdini（DCC软件）-> 创建HDA/工具 l Houdini engine -> Houdini的核心API整合到了我们的游戏编辑器；在编辑器中使用HDA/工具； l Houdini Batch（渲染农场）-> 渲染农场中的计算工作；
地形的确就是其它一切的基础； 我们所做的第一件事就是创建了自定义节点来读取地形数据； 这里用一个应用到Houdini网格的地形块作为例子；如上图，可以看到若干个选项，现在获取的是地形基础层；
然后是选择了所有层； 手动修改的层（<macro>层和<micro>层）和生成的其它层如道路层等；
我们有很多在这个世界中填充大量物件的工具； 这些工具并不创建模型，而是帮助美术对已有的物件制定摆放的规则； 我们大部分的Houdini工具处理好摆放点然后返回引擎以下数据： l 矩阵； l 已有物件的ID；
https://vimeo.com/207489407 以上是展示工具创建以及为何快速和灵活的视频链接；
我们估计有80%的数据是使用Houdini创建或操作的；由于它们是基于规则的工具，所以能很好地保持一致性； 这些工具修改迭代世界中的大量区域，为美术节省时间，让他们能专注于更有价值且不能使用自动工具完成的任务： l 统一大局； l 赋予意义于这个游戏世界； l 通过场景环境来讲述故事；
地形只是最初始的一层，让我们来看看构建在其上的其它层的细节；
地形不仅仅是高度以及贴图混合； 我们推导出能够在其它工具中复用的有用信息，比如： l 从海拔高度中我们可以获得粗糙度、检测出山顶，这些信息对摆放石头或植被很有用； l 从河流、材质和一些特定的物件我们可以定义出潮湿度，然后可以使用在植被的规则中，或影响地形的高光； l 求阳光照射的平均值，我们可以得到一张有用的蒙版，用来驱动植被和环境音效； l 来自world machine的初始水流蒙版（waterflow mask）用来影响地形splatting；但是当地形被雕刻修改后我们想保持这张蒙版的更新； 我们在渲染农场中自动更新这些地形层： 每次当有用户提交了地形的拓扑结构修改，会触发Houdini渲染农场的重新计算；更新文件存储在Houdini工具可以立刻读取的服务器上；成为中间数据后可以随时更新，我们对此没有任何版本控制；没有版本控制和备份听上去有点吓人，但制作中我们也没出什么问题；
https://vimeo.com/207479343 在谈到我们工具集的具体细节之前，用以上的视频展示一下程序化生成的层； l 道路生成和程序辅助； l 野外的道路、植被、岩石；除了最后两块大石头是手动摆放其它的都是程序化生成，包括河流的成形、水体模型和流向； l 甚至村庄也是生成的，从仿地成形到建筑的摆放； l 带有隧道和桥梁的铁轨线路； l 在全局运作，连接所有的道路，计算flow map蒙版，摆放植被和村庄；
定义路点，通过寻路算法（Pathfinding）自动连接成道路；
第一次寻路的测试结果还不错，但还不够好；
我们开始试验加权各向异性（weighted anisotropic）最短路线算法； 其关键是搜寻多个方向和每个方向的多个距离，而不是之前的四个方向； 最后的结果正是我们想要的；
在地形上放置少量路点。。。。
我们获得了有各种类型道路和小路的统一道路网； 记住这都是离线过程；其计算时间并不是问题（2km*2km的地块计算起来只要10分钟）；
道路层输出的信息有： 道路轨迹：我们可以在很多情况下使用这些信息，如AI的交通系统； 地形塑造：一张heightfield贴图塑造了地形； Splatting：一张更新地形材质的贴图蒙版； 桥梁：假如是最优路线，我们允许寻路算法能跨过河流；
https://vimeo.com/207479385 展示寻路算法形成地形主干道的视频链接；
我们有手动创建decal、电线、栅栏和防撞墩的工具，然后当我们试图去构建一个完整、真实的公路网时，意识到我们只需要输入路网的道路轨迹信息到工具，可以很方便的生成这些道路辅助设施，不用人工去摆放；
铁路层同理，但其规则稍稍不同；更低的坡度，转弯少且平缓，还有更多的桥梁和隧道； 公路的道路轨迹信息为隐式输入，因为铁路需要考虑到公路情况，不能重叠（某些地方会平行）并且相交时要保持90度角来避免危险和潜在的交通问题；
https://vimeo.com/207479400 之前提到的一些工具，比如视频所展示的桥梁工具，可以在独立模式下手工创建桥梁或嵌入到更大的工具中去自动创建相关内容； 注意：桥梁或隧道是模块化的，并没有新的模型被创建，只是实例化而已；
游戏中16平方公里的地方被水覆盖； 这是一个被切分为块（tile/平方公里）的单独连续模型； 水关乎到湖、河流和小溪； 河流湖泊这些地形的主要特征可以在地形工具中直接制作； 另一方面数量庞大的小溪使用道路的寻路做法把山顶的源头和河流连接起来（然后河流连接到湖泊）； 对于地形地貌我们定义了一些层顺序，所以小溪会在道路下铺设的管道中流动，但河流我们更倾向于让其穿过桥梁来保持连续性； 我们生成小溪的轨迹信息后（还有某些河流）我们就能复用这些信息来定义flowmap的向量；然后flowmap被存储在顶点色中；
定居点构建工具是我们最复杂的工具之一； 输入定居点中心、建筑清单和一些参数来完整的生成游戏中的村镇； 我们花费了不少时间去做成这样一个稳定的、可用的工具，最后我们达到了所期望的目标； 程序动态生成定居点后，我们会把其“锁死”，让美术去手动添加更多的细节和润色；
https://vimeo.com/207479416 以上视频链接是定居点工具的展示视频；
农田生成工具可以单独使用，创建独立的农田；也可以把定居点作为输入值来生成其周边的农田；
我们用了比较传统的方式来做岩石的分布： 定义一张分布蒙版 - 美术可以在编辑器中直接视觉预览： l 分布规则应用在什么地方 l Material – Occlusion – Curvature – Flowmap –Roughness – postFilter 创建应用在蒙版内的分布规则： l 模型 l 相对坡度调整 l 比例参数 l 密度/最小距离
假如需要的话，分布规则还可以考虑到其它工具的结果，来避免石块与路面或建筑等重叠；
基本来说，植被工具用起来和岩石工具差不多，不过当然还是有自己的一套参数； 复杂的多功能工具维护起来也很复杂，并且效率也相对低下；各种情况下我们都更喜欢专用工具；
我们可以在开发过程中不断的改进这些工具； 为了避免每一个可能的用户都有特定的需求，我们决定每个工具都有一个拥有者；通常是一个美术与将创建相关工具的技术美术合作；为一个工具编写相关文档的也可以是工具的拥有者，来编写更友好易于理解的帮助文档而不是技术文档； 我们还整合了预设支持，那么工具拥有者就能够创建一系列规则，其它的用户可以直接使用这些预设值而不用去理解和使用所有的参数；
排除法工作流： 混合程序化内容和手工控制是非常复杂的； 假如想要好的手动控制那么就应该纯手工去做；所有的工具都支持输入手工定义曲线来排除某个区域，或隐式输入（比如：排除道路上的植被）； 使用这个工作流，负责植被或岩石摆放的美术可以不用考虑村庄、道路等诸如此类的问题；他们只用任意定义生物群落的规则，必要的排除过程会在之后的整合过程中完成； 异步更新： 我们需要保证一个始终可游玩的世界，但并不意味着其要很准确； 假如地形的拓扑结构修改了，我们不必完全重算植被的摆放，大部分情况下我们只需要保证没什么东西挡住道路并且所有东西吸附到了地形； 记住这些工具是独立使用的，不受其它物件摆放的约束，并且它们都应用在原始的基础地形上； 我们还有“点缓存（pointcache）”，所有point来自各个工具； l 首先编辑器针对地形检查所有实例； l 把所有的东西吸附到地形(保持所有的地形相对偏移 - 想想陷入到泥土中的石块) l 删除程序地形化区域所不需要的物件 l 从道路、河流和定居点等等地方移除植被； l 然后针对所有实例组间的相互关系 l 桥梁和隧道则删掉石头 l 石头上则删掉植被 l 电线不能穿过树木 l 还有诸如此类的情况。。。。。
当我们能获取Houdini上所有的数据的时候，我们能做的不止是物件的摆放了； 这里我们在检查物件密度（植被和岩石）然后以此平衡每个物件的LOD；
除了视觉化方面的我们还可以用来做音效设计； 我们有工具可以根据地形、物件的类型定义规则来生成一张音效图（sound map）； 每个颜色可以作为一个特定环境音效的索引；
Worldbatch可以帮助自动处理这种任务，或者允许你在任何时候更新世界所使用的任何类型的数据； Worldbatch基于Houdinipython (hython) ，使用 "Hqueue" 任务分配系统（由SideFX开发）在渲染农场开始一个数据任务； 一个任务读取一个Houdini asset资产文件（otl格式），假如需要的话设置好参数然后开始此otl文件的渲染进程； 用户在UI模式下能够从世界地图中直接选择想要重新计算的东西，它能自己运行，把任务发送到自己的电脑上或发送到渲染农场； 之前我提到过把Perforce也加入了进来，worldBatch会在用户提交Anvil引擎的地形相关修改清单时自动运行，命令行脚本将会让worldBatch发送基础任务到渲染农场保证数据的更新；
4位技术美术创建了多达145个的各种工具和全自动化的管线流程，让关卡美术能更专注于细节表达，甚至能帮助视觉方面以外的音效、游戏玩法、逻辑等工作，推动了整个项目的效率；
这里，演讲结束； 下面是总结和特别感谢名单；
<全文完>
看完的朋友们我对你们表示敬意。。。我贴了一百张图手都要断了。。当然，感谢作者和译者！
| 
显示全部 17
评分
但是我觉得这是个贼强的贴
