FAQ

Important

Before going through this troubleshooting guide please check that you have the latest version of the asset. This can be done through Window > Package Manager.

Vehicle physics is behaving weirdly (jitter, jumping, etc.).

  • Check the model rotation as per this guide.
  • Check the model scale. The root object of the vehicle and WheelControllers should have a scale of [1,1,1].
  • Check that the vehicle inertia is adequate. Sometimes when a model that has the wheels far out (e.g. a 1x1x1 cube with wheels 1 meter away from it) the automatically calculated inertia is too low for the suspension stiffness, physics update rate and default friction settings so the vehicle can become unstable. You can fix this by inputting the inertia values manually into the Rigidbody after unticking the automatic inertia calculation. As a rough car-sized example, in kg·m²:
    • X (pitch): 1000-2500
    • Y (yaw): 3000-5000
    • Z (roll): 2000-4000
  • Too low physics update rate for stiff suspension, friction or low inertia. This can be fixed by lowering the fixed delta time in the project settings. Check the Why is physics update rate so important? section below for more info. It is usually better to fix the settings instead of bumping this up due to the performance cost, with 60 Hz (dt = 0.01667) a useful desktop starting point.

Vehicle is not reacting to the input.

  • Check that there is a vehicle input provider script present in the scene. The full name will depend on the input method used, e.g. InputSystemVehicleInputProvider.
  • Check that the vehicle is enabled during play mode. This can be checked through the tick-box next to the VehicleController script name in the inspector.
  • Check that the vehicle is receiving input by clicking on VehicleController => Control => Input. The values there should react to user input if the vehicle and the InputHandler are enabled.

How to make the vehicle feel more arcade?

NWH Vehicle Physics 2 is by default set up more towards realism / simcade style of vehicles and tries to be as physically accurate as possible. However, sometimes games require a more arcade approach. Here are a few tweaks to get more arcade behavior:

  • Use the Arcade module for artificial steering and drift assistance. Tune it after the vehicle drives correctly without assists.
  • Set the center of mass a bit lower than realistic, e.g. a few centimetres above the floor of the vehicle. This will reduce leaning in corners.
  • Adjust the Rigidbody inertia to make the vehicle change direction more easily. Overdoing it can cause instability and jitter.
  • For more advanced users, adjusting the wheel friction curve can also help. In v14, longitudinal and lateral stiffness are on StandardFriction. Reducing stiffness spreads the response over more slip; reducing grip lowers the available force and can make wheel spin worse. Change one setting at a time and test braking as well as acceleration.

How to improve mobile performance?

VehicleController is quite well optimized but the settings by default are intended for desktop devices and visual quality.

Here are a few optimization tips:

  • Use Project Settings > Time > Fixed Delta Time of 0.0333 (30 Hz) as a mobile starting point. Verify suspension and braking at that rate.
  • Use vehicles with low poly meshes.
  • Use particle and skidmark materials suited to the target device and render pipeline.
  • Reduce particle count and avoid using soft particles.
  • Reduce the quality of skidmarks under VehicleController > FX > Skidmark Manager.
  • Disable unneeded vehicle components under VehicleController > Settings > State Settings.
  • If there is stuttering on collision reduce the DamageHandler > Deformation Vertices Per Frame or use lower poly count mesh.

Why is physics update rate so important?

This is because the physics updates in discrete intervals (each X seconds, e.g. 0.02s by default) which means that the vehicle travels certain distance in between the frames, where there is no physics update. At 450 km/h, for example, that is 125 m/s or 2.5 meters traveled between the frames when using Time.fixedDeltaTime of 0.02 (50Hz physics update). In comparison, only a few cm of sideways travel on the tire can result in slip reaching the peak value and going over it, resulting in reduced friction due to the way tires work on hard surfaces in general. This is why the fixed timestep still matters even with the v14 wheel solver.

Start at 0.01667 s (60 Hz) for a desktop project or 0.0333 s (30 Hz) for mobile, then test at the highest speed and load the game needs. A shorter timestep also costs more CPU time across the whole physics scene.

v14 additionally substeps the wheels and powertrain through WheelControllerManager. Use the wheel group's effective simulation rate to tune that solver independently. These substeps do not turn every Rigidbody collision into a separate full Unity physics step, so they do not remove the need to test the project timestep.