BoredEngineer suggested this earlier as well on this thread:
I also recommend tracing/sweeping over constraint setup as you can’t make a fully constraint based car setup like this stable with ue4 (unless your vehicles only travel at slow speeds). I already briefly mentioned constraint setup has issues and I’m sure who’s worked for a while on vehicle physics with physx will agree to the underlying issues.
I’ll list few of the biggest ones here:
- Constraint based vehicle will be unstable at high speeds since physx can’t solve it properly anymore. You may be able to drive on somewhat leveled ground at high speeds if you just drive a straight line but that’s not what games do.
- Even without landscapes, your vehicle will not have reliable grip to the ground because on every small bounce on wheel, you loose grip, same thing would happen in real life if you just put full metal wheels to a car. If Physx will provide more reliable way to solve these collisions in the future, this might change but it still wouldn’t still be ideal.
- You can’t model tire friction properly on constraint only approach. I see you rely on physical materials on this but they were never designed to cover this kind of use case. You can preset one friction value per tire but you can’t modify it at run time on blueprints without swapping the physical materials around. Physical materials don’t make a very believable tire friction even if the contact points kept stable. With tires you’d want this kind of setup: https://pavemaintenance.wikispaces.com/file/view/Figure_2_pavement_friction_vs_tire_slip.jpg/207423378/Figure_2_pavement_friction_vs_tire_slip.jpg. To explain that bit more, your tires usually grip well up to a certain point and then when they lose the traction the force they can put toward the ground drops as tires just slide. You can’t model this properly on physx physical materials and is one reason why you either have grippy tires or car on full drift mode with lower friction value on a physical material. This is especially an issue at high speeds as car just rolls over if you have grippy tires when in reality grip level would go past threshold and start sliding instead, resulting in a just a spin in most of the cases.
Since your car is BP only, the hacks that are done during the Tick (to make it more stable) will be framerate dependent (remember Ticks are run at rendering speed, not at fixed intervals). This means fixes will work differently if player runs game at 20fps or 100fps.
Traced wheels have their own share of issues to solve but most of them are solvable. I admit it’s not as easy approach as just putting together a bunch of colliders with constraints as you actually need to solve the grip and corner cases yourself. But this is also a huge benefit: you actually have control on how the friction gets applied, unlike with pure constraint+collider setup.
Worth mentioning though, you can’t do tracing/sweeping for suspension on BP only project reliably because the already mentioned variation on delta time on Tick, you’ll need to do that during substeps which requires at least some c++ code or a plugin.
Some additional observations on this project:
- You don’t have antiroll. One reason for cars rolling over in this project is the lack of anti-roll bars, you’ve only setup the COM to the ground level to prevent that but that is more of a hack and will lose it’s effect at higher speeds.
- The way you do fake wheels is not good for the simulation. You add additional constraint and mass to the simulated wheels physics sim which can make it even more unstable. Your fake wheels are for visuals only, you wouldn’t want to do any form of physics on them. Instead of doing what you do now, you could just disable the physics sim on fake wheels, attach fake wheels to suspension childs without constraints so they’d always follow the suspension. Then rotate the wheels on code, that way you can also control the visible rotations not happening too fast for motion blur.
Your engine sim logic has fundamental flaws in it:
- You apply more torque at wheels at higher gears, what happens in real life is exactly the opposite.
- Each gear has it’s own torque curve. Cars only have one engine that works with the same torque curve regardless what gear you use.
- You force RPM to rise at constant speed (for each gear) regardless if your wheels have grip or not, which means engine sim is totally decoupled from actual cars behavior and it can’t handle wheelspin properly. Do note that in real car, when clutch is gripping, you have fixed connection between engine rpm and wheel rpm through transmission and differential (with manual gearbox).
- You limit wheels angular velocity directly with engine torque value, I’m guessing this is some attempt to make a traction control but it doesn’t make much sense in the end.
- The way you’ve implemented engine sim leads to a bug where you can occasionally loose all traction on some bumps and your car just stalls. Since engine sim doesn’t know anything what happens to the wheels grip, it just keeps adding more torque to the wheels which just keep spinning wheels even faster and they can’t grip anymore. When that happens, you have to wait until the cars speed drops low enough for the car to shift down and find a grip again.
- You control automatic gear changes by vehicle speed regardless what happens on the engine or wheels.
- Engine setup is based on magic numbers that need to have retuned on each change, even if you change tire friction value.