unity聚光灯

On the Spotlight Team, we work with the most ambitious Unity developers to try to push the boundary of what a Unity game can be. We see all sorts of innovative and brilliant solutions for complex graphics, performance, and design problems. We also see the same set of issues and solutions coming up again and again.

在Spotlight小组中，我们与雄心勃勃的Unity开发人员一起努力扩大Unity游戏的界限。 对于复杂的图形，性能和设计问题，我们看到了各种各样的创新和出色的解决方案。 我们还会看到同样的问题和解决方案不断出现。

This blog series is going to look at some of the most frequent problems we encounter while working with our clients. These are lessons hard won by the teams we have worked with, and we are proud to be able to share their wisdom with all our users.

本博客系列将探讨与客户合作时遇到的一些最常见的问题。 这些是我们与之合作的团队所赢得的经验教训，我们为能够与所有用户分享他们的智慧而感到自豪。

Many of these problems only become obvious once you are working on a console or a phone, or are dealing with huge amounts of game content. If you take these lessons into consideration earlier in the development cycle, you can make your life easier and your game much more ambitious.

这些问题中的许多问题只有在您使用控制台或电话或处理大量游戏内容时才会变得明显。 如果您在开发周期的早期就考虑了这些教训，则可以使您的生活更轻松，游戏也更具野心。

大问题 (Big Problems)

Occasionally, we can track down a physics performance problem to a single problem asset or setup. The best way to notice these is to regularly run the Profiler and compare to a previous run. If you catch a performance regression early, it is pretty easy to go through the recent changes and spot the problem.

有时，我们可以将物理性能问题归结为单个问题资产或设置。 注意到这些的最好方法是定期运行Profiler并与之前的运行进行比较。 如果您尽早发现性能下降，那么很容易就可以了解最近的变化并找出问题所在。

While a simple physics joint can be quite fast, the underlying math is very complex. In essence, a joint is setting up a system of equations for your Rigidbody’s position, velocity, acceleration, rotation, etc. If you set up something with lots of different Rigidbodies with lots of different joints –all of them colliding, all of them needing to meet the requirements of their joints and not penetrate collision — it can get extremely expensive very quickly.

虽然简单的物理连接可能很快，但是基础数学却非常复杂。 从本质上讲，关节是为刚体的位置，速度，加速度，旋转等建立方程组。如果您设置了具有很多不同刚体的关节，而这些刚体却具有很多不同的关节–所有这些都发生碰撞，那么所有这些都需要满足其关节的要求而不穿透碰撞-它很快就会变得非常昂贵。

When setting up complicated joint schemes, think critically about how many joints you need, what sort of collision you require, and how many Rigidbodies are necessary. You can use Layers to mask out unnecessary collisions, and joints have an Allow Collision checkbox that should be used very sparingly. You can reduce the amount of collision you need to detect by constraining the range of motion of your joints. Tune the joints such that collision is unlikely or impossible and you no longer need to detect it. You can reduce the number of joints and Rigidbodies by using them as control points into an interpolation method.

设置复杂的关节方案时，请认真考虑您需要多少个关节，需要哪种碰撞以及需要多少个刚体。 您可以使用“图层”来掩盖不必要的碰撞，并且关节具有“允许碰撞”复选框，应非常谨慎地使用该复选框。 您可以通过限制关节的运动范围来减少需要检测的碰撞量。 调整关节，使碰撞不可能发生或不可能发生，并且您不再需要检测到它。 通过将关节和刚体用作插值方法中的控制点，可以减少关节和刚体的数量。

The Profiler screen will show you how many Rigidbodies are active at any given time. Keep a close eye on this number. Rigidbody count, especially if they are near each other, can have a big impact on performance. It is very easy to inflate this number more than you expect when placing objects or spawning things at runtime. While a single can of soda that moves around is no problem, trying to make a supermarket display pyramid with that same Prefab is going to cause issues.

Profiler屏幕将显示您在任何给定时间激活了多少个刚体。 请密切注意这个数字。 刚体数，特别是如果它们彼此靠近，会对性能产生重大影响。 在运行时放置对象或生成事物时，将这个数字膨胀得比您期望的要容易得多。 尽管可以移动的一罐苏打水没问题，但是尝试使用相同的Prefab制作超市展示金字塔会引起问题。

