Unity 5. WheelCollider component is unusable.

Unity Engine
1

Hello!
Sorry for my English, it is not my primary language.

Some info about the project:
I’m developing a car racing project which has a complex physics and damage model. The vehicle has a variable mass and floating center of mass. I started to develop this project 1.5 years ago and I used Edy Vehicle Physics with my own changes. Everything works fine in Unity4 and the project is close to completion.

I spent some time to find out whether it is possible to port the project to Unity5.
So, the new version uses PhysX 3.3 that is not compartible with ver2.8. WheelCollider now has a parameter named “sprungMass” that is readonly and calculated at runtime (I guess at start). That is a big and fatal problem for me.
In the regular vehicle project there is a main rigidbody with the wheelColliders attached to this. It is right and so easy for mainstream. The main rigidbody has it’s mass that represents a mass of the whole vehicle.

In my project design I have no main rigidbody that represents a full vehicle mass. It can be floating (cargo) and the center of mass can travel too.

I tried to port this aproach to Unity5 and found that this is impossible to develop any vehicle with variable mass or fragmented structure. In version 3.3 the main rigidbody needs to have a static mass of the vehicle. In another way it becames a very unstable, contacts are bouncing and jittery.

In the prev version I can quietly use the mainbody with the weight much less than the suspension tuned to. For example: an empty cargo’s weight is 3000 kg but the suspension is tuned to 7000kg (for an additional load). The suspension is tuned to 7000kg and when the cargo is empty it is still stable.
So, an old version implements a realistic suspension behaviour as described here:

In the new version it is unstable and needs to be retuned after the loading the cargo with the payload. That is wrong and unnatural. You doesnt retune your car’s suspension when loading it in the real life.

But it is just flowers. The berries is next.
The mainbody with the wheels attached to it and a suspension tuned to a much more mass send the cargo into the orbit. And what is interesting, it doesnt matter attached or not all other fragments (payload througth FixedJoint). So, if I loading my cargo with an additional 3000 kg it’s behaviour stays an empty like.

Seems that in version 2.8 each FixedJoint component propagating the mass to the next object attached and this process is recursive up to the last terminal object. There is no mass propagation in version 3.3, and its very sad and unnatural.
The design based on the constant sprung mass is plain wrong, it is unnatural arcade-like.
I tried many workarounds, but no way found.
Seems that there is impossible to make something more than an arcade like vehicle with an arcade behaviour.

I asked Edy about this and he confirmed me that the problem exists.

4 Likes
2

Same here.
i’v think i’v got unbeliveable curved hands with settings, but, at u4.6 i’v spend 2-3min for make what i need (on wheel colliders), un u5, i’v spend 1.5 day, but, it still likes a turbulanced epelepsing munkey under meth. (not work correctly). Problems what i’v encountered:
1 - rigidbody mass - 100, springs works normaly with this weight, set mass to 10 - “Ugh! it’s heavy!” and so car goes down without springs… No scripting used.
2 - can’t set it for staying still on surface with angle > 10 degrees + little-smooth moving wit rigidbody mass 10-100 + realy soft springs.
3 - if i’v set springing >0, i’v got little jumping of vehicle. it’s not so nice…

3

How arbitrary is the rigid body’s mass? Does it, along with torque provided to the wheels, need to reflect real world values?

Out of curiosity, I upgraded a project that I was working on, and the car was not moving at all with a mass of 1000 (1 unit = 1kg). When I reduced the mass to 50, it began moving, although not as it used to in version 4.

4

mass works strange - set mass to 100, set springs for tis mass, after - set mass to 10 and… yep, 10 > 100, springs go down… reset springs, try to mve… Call an exorcist…

1 Like
5

Definitely an exorcist is needed.

I forgot which mass value caused it, but the vehicle began spazzing along the road as if it were demon possessed.

1 Like
6

i’v think we REALY NEED hotfix for physic… For wheel colliders, for triggers, etc… Coz 25% unuseable, 25% unstable, 25% uncomfortable.

