Unity 5. WheelCollider component is unusable.

What happens when you increase the forward and sideways stiffness ratios?

Have you had any luck with EasySuspension?

Also, what parameters are you passing to ConfigureVehicleSubsteps?

 

EVP beta is already working in Unity 5. Just some features are still missing (I'm working on them):

I've been unable to extract any logic of the torque vs. rpm vs. slip vs. force values in the new WheelCollider, so I developed my own wheel simulation models.

 

Good to know.

 

hello Edy

if course i dont want you to give your secrets away, but would you mind briefly outlining what approach you took with this?

thanks

 

Setting wheel weight to 150 kg makes the wheel work much more like unity 4.X. Did someone miss a conversion factor its off by like 10X.

RPM seems fine with the extra weight.

 

If you are doing anything with wheels just buy Edy's package. It's more than worth it.

 

@Tegleg I can tell that the WheelCollider is currently used for suspension only (spring, damper, radius and suspension distance), while my simulation models calculate and apply all other forces. Edy's Vehicle Physics (EVP) uses a simple simulation model focused on gameplay, simple settings and ease of use. Vehicle Physics Pro (VPP) is a completely different simulation model where all vehicle components are accurately simulated using real-world settings, from engine to wheels, providing strictly realistic behaviors and reactions based on how all components are set up together.

 

Looks cool !

 

thanks for the reply Edy
pretty tempted with VPP but im actually trying to get to the bottom of the wheel bugs in the physx sdk, unfortunately both engines i use have the same problems.
seems the only option is to throw the physx wheels in the bin and write my own system (for the other engine at least)

out of interest how much will VPP be?
awesome work btw
cheers

 

Realy nice work, but: 1 guy + time = nice vehicle, 1 Unity Team + time + new PhysiX = dubstep machine... Unity needs u =)

Unity Team, get Edy into engine development, pay him and love him =)

 

Car script from my testing car controls and of course for testing wheelsColliders and see if the script works.
I walked laps in the code for it to work as it should be .
I think it's a starting point .
But the slip of the wheels is difficult to control , as the remainder.

The script include the breaks. For now that´s it.

 

I read the whole thread and as a topicstarter I made a conclusion.
Before writing the post I need to notice that I speaking very well in Russian but still not in English. So the aggressive linguists please dont throw the arrows. Lets go.

It seems that the Unity3D company not understand what was happening. Hundreds of devs are telling you that everything is bad, you do not pay attention to it.
The specialist (Edy) tells you that everything is very bad, you also do not react and continue to stick your line about "another different" PhysX3 implementation. By the way, Edy is more educated in vehicle physics as all of us (IMHO). My opinion is based on the private discussion with Edy and I read all of the posts in this thread.

You are telling us that we made wrong settings and some of us is uneducated in car physics. May be, but... Who you are, if you think that the closed system is right which have the output energy is more than input energy (jitter and cosmic jumping with a little mass)?
After that we do not need any explanations and excuses about the peculiarities of the implementation of the new WheelCollider algorithm. It is physically incorrect! No more words. Who is disagree go to school and ask the teacher!

So, what we have. We have unusable physically incorrect vehicle physics for 1$ trash arcades because it cannot handle more complex projects. What you do now is putting the crutches to terminally ill. How long you can do this? All terminally ill die...
Or is this the target to destroy all of the interesting projects and leave the arcades? May be you have any shadow contracts with a game industry gigants to destroy indies? Try to read game dev forums, it is not only my crazy thougths it is thoughts of the many devs.

I can tell you about me and my project. With Unity 5 I have no way to bring my game to market because it is not working with the new physics. It is dead in V5 not because my hands is curved but because it is theoretically impossible to adapt it to new physically incorrect physics. I have a physics education and I tried to make a true physically realistic game. True realistic, you listening this word? Not faked physics!
I spend 1.5 years of time and I went so far in my investigations in PhysX behaviour and found things about which no one says, trust me. Now I have a fully working game prototype based on PhysX2.8. It has a physically correct behaviour at all conditions including the worsest when only one rigidbody left (70kg) to which wheels is attached. There is no crazy jumping and another "cool new physX 3 behaviour".

Now I tried to use Edy's update that makes new physics usable a little but it doesn't work for me. But not because Edy makes something wrong, no! He makes a lot for all of us, and I think that you must pay him a much thousands because he doing your job!

As we say in Russia - it is not possible to make a sweet from a S***. Please, do not get me wrong, I dont want to insult anyone, but it is true, PhysX 3 vehicle physics is unusable for serious projects. And no one can fix anything, not Edy no one else, except Unity3D crew !
What the problem, guys! You have a big crew, you have an unlimited money, you have the sources of PhysX !
Dont say that you cannot do anything, it is lies in the a priori!