Be aware of any MeshColliders you add to the game. It is very easy to simply use the visual mesh for collision, but that can cause significant performance degradation, and not always in obvious ways. PhysX does a very good job of only testing against what it absolutely has to. So if you add high-poly collision to an object that is small, or out of the way, it might work just fine. However, when you scale up that same MeshCollider and place it somewhere that RayCasts are common, you can see your performance suddenly plummet. As a general rule, make custom, low-poly collision meshes for any object that is going to be in the default layer, or can collide against most things. If you find a specific mesh to be a problem and do not want to or cannot take the time to make a custom mesh, you can make that MeshCollider convex and tune the SkinWidth to get an automatically generated lower poly collision mesh.

请注意您添加到游戏中的所有MeshColliders。 简单地将可视网格物体用于碰撞是非常容易的，但是这可能会导致性能显着下降，并且并不总是以明显的方式出现。 PhysX在仅根据绝对必要条件进行测试方面做得很好。 因此，如果将高多边形碰撞添加到较小的对象或不碍事的对象上，则可能效果很好。 但是，当您放大相同的MeshCollider并将其放置在RayCasts常见的位置时，您会发现性能突然下降。 通常，为将在默认层中或可能与大多数物体发生碰撞的任何对象创建自定义的低多边形碰撞网格。 如果发现特定的网格是一个问题，并且不想或不能花时间创建自定义网格，则可以使MeshCollider凸出并调整SkinWidth以获取自动生成的下部多边形碰撞网格。

Shadow Tactics NPC with multiple overlapping colliders

Undertow战术NPC有多个重叠对撞机

小问题 (Little Problems)

Our users are very clever and generally avoid the big, obviously slow things. It is much more common to see a project that made a series of rational decisions, each of which slowed down the PhysX update a small amount. When you are working on a game at scale, it is very easy to have this happen. Your AI test level runs fine with 5 AIs in an empty box. When you put those same AI in your real level, suddenly your framerate tanks, Physics.Update spikes, and you don’t really know why. Which of the hundreds or thousands of GameObjects with collision are the culprit?

我们的用户非常聪明，通常会避免大型的，显然是缓慢的事情。 看到一个项目做出了一系列合理的决定，这是很常见的，每个决定都会使PhysX更新速度变慢。 在大规模开发游戏时，很容易发生这种情况。 您的AI测试级别在一个空框中有5个AI时运行良好。 当您将这些相同的AI置于实际水平时，突然您的帧速率储罐Physics.Update会飙升，而您实际上并不知道为什么。 造成冲突的成百上千个游戏对象中，哪一个是罪魁祸首？

Are you doing more tests than you need? Layers can be used to control which GameObjects collide with each other using the grid of checkboxes in ProjectSettings->Physics. This gets evaluated before any expensive tests against your specific collision geometry. Use this to aggressively cull any collisions that do not need to happen. Many games will use large Colliders with ‘Is Trigger’ set to true to detect characters or other specific game objects, commonly referred to as trigger volumes. Very often these trigger volumes are set to collide with the Default layer or everything. By having characters in specific Layers, and these trigger volumes in a Layer that only collides with your character layers, you can avoid testing large volume colliders against your complex world mesh collision or terrain collision.

您进行的测试是否超出您的需要？ 使用ProjectSettings-> Physics中的复选框网格，可以使用图层来控制哪些GameObject相互碰撞。 在针对您的特定碰撞几何体进行任何昂贵的测试之前，将对此进行评估。 使用此选项可以积极地消除不需要发生的任何冲突。 许多游戏会使用“ Is Trigger”设置为true的大型碰撞体来检测角色或其他特定游戏对象，通常称为触发量。 通常，这些触发音量设置为与“默认”图层或所有其他内容发生冲突。 通过在特定的图层中放置角色，并在仅与您的角色图层碰撞的图层中触发这些体积，您就可以避免针对复杂的世界网格碰撞或地形碰撞测试大体积的碰撞器。

Are triggers slowing everything down? A trigger volume, a Collider with ‘Is Trigger’ set to true, is still collision geometry that has to be tested against at the end of the day. If you are moving a trigger volume is just as expensive as moving any other collision geometry, and can cause a lot of work sending collision and overlap events. If you are going to have trigger collision moving every frame, make sure you are colliding against only the objects you need to. Try to keep the trigger as small as possible, and group up similar or overlapping triggers.