2 Likes
7

Do you know if a bug report can be sent within Unity?

When Unity crashes, I see a feedback form, but I don’t know if this is different from the one we need.

8

I’m afraid to tell that, as far as I’ve researched on this, the actual behavior of the WheelCollider is “by design”. It’s not at the Unity side: the problem comes from how the suspension is designed and implemented in PhysX Vehicles SDK:

https://developer.nvidia.com/sites/default/files/akamai/physx/Docs/Vehicles.html#pxvehiclesuspensiondata

which to me sounds totally unrealistic and artificially constrained as vehicle suspension simulation. That kind of design surely works fine on the specific situations it has been designed for. But it will fail and produce the artifacts you’re experiencing on generic situations where simple real-world reactions are expected.

A realistic suspension simulation is much simpler, and would work and behave as everyone expect without artifacts:

I’ve been able to figure out a hack that makes the WheelCollider work as expected in Unity 5. After applying this hack, you simply have to specify spring rate, damper rate and suspension distance, and the suspension will behave exactly as expected, with natural realistic reactions in any situation. No artifacts at all. This fix is already working in the alpha-development version of my upcoming product, Vehicle Physics Pro. An upgrade to my other package, Edy’s Vehicle Physics, will be available by April 1st and will include a fixed WheelCollider component as well. More information on the plans for vehicle physics and Unity 5:

3 Likes
9

Great news!

10

So I take it that will be a free upgrade for existing customers or was my $60 not recently well spent? :face_with_spiral_eyes:

11

Yes, Edy’s Vehicle Physics will receive a free upgrade to be compatible with Unity 5.

In addition, I’m developing a different product, Vehicle Physics Pro, to be sold separately. Currently it’s on pre-beta stage.

12

hi. maybe u should cooperate with Unity tech support for fix \ improve \ upgrade physic? Coz it’s realy bad, when new version of engine gets so… unprepared for using… Just random thoughts…

13

The problem doesn’t come from Unity, but from nVidia and the PhysX Vehicles SDK. Unity integrates whatever thing nVidia gives them. In Unity 4 and earlier the WheelCollider was unusable as-is because of a bug in the PhysX 2.8 wheel component. In Unity 5 PhysX was upgraded to 3.3, but this time the wheel comes with a strongly doubtful behavior “by design”.

14

Why did they do this so weird? I dont beleive that it was a mistake, they did that on purpose, but why?

15

Surely it works in the specific situations, scenarios and vehicle configurations it was designed for. But it fails in all others causing the artifacts you are experiencing. It’s not designed as a generic vehicle wheel, but as a component that must be used under (artificially) constrained requirements and specifications.

16

Is sad :frowning: :

17

Cool. :wink:

18

at last, old physic better up to 60%-65%. it’s a real step backward… And, as for me, realy needs wheelcollider-rigidbody pair, which works not like soap on ice, or epeleptic monkey under meth…

19

Also, I found the problem with the breakForce and breakTorque. I have an assembly of the rigidbodies linked with a FixedJoint and finite BreakForce and BreakTorque values. In Unity4 it works as expected. I make an investigation how that values correlate with the real physics and found that it is near and depends of the solverIterationCount value.
So, when the game starts this assembly of the rigidbodies instantiating in the air one meter above the ground. Then it starts to fall and landing unbreaked.
In the new version all joints breaks immediately just after start (I suppose it happends in the first FixedUpdate() ). I dont know why this happend and I was forced to make a workaround (start with infinite breakForce and breakTorque values and then set them to my values). Sorry for my English but this is a shit on a silver platter.

You guys made an awesome development tool you made it free and fully functional but simultaneously you made it fully unusable. I can list many drawbacks that I found the last two days, but I don’t want to spoil your mood and my. I just want to ask the Unity5 stuff, what are you going to do next? Can we expect that these problems will be eliminated? Now I mean only physics.

Talk to us.

20

Which solverIterationCount settings cause the joint break and which ones don’t?