最佳实践 | 碰撞性能优化
在Spotlight团队中，我们和优秀的Unity开发人员一起合作，深度挖掘Unity在游戏开发中的潜力。针对复杂图形、性能和设计方面的问题，我们看到了各种具有创新性的优秀解决方案。我们也看到了同样的问题与解决方案不断的反复出现。
最佳实践系列文章将探讨我们在与客户合作时遇到的一些常见的问题。这些都是我们的合作团队辛苦得出的经验和教训，我们很自豪能够和大家分享他们的智慧。上一次介绍的是在多个Unity场景中使用实时全局光照。
这其中的很多问题只有在真正制作主机游戏、手机游戏、或者处理巨量游戏内容时才会出现。如果能在开发早期就将这些问题考虑进去，那么开发过程就会更轻松，而游戏也会更炫酷。
大问题
偶尔，我们追踪某个物理性能问题时，会落到某一个问题资源或设置上。经常运行Profiler并与前次运行结果进行比对，是发现这些问题的最佳方式。如果能尽早发现性能的减退，就可以通过查看最近所做的更改，找到问题所在。
虽然单个简单的物理关节速度很快，但其背后的运算却很复杂。本质上，一个关节就是一套由刚体的位置、速度、加速度、旋转等信息组成的等式系统。如果创造了一个由不同刚体组成的物体，而这些刚体又各自包含了许多不同的关节——它们互相碰撞，都需要满足关节和非穿透式碰撞的限制条件——这会使性能消耗迅速增大。
当设置复杂关节方案时，要慎重考虑所需关节数量，碰撞类型以及必要的刚体数量。你可以用图层来移除不必要的碰撞，对于拥有Allow Collision复选框的关节，也应谨慎使用。通过限制关节的活动范围可以减少碰撞检测的数量。调整关节，使它避免发生碰撞。通过将关节和刚体作为插值方法的控制点，也可以减少它们的使用数量。
使用Profiler可以看到某个特定时刻激活的刚体总数。紧密关注这个数字，刚体数量，尤其是当刚体互相接近时，会对性能产生巨大的影响。在运行时放置或生成物体时，这个数字很容易会膨胀到超出预期。来回移动单罐汽水没什么大问题，但使用相同的预制件摆出超市里那种汽水金字塔造型就会产生大麻烦。
要小心游戏中添加的MeshCollider。为了图方便，很容易会拿模型网格作为碰撞网格，但这可能会引起严重的性能下降，而且还不易察觉。PhsyX对于碰撞检测工作相当尽责。所以，如果为一个小物体添加了高多边形碰撞，或添加到碰撞不大会发生的位置，可能一切都还好。但是，如果将相同的MeshCollider放大，并置于充满RayCast的环境，你会发现性能骤然下降。按照惯例，对于默认图层中的所有物体或可能会与许多东西发生碰撞的物体，要为它制作一个低多边形碰撞网格。如果某个特定的网格有问题，但又不想或没时间制作自定义网格，可以将MeshCollider变为凸面体，并调整SkinWidth以获得一个自动生存的低多边形碰撞网格。
拥有多个重叠碰撞器的影子战术NPC
小问题
我们的用户都很聪明，通常会避免那些明显的问题。更为常见的情况是，项目中所做的一系列理性决策，依次减慢了PhysX的更新速度。这在制作规模较大的游戏时很容易出现。例如，AI测试关卡在一个空箱中运行5个AI时表现很好。但将相同的AI放到真实的关卡时，帧率骤降，Physics.Update激增，而你却不知道问题何在。这成千上万个带碰撞器的GameObject里到底哪些才是罪魁祸首？
是否存在不必要的碰撞测试？通过ProjectSettings->Physics的那些复选框，可使用图层来控制GameObject间发生的碰撞。此设置会针对特定碰撞几何体在碰撞测试发生前先行进行计算。用这种方法来主动屏蔽不必要的碰撞。许多游戏使用”Is Trigger”为true的大型碰撞器来检测角色或其他特定游戏对象，这通常被称为触发器。通常这些触发器会设置为与默认图层或所有东西发生碰撞。通过将角色放到特定图层，并将这些触发器放到某个仅会与角色图层发生碰撞的图层，可以避免大体积碰撞器与复杂的世界网格或地形网格发生碰撞。
触发器是否正使所有的东西慢下来？触发器，即“Is Trigger”为true的碰撞器，依然是一个至始至终都需要进行碰撞检测的碰撞几何体。移动一个触发器与移动其他任何一个碰撞几何体所产生的消耗并无两样，而且会需要做很多工作来发送碰撞和重叠事件。如果要在每帧都移动触发器碰撞，确保它仅对必须的对象进行碰撞测试。尽可能将触发器做小，并将相似或重叠的触发器分组。
一种常见方式是在NPC上使用多个大型触发器体检测互动对象。NPC期待的每种类型的游戏对象都会有自己的碰撞器，以及一堆放在OnCollision回调中的代码，以确保能找到正确的交互对象。通常，将多个触发器体合并为一起会比较快，然后在OnCollision回调中通过Tag或Layer或距离来进行过滤。很多情况下，可以通过完全绕过碰撞测试来获得更好的性能。不必每帧都对球体与世界的碰撞进行检测，而是将所有希望访问的物体注册到一个共享管理器，然后让NPC对所有已注册物体做简单的距离计算。如果有一小堆需要检测的潜在目标。这种方法要比对世界中所有的碰撞做检测高效的多。
可能Hierarchy导致PhysX做了额外的工作？在《ReCore》游戏中，我们发现场景中圆形旋转平台上的每一个扇区都拥有自己的刚体。这导致了每个扇区都会与其他扇区发生碰撞检测。通过将所有的平台扇区归于同一父对象之下，将刚体赋予父对象，让父对象进行旋转，在Physics.Update中节省了大量帧时间。注意：将一个共享刚体下的碰撞器合并会增加针对其Raycast或形状投射检测的开销。
从另一个方面来说，如果一个共享的刚体父对象下已经有几个碰撞器，你需要非常小心，不要让它们做相对于父对象的移动。任何时候刚体改变形状，质心和惯性张量都必须重新计算，这需要大量的帧时间。当多个刚体连接到动画角色的四肢时，通常会出现这种情况。可以通过设置自己的质心来关闭它。只要GameObject的形状变化不大，影响就不大。
这些小的系统性问题累积起来很快，所以在开发中要时刻牢记，并在一开始就做好计划规避它们。如果突然发现Physics时间出现一个巨大峰值，那就分析下那些常见的性能问题原因，看看是否存在对应问题。
感谢Mimimi Productions和Armature Studio 让我们用他们的游戏作为例子。我们还会为大家分享更多最佳实践系列文章在Unity官方中文社区（unitychina.cn），请保持关注。
推荐阅读
点击“阅读原文”进入Unity官方中文社区！