Putting a Rider on a Physics Bike

Putting a Rider on a Physics Bike

In Race Day, the bike is not a single animated object. It is a full multi-body simulation. The frame, fork lowers, fork uppers and bars, both wheels, swingarm, seatstay, rocker, and both halves of the rear shock are separate rigid bodies. Chaos physics constraints join them, and custom forces drive them on an async physics tick at 120 Hz. The bars steer, the fork compresses, and the frame pitches and rolls on its own. Nothing about the bike's motion is authored ahead of time.

That makes the rider a hard problem. A riding animation assumes the bike moves in predictable ways, and this one doesn't. Put a pre-animated rider on it and the hands drift off the grips within seconds.

The solution splits the rider into two systems. The rider's weight belongs to the physics: a dedicated rider-mass system that the bike actually responds to. The visible rider has one job, which is to stay attached to a bike whose motion is only known once physics has solved it. This page covers the visible rider. The whole system is built in Blueprint, Control Rig, and Unreal's animation framework, with no C++.

A seated starting point

The rider is a skeletal mesh inside the bike Blueprint, attached to the frame. Before any live tracking runs, a hand-authored seated pose holds the rider in a riding position: knees bent toward the pedals, torso hinged forward, arms already reaching toward the bars.

The starting pose determines how good the result looks. Inverse kinematics (IK) solves joint positions so that a hand lands on a target. If it has to pull an arm all the way from a standing pose to the bars, it still reaches the target, but the elbows and shoulders end up in unnatural positions. Starting from a riding pose means IK only makes small corrections, and small corrections look human.

Hands on the bars

Each handlebar grip has a socket. Every frame, the bike Blueprint reads the world transform of each grip socket and converts it into the rider mesh's own space. It then passes the result to the rider's Animation Blueprint. From there, a Control Rig sets those targets on Null hierarchy elements, and a two-bone IK solve on each arm (shoulder, elbow, wrist) puts the hands exactly on the grips.

The space conversion is the critical step. The rig needs to know where the grip is relative to the rider, not where it is in the world, and getting that wrong makes hands float, lag, or snap to the wrong position. With the conversion correct, the hands stay locked to the grips through steering, fork compression, and everything the frame does under them.

Each elbow has a pole target that sets which way it bends. The arms hold a proper attack position instead of folding at unnatural angles.

What's next

The rider's body is currently fixed to the frame. The next stage drives the upper body and pelvis from the physics rider mass. When the player shifts weight back for a drop or leans into a berm, that shift will be visible on the rider as well as felt through the bike.

That change has a direct consequence. Once the body moves independently of the frame, the feet no longer stay on the pedals automatically. They will use the same pipeline as the hands: pedal sockets, conversion into rider space, and two-bone IK on each leg. The architecture already supports this. It is the same pattern applied to a second pair of limbs.

Previous
Previous

Race Day: Game loop and more

Next
Next

Async / 120Hz Physics