【GDC翻译】在“Control”中学到的程序化破坏系统的经验

0. 介绍

对于 Remedy 其实不用过多介绍了，因为它已经很出名了。但对于那些不了解的人，我还是介绍一下吧。

下面是我今天的议程：

还有个关键的特点是野兽派风格，它很适合政府建筑。

挑战-触觉

当我们讨论“破坏”的时候，我们会讨论 “触觉”。

2. 粒度的准则

我们还创造了一个非常重要的准则：粒度的准则(Principe of Granularity)。

• 第一层使用刚体模拟。这一层有碎片、道具的部件、环境中的道具。他们都是刚体。“environment” 代表了环境中大型的静态模型，你可以与之碰撞的。而 “object” 代表了桌子椅子等。
• 接下来你会想用其他的东西来表示，因为东西越小则屏幕上的数目就会越多。所以你会想用 Mesh粒子、rigid body hierarchies、材质贴花也在一定程度上增添了丰富性。所以我们现在从 “object” 转向了 “chunks”，甚至是 “debris”。
• 最后一层是纯粹的粒子，包括面片粒子和Mesh粒子。代表了余烬、火花、烟雾、火、碎片、砾石、沙子或类似的东西。他们填充了自然中粒度最细的一个级别。

在《Control》中，我选择了一个视角来演示不同规模级别的内容。

当你把所有物件都加入后，场景将会有很大的不同：

• 首先是“环境构建”。环境美术会提供关卡几何体、模块化套件、物件。
• 随后它们被送往特效部门以设置破坏。我们有很多系统的设置、Prop Rigs、和一些特定场合的过场动画。
• 最后是我们的内部引擎Northlight，一切在那里运行。

程序化

然而，我们还需要选择一种具体的方式来实现它。我们选择了程序化的方式。

• 我们需要一个持续而快速的转变。
• 我们需要行为是可预测的，我们被定义了指标，我们需要知道有多少东西可以破坏等等。
• 我们有数百个资源和变种。在上图中你可以看到建筑组件，他们构成了房间、墙壁、柱子、混凝土栏杆等等。下图有一些道具比如桌子、厕所隔间、墙壁、隔板、植物、电脑、电话和其他东西。
• 有太多东西了，但我们只有一个小团队，平均只能看到1到3人在一起工作。

因此我们需要一种方法，可以将特定东西放进管线，然后管线就以我们预先定义好的方式对其进行加工。我们是没办法对物件一个一个地加工的，因为那是不可能的，也没有收缩性。

行为由材质驱动

接下来，看下具体来说材质是如何驱动破坏行为的：

我们现在看到的是一根栏杆，底部是混凝土做的，中间是金属做的，顶部是木头做的。从左到右你可以看到这个东西逐渐被破坏的阶段。

• 在A阶段中有一些破坏，混凝土上没有贴花，因为你不想在打碎一个物体时看到所有的裂缝。你可以看到木条有一些长长的木刺，金属也扭曲了。
• 在B阶段中已经没有金属了，因为金属不会再破坏了，然而混凝土和木头会继续破坏。
• 最后是C阶段，它是可选的，取决于其材质是否可能会继续破坏。

现在这里可能看起来有些滑稽，因为他们看起来超级普通，你会说“哦，这不就是Voronoi吗”。但你要想，你并不是每时每刻都在打碎物体的所有部分，你实际上是在打碎它的某个角落，在那里它会碎成碎片。

模拟实体

现在，我们有了不同的模拟实体：

而对于“关节”——

这实际上让我们的破坏系统更具有丰富性，因为你可以在门上打一个洞，而门仍旧可以正常打开和关闭。不像某些游戏，其中的东西稍微碰一下就整体破碎成碎片。在我们的游戏中是可以保持结构的，而上述就是其实现的原理。

关于模拟——

