WheelCollider issues come from PhysX Vehicle SDK, not from Unity. The causes are a terrible design and a buggy implementation. I wouldn’t expect any significant improvement here unless nVidia decides to drop the current version and implement an actually serious design for their vehicle SDK.
There is someone working on a custom wheelcollider which looks very promising [WIP][Released] WheelController - Realistic Three Dimensional Alternative to WheelCollider - Community Showcases - Unity Discussions
The problem with most replacements is that they’re paid, and I have $0 to spend 
Wheels should just work out of the box, not force one to spend money…
Edy, you said that did not solve the problem of this video, and said that it was related to PhysX 3.x
But did you get any way to stabilize this problem?
I’ve tried everything, but I have not been able to stabilize, and it’s something that gets in a lot of trouble in some situations.
@Marcos-Schultz tried many things but I coundn’t do anything. This is something deep inside PhysX Vehicle SDK. Release notes for PhysX 3.4 mention something that might be related with this issue, but haven’t had a chance of testing it yet.
1 Like
The worst thing is that wheels are using physics.gravity somewhere deeply in the code. So if I set Physics.gravity to 0, 0, 0 and just apply equal constant down force to a vehicle, it start to infinetely slip around on a flat plane. This is very stupid.
Exactly.
Something similar happens with the suspension. The WheelCollider suspension always applies a minimum fixed amount of vertical force which depends on the gravity, regardless of any other consideration or situation of the vehicle.
I’ve been warning about this faked design since 2014 (Unity 5 Alpha) which, no surprise here, produces faked and unrealistic results. It’s very difficult to configure the WheelCollider properly to produce minimally realistic and coherent results, other than just arcade-ish, trial-and-error-until-looks-good vehicles. PhysX justifies their model by describing the formulae used, which clearly define something not corresponding to a simulation of a vehicle suspension.
Their most recent justification on the suspension matter states “we are free to choose any definition of zero displacement”. No, we don’t, if our goal is to simulate a vehicle suspension. It’s like stating “we’re free to choose any definition of a spring”. You may certainly do so, but then you’ll simulate something else but not a spring.
PhysX uses their own totally invented definition of a damped spring in a vehicle that includes gravity in the formula. Not only that, they also use gravity in the calculation of the tire force, which is absurd as you’ve clearly seen. Their entire design assumes all wheels are permanently under the same constant gravity-based vertical acceleration. Such a situation happens exclusively with the vehicle either stopped or cruising straight at constant velocity, and always on a flat plane.
My personal opinion after these years is that the guy designing and implementing PhysX Vehicles is very good at reading and using the available theoretical literature, and then translating that to PhysX C++ code. But he doesn’t really understand how actual vehicle dynamics work in reality. So he takes some literature, adapts and implements it without realizing that many of these papers and studies are applicable to specific situations only, and/or under specific conditions, and/or and serve some specific purposes only.
In the case of the suspension you can get rid of that fake gravity-based term by either setting physics.gravity to zero or by setting sprung mass to zero. In the case of the tire friction, I couldn’t extract any logic out of it but there’s some useful info here . I ended up setting the tire friction to zero, then computing the tire friction forces myself and applying them to the rigidbody at the contact points reported by the WheelCollider. Works perfectly fine and, most importantly, realistic in all situations.
2 Likes