Force Calculation Formulae

Hello all!

I am trying to figure out how the ground contact forces are calculated when using the wheel collider component. Like I understand that slip is computed followed by a series of calculations. But surprisingly, I couldn’t find a single reference on what’s happen in the engine. Worst part is I don’t have a premium tech support packages and I can’t reach out to the support itself. Does someone knows how and where I can find this information?

A little context - I am a mechanical engineer trying to use unity to simulate robots in environments developed based on high fidelity point cloud and texture data rendered from images. I want to make a realistic simulation and so looking for understanding how unity physics engine is put together. I know that Nvidia PhysX drives unity but is it safe to assume that their source code is exactly how calculations in unity are done? Any inputs on this matter would be highly appreciated, TIA!

1 Like

Hello.
WheelCollider only expose Normal force, in WheelCollider.force.
Longitudinal and Lateral friction forces are not exposed. I also can’t find any thing regarding tire force in PhysX either.
Based on what you said, you don’t need to simulate high speed movement. What you can do is to ignore wheelcollider tire force altogether (set stiffness to 0), and make your own tire friction force using Normal force exposed from wheelcollider, using the formula F = Fz * mu, with mu is the friction coefficient, Fz is the normal force
Most racing game also went this route, using F = Fz * mu until the rigidbody reaches a high enough speed to use slip-based friction

I’m going to reply to the background of this question:

As far as I am aware, Unity 3D physics is PhysX, Unity wraps the PhysX functions in its own calls, so not all parameters are exposed to you and some defaults may be set without you realising (to values that may be hard to find), but the actual physics engine is PhysX.

I’m a mechanical engineer who worked for many years building physics based models and I would not recommend relying on anything in a game engine to model real world engineering problems. The number one requirement of game physics is that it be as efficient as possible; accuracy is not a priority, it only needs to produce a believable approximation.

Here are some trivial examples to think about:

Friction (Unity - Manual: Physic Material asset reference)
“Please note that the friction model used by the Nvidia PhysX engine is tuned for performance and stability of simulation, and does not necessarily present a close approximation of real-world physics. In particular, contact surfaces which are larger than a single point (such as two boxes resting on each other) will be calculated as having two contact points, and will have friction forces twice as big as they would in real world physics. You may want to multiply your friction coefficients by 0.5 to get more realistic results in such a case.”

Integration Scheme (Integration Basics | Gaffer On Games)
PhysX uses semi-implicit Euler integration. You can see we had some fun with this a while back ( Not reaching exact jump height using kinematic equation? (following Seb Lague's kinematic tutorials) ). The positional error will depend on the magnitude of the acceleration, but will of course be cumulative.

Rigidbody Constraints ( Object rotates despite axis is frozen )
These are unreliable at best and would need to be wrapped up in some code to have any confidence in.

You could look at implementing a different physics engine, PyBullet would seem a promising choice for robotics (although I have never used it). You can find an early port here (Bullet Physics For Unity | Physics | Unity Asset Store), but if this is a serious project it would probably be better to do some research and re-port the latest version.

However, I think Unity offers good potential to build a tool for creating a GUI environment and to pre- and post-process data for technical applications. Good luck!

We don’t modify the underlying source apart from a potential fix or compatibility related thing. Most of what you select goes directly through to PhysX and certainly the simulation, when running, is all PhysX.

The same goes for 2D in the case of Box2D.