Physics in Unity 2022.2 -- collecting feedback.

One issue that still constantly plagues The Last Clockwinder is that collision response does not seem to be locally deterministic. Essentially if there is a stream of rigidbodies all moving and bouncing against the same objects, they won't always bounce in the same trajectory.

Or another way to put it: we need determinism of collision response, even if other bodies are added / removed from other parts of the world.

I know this isn't a guarantee in PhysX. It's only deterministic if you replay inputs from the start, but it'd be nice to find a way to work around this! The various settings in the physics settings don't help.

I have to assume the issue stems from the binning process / ordering of the collision responses.

 

Improved Patch Friction

To me, the most significant addition to Physics in Unity in the recent versions was the improved patch friction in Unity 2021. I upgraded my main projects from Unity 2018-2019 straight to Unity 2021 because of this feature alone. This option should be enabled in new projects by default.

Frictions and collisions used to work nice in Unity 3 and Unity 4, but become broken in Unity 5. We had to deal with non-realistic and rather unpredictable frictions and collisions all this time because the reactions strongly depended on the number of contact points in the collision (!). It was essentially trial & error from Unity 5 to Unity 2020, far away from any expected physically realistic behavior. So I'm very happy that you guys finally could improve this part in Unity 2021.

Contact Modification API

Another great addition was the Contact Modification API. I haven't had a chance to test it extensively yet, but as for the documentation I think it could allow to simulate some sort of elastic collisions. This would have a direct application to car collisions (as they're never rigid collisions, there's always some deformation absorbing the collision energy) and hopefully to simulate volumetric 3D wheels at very low speeds.

Wheel Sweeps

Speaking of volumetric 3D wheels, I'd really appreciate if you give some love to the WheelCollider and expose the Wheel Sweeps feature from PhysX Vehicles. There's a significant demand for this feature today.

WheelCollider.sprungMass

In terms of vehicle physics, I'm very grateful to you because of exposing WheelCollider.sprungMass for read/write in Unity 2019. This allowed me to keep using the WheelCollider for suspension in my vehicle simulation packages, with very realistic and stable behavior.

Let's face it, the "sprung mass model" in PhysX is essentially a broken design because it assumes the car is under a constant vertical acceleration of 1G. That only happens when the car is at rest or cruising at constant speed on a flat plane. The calculations for suspension and friction in PhysX explicitly include the term 1G, which it's nonsense to anyone with even a minimal knowledge of vehicle simulation. Proof of this is that if we remove the gravity from the scene and apply an equivalent downforce, a vehicle based in the WheelColliders just slips around indefinitely on a flat plane: no tire friction is generated at all.

In my case, I don't use WheelCollider friction but the suspension only. Being able to explicitly write the sprung mass value allowed to remove the 1G term from the equation in PhysX. Now the suspension totally behaves as a realistic suspension no matter the actual vertical acceleration applied to the wheel. I use this solution extensively, and it has been validated on high end engineering projects for the motorsport industry.

Unity 2022

As for Unity 2022, new features look interesting but I'll try them when it's released out of Tech, so I can't tell anything yet.

Integration of PhysX 5

As for the future, I'm sure that most of us expect the integration of PhysX 5. Current PhysX is so severely optimized for performance that even the simulation of rigidbodies with non-uniform inertia (almost anything not being a primitive) is non-realistic and plainly faked. This is confirmed by the PhysX devs themselves. PhysX 5 brings back a realistic rigidbody simulation.

 

when do we expect the integration of PhysX 5

 

I've found the networking capability of PhysX to be questionable.

In my custom network test, the client is rolling back a single rigidbody. The time for each physics event when I call Physics.Simulate is around 0.2-0.3 milliseconds. At low latencies this is fine, but at higher real world latencies, it hogs a ton of the CPU during rollback. This is for a single physics body! And yes, it was tested in a build.

I'm not an expert of physics engines by any means, but isn't this a little bit high? Maybe it's just my old 7700k.

Is this something that could be looked into? Perhaps not the optimization of physx in general, but rather the rapid firing of physics ticks during something like a rollback event.

 

I think most of us is excited with the positibility of integration of PhysX 5 in Unity. Most interesting aspects I would like to see is the new gyroscopic effect of any rotational speed of Rigidbodies (known issues), a guarantee momentum conservation for the articulation solver (create an of Articulation body chain and allow it to collide with an obstacle - the chain will explode everytime), and a FEM solver for at least a series of particles that could lead to accurate wire simulation or primitives (beam deformation analysis). Especially combining Articulations, Joints + Rigidbodies and softbody physics of PhyX 5 in the same simulation in Unity would give tools to engineers to massively expand Unity's use on digital-twin applications. Until then, Omniverse will be the preferred platform for real-time physics. Or third party plug-ins for physics in Unity if your team can't migrate.

 

What would be the settings for automatic tensor to make rotation act the same as the rigidbody rotation in Unity 2021?

 

It wasn't the tensor settings. I was using a transform to move and rotate my npc characters for paddling and turning and using physics for when they surf. In Unity 2022 the transform is set not to work, so in the physics in the project settings there is a setting for Auto Sync Transforms that needs to be checked if using physics and transforms. In Unity 2021 this was not the case. Darn check boxes take hours to find.

 

wheelcollider will work with ecs multithread?

 

Not sure how much of this fits into this thread, but here goes!

Something I'm running into frequently as of late is the inability to detect failure when assigning a

Mesh

to a

MeshCollider

. An error is logged to the console on failure, but I can't catch that error in my own code (and I can't even do it hackily by intercepting the message, because it doesn't go through a custom log handler if you have one set up). It'd be nice to have something like:

Code (CSharp):

1. namespace UnityEngine;
2.  
3. public static partial class Physics
4. {
5.     public static bool TryBakeMesh(int meshID, bool convex);
6.     public static bool TryBakeMesh(int meshID, bool convex, MeshColliderCookingOptions cookingOptions);
7. }

Which I could then use to implement something like

TrySetSharedMesh

for

MeshCollider

:

Code (CSharp):

1. public static bool TrySetSharedMesh(this MeshCollider collider, Mesh mesh)
2. {
3.     if (!Physics.TryBakeMesh(mesh.GetInstanceID(), collider.convex, collider.cookingOptions))
4.         return false;
5.  
6.     collider.sharedMesh = mesh;
7.     return true;
8. }

It would also allow me to avoid unnecessarily creating

GameObject

s and colliders for

Mesh

es that I can't use (many of these are computed from external data, and are not guaranteed to always be valid -- hence the problem I'm facing).

Something I have also noticed, which I'm not sure is a bug or not, is that the navigation system is not able to use a convex

MeshCollider

unless the source

Mesh

contains triangles (even though only the vertices are necessary for PhysX to compute a convex volume). As far as I know, PhysX will compute a triangulation for the geometry, so would it be possible to expose this triangulation somehow -- even if only to the navigation system?