Unity 5. WheelCollider component is unusable.

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:
http://vehiclephysics.com/advanced/how-suspensions-work/

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.

 

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...

 

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.

 

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...

 

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.

 

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

 

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.

 

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/...sx/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:

http://vehiclephysics.com/advanced/how-suspensions-work/

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:

http://www.edy.es/dev/2015/03/plans-for-unity-5/

 

Great news!

 

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

 

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.

 

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...

 

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".

 

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

 

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.

 

Is sad :

 

Cool.

 

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...

 

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 S*** 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.

 

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

 

I purchased your physics package, but will some form of the wheel collider hot-fix become available to non-owners as well?

 

Is the video still available?

 

I talked about version 4. In Unity5 any solverIterationCount value causes joint break on start. I couldn't reach any stable state and made a workaround which was described above.

 

Seems like the physics are barely working. Makes me wonder what sort of testing of the physics system was done, as some of the most basic stuff isnt working.. terrain colliders with no heightmap for one. I dont think U5 was ready for prime time, but I know how this stuff happens, I've been involved in some... flawed releases because they were pushed out on a deadline.

 

yep, GDC 2015, unreal release... but, if new physics works like a ****, if u got realy close deadline and unworkable part of engine - use OLD physics in u5 and in U5.1, with all tests, with all fixis - put new physics. Old but workable - better than new but unstable.

 

Being a new version of PhysX, its not quite that simple. Oh well.. they will sort it.

 

New UI, substance, lights... and PhysiX like Googlechrome, firefox and explorier... Maybe we need kill it with fire and change PhysiX on any else physics? Coz unreal \ cryengine gots it...Nothing works on 100% correctly, but, at this time - they: 1 - works, 2 - works nicely. 3D multyplatform game engine without good physics - seems pathetic...

 

Are any of you guys also seeing incorrect fluctuations / spikes in the values read back from wheelcollider.rpm. In my simulation I am seeing extreme negative values coming back (every now and then) even when the wheel is rolling forward. Even in the positive range though, the RPM value is jumping all over the place,

Would love to know if any of you have seen this behaviour too

 

is available now.

 

He has, from the start of Unity 5 alpha.

There isn't actually anything broken here. It is simply how it works. I have made several vehicles in Unity 5 and they all run nicely by tweaking the settings. When a wheel isn't grounded I apply less torque for stability purposes. The key here is generally having a proper torque model and some stable downforce.

You can also find a working vehicle for Unity 5 in the sample assets. If you bother to look

 

load asset after 5-6 try for stable my veh. but, "lol, it's riding" and "fixed and work as i need" - not same at last. I'v can't stable it on new physics, but on 4.6 it takes 30 min for set all as i need.

 

Can you explain how to work with the new wheelCollider system, a tutorial?
If possible. I'm lost in the new system.

 

Well...this is okay for a completely hacked non realistic example...sure I could get my vehicles working like this in a simple arcade game. But I have found so far that when integrating into a much more realistic simulation (in particular where the engine torque is itself also a product of wheel angular velocity) that the RPM returned from the wheel collider is extremely erratic when the wheel is slipping causing spikes in the input drive torque thus causing a kind of slippage feedback loop. I was just looking for any confirmation from anybody else that they are seeing this?

Obviously a bug of this kind would not manifest itself in the sample asset as this assumes that engine torque is in no way related wheel angular velocity. It assumes only a one way connection from the crank shaft to the wheels and not back again. Using single engine torque (scaled by input in this way) means gears are not implemented in any meaningful way and neither are gear ratios and the differential. In fact the sample asset sidesteps the issue by using gears as nothing more than a means to play a sound effect. Its really working like a single geared electric car.

 

Great video!

Look at the polling results. And also look at the Edy's articles about vehicle physics. The most people report the problem.

 

Poll? lol

At the time of writing, 12 people voted for "It is unusable and needs reingeenering."

Alright then, you should email Physx. It's not actually Unity's fault.

 

