This “feature” makes those wheel colliders useless to any wheeled vehicle that doesn’t have wheel torque (like airplanes or carriages)…
In general, there are a lot of issues with the physics implementation and you have to simply work around it or use a different physics engine. For example here you might be able to just force it to stay awake somehow.
I’d suggest updating to the latest version to see if it fixes it but you’re going to be greeted by even more unexpected behavior and regressed performance changes.
It’s not a bug because the behaviour is in Physx, not Unity. You will find that Physx generally is about performance, not accuracy so it’s your job (assuming your issue is actually what I think it is)
1 Like
I guess it’s not, you can try it yourself,
create a cube to function as a car,
put four wheel colliders on it,
add a rigidbody to the cube,
add a plane to the scene to function as ground
let the car fall on the ground and stay there (it will sleep)
move the ground down, the car will float on the sky.
This definitely looks like a bug to me…
I will upload a test project or maybe a video/screenshots later.
A PhysX Vehicle is designed so that if the vehicle reaches certain conditions, it would go to sleep, and PhysX keeps a so called “sticky tires” constraint active which prevents the vehicle from rolling/sliding. This is done so to make sure you don’t spend excess CPU cycles doing unnecessary calculations.
The “workaround” is applying a small wheelTorque in order to keep the needed vehicles active. Around 0.00001 is small enough to keep the vehicle still.
For this reason, we don’t consider this as a bug in the physics system as it is the intended behaviour from the PhysX library.
3 Likes
I have tried that workaround before, the problem is that you no longer can use the wheel.GetWorldPose to rotate the visible wheel, because if the vehicle is stopped with 0.00001 motortorque the wheel gets all weird, shaking a lot.
It feels like the wheel only works if you have a car in a scene with it’s own engine applying torque, and that car doesn’t stop ever, and if it stops it doesn’t receive any external forces… Pretty much only racing games ?
BTW why doesn’t it wakes up properly when we do it ourselves or another collider/body hits the parent body like every other thing ? I’m not saying that the optimization is bad, but it needs to be able to be awaken on some conditions, like the ground leaving, other bodies hitting it or external forces being applied, instead it sleeps and only wakes up when you apply ridiculous amounts of force or a fake torque…
You could try keeping the Rigid body awake. That may work. Unity - Scripting API: Rigidbody.WakeUp
@Edy will probably be able to add some insights. Btw, I recommend his vehicle systems. For the price, you are immune to all these problems.
This is the problem, even keeping the rigidbody awake on fixedupdate with .WakeUp() calls every update doesn’t work, the rigidbody never sleeps, but the wheels do, the wheels collider sleep independently of everything else, and nothing else ever wakes them up again, except for motortorque, which is what I’m saying is definitely a bug. Again, the bug is not that it sleeps, the bug is that it doesn’t wake up ever again when the attached rigidbody does.
As far as I can tell, no rigidbody having active WheelColliders will sleep, ever. Even with the car being upside down and resting completely on its roof, the WheelColliders will still be modifying the rb’s velocity preventing it to sleep. So there’s no effect on keeping the rigibdody awake. It won’t ever sleep either.
On the other hand, I haven’t experienced your problem @JustAnotherDude . I’ve recorded a video testing the adherent state of the wheels in my package Vehicle Physics Pro. In this video, the WheelColliders stay perfectly adherent (sleeping) while the platform supporting them is moved. At some point, the wheels loose adherence due to the pronounced slope and they begin to slide. The platform is a kinematic rigidbody moved using Rigidbody.MovePosition and Rigidbody.MoveRotation.
Thanks for the mention @hippocoder !
2 Likes
Hi Edy, unfortunately I can’t comment on your asset, maybe it works somehow, what I’m reporting here is a bug with unity’s builtin wheel collider, and it certainly doesn’t work properly.
I can’t record a video right now but here are screenshots of what I said is happening on my second post in this thread.
Create an empty scene, add a cube, add a ground, add 4 unity wheel colliders to them :
The colliders have default parameters and only positioned accordingly…
This is the script attached to the parent body :
using UnityEngine;
public class forcetest : MonoBehaviour
{
public float force = 1000f;
public bool use = false;
public bool sleeping;
void FixedUpdate ()
{
this.sleeping = this.GetComponent<Rigidbody>().IsSleeping();
if (use)
{
this.GetComponent<Rigidbody>().AddForce(this.transform.forward * force /** Time.deltaTime*/);
}
}
}
You can see that after play the vehicle stands on the ground and the body sleeps
After that, nothing (properly) makes the vehicle move again, you can even delete the ground under it and it will float :
And if I enable the force on the script being applied to the parent, the rigidbody wakes up, but the vehicle still refuses to move :
Attached the project.
3382536–265572–wheeltest.zip (48.9 KB)
Hi @JustAnotherDude , good to know that a rigidbody with WheelColliders can go sleep! I hadn’t observed that behavior, so I presume that some part in my scripts is preventing the vehicle’s rigidbody to sleep.
My assets also use Unity’s built-in WheelCollider. This is why I used VPP as example on a similar situation (moving ground under a vehicle with sleeping wheels):
The difference is that the tire forces are computed by the component instead of using the WheelCollider’s friction.
Said that, have you tried these workarounds?
- Keeping the rigidbody awake (Rigidbody.WakeUp() on each frame)
- Applying a small motorTorque (0.00001) to the WheelColliders. I use this for instructing the WheelColliders whether they can enter sleep mode or not.
2 Likes
Hi all, sorry for the delay to answer, really busy days and I got very weird results with this issue, anyway, what I think of this remains unchanged, that the wheels are broken is a fact, but after a lot of testing I’m not sure anymore where it’s the bug, I think there are actually 2 bugs, moving on to the first, as per unity documentation that karl_jones linked and what we believe is true :
The first part of the documentation is correct, the body does in fact sleeps as expected and that’s a good thing.
The second part is definitely broken for wheel colliders, the rigidbody does not wake up after the floor is removed from under it because the wheel colliders do not detect that removal anymore after they’re sleeping, (exactly as described on the documentation) as if the floor under it was static, but it’s not, you can download the example above and see for yourself, this is what I would say Bug #1, because, if you remove the wheel colliders and leave only the box collider, the car will fall, rest, and sleep, then wakeup properly after the ground is moved down. This is a fact, this is a bug. Again, the bug is that the wheels fail to detect wakeup conditions, unlike other colliders.
Now for the workarounds to this bug that have been mentioned many times, they all revolve around trying to keep the body awake to never sleep, that does indeed seems to “work”, but I put that in doubt because :
1 - That entirely kills the point of having the vehicle sleeping, as per unity’s own documentation, that’s an optimization, and all workarounds to fix the #1 bug remove the optimization entirely, they are not acceptable.
2 - If you use the motortorque workaround (the only one that actually seems to “work”), as I already said, the wheels will not stay still, just download my example above and put a motortorque on every wheel, press play and watch, they will rotate (“flicking”) in place, this is a bad thing because it not only breaks optimization but it also breaks the GetWorldPose method, the wheels rotating in place with a jerking movement are not useful to rotate the visual model anymore because the players will see the broken movement.
3 - Calling WakeUp on the rigidbody on update does not work, the wheels will still lock in place by themselves, and I believe this is either because the wheels do not obey the attached rigid body state, or that it might be linked to bug #2 below.
Now for what may be bug #2 I discovered these days trying to fix these wheels, it’s very difficult to explain. As I just said the only workaround that “fix” bug #1 is the motortorque, so I was experimenting with it and discovered that the freezing state of the wheels might be linked to some issue with braketorque, I haven’t been able to figure it out yet but some things I discovered :
1 - Setting motortorque = 0 or braketorque = 0 in update will prevent the body from sleeping, even if it’s stopped (that’s ok).
2 - Preventing the body from sleeping with either motortorque = 0 or braketorque = 0 will not work to fix bug #1 (it behaves just like calling WakeUp on the body and doesn’t work).
Now the odd ones :
3 - Setting motortorque = .000001 prevents the bug #1 (although it breaks optimization and GetWorldPose), but setting both motortorque = .000001 and braketorque = .000001 will not prevent the bug. It will prevent the broken rotation in place error but will not function to fix the #1 bug.
4 - Setting motortorque = .000001 prevents the bug, but if you change it to 0f later then try to move the body directly it will not prevent it anymore, which brings us to item 5…
5 - It seems that those workarounds that only keep the rigidbody awake doesn’t work because of some issue with getting the wheels to rotate again, even with brakeforce = 0, I wish I had the source code for them because it’s very weird, I got multiple cases where the wheels work and don’t work in very odd conditions, posting them all would take a lot of effort (which is why I took so long to reply, I was planning to post many experiments), but there definitely seems to be a bug in either setting brakeforce = 0 and/or motortorque = 0 killing the rotation on the wheels, independently of anything else you might throw at it and that may be unrelated to any sleeping/waking up conditions of the rigidbody, as if wheels only rotate/work on a stopped vehicle if (motortorque - brakeforce) != 0.
There definitely are bugs with these wheels, bugs that can be easily proven and replicated, where no amount of workarounds are of acceptable quality, I really wish the Unity team acknowledge the bugs and fix them.
If all your issues are related to sleep/awake, it’s probably expected. This is because Physx is designed to be pretty conservative about waking up. Imagine if there’s 50,0000 that wake up suddenly. Not good. Best let the developer wake things up as they know what is going on with the game.
If you disagree you should totally file a bug with the bug reporter tool.
If that’s 50.000 box colliders I’m sure they will wake them all up.
As I said :
I guess I’ll have to do it, I’m just afraid it will be marked as “not a bug” and ignored, even after proving time and again that it’s bugged.
If it has a proper test case and the bug reporter turned green, it will be seen for sure by humans and tested. You can also link this thread so they get a clearer background idea. I suspect if it’s just wheel colliders having the problems then there might be something to it bug wise, but need experienced eyes on it.
Check nvidia documentation if you can find it against this issue. Remember, wheel colliders are not really colliders but raycasts.
Does sound buggy and would not surprise me either way in this case. Please leave your case number # in thread so any wandering wild @yant can find it (if he is not way too busy).
1 Like
Thanks, just did the bug report with a very clear test scene/case, hopefully they can observe it.
I will take a look into the nvidia physx documentation and maybe play with it a bit, try to see if it’s a bug on their end.
Hi there,
I have the same issue. I am controlling a car to act as if it is autonomous. It accelerates perfectly, breaks wonderful, but when it reaches 0 velocity nothing happens anymore. I have three methods, one doe accelerating, one for breaking and one controlling the parking. When debugging the applied forces behave correctly. Breaktorque is removed and a motortorque is applied. I tried adding a small motortorque as suggested during the breaking and parking. Did not work. Calling WakeUp does not help. I am stuck in the problem…
I am using Unity 2018.3.6f1
I just could never find anything that would wake the wheels up after they went asleep. I haven’t messed with wheels recently I don’t know if the bug I had a year ago still persists.
Anyway, the only way I ever found to avoid this bug is to make sure the wheels had a motortorque on the awake of the gameobject that has the colliders, and after that NEVER set the torque to 0. That way the wheels don’t sleep.
Funny how my question remains unanswered though… how is this not a bug but “by design”? ¯_(ツ)_/¯