Physics performance issue when migrating from 2017.4.3f1 to newer versions

Hello everyone,

We work on a train simulator which runs with Unity 2017.4.3f1 and we are stuck about migrating to new versions such as 2018.3.5f1 and 2019.4.7f1 (then for more than 2 years) because of physics performance drop.

For your info, these 3 versions use a different PhysX versions, respectively 3.3.3, 3.4.2 and 4.1:

https://blogs.unity3d.com/2018/11/12/physics-changes-in-unity-2018-3-beta/
https://blogs.unity3d.com/2019/10/22/physics-updates-in-unity-2019-3/

We spent much time trying to find out what could be the issue(s) and we finally noticed something by starting from a very simple scene. Without being able to say what would be our next moves to solve this, we decided to share this performance issue case in case you would have some explanations or hints.

For each version, the create scene is the following: a default created scene with setting "Quality" set to "Very Low" to not be bottlenecked by some graphical stuff and a single cube with component Rigidbody ("Use Gravity" off):


If we consider a fixed timestep equal to 0.02, we won't see much things because physics computations are not heavy in such a small scene. We would be able to increase the number of cubes to solve this but we chose to increase the fixed timestep instead.

Fixed timestep = 0.002
2017

Based on the profiler (and my eyes, not a very thorough way I must admit), PhysicsFixedUpdate goes from 0.50ms to 0.85ms with an average of 0.65 - 0.70ms.

2018

PhysicsFixedUpdate goes from 0.7ms to 1ms with an average around 0.80ms.

2019
PhysicsFixedUpdate goes from 1ms to 1.5ms with an average around 1.2ms.

Fixed timestep = 0.0003
2017

Average : 8ms

2018

Average : 14ms

2019
More than 20ms

As a result, one of the most simplest scene performs worst (from a physics perspective) when using newer versions of Unity and, more specifically, newer versions of PhysX. How can we explain this? From the links provided above, it's stated new versions bring global improvements and I can understand some optimizations lead to few drawbacks in certain cases but I'm surprised to get that kind of result for a basic situation which composes every physics design that could be implemented.

From what we have tried, creating builds from those cases lead to similar conclusions.

Therefore it appears complicated to migrate our project which consists of many rigidbodies and colliders plus a fixed timestep value set to 0.003.

Somehow, we are puzzled about this analysis and we think we probably miss something. That's why we are asking for external opinions.

Thank you and regards.

Flo

 

Dear all,

Have someone noticed something similar or would have tried to redo the above example?

Regards.

 

Unfortunately, every new Unity version provides lower performance and expects more powerful hardware. This has been like this as long as I can remember.

Yes, there are some specific optimizations between versions that look great in the benchmarks specially crafted for them, but the "many new things running per frame" surpasses the "optimized existing things" improvements. If all, the optimizations may slightly reduce the added overhead, but the net result is always less performance.

 

Hi Edy,

Thank you for your reply.

Your explanation makes sense and that's a bit what came to my mind when writing my thread. However, I thought also some optimizations/improvements do not consist of "new things" adding overhead but rely on sources/code improvements. In fact, that's likely both.
Then it sounds like a lie when blog posts (as the ones linked above) assert performance improvements and deep testing, which is a bit a shame in my opinion (even if it's probably considered as usual "sales" speech).
Practically, since "direct" migration is not suitable at all, the only way to go further with Unity versions consists in finding (if exists) the adequate new algorithms and optimizations which put our simulation to the same stage/level as it is right now.

How do you handle this aspect in your own physics ?

 

There are local optimizations that provide some performance improvements here and there. Scenes can be prepared specifically to show great benchmarks on those improvements. And that's surely true, those specific case usages perform better. But in general usage and overall performance the result is always worse.

From the linked blog posts I can only see one clear performance optimization, "More batched queries", but that happens when you specifically use RaycastCommand instead of regular queries. Other supposed optimizations such as "New broad-phase type" and "New mid-phase" seem narrow corner cases which require explicit activation and have effect in some specific situations only. So I wouldn't label any of those posts as "better performance". The "New solver type" couldn't even be labeled as "improvement" at all (reason).

I use as few features as possible, in the most standard way possible. Currently only the components Rigidbody, WheelCollider and ConfigurableJoint (where applicable). I apply forces to the rigidbody via Rigidbody.AddForceAtPosition. My packages include a file "Physics Settings.unitypackage" which may be imported optionally. It configures the recommended physics settings in the project.

 

I'm unable to reproduce the problem with a new project (attached to this post). Here is what I tried:

1. Create new Project in 2017.4
2. Set "Quality" to "Very Low" in Project Settings
   
3. Set "Fixed Timestep" to "0.002"in Project Settings
4. Add Cube GameObject
5. Add Rigidbody to Cube
6. Untick "Gravity" in Ridigbody
   
7. Profile in Editor "FixedUpdate.PhysicsFixedUpdate"
8. Open project in Unity 2018.4 and repeat step 7
   
9. Open project in Unity 2019.4 and repeat step 7
10. Open project in Unity 2020.2 and repeat step 7

My results for FixedUpdate.PhysicsFixedUpdate are:

• 2017.4.40f1 = 0.62 ms
• 2018.4.27f1 = 0.72 ms
• 2019.4.9f1 = 0.21 ms
• 2020.2.0b2 = 0.12 ms

Spoiler: Profiler Screenshots

If you have a project where you're able to reproduce this issue, could you please submit a bug-report as described in this document?
https://unity3d.com/unity/qa/bug-reporting

Since I'm unable to reproduce it, perhaps it's related to a specific hardware setup. The Unity bug reporter collects information about your hardware and Unity can use this information to recreate the same/similar setup and check if they're able to reproduce it.

It's important to report these issues together with a reproduction project if you want them to get fixed. If you don't do it, it might be a long time until someone else reports them or until Unity Technologies find them.

After you submitted the bug-report, you receive a confirmation email with a bug-report Case number. Please post the Case number (number only, not the link) in this forum thread for Unity staff to pick up.

 

Hi Peter,

Thank you very much for your effort about recreating the demo scene and explaining me the good way to send a bug report.

Hopefully (it's a bit ironic), the project you have shared gives the same performance drop on my computer (see below screenshots, for information) therefore I allowed myself to reuse your project when generating the bug report.

Spoiler: Profiler screenshots

2017.4.3f1


2019.4.7f1

As a result, here is the case number: 1280367

Regards