Not actually Unity's fault? Put new unstable physics in engine, without hard testing, with 1 vehicle asset which shows how soap with 4 wheels can ride on ice? When with "brakeTorque" i'v can stuck by back wheels on collider border (8 wheels on truck) - realy nicely done, good work, no faults \ fails at all. Realy, by 6h of testing i'v think - my bad, try hard, go PRO. After 6h - reuse vehicle in 4.6 - stable as sword in stone for 10m work. So, if they get unworkable physics and put it in engine, it's there fault at all.

 

It's not unstable. You're using it wrong. Unity 5 is a major version change, stuff will change a lot. It's not broken.

 

So how to use the new system of wheel colliders?
I created a new scene set up the car and a simple script to move the car.
The car does not seem to respond to the small number of motorTorque.
To move the motorTorque is the number for example 1000000 crazy number, even so the car moves little.
Added the same values of similar wheelsCollider the previous version, it is a rocket.

 

The only way I've got stuff to move is by chucking it up in the air, it lands, and then the wheels magically work.

Something is wrong...

 

just confused whit the new wheelCollider system

 

I'm guessing all the Wheel Collider tutorials around are garbage now. I can't even get one wheel to work right. I can't even get the wheel collider in the right spot on my wheel.

 

For 2$ arcade game - maybe it's useable, but if u go in deep-settings for mid-level game - nope, not works fine. So, it's not "major version change" it's step backward in physics and development.

 

Wheel collider does not take into account the parent position. I created a sample 3 wheeled car, with powered nose wheel. The nose wheel is child of an object NoseWheelStrut. When the parent to the nose wheel (NoseWheelStrut) is rotated 45 degrees, the car is suposed to turn, however the car goes straight.
Changing the steerAngle will make it turn, but the turning must be relative to the parent position, and it is not. I submitted a bug with a sample project.

 

so, solved problem by downloading Unity 4.6 and use it for project, untill u5 gets stable physics... Maybe Unity needs own physical engine?

 

Basic functions broken shows lack of testing. There is a rush to add new features, and I am worried that the side effect of that is the quality of the new Unity releases is going down.

 

My skateboard worked fine in 4.6. using WheelColliders. Completely broken in 5. I spent 3 days, no way. Found a ton of bugs. After all I tried to change wheels with sphere colliders with anisotropic friction, but, as I should have known, they disabled this feature in PhysX 3. There are two options left for me: make my own physics or back to Unity 4.

 

back to 4.6. I'v use it for project now, waiting when Unity somehow fix 60%+ bugs about physics at all, coz not only wheels dies.

 

You should reset your wheel component settings using cogs or rebuild them. The same settings no longer apply in general. you should also use much higher mass settings for the rigidbody for stability. Again, you need to pretty much start from scratch, or stay with Unity 4. Those are your options. I understand it pisses people off though.

But what can they do? it's a new physics engine.

A long wait then (forever).

You could report a bug using the bug reporter. Having a moan on the forum will not fix it for you.

 

Thank you for suggestion but I tried all the things, read all the docs, Unity's migration rules, forums, physics and time settings, custom physic materials, and of course tried some magic and spells. My skate weight is 1500 kg now, lol, that is because they have hardcoded suspension calculations and we need to put certain mass on rigid body. The main problem for me is that my skate can't move on slopping surface while box (or mesh, or mesh convex) collider of skate's deck is too close to the ground (not rigid body, but collider). It is strange, but I found this dependancy. If I lift it up, skate starts to move. It is possible to achieve the same result making suspension distance longer, but it becomes to look like not a skate, lol. Even if it moves with long legs like a giraffe, steering is awful (skate must steer with pairs of wheels in oposite direction). Sometimes skate begins to jump like a freak. To make things worse they disabled anisotropic friction and we can't now make snowboards, sledges, skateboards, and so on. At last I returned to 4.6 and it started to work fine for me. That was the best solution.

 

Boat physics are gone, too. I'm going to have to start looking at customizing an open source physics package (BEPU, JigLibX).