触发器会减慢一切吗？ 触发器体积(将“ Is Trigger”设置为true的对撞机)仍然是碰撞几何体，必须在一天结束时对其进行测试。 如果要移动触发器，则触发体积与移动任何其他碰撞几何体一样昂贵，并且可能导致发送碰撞和重叠事件的大量工作。 如果要在每帧移动触发碰撞，请确保仅与所需对象碰撞。 尝试使触发器尽可能小，并将相似或重叠的触发器分组。

A common pattern I see is to have NPCs use multiple large trigger volumes to detect interactive targets. Each kind of game object that the NPC is looking for will have its own Collider with a bunch of code in the OnCollision callback to make sure it has found the sort of thing of it is looking for. It is generally faster to merge multiple trigger volumes into a single trigger, and then filter based on Tag or Layer or distance inside the OnCollision callback. In many cases, you can get even better performance by bypassing collision entirely. Rather than check a sphere every frame against your collision world, register any objects you want to find with a shared manager, then have the NPC’s do a simple distance check against all registered objects. If you have a small list of potential targets, this will be far more efficient than testing against all the collision in the world.

我看到的一种常见模式是让NPC使用多个大触发量来检测交互式目标。 NPC正在寻找的每种游戏对象都将拥有自己的Collider，并在OnCollision回调中包含一堆代码，以确保它找到了所寻找的东西。 通常，将多个触发器量合并为一个触发器，然后根据Tag或Layer或OnCollision回调中的距离进行过滤，速度更快。 在许多情况下，您可以完全绕过碰撞来获得更好的性能。 与其在碰撞世界中检查每个球体，不如在共享管理器中注册要查找的任何对象，然后让NPC对所有已注册对象进行简单的距离检查。 如果您的潜在目标列表很少，那么这比测试世界上所有碰撞的效率要高得多。

Perhaps the Hierarchy is causing PhysX to do far more work than is needed? On Recore, we found several places where rotating rings of platforms were constructed with each square of the ring having its own Rigidbody. This causes each segment to test for collision against all the other segments. By grouping all of the platforms under a shared parent with a Rigidbody and rotating that parent instead, we were able to save significant frame time inside of the Physics.Update. Be aware, combining Colliders under a shared Rigidbody does increase the cost of doing any Raycast or shape cast tests against it.

也许，层次结构使PhysX做的工作远远超过了需要的工作？ 在Recore上，我们发现了几个构建旋转平台环的地方，每个环的正方形都有自己的刚体。 这使每个段都测试与所有其他段的碰撞。 通过使用Rigidbody将所有平台归为一个共享的父对象，然后旋转该父对象，我们可以在Physics.Update内部节省大量的帧时间。 请注意，在共享的刚体下合并碰撞器确实会增加进行任何Raycast或对其进行形状转换测试的成本。

Coming from the other direction, if you already have several colliders underneath a shared Rigidbody parent, you need to be very careful not to move them relative to the parent. Any time a Rigidbody changes shape, the center of mass and Inertial Tensor must be recalculated. This takes significant frame time. This most often comes up when a Rigidbody gets attached to the limbs of an animating character. You can turn this off by setting your own center of mass. As long as the GameObject’s shape doesn’t change too much, this shouldn’t be noticeable.

从另一个方向来看，如果您在共享的Rigidbody父级下已经有多个对撞机，则需要非常小心，不要相对于父级移动它们。 刚体改变形状时，必须重新计算质心和惯性张量。 这需要大量的帧时间。 当刚体附着在动画角色的四肢上时，通常会出现这种情况。 您可以通过设置自己的重心将其关闭。 只要GameObject的形状变化不大，就不会引起注意。

These small, systemic issues add up quickly, so keep them in mind as you develop and plan ahead to avoid them. If you suddenly see a big spike in Physics time, look to the common causes of large performance problems and see if any of those apply.

这些细微的系统性问题很快就会加起来，因此在开发和计划避免这些问题时请牢记这些。 如果您突然发现物理时间急剧增加，请查看导致大型性能问题的常见原因，然后看看是否有任何适用的方法。

Thanks to Mimimi Productions and Armature Studio for letting us use their games as examples. Our next post will cover very first steps: how to set up a new project to make everyone’s life easier.

感谢Mimimi Productions和Armature Studio ，让我们以他们的游戏为例。 我们的下一篇文章将介绍第一步：如何建立一个新项目，使每个人的生活都更轻松。

翻译自: https://blogs.unity3d.com/2017/07/26/spotlight-team-best-practices-collision-performance-optimization/

unity聚光灯