For people who want to try UE4 - it has the similar problems out of the box, I'm already tried. You can fix it if you are able to fix the physX and integrate it to UE4. The problem of the wrong suspension is well explained by Edy.

And the last one. If you really want to make the best 3D Engine you should turn to face us. I'm understanding that you have your own corporate politics plans etc... But you should take into account our interests, else way you will lose the new clients. The people who have work in progress will erupt a negative, write a hate posts in forums but they will left with you. But new users will read threads like this and never never never use Unity3D for a serious project. Remember this.

 

In English we have an equivalent saying - "You can't polish a turd."

And sadly I think I have to agree that that description may well apply to the new wheel physics.

 

Unity just used the car implementation that came with PhysX. It is as simple as that. No one stated it is accurate or realistic. What prevents you from using Edy's implementation if you are looking exactly for this? Unity can't provide everything in a top notch, high end manner. Unity provides a framework in which this should be doable as much as possible and Edy proves exactly that this is possible with the provided framework.

 

Truly the new PhysX 3.3 is the way it comes sadly. I hope see soon wheelCollier physics fixed.
However, not everything in 3D engine is completely damaged.

 

Edy's custom friction and force implementation provides a nice setup for standard vehicles, but in Unity 4 wheel colliders were much more usable as-is. If "just use Edy's physics" is the answer, it's also an admission that the built-in wheel system simply doesn't work anymore.

 

The fine tuning of the Unity 4 wheels was already tricky when it was about details. Of course, it didn't become easier in Unity 5. Still, all games involving cars I am aware of that were created with Unity 4 didn't use the built-in wheel colliders, but customized ones.

 

I upload an video to YouTube showing the car behavior and A.I car. Its really strange to set up the wheelCollider, but at the same time funny.

 

Thank you! Licensing details and pricing here: http://vehiclephysics.com/#licensing

Right. I also have to disagree with @SeriouSerg on who should be blamed about the WheelCollider problem. The problem comes from how the PhysX 3 Vehicle SDK has been designed and implemented by nVidia. This also explains why UE4 has similar problems: UE4 vehicles are also based on PhysX Vehicle SDK.

Unity decided to adapt nVidia PhysX Vehicles as it comes. Other vehicle systems would then be available via Asset Store packages. I'd really wish that PhysX / nVidia / Unity decide to provide a good generic WheelCollider component that works like everyone expect, without blindly trying to justify a physically doubtful design being clearly unsuitable for most cases. The fact is that the wheel code could be simplified to work just as anyone expects. This way everyone would benefit on it: users wanting to create their own vehicles, package developers using it as base for providing more complex vehicle physics, Unity team providing a system that is simple to explain, use, and document.

I disagree. My vehicle and wheel system are mostly custom C# code. The "provided framework" in this case is just the Rigidbody and its AddForceAtPosition method.

The PhysX wheel component comes artificially constrained in many ways. Actually I'm using the suspension part only. I've been able to make it work correctly by using ugly hacks that mostly make the suspension work as a correct vehicle suspension. Indeed, this proves that the PhysX suspension can work correctly if (and only if) all the involved parameters are combined in a specific manner. Otherwise, secondary effects and issues may arise.

Still, the above applies to the suspension only. I've been unable to extract any logic out of the values for torque, rpm, slip, and tire forces in the WheelCollider. So I developed my own friction models.

Wheels in Unity 4 had yet another design or implementation fault coming from PhysX 2.x that made the tire friction mostly unusable unless adjusted in runtime depending on the vehicle's state. The old EVP4 package worked around this fault providing better reactions in vehicles using the WheelCollider.

 

It seems I expressed myself not clear enough. Unity provides enough access to implement a more custom solution. It doesn't matter at the end of the day what exactly that involves. If it is just a few method calls, so be it. That's exactly the purpose of a framework.

 

The first step in fixing any problem is to recognize there is a problem. Exactly this is missing from Unity at this time. It is easy to notice they are in denial, and not only on the wheel collider. No one posts here, no comments, no promises, nothing. Unless management takes rapid action to narrow and fix the issues, this is slow moving disaster with no good end.

 

Well... ehmm... I don't think this is the case here. Imagine that a dev tool offers the Transform class but no physics. People complains that the tool has no physics engine. Following your logic, that dev tool already provides a framework that allows physics to be simulated (just setting Transform.position) and people shouldn't complain about the absence of physics simulation, as they have enough access to implement a custom solution. I've developed that custom solution, but it's a rather advanced topic out of scope for many users (comparable in this example to developing an entire physics engine that finally sets Transform.position). Users expect the development tool to provide easy to use components that just work. Otherwise, they wouldn't use the dev tool.

