Broken rigidbody collision after updating to 2020.1

Hi,
I recently updated to 2020.1 from 2019.4 and noticed that my rigidbodies weren't colliding correctly, so I created a fresh HDRP project to test. I made a simple plane ground, created some spheres and gave them rigidbody, then created a big cube without rigidbody and animated it to move towards the spheres. In 2019.4, the cube pushes the spheres as expected, but after updating the project to 2020.1, the spheres clip into the cube. Please see the gifs for visualization:
2019.4:

2020.1:

The same thing happened when I created a clean project directly with 2020.1. All project settings are default. Moving the cube directly has the same problem. Giving the cube a rigidbody doesn't fix anything either. Setting the spheres' rigidbody to continuous or any interpolation/extrapolation doesn't help.
Any idea what might be happening here? If anyone can reproduce the bug then I will create a bug report, but I'm not so sure because I think something as important as rigidbody breaking would have been noticed already. Appreciate any help I can get!

 

I just did more careful testing and confirmed that it in 2020.1, rigidbody collision is just worse compared to 2019.4. It was not about updating from 2019.4 to 2020.1 or creating a new project in 2020.1 from the start, it is a problem with 2020.1 altogether.

I made a new clean project using 2020.1 then recreated the test scene and as expected, the same problem happened. I found out it was about the speed of the cube, if I lowered the speed, the spheres no longer clipped through. There was a certain threshold when the collision breaks down, the problem is that threshold is much lower compared to 2019.4. I created a new clean 2019.4 project then copied the Assets folder (which contained only the scene and the cube animation assets) from the 2020.1 project to it, and this time the spheres did not clip through the cube, even though in 2020.1 they did. Both project settings are default to their respective version. I changed nothing after creating the projects.

Did Unity make physics worse in 2020.1 or is there something I'm missing? I would really appreciate it if someone could tell me what could be going on here.

 

For that situation to work the cube must be a kinematic rigidbody, and must be moved with Rigidbody.MovePosition from FixedUpdate.

Any other way of moving the cube will cause unreliable behavior. Different default physics parameters and/or optimizations may explain your observations perfectly. If you follow the above rules then the behavior should be consistent across both Unity versions.

 

My use case requires using animation to move the cube's equivalent in my main project though. You gave me an idea though so I tried giving the cube a kinematic rigidbody and set the animator to animate physics, and it actually worked! It's not ideal however, as animate physics does make the animation janky for some reason. I also tried making a script with a FixedUpdate function to move the rigidbody of the cube with Vector3.zero but it doesn't work without animate physics. Setting it to Vector3 whatever doesn't work either, animate physics is required. If there's another workaround I'd love to hear it.

Still, I'm wondering if there was some change in the physics engine in 2020.1 that causes this? My test projects are literally just clean projects. I went as far as copying the entire ProjectSettings folder from the 2019.4 project to the 2020.1 one and it still doesn't fix it.

 

Enable Interpolation in the Rigidbody. That should move it smoothly.

The release notes for 2020.1 show several entries related to physics, but I can't find anything related.

Moving physics objects by modifying their transform (or animating it) is unreliable by definition. Modifying the transform means "teleporting" the physics object, not moving it. If that's also done within the Update cycle (as the animation does) then the result is also dependent on the frame rate. This makes the results extremely dependent on that specific Unity version and project settings. Some internal optimization, or some change made to accommodate some new feature may perfectly cause different behavior in unreliable code.

The change might well be totally not related with physics, but with animation or rendering. If the modification to the Transforms is now scheduled in a different way with respect to physics or to the render queue, that could easily cause different behaviors in physics objects animated via Transform.

 

Thanks for the suggestion. However, I actually have the cube's equivalent in my main project is attached to a parent animated character instead. Basically, I want the character to push rigidbody objects with their hand by attaching a cube (or equivalent object) to his hand's rig transform (don't know the actual name), so setting the character's animator to animate physics doesn't help. Any idea how to deal with this situation? I think I can separate the cube and use FixedUpdate to move it along with the character's hand, but it's not very ideal and if I need to also animate whatever object the character's holding in which case should I just give it a separate animator?

Really appreciate your help so far. Thanks!

 

Another user posted a solution based on monitoring changes in the Transform and make the appropriate Rigidbody.MovePosition / MoveRotation calls so the physics body follows the animated Transform in a physically coherent way. However now I can't find that post

 

I might be a little too late in the conversation, but I would suggest to change the new parameter added in 2020.1 in the physics tab called "Default max depenetration velocity" to 20 instead of 10

 

EVEN LATER to the reply. I really wished I recorded my screen when I fixed this...

- To state I had the same issues as OP, Rigidbody gets 'stuck' on certain edges (even though it's a Level floor) seems as if there was an 'invisible' wall... All I can say is just re-import?? Since it was getting stuck by 'invisible walls', I copied the project from backups just before my 2020.2 update, from 2019.3.

- Reimported into 2020.2, and it was Different. Like. The 'invisible walls' weren't there anymore. However, there were still slight differences from the physics. Which I think Tozzo was mentioning the fix for. However I have the video for Tozzo's fix:

So you see, Tozzo mentioned the "Default max depenetration velocity" was set to 10. I just pumped it up to 100. And it resolves rigidbody phasing. So thanks Tozzo lol

 

@purpl3_grap

Work for me too, Thanks!