• 首先我们有场景或道具的几何体。
• 接下来我们需要为模型做点准备。在某些情况下我们会创建一些包围盒，来说明“嘿，这些部分可以破坏，这些部分不能破坏”。
• 然后就进入Houdini里的破坏工具，里面有大量的HDA来处理完整的基于材质的破坏。之后数据就会被存到磁盘上。
• 有时，你不得不手动修补一些物理元数据来确保一些设置是正确的，特别是当你在配置复杂的东西时，有些值是不得不手动设置的。
• 最后他们进入引擎，这些元数据和mesh数据被引擎用来创建和模拟世界。

破坏工具看起来像这样：

这是仅包括刚体的视频：

• 在任何时间点上，我们的屏幕上最多有200个刚体。这是我们的预算，因为我们要让它运行在主机上。这意味我们可能会以某种方式让屏幕之外的刚体消失。
• 在一些大型碰撞事件比如爆炸中，我们会在开始的几帧中禁止“自我碰撞”来确保你不会对快速移动的物体进行过于疯狂的碰撞计算。你并不需要它，因为很明显他们会在爆炸中分开，你不会对这些碰撞感兴趣的。这就是为什么要用“碰撞延迟”，我是在电影行业知道这种方法的，我们在其他问题上也做了同样的事情，比如它在“自我相交”问题上也有所帮助。
• 我们使用了“休眠阙值”。当混凝土碎块掉到地上时，它们将很快“休眠”，没人会想让它们到处乱蹦的，那也很滑稽。越是靠近真实，你就会越能相信这一点。当你把什么东西掉到地板上时，它真的不会有很多反弹。也只有弹珠会多蹦几下。所以我们有一个很高的“休眠阙值”，这也是为什么我们能让物体固定在一起。
• 然后，当然要用很多粒子来填补空白，这就引出了下一个部分。

粒子层

关于粒子还有另一个特别的部分——

材质贴花

最后一部分是材质贴花，

现在，所有的东西都在一起了，我们有了刚体、粒子、贴花：

4. 经验

关于我学到的经验，主要有以下四个方面：

• 以错误的方式缩放、朝向错误。
• 材质指定错误。有时它看起来是木头，却被标记为“植物”或是“肉类”。
• 有时模型质量太低，这可能意味着细分不好、单面等等。有时你打破了一些东西，但里面什么都没有，但实际上是应该有的。

这是沟通中比较难的一部分，毕竟我们是使用程序化的方式来破坏东西的。

所以你需要做些事情来改进输入数据：

• 对不同美术工具的模型制作管线进行标准化。
• 确保在导出时一切都进行了完备的检查。这样在导出时，工具就会说 “嘿，这不符合它需要满足的标准，请在导出前修复它”。这是很有帮助的，避免了不同部门之间持续的反馈循环。这将把问题放在真正引起问题的地方，同时也有助于解决问题。
• 还有，如果有内嵌的工具来简化设置会非常棒。因为你可以让建模的人能够立即看到如果它被破坏了会是什么样子。但很明显，这带来了很大的开发工具的压力，特别是你还希望有用户友好的界面，这其中有很大的工作量。因此你需要做权衡。

命名约定

对此的解决方法是粒度更细的工具，但这也会带来挑战。我们会想用很多独立的、可互换的工具，但问题是你必须以某种方式维护它们，你需要确保你的版本是正确的，你要确保即使进入一个项目两年，你也可以从项目一开始就打开一些东西，尽管工具可能已经改变了20次但你仍然能够使用它。

对于我们来说，这意味改进标准化的HDA管理，确保所有东西都在命名空间下，所以东西都为美术们分布，所以你不会丢失工具的任何版本。

另外重要的一点是，对于工具，你可以完全自动化地进行，但也应可以手动地调整，二者不应该有区别。这会更灵活，比如说 “嘿，这是自动化生成的东西，但是我进去调整了一些东西”，你在10%的情况下需要这么做，只要他们有相同的结果就行，这很重要。

性能与测试

性能与测试几乎是最大的教训。

第二件事是自动测试。在测试环境中对资源进行自动地评估，然后就可以得到差异并看到其对引擎的影响了。

另一方面是针对性能问题的应对措施：