The point here is a stock component (WheelCollider) that doesn't work correctly in most cases. People complains, logically, as they need/want a wheel component that works properly in their projects. I think that "build your own wheel, the framework provides access enough" is neither a good advice nor a proper solution in this case.

 

I've spent a bit of time lately digging into the new Unity5 WheelColliders. They can be finicky, but I think I have found a good balance for working with them. I have plenty of polish to do on the setup and features I want to get in, but hoping to put this up on the Asset Store soon. Right now I could put some more work into the sideways slip at higher velocities. I am going to soon show the small dune buggy and the semi rig working with my setup. I felt like that's a decent range of vehicle types.

 

Unity could not have provided a wheel collider at all, like that no one could have complained that it doesn't work properly. But many would have asked to at least expose the default wheel collider from PhysX.
In my opinion it is not the responsibility of Unity to provide a physically accurate wheel collider. If they would, someone would ask for a more arcade like behavior next to the physically accurate one.

 

There are a few of us. We might be crazy, but we do exist.

Edit: Although it depends what you mean by customised. No-one was just slapping some friction values on some wheels and calling it a day.

 

It would be really great if Unity could reach an agreement with NVIDIA similar to Epic's agreement for Unreal Engine, and provide the source code for both PhysX as well as Unity's C# layer on Github. Unity's resources are largely tied up at the moment, and realistically speaking, the vehicle physics ranks very low on their priority list.

 

Should you buy thing that is damaged and you know that this thing is unusable and you cannot use it? Or imagine another Situation. You are the master of the frost machines, for example. Your customer asks you to exchange an old part with new one. You install new part to his device and now you tell him that his device will not work anymore. He needs to reset all parameters, reinstall software, reset and setup all setting from the scratch. He will brake you something...

New physics has been integrated. Well, I'm happy. We all happy because we asked Unity team to renew physics many times. But as a master you see that some things are unusable, what you will do as a good master? Right, you will try to fix the issues. In our situation the master tell us "Eat this! You will die, but you must eat".
I suppose that if we would know what the pig has been prepared to us by Unity team we were never asked them to renew Physics engine.

As I told early WheelCollider is physically incorrect and cant handle variable mass in wide range. Try to lower the mass of the vehicle from 1300 kg to 100 kg and setup 1200 kg payload. You will see that the car behaviour will be another but an overall mass is the same (1300kg). I tried to distribute payload to prevent offset of the CoM. No success. It is not Edy's issue, it is a fundamental issue of the new wheelcollider. I understand that many people doesnt need a variable mass handling, also I understand that Unity cant provide everything in a top notch high end manner but I also understand that any development tool must provide the right environment and right framework. In else this is not right tool, this is bad broken tool. UE4 has a possibility for fix, so theoretically everyone can fix the wheelcollider in that development tool. By the way UE4 wheelCollider has the differences. It is not so crasy as Unity's implementation and it starts to jitter in much more worser conditions. What that means? Unreal team has made some changes. So?

 

I know I keep saying this but we also still have no evidence of really heavy vehicles working with any friction setup.

Take a 10 ton tank for instance (which is light - tanks are often 50+ tons), driven by powerful motorTorque. Low friction values spin the wheels and feel like driving on ice, but high enough friction values to prevent slipping have major jitter. Even driving with direct forces instead of motorTorque, you can go faster but still seem to be stuck either sliding around or jittering everywhere.

I'd really like someone to prove me wrong with a working example.

 

@SeriouSerg, there is no need for a lengthy discussion. I explained my point of view. Obviously, we don't agree.

 

I don't want to contribute to an argument. I do want to add, the WheelColliders in Unity 5 do work and they actually have cool functionality for drifting and burnouts (out of the box). I have been putting up videos of my current work with them. Here is the latest. As you can see, they do work and they work moderately well by default. I have massaged some important settings on the wheels and the parent rigidbody, but that's all.

 

I can only tell that the WheelCollider suspension can work with extremely heavy vehicles. In this picture, the vehicle weights 600 tons with huge load on each wheel. Yet the suspension does its job correctly.



I'm talking about the suspension only. I also experienced the same jitter you mentioned with 10-20 tons while testing the WheelCollider friction. That happened without applying any torque, so I abandoned the tests at that point. My custom friction models work correctly in the same situation, even the simple model used in EVP5.

 

Haha, so we can use heavy vehicles with WheelColliders in Unity 5 as long as we completely rewrite the friction code ourselves.

Thanks though Edy, that's better than it being completely impossible at least (and I'll likely be buying your code once I move to Unity 5).

Next step, might as well rewrite the whole wheel collider - have it represented as a sideways cylinder instead of a single raycast...

 

