This is real time, not slowed down. The front end of the truck slowly, gently lifts up into the air by some dark magic, in defiance of everything I’ve ever seen about how real objects behave.
It’s not like popping a wheelie, where a sudden forward movement gets the rear wheel under the COM before it can move out of the way. My truck here is actually moving forward, and then tilts up slowly. The three green lines there indicate the Rigidbody COM, which is quite realistic, and is in fact more over the front wheels than the back ones.
I am not using WheelCollider here, nor any vehicle physics package. This is just a Rigidbody for the main body, connected to cylindrical wheels via HingeJoints. You can see the collider shapes here:
All four HingeJoints have their motors set to the same target velocity (-400 or so) and force (250). I’ve tried various physic material parameters, as well as no physic materials at all. Even when I have the friction set to 0, my truck sits there and spins its wheels… and then oh-so-slowly… lifts its front end into the air.
Anybody have a clue what the heck is going on here?
I did find that if I explicitly move the centerOfMass down considerably, so that it’s between the wheels, then the tip-up stops. But the original COM is more realistic, and realism matters for this sim. So, if anybody has any other idea how to stop this weird behavior, I’d love to hear it!
Do HingeJoint’s apply torque to both connected components…? I can imagine the opposing torque in a direct-drive motorized vehicle system being enough to pop up the front end of the vehicle under the right conditions, but I don’t know if Unity bothers to apply an opposing torque-- I’m guessing not, and I don’t really see such a heavy vehicle having this problem anyway, but that’s all I can think of.
Zounds! I thought lowering the COM fixed it, but no — today I increased the motor force, and my truck now actually flies, Peter-Pan style (if Peter Pan were drunk).
(Hmm, the forum doesn’t seem to want to display that one inline for some reason… but click here to check it out, it’s really quite amazing.)
If I could make a 400-ton truck do this in the real world, I’d be looking at a Nobel Prize and rapid colonization of the solar system.
But as it is, this is not acceptable behavior for my simulation. Clearly there is something going on here that I don’t understand.
It might be something like that. But you’d think gravity (which is indeed set to the standard 0, -9.81, 0 here) would keep the truck grounded.
I guess I need to experiment with other ways of connecting and driving wheels. Argh. I love physics… but man, I’m really growing to loathe PhysX.
Well then. Despite the fact that the effect seems to be related to the magnitude of the motor force, I wouldn’t expect the torque to give your vehicle anti-gravity. What happens with a lower mass and proportionately lower motor force? More flight? Less? I know it needs to be a realistic mass, I’m just curious.
OK, I’ve discovered that this weird behavior relates to the relative mass of the wheels and body.
In the video above, the body mass is 410 and the wheels are 10 each. Those are pretty dang heavy wheels, so I tried reducing it to 1. The result: the wheels spin as if they’re not getting any traction at all (despite, one would think, 410/4 units of mass pressing them into the ground plane), and then pretty soon, the truck gently lifts into the air and starts flying.
But when I increase the wheel mass to 100, body still at 410, then it stays grounded, at least until I hit a 10% slope. Then it lifts its front wheels up and drives in a wheelie (despite the COM still being well ahead of the supporting rear wheels).
When I set the wheels mass to 100 each and reduce the body to 40, then it stays grounded even on the slopes.
But this is rather ridiculous as a simulation… the real trucks are about 410 tons; I’m not sure exactly how much the wheels mass, but probably not more than a ton. I can’t put all the mass of the vehicle in the wheels; that’s just silly.
Good question. If I reduce all the masses, and the motor force, by a factor of 10: the result looks pretty much exactly the same. So I now think it’s not a problem with the overall magnitudes, but only with the relative mass of the wheels and body.
Do you really need to use such setup of rigidbodies, joints and motors? I’ve been able to simulate a 600 tons truck properly using a single rigidbody with regular WheelColliders (and Vehicle Physics Pro for the dynamics, I must say).
Well, as you know we’ve used Edy’s Vehicle Physics in the past, but we are worried about the WheelColliders being a poor model for the very wide tires these trucks use.
Also, to be honest, EVP (or VPP) is such a complex black box, it’s hard for us to know how to make sense of it (for example, to calibrate simulated vehicle behavior against real vehicle data). I was hoping a simple model (essentially four wheels and a box) would give us something we can analyze in detail. But, of course, I wasn’t counting on PhysX failing so badly. So we might end up going back to EVP or VPP after all.
My hat is certainly off to you for tracking down and working around all of PhysX’s oddities!
Certainly, I was unaware of such problem when using joints and motors. As for what I know about PhysX, it looks like the motors are imposing counter-impulses to the main rigidbody when providing the angular impulse to the wheels. If you ask PhysX devs about this I’d bet they would reply something like “it’s Newton’s Third Law of Motion”. So, following their logic in the same way they do with the WheelColliders, they are right and reality is not.
WheelColliders are used for suspension only in both EVP and VPP. The tire model is entirely designed and implemented by scripting. The only significant limitation is the tire being a single raycast instead of a 3D volume. This might be noticeable when encountering obstacles, but it’s not an issue at all on the vehicle dynamics. Still, I plan to implement a true 3D wheel model in the future and abandon the WheelCollider completely. This will be a seamless upgrade to current VPP projects without requiring further action.
Both EVP and VPP packages can be reduced to a simple “Acceleration = Force / Mass” and “Friction Force = Coefficient of friction x Normal vector”. As simple and predictable as that, really, in both packages. For example, if you configure a vehicle in EVP to have a max drive force of 1000 N, it means at a full throttle each drive wheel will apply 1000 N of force to the rigidbody. For 4 wheel drive, this is 4000 N. If the vehicle has a mass of 1000 Kg, and the tire friction coefficient is 1, it means that the maximum acceleration on flat asphalt is (4x1000 N) / 1000 Kg x 1 = 4 m/s^2. Other factors also have influence such as the acceleration curve or the aerodynamic drag, but the main point persists.
In summary, specifically with VPP it would be rather straightforward to configure the simulated vehicle in order to fit the real data. I’ve already done it in many vehicles, including trucks, semi-trailers and buses.
