Unity 5. WheelCollider component is unusable.

This message was addressed to yant and as I understood from his twitter - Russian is it is his native language. For a better understanding, I wrote on it.
Have a great day comrade!

 

User has been banned. We don't allow racist comments.

 

@yant, I'm using EasySuspension which works well, I have a 100kg vehicle, but the vehicle is only stable when each of wheel collider masses are above 15kg. Is this the correct mass for a wheel for such a light vehicle?

 

Your post was perfectly good, even for me using Google Translate to read it. Don't worry about one idiot.

 

Hi, when any physical solutions r planned? Coz we need to decide - work on u4.6 and wait u5.x with fix, or, relise it with u4.6. I'v don't need absolute date, just like - "It"ll be > 1-2 month".

 

Hi, I have been experimenting around with the WheelColliderSource the last days, although it may work with some modifications, I won t be useable for final releases because of the high CPU load.

It won t matter if you have just 20 colliders in your scene, but if you get somewhere near 10 vehicles and each of them has 20 colliders you get 200 FixedUpdates per frame which absolutely kills your framerate.

The problem is not the speed of WheelColliderSource code, but the call to FixedUpdate. The call alone costs almost all the execution time. Running the code for all Colliders in a single FixedUpdate works just fine.

In my case I am currently working on a Vehicle Suspension class that is instantiated inside the VehicleScript, such that I get only one FixedUpdate per vehicle.

 

Actually I find the WheelCollider in 5 miles better, it's a great implementation, thank you...however I do get this:

PxVehicleComputeSprungMasses: Unable to determine sprung masses. Please check the values in sprungMassCoordinates.

On Windows Store deployments....

 

For rotation around the y-axis you can just apply a base steering angle to your wheel colliders to match the rotation of the containing game object. It has worked fine for me.
For scaling, manually set your wheel collider to fit your mesh and then in code resize it something like:

Code (CSharp):

1. wheelCollider.radius = wheelCollider.radius * wheelModel.transform.localScale * rootTransform.transform.localScale;

@yant I am developing a vehicle crafting game. I have everything working pretty much how I would like, except for one problem: when the center of mass of the vehicle is offset along the x-axis, the wheel colliders automatically turn, as if steering.
In the following images the wheels should be pointing straight ahead.





Any ideas on what is going on here?

 

How is that vehicle built?

I've tried offsetting the CoM along the X axis (white cross-mark in the picture below), but I haven't got any strange result with the wheels:



Maybe the problem has something to do with your your rotation fix around the Y axis?

 

Got a lot more bugs and decided not to move to unity5. Good luck everyone!

 

@Edy thanks for checking it out. The problem existed before that feature was added.

@yant it does change! I set it manually back to identity and it fixed the problem!!! Thank you!
This vehicle now behaves as it should.


I was starting to think it had something to do with the changes that PhsyX makes to match camber for wheels on the same axis. Maybe it did have something to do with that.

 

@yant I have only a couple more questions:

Must suspension always be calculated in the -y-axis of the rigidbody? i.e. can I do anything to make a vehicle like this work? Possibly even one with wheels going out in the x-direction as well?


@Edy do you know if there is any way around the wheel colliders setting their own sprung mass? In an example like the one in the picture above, the wheels on the top of the vehicle would have a sprung mass set even though they don't touch the ground.

 

Just some questions about updating U4 WheelCollider to U5. Is there no compatibility or automatic conversion to the new WheelCollider? Is the new PhysX collider implementation faster than the one in U4? PhysX is a Nvidia product, what about the AMD-Radeon cards? Am i have to buy an AMD card, because everything depends on how fast the game is on the non PhisX card?

 

There is no automatic conversion. The new PhysX engine in Unity 5 is much faster than the old one in Unity 4.
I don't believe Unity's implementation of PhsyX uses hardware acceleration at all, so it won't matter which brand/type of GPU you have.

 

@Edy btw I have your wheel package.

 

Thank you for the answers,

im happy to read, that no Nvidia hardware acceleration is active yet and that the wheel collider implementation is faster then in unity 4. However, it's a bad coding style, if the new wheel collider has a new interface for the Unity users. This should have a generic interface, written by Unity, which is always compatible to the old implementation. And what you do under the interface, using PhysX 2, 3, 4 would be invisible for us.

 

Backwards compatibility is not always possible, nor always beneficial. Coding the new implementation so that it worked with the old settings would've taken considerable amount of time (if even possible) and might have introduced a slew of issues. I am glad they bit the bullet with Unity 5 and made backwards incompatible changes.

 