That's my long-term plan. In VPP a custom wheel collider component is provided. Actually it creates and manages a standard WheelCollider internally, but the plan is to write a custom implementation in the future. Using a solid 3D wheel is in the sight as well, but it would require Unity to expose a few more data out of the PhysX engine in order to allow a physically correct implementation.

 

I'm sure a native implementation of a cylinder collider would be faster than using the mesh collider alternative as well. Could offer people a faster capsule collider option if they don't mind about the half-sphere coming out the side of their wheel.

 

Can you show us some tips on how you achieved that amazing work ?

 

Good basic

 

yep, nice. But, if i need make something except 2$ game? Something little bit closer to reality? Not soap on ice, not dubstep machine, not jumping maniac... What i'v need to do?

 

Oh, but Unity didn't upgrade PhysX at all. Yeah, version number is bumped, but that's not upgrade. They should upgrade PhysX to Havok. That's the only way. Just like you upgrade IE to Firefox, Opera, Safari or Chrome (last if you're desperate). NV should stick to making GPUs. It's what they do best.

 

PhysX overall performance has been upgraded for sure. The WheelCollider in this version of PhysX, not so much.

 

You may add my name to the list of grievances. Having to write a script just to get visible wheels is inelegant enough, but as far as I know, you literally can't even have your graphical wheels follow your colliders. It's really bad if you're trying to do anything less than a full driving sim, at which point you'll probably be using custom code anyway.

 

What? You can match perfectly the "graphical wheels", also known as mesh renderers and the wheel colliders. Use GetWorldPose() and it will be fine.

 

I have Unity 5.0.2f, and the wheelcollider is a problem, and more that i don't want to discuss here. In my case, I have different kind if vehicles and as i supposed, non of them worked under Unity 5.

1. I cannot explain what happened, but one time I had have to rise the motorTorque 1000 times to move the vehicle forward. Next day it was too much, then i lowered it to the old value, strange... WTF. If somewhat in Unity wouldn't be screwed up, then everything would work fine after the project convertion.
Next vehicle easy going, no such weird things.

2. On the third vehicle, nothing works. If I raise the motorTorque the wheelcollider slip, if it is too low the wheelcollider turn too slow or/and the vehicle moves like a snake. I trying to fix the vehicle since 1 day, nothing works... This vehicle has the same vehicle controller as the first one.

I have a simple setup, 1 boxcollider (+rigidbody) on the parent, and wheelcollider under the parent.

Edit: This wasn't weird enough, so the reason was the Animator component on the perent, where the rigidbody is. More exactly the 'Apply Root Motion' attribute, which was set on true. There is a part of the vehicle, which has an animation, but this worked in Unity 4... Disabling the 'Apply Root Motion' let the vehicle move normal forward. The vehicle has bones, whose are bending the track, but the tracks have no collider on it.....

Has anyone an explanation for this?

 

I'd strongly recommend to keep the physics components separate of the visual and animated components. The root of the vehicle should have the rigidbody, and the WheelColliders should reside in children gameobjects of the root. These components should all have scale = 1. You may put the visual components in their separate gameobject as child of the root.

 

The wheelcolliders are in separate GameObject und directly under the parent. The bones are siblings. The scale problem also known in Unity 4.
I normaly duplicate the mesh-wheel-GameObjects and then I add the wheelcolliders to it and then i remove the mesh components on the duplicated wheelcolider-Gameobject.

 

I hate to spoil everyone's fun, but the Unity 5 wheelcolliders can actually be used without any "hacks". Yes, it did take me two weeks of experimenting, but I got them to work well. The problem is that wheelcolliders ported from Unity 4 to 5 MUST be deleted and remade, and many people don't understand that. In addition, many people reuse Unity 4 wheelcollider settings and scripts expecting them to behave the exact same way. While I do acknowledge that there is a lot of experimenting and reworking/improvements to be done, Unity 5 wheelcolliders are in fact usable. One final note: I got it to function properly, and I'm only 13. If a middle school kid can do it, I'm sure a bunch of REAL game devs can, too.

 

Sure, we got it to work too. The thing is it doesn't behave realistically. That's for sure.

 

Also, in the six pages of discussion here I don't think anyone has said they simply copied their Unity 4 settings across and expected it to work.

 

@Nition, when I said that I was not specifically referring to anyone on the forum, it's just that copying old wheelcollider values over is common if you check unity answers. As I said, "I hate to spoil everyone's fun," but the wheelcollider is not a severe failure as many believe it to be.

 

While this is probably a letdown on Unity's part, I don't think the wheelcolliders can really be used for anything other than average, four wheeled cars. Using them is almost strictly limited to that.

 

Agreed, for an average weight, four-wheeled vehicle they are usable. It's just unfortunate because in Unity 4 they were usable for a lot more (though they were never perfect).