I promised a couple individuals I'd share a trick for smoothing out solving the equations for a stopped tire, long overdue. 🙏

If you're reading this after the Driving Simulator Workshop series I wrote a few years ago, first let me don my hat of 3 more years of experience. 🎓

There. Now...tire formulas are an example of calculus integration. Forces are calculated across steps of time (the ticks of the physics engine), based upon the relationship between the tire's orientation and its velocity. If the car is moving forward, the tire is induced to spin. If the car is sliding sideways, the tire exerts a corresponding friction force in the opposite direction. Et cetera.

The Problem

The mathematical relationship works most of the time, but breaks down when velocity approaches zero. When a tire is not moving, in what direction is it slipping? In a simulator such as GDSim (because I had not fixed this), at a stop, tires are subjected to noisy forces as the tire moves in all directions by very small amounts, creating forces that mostly balance but oscillate around, causing the car to "fidget" in place, maybe even drift away. Perhaps you noticed this in GDSim already. What can we do about it?

One solution is to reduce the window of time for tire calculations. GDSim offered the choice of very high physics tick rates. This is not ideal for several reasons, including performance and even the fairness of recorded laptimes. A vehicle simulator benefits overall from greater-than-ordinary physics fidelity -- I'd say 120FPS is desirable at minimum (try doing the math for how much ground a car covers at high speed in 1/60 of a second) -- but faster physics do not even solve this problem. It just becomes less apparent.

The actual solution is to just ignore the tire forces under the right conditions. That's all. But there's a trick to it. ☝️

The Solution

I've dubbed the trick "stiction". It's not friction, but it conveys a feeling of sticking to a surface. The trick is permitted under these two conditions:

• All wheels are touching a surface (suspension compression is greater than zero)
• The brakes or handbrake are active (including a hands-free "parked" condition)

A boolean value (allow_stiction) is passed to the wheels when they are updated each frame. Before the final tire forces are collected, a factor is calculated to drop off linearly as the wheel approaches a stop.

# Correct 'window' for the fix roughly depends on physics FPS
# stict_window = 0.014 * Engine.physics_ticks_per_second
var stiction := 1.0
if abs(spin * effective_radius) < 5.0 and allow_stiction:
    stiction = min(stict_window * _local_velocity.length(), 1.0)

The lateral and longitudinal tire forces are multiplied by this stiction value.

There's one more important thing to do. With the tire forces disabled, any incline will cause the car to move, going right back to square one. However, we're only interested in one thing from the suspension in this case -- keeping the car...up. Oh. 🤔 Is that all?

Change the suspension force vector to do only that, when stiction is applied.

var y_vector: Vector3 = Vector3.UP if _allow_stiction else suspension.vector

The suspension forces are each applied in the direction of this vector.

Now a car can park on a slope (but not too steep), and actually stay there. 🎉 Deceptively, it appears as if it is held in place, just by discarding forces we didn't want.

Better yet, the physics tick rate can be settled at a nice conservative value, improving physics engine performance! I have adopted 144FPS now, hoping it will play very nicely with new 144Hz screens.