@redthrawn, @yant the main problem is that the WheelCollider is always projected vertically top-down wrt the rigidbody, no matter the actual orientation of the component. I've tested some setups failing to provide suspension when the WheelCollider points forwards. It keeps pointing "down". Is this scheduled to be addressed? In PhysX the suspension travel direction should be set to match the orientation of the WheelCollider's transform.

The workaround I can think of is to have an independent rigidbody per "block" and joining them all with joints. Thus, WheelColliders would behave according to their corresponding rb. But I fear this would lead to another round of issues with physics and joints...

If we could have a generic wheel component that just provides plain spring with stiffness in any direction, it would be great!

 

Yes I have today. I tried calculating the wheel MPH and it was jumping all over the place, eventually figured out it was the wheelcollider.rpm. Completely unusable values even after lerping those values to try to calm them down a bit.

 

This would be great. I can write my own code for turning an object, rotating it, and applying force. I need to support various different vehicle configs and the new wheel system seems like it just isn't going to work. Most of all I just need a realistic suspension spring and something to handle the wheel collisions and friction.

Might need to code it myself at some point but it'd be nice to get that internal engine performance.

 

Long time ago I used ODE physics engine for PC to implement very workable realistic RC cars wheels and suspension. I used mesh colliders for wheels and joints for springs and for front wheel steering (something like that: steering joint->spring joint->wheel axle joint->wheel mesh collider). It worked very well for buggy type cars and for street racing cars. Because of the quality of the ODE engine and the quality of the joint simulation, all this worked beter than the same cars implemented with Unity 4 wheel colliders. Because of the problems in Unity 5 wheel collider, I created a sample project to create realistic car using joints and mesh colliders for wheels. The results: In Unity 4 it creates workable car simulation that is better that the Unity 4 wheel collider at low speed and uneven terrain. In Unity 5 the same project does not work at all. After careful examination, I find that Unity 5 joints are total mess and mostly do not work AT ALL. The performance is very bad as well. The joints do not hold and are are acting like rubber strings at anything less that 200 physic phrame per second and much worse than Unity 4 joints. Even at higher frame rates they mostly do not work as expected. Since Unity 4 joins work rather poorly compared to ancient ODE joints, I suspect that:

1. Unity team properly integrated the new PysicsX 3.3 but Physics 3.3 is JUNK.
2. Unity team failed the integration completely.

Since Unity 4 physics where not that good compared to ODE (a package created by single (yet very talented person) about 20 years ago), I tend to think that #1 is correct and the underlying Physics 3.3 in the new Unity 5 is junk and un-salvageable by the current NVidia teams and resources allocated. Creating a good physics engine requires very rare top talent in Math and Physics and no ordinary developer can improve a physics package without having proper education end expertise in the field. I think this is rather management fault and poor choice to base Unity physics on NVidia PhysicX that will have long term repercussions on the product. It is hard to like a product with a poor physics engine and that is unfortunately what is in store for all of us now.

Regarding all efforts to fix the wheel collider, I think it is naive to think that one can implement one just using some vertical hard coded ray casts and applying few forces here and there and trying to simulate springs in naive way. The reason is, in good physics engine, the JOINTS are the only way to properly connect and simulate two bodies connected by a spring and subject to some limitations. If you don't use JOINTS to make wheel collider implementation, you are making a hack that will never work as expected. For all these reasons I am very pessimistic and will not use Unity 5. Good luck to all.

 

@skirtz1 I've noted that Joints do not work when rigidbodies are nested. That is, if you have a main rigidbody and a child rigidbody with the second joined to the first using a joint, then the joint has no effect at all and both objects behave as one, like if the child rigidbody and its joint were disabled. That worked fine in Unity 4. But Unity 5 seems to require all rigidbodies involved to be non-parented. This regression makes a mess to have complex objects built with rigidbodies and joints, as all rigidbodies involved must be in the root of the hierarchy. @yant, is this behavior as design? Could it be corrected so children rigidbodies+joints behave as in Unity 4?

With regards to the WheelCollider, I also think that several bad decisions have been taken in PhysX. I'm exploring new ways for simulating wheels correctly, but I'd need a few more PhysX things exposed by Unity.

 

I'm watching a lot of negative things about the new wheelCollider system. It's sad but I have to admit that the wheelCollider not working as it should, compared to 3D engine wheels system Unreal Engine 4.7 or even other types of 3D engine. A good idea of the physical 3D engine of the vehicle, CryEngine, is a good example

Anyway, hope for the best of the new wheel systems, that is, if possible

 

@Edy: ...I've noted that Joints do not work when rigid bodies are nested.
One of so many thing that are wrong ... Read my previous post again, I don't think you can implement proper vehicle simulation (or "wheel collider") based on flawed physics engine that lacks properly working joints (Joints are the most essential part of the engine to create realistic mechanics). It seems we are talking to deaf ears...I have zero expectations at this point. There is no easy way out.

PS: the video above shows everything that U5 with the "new" PhysiX can never do...

 

PS: the video above shows everything that U5 with the "new" PhysiX can never do...[/QUOTE]

Yep agreed, At least it's a good idea and a tip.

 

@skirtz1 I've found that CharacterJoints are by far the best joints to use when it comes to "hard-linking" rigidbodies (that is, when no "springy behaviors" are wanted). The problem is that they do not allow lineal movement, only rotations.

 

I think the team unity should hire the "Edy".
Do not you think?

 

One basic question though. Can someone explain me the meaning of the friction values in Unity 5? In some examples including the one above I see forward friction values like 1 for the extreme and 0.5 for the asymptote. Friction values of 1N and 0,5N ?? That is like driving on ice. How should I interpret these values correctly ?

 

I ported my Segway type physics (highly unbalanced 4 wheel torque steer vehicle that does wheelies) over to unity 5. I used the EasySuspension script although I am not sure I had to since it worked ok without it.

I noticed.

1: Making the ridgebody kinematic then rotating it then turning it back will either crash unity or launch the ridgebody into the air.

2: I had to increase torque by a factor of 2.5 and it’s still slower than before.

Over all it works acceptable, now off to port tanks and cars.

 

I think that the new values are slip ratios rather than forces.

In Unity 4, I was able to use fairly realistic values for engine torque, but with Version 5 I have to decrease the mass considerably (using EasySuspension) before using the same values.

I asked @yant how it's possible to have a 100kg vehicle with four wheels each with 20kg mass, but he doesn't know the answer.

 

For the record my Segway weights 1040 kg

 

Cool, I do find the wheels to be far more bouncy on windows phone (as in when you drive you get more shake, the other devices are smooth) which is odd, I'll report a bug if I can tie it down to the wheel collider itself as it could be just some issues with the float inaccuracy being more visible on windows phone where I'm adding my down forces.

 

Thanks, I've looked into that a bit but for now I'm just preventing the player from placing wheels on the top of the vehicle.

I've looked into using joints and it might be possible except for the nesting rigidbody problem you described in one of your last posts.

 

I've asked @yant about this. Ragdolls work fine and they're built out of nested rigidbodies, so it may be an issue of the Configurable Joint itself. Which joint types have you tried so far? I'll be doing some tests using different joint types in order to isolate/report a possible bug.

 

Sorry but i have to ask, the WheelCollider will be fixed in the next release or 5.xx very soon?

 

Normally, a segway's mass (including the payload) shouldn't exceed 100-120kg.

 

I think based on his post before that, that he's just saying his vehicle is designed a bit like a Segway.

 

can we get some examples of like a perfect handling car, rear wheel drifty ish, semi understeer. and such things? Atleast then we'd have a goal to strive for if we want a perfect handling car, super drifty car and so on.

 

That and a several-ton tank that doesn't jitter or feel like it's driving on ice. No-one's managed that yet.

 

UnityCar and Edy's Vehicle Physics are good examples. I don't know if they are updated to work with Unity 5.

 

When I get back to that stuff I'll definitely let you know some specific cases.

@yant @Edy since rpm values are kinda wonky, have you come up with a good way to calculate current slip?

 

both of those are purchase only with no option for free. which is kinda not possible when on the super tight budget of 0. I still want to have some decent ish handling which wouldn't be that much to ask. Where as the paid ones are most likely way better to tune and do all sorts of crazy stuff.

 

I had the same problem with RPM jumping around positive than negative very flaky.

Since it is basically a graphical effect I calculated RPM based on wheel diameter and speed. And moved the wheel objects based on this.

So I started working on porting over my car. It drives like its on ice and wants to do crazy drifting with tons of wheel spin.

CorrespondingCollider.ConfigureVehicleSubsteps does not help.

Its controllable but drifts like nutz.