Just did the physics test
The test scene is 3600 interpolated rigidbody spheres freefalling into a box, and 400 interpolated kinematic rigidbody cubes that are moving, rotating, and raycasting on every fixed update.
I call this test… “Eh… that’ll do it”
Here are the results in a release build:
- 2017.1p5: Goes down to 56 fps when all the spheres are landing in the box, then gradually goes back up to 105 fps
- 2017.2b11 - AutoSync OFF: Goes down to 65 fps on initial impact, goes back up to 115 fps
- 2017.2b11 - AutoSync ON: Goes down to 16 fps on initial impact, goes back up to 45 fps
So, have no fear: the physics performance is fine in 2017.2 as long as you remain in AutoSync OFF mode, which is no big deal at all. In several cases you may not even need to ever call Physics.SyncTransforms() at all. The only things that aren’t fine are:
- AutoSync ON by default, which will no doubt cause massive hysteria and make thousands of devs wonder why their game suddenly runs like a console game
- this problem , which - thank god - has been resurrected from its “Won’t Fix” status and is now back to “Active”
This doesn’t confirm beyond any doubt that 2017.2 has no performance regression whatsoever, but it’s still somewhat reassuring I think. The only way to find out what did regress now would be to compare profilers for the same project in .1 and .2
Also, I tried the Adams rendering test with DX12 and Vulkan. The performances were abysmal with DX12 (it ran at 25 fps), and it just didn’t work at all with Vulkan (1 fps and everything is purple). Just stay away from those for now, and stick with DX11