Unity 2018.2 - Huge spikes in CPU usage caused by Physics.Processing

Hi all,
I upgraded to Unity 2018.2 and now see horrible CPU usage spikes caused by:
fixedupdate.physicsfixedupdate() - physics.UpdateBodies

Much like this post found also:
https://forum.unity.com/threads/fixedupdate-physicsfixedupdate-physics-processing-terrible-performance.521018/
&
https://forum.unity.com/threads/physics-causing-lag-spikes.514551/#post-3370607

I am unable to post in reply to those foums not sure why but it states (You have insufficient privileges to reply here.) but concerningly
https://issuetracker.unity3d.com/is...e-in-runtime-caused-by-physics-dot-processing
states that "Fixed in: 2018.2.0a6, 2018.1.0b13", i am using "2018.2.0f2"

From the testing i have done, in Unity 5.6 you can have 1000s of RB active in scene with rb.iskinematic = true but in 2018.2 you now get worse performance?

Active Dynamic: 0
Active Kinematic: 0
Static Colliders: 6
Rigidbody: 6.7k
Trigger Overlaps: 0
Active Constraints: 0
Contacts: 0

 

Could you please submit a bug-report and perhaps attach your test project? If Unity Technologies have a project to reproduce the issue, it's much more likely that it gets forwarded to a developer, who is going to work on a fix.

 

ok bug reported submitted.

Unity 5.6 - Create emtpy scene with spawner that spawns 20,000 GO's that just have: transform, rigidbody isKinematic and capsule collider.
In Unity 2018.2 do the same

results:
Unity 5.6 profiler CPU 1.28ms GPU 1.99ms Mini profiler shows 182fps average, 159lowest
Unity 2018.2 profiler CPU 10.25ms GPU 0ms Mini profiler shows 133fps average, 89 lowest

concerned about the clear drop in performance.

 

Update from Unity QA team:
Hey,
Physics.UpdateBodies was taking way longer than it should have.
The fix will definitely be in the next available beta version.
Sincerely,
Unity QA Team

 

For some reason my scene, in play mode only, will run really slowly, like not even 0.2 fps. The profiler (after a 30 second wait for just a few frames) shows that the Physics category (orange) was 12000 ms or so. It looks like that is way out, and I know not why it's happening, but that it needs some solution. Any help appreciated- if not I might not figure anything out.

 

Update: this scene was a 2D part of my game, and I had made a tall tilemap of bullets a while back. I remember moving my square tank character to the embarking part of the hovercraft/airship I made below it for testing purposes. However, I remember playing the game, and the framerate abruptly ground to a crawl. I didn't know why, and was baffled. Later, I discovered that somehow when I moved the character, I may have done something. Because the profiler was saying that the cause of the spike was "Physics2D.Simulate" related issues or something. So one thing I knew from a 100 Unity tips video was that in the project tab, you can type "t:" and then a type of asset you have in project (eg. "t:textures, t:scripts, t:audio) to filter the search down to that one thing. So, I thought maybe the same would hold true for the Hierarchy view, like maybe you search "tthe name of a component)" and get a result comprised of any objects with that component type. So I tried "t:Rigidbody2D" first, and there didn't seem to be anything related. A few objects, nothing much. However, I thought it might have to do with colliders. I searched that (Collider2D since this scene is 2D) and found quite a few more objects than last try, and I started testing by disabling the colliders for a few objects at a time.

- After fiddling with this for a minute, I found the one object that was causing this was the tall bullet tilemap from earlier. So one of the hits I then guessed was the fact that the collider type for the tile I only used on that tilemap and only with that tile, was set to Sprite, and there wasn't a... composite collider on it? But it was working fine before. So I discovered another problem. The Rigidbody was set to Dynamic. I don't remember doing that to it, but OK... So if you have this kind of problem, the best thing you can do now is go to your profiler and enter play mode so it can sample the runtime, then filter search any components related to your processing spike, then disable a few at a time. Maybe the profiler could immediately tell you what object is the most intensive for things like this, but I don't know.