Physic Behaviour of Unity 5.3 (performance + bug)

Hello,

I am here to discuss a performance issue and a bug that I encountered with 5.3 (different behaviour compared to 5.2).

Let's start from the performance issue.

I wrote this small test to understand the performance of BoxColliders attached to a not kinematic Rigidbody.

The code is very straightfoward and shows 12 possible scenarios:

1) 1000 gameobjects with one box collider each, all parented to a RigidBody. The Position of the gameobject is set once for each update. (#DEFINE POSITION)
2) 1000 gameobjects with one box collider each, all parented to a RigidBody. The LocalPosition of the gameobject is set once for each update. (#DEFINE LOCALPOSITION)
3) 1000 gameobjects with one box collider each, all parented to a RigidBody. The Size of the BoxCollider is set once for each update. (#DEFINE SIZE)
4) 1000 gameobjects with one box collider each, all parented to a RigidBody. The Center of the BoxCollider is set once for each update. (#DEFINE CENTER)

And

5) 1 gameobject with 1000 box colliders, all parented to a RigidBody. The Size of the BoxCollider is set once for each update. (#DEFINE SIZE)
6) 1 gameobject with 1000 box colliders, all parented to a RigidBody. The Center of the BoxCollider is set once for each update. (#DEFINE CENTER)

And finally all the scenarios above but with the GameObjects NOT parented to a RigidBody (#DEFINE WITHOUT_RB as well)

I tested all the cases on Unity 4.7 and Unity 5.2. This is what I found out:

- All the cases between 1 and 6 are not affected by slow performance when the gameobjects are not parented to a RigidBody.

- With unity 4, All the cases between 1 and 6 are affected by slow performance when the gameobjects are parented to a RigidBody.
The Update of ProfileBoxCollider and Physic.Simulate are both slow, with the ProfileBoxCollider update being 6 times slower than the physic simulation.
I also don't notice major performance difference between the 6 methods.

- With Unity 5.2, the story is different. The first difference noticeable with the profiler is that the Physic Simulation is this time very fast. Only the update is slow, but still 5 time faster than the Unity 4 version.
All that said, the interesting part is:

- Methods 1, 3 and 4 are slow. However differently than Unity 4, 1 is noticeably slower than 3 and 4.
- Methods 5,6 are as fast as 3 and 4 (actually a tad faster)
- the case 2, that is setting the local position, is as fast as using the function without parenting the gameobjects to a RigidBody, but only if the position doesn't change. Unluckily if the position changes it get slows again. (I wonder why this optimization has been performed)

In our code, we use a GameObject pool to recycle the game objects holding the colliders after being destroyed and requested. However, in our profiler, setting the position of the collider, once is recycled, results in quite a slow operation.

As far as I understood, these operations are slow because Physx recomputes the CenterOfMass and Inertia Tensor in the moment those values are changed.

However, with Unity 5.3, the way the center of mass and intertia tensor are computed has been changed. I can read from the documentation:

If you don't set the center of mass from a script it will be calculated automatically from all colliders attached to the rigidbody. After a custom center of mass set, it will no longer be recomputed automatically on modifications such as adding or removing colliders, translating them, scaling etc. To revert back to the automatically computed center of mass, use Rigidbody.ResetCenterOfMass.

Now, in our project we compute CenterOfMass, Inertia Tensor and Inertia Tensor Rotation with our custom functions, therefore I would expect, in this scenario, a major improvement in calling Set position and the other functions.

It does not seem to be the case though, since, even if I sent the centerOfMass and the InertiaTensor in the small project, the total milliseconds doesn't change.

The second project is about what it seems to be a bug, or at least a different behaviour between 5.2 and 5.3 (only reproducible with 5.3).

This bug is reproducible when custom Center Of Mass and custom Inertia Tensor are used. The project can be download here: https://www.dropbox.com/s/g2ik4z68j9ac6xi/testCOM.zip?dl=0

Press A to SetActive(true/false) the rigidbody
Press S to Set custom CenterOfMass and inertiaTensor

In Unity 5.2
Set custom CenterOfMass and inertiaTensor
Deactivate RigidBody
Activate RigidBody
CenterOfMass and inertiaTensor are set to the previous values

In Unity 5.3
Set custom CenterOfMass and inertiaTensor
Deactivate RigidBody
Activate RigidBody
CenterOfMass and inertiaTensor are set to Vector3.zero and Vector.one respectively

Until this bug is not fixed, we cannot update to 5.3. I know I have to open a bug report, but before to do it, I will share this thread with some unity coders, to be sure that it has actually not been fixed already.

 

Thanks Anthony,

please be aware that we can't update to 5.3 because of the bug reported at the end of the post and not because of the performance cost. I am waiting for you to tell me that it has not been fixed to open a proper bug report.

However, to reply to your last post, we don't need Physx to compute neither the center of mass nor the inertia tensor and inertia tensor rotation. Is there any way to switch off the feature? It would be very useful to us.

 

thanks a lot!

 

I'll do it

 

Bug report has been sent. I guess they are moderated, because I didn't get the e-mail with the link yet.

While I was writing the bug report, I noticed another thing: Why are the CoM and Inertia Tensor reset when the RigidBody is disabled? I don't see the point.

Btw, at the end of the day, finding a work around for the issue won't be hard for us, so we will update to 5.3 anyway. However all the performance optimizations and correct behaviour implemented will be strongly appreciated.

 

yes, I can do it

 

bug is here: https://fogbugz.unity3d.com/default.asp?765300_ekr2q3ubj5qmnerl

 

testing it as soon as possible, thank you a lot! If I understood correctly, you are also planning to do the optimizations, am I right? BTW, have you ever tried our game Robocraft? Please do if you haven't, so you can see why we need it

 

no worries, as long as I know it's in your TO DO list is fine to me.

About the beta version of unity, I forgot to tell you that we have too many problems with 5.4 and I actually cannot test the game. I can test the project we made though. As you probably found out, we cannot reproduce the problem there.

 

awesome thanks, looking forward for it.

 

Hi @yant,

I've been getting very weird results from rigidbodies since 5.3. My vehicles which don't use any wheelcolliders, just raycasts and AddForceAtPoint, have become very unstable.

I modify the centerOfMass but not the inertia tensors. In 5.1 the automatically inertia tensors generated ones are drastically different to the values in 5.3.

I initially tried to set them back to their 5.1 values which caused insane instability, this looks to be fixed now in the 5.3.2 p4 patch release.

Has the formula behind calculation of inertia tensors been changed since 5.1?

 

I have a boom lift vehicle that, since upgrading to Unity 5.3, tips over because of the center of mass calculation being based on the colliders. Normally, we have been manually overriding the center of mass on the rigidbody, but now this no longer seems to work. @yant I noticed that you offered a zip file download. Does this resolve this center of mass issue, or is it something else? Has anyone found a workaround?