Unity 5. WheelCollider component is unusable.

Profiling when you have a very basic setup is not that useful.

Throw a bunch more physics work in there, then youll start noticing the performance drops

 

I am making a racing game and I am seeing what Marcos pointed out on sidewalks that barely extrude.

Is there a way to fix it with U5 wheel collider (and some scripting) or am I doomed to try making my own?

 

Edy, you managed to stabilize this problem?

 

No, this problem comes from PhysX 3.x Vehicle SDK. Some genius at nVidia thought that applying the suspension forces vertically wrt the rigidbody would be the correct way to go.

Unity devs are aware of this problem and I expect they will be working together with nVidia devs for finding a solution.

 

hi all, who met the problem with wheel collider falls throught the road collider? I have this problem, i used road collider as a mesh convex flat, thickness, with different count of polygons and it dimensions and sometimes wheel collider falls down, there is no problem only with primitive collider, for example cube....

 

I've been trying to implement large vehicles, such as the photo below.



It is possible to implement such a giant vehicle and Unity physical works well. But a double wheel is 2.5 meters high, is about 2 meters wide, and it is ridiculous to simulate a wheel of this size with only a distance pointed down ...
The wheel goes through everything all the time, it's horrible.

I thought of putting multiple colliders, but it is not possible because the shaft is unique, then the suspension should work alone for 2 wheels.

After trying to implement more than 20 types of different vehicles in my project, I came to the conclusion that the wheels of Unity serve only to 60% of cases ...

And all vehicles had problems with low substeps, for example:
ConfigureVehicleSubsteps (1000.0f, 1, 1);
This leaves the physics of Unity in sync with the wheels, and avoids some unwanted bugs, but brings a very low rate updates to simulate wheels, being necessary to leave the "Fixed TimeStep" in 0.002f to get a realistic result.

In addition to the various problems that the wheels have, physical Unity does not help much, by making a simple simulation designed to common games, without simulating air friction and vacuum, and this brings some more undesirable effects such as the car jump to 90 km / h, when in reality, not even 150 km / h the car can get off the ground.

Among many other problems that can still quote, think it's pretty clear how difficult to make a realistic simulator with the wheels of Unity, mainly because of the bugs reported in previous posts.

I'm currently creating my own wheel, try to get a more realistic simulation. Even if it is extremely difficult.

 

Hi, I have a problem with the jumping wheel collider. I have a tank with 14 wheelcollider and sometimes one of the wheelcolliders shots (after colliding with the terrain some kind of unusual big force moves the wheel to +y direction) my tank from the bottom. If the wheel has a big mass, then it is capable to turn my vehicle. The tank has a mass of 62 000 and a spring of 35000 and the damper is 1500 and a wheel mass is 100. The tank jumps often at driving on the flat terrain, because one of the wheelcollider collides with the terrain in a strange way. It seems to be that I'm applying forces outside of physic update, but dis not found any code outside of the fixed update. I'm also not modifying in code the wheelcolliders position. I did not have such bugs with the predecessor of the NVidia Physic engine.
However, I still suppose, that I made a mistake in my code, because vehicles with 4/6/8 wheels do not have such problems.

What I did:

1. Rising the spring to 100000 nearly eliminates the jumping wheels, but if the wheel jumps, then the vehicle is much more affected, looks very bad.

2. Lower the mass of the wheel to 1. This simply lower the effect of the jumping, because lower mass cannot influence so much.

I'm using Unity 5.3.3f.

I can live with this, but about in 1 year I would like to release my game...

 

I found the problem. The track controller changed dynamically the Center of Mass. This caused the jumping behavior. Dammit, cannot complain about the wheel collider.

 

Any idea why that is happening? I have an AI controlled car driving around (using standard asset waypoint system) that brakes when it notices obstacle in front, but if it brakes to a complete stop, it can't start moving forward without "chucking it up in the air" first.
It seems like it gets stuck on terrain.

 

When will the issues with Wheel Colliders be fixed? I'm not seeing anything about them in 5.5 beta notes...

 

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 https://forum.unity3d.com/threads/w...hree-dimensional-custom-wheelcollider.425443/

 

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.

 

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.

 

@iamarugin


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.