Skip to content
HY Devlog
Go back

Taking Apart Cinemachine's Follow Camera: Binding Mode Isn't a Rotation Mode

I’m building a runner game. Looking for material on wiring the camera up with Cinemachine, I ended up clipping this post. It covers exactly the viewpoint I wanted — the racing or Temple Run style camera that chases a target without taking any mouse input.

The procedure is short: make a virtual camera, attach a target, adjust one offset. But checking the Binding Mode explanation that follows against the official documentation, the framing is off. It reads Binding Mode as “how the camera rotates,” and that isn’t what it is. Carrying that misconception around means cycling through modes without finding the shot you want, so I rewrote around that point.

Everything here is against the Cinemachine 3.1 documentation.

Table of contents

Table of contents

What the Follow Camera is made of

The menu path:

GameObject > Cinemachine > Targeted Cameras > Follow Camera

That produces one CinemachineCamera with two behaviours attached.

The structure is already visible there. A Cinemachine 3 camera separates the module that decides position from the module that decides rotation, and this preset is just one pairing of the two. That’s what the original calls the “control modules.”

You only need to assign Tracking Target. The official wording:

The CinemachineCamera automatically positions the Unity camera relative to this GameObject at all times, and rotates the camera to look at the GameObject.

The original’s setup is likewise two things: drop the character’s camera root object into Tracking Target, and set Cinemachine Follow’s Follow Offset Z to -3. The default offset is (0, 0, -10), placing the camera 10 metres behind the target; this pulls it in to 3.

And one caution the original adds still holds. If you have a virtual camera from earlier, turn it off. Cinemachine picks one camera by priority among the active ones, so leaving the old one on can mean the new one never takes over.

Binding Mode isn’t a rotation mode

The original introduces Binding Mode as “the mode for how it tracks,” then describes each option in terms of rotation and mouse input. That’s where it goes off.

The official definition is one sentence.

The binding mode defines the coordinate space Unity uses to interpret the camera offset from the target and to apply the damping.

So what Binding Mode decides is which coordinate space Follow Offset is interpreted in. Whether the camera “rotates” is a consequence of that choice, not something the mode specifies directly.

Seen that way, the six modes line up on a single axis: how much of the target’s rotation you take.

Binding ModeSpace the offset is read inOfficial definition
Lock To TargetThe target’s full local frame“When the target rotates, the camera rotates with it to maintain the offset and to maintain the same view of the target.”
Lock To Target No RollTarget local, roll removed“Makes the CinemachineCamera use the local frame of the Follow target, with roll set to 0.”
Lock To Target With World UpTarget local, yaw only“This binding mode ignores all target rotations except yaw.”
Lock To Target On AssignA snapshot of the target frame at assignment“This offset remains constant in world space.”
World SpaceWorld coordinates“The camera will not change position when the target rotates.”
Lazy FollowCamera local“This mode emulates the action a human camera operator would take when instructed to follow a target.”

Top to bottom, less and less of the target’s rotation is reflected. Lock To Target rolls the camera when the target rolls; World Space keeps the camera’s position put no matter how the target spins.

The original describes Lock To Target On Assign as “moves toward the target but doesn’t rotate.” More precisely, it takes one snapshot of the target’s orientation at assignment or activation and pins that offset in world space. It doesn’t ignore rotation — it uses it exactly once.

Lazy Follow is likewise described as “a delayed response is added,” but it isn’t simply a delay. It’s a distinct mode that interprets the offset and damping in camera-local space, which is why the camera keeps its distance and height while following regardless of which way the target faces. Hence the description about emulating a human camera operator.

No Binding Mode rotates on mouse input

For Lock To Target With World Up, Lock To Target No Roll and Lock To Target, the original states that the camera “rotates via mouse input.” That doesn’t hold. Whatever the Binding Mode, Cinemachine Follow does not read input.

Cinemachine handles input at an entirely different layer. The official wording:

Cinemachine cameras don’t directly process user input. Instead, they expose axes that are meant to be driven, either by script, animation, or by user input.

To turn the camera with a mouse you use a component that exposes input axesCinemachine Orbital Follow, Cinemachine Pan Tilt and the like — and attach a Cinemachine Input Axis Controller to drive them. The Follow + Rotation Composer pairing has no such axes.

Which means the original’s condition 3 — “is unaffected by mouse input” — isn’t achieved by picking the right Binding Mode. It’s satisfied from the start because this preset has no input path at all. The flip side being that if you later want mouse control, you have to change components, not settings.

Which mode for a runner or a racer

Sorted by purpose:

For a runner, the Rotation Composer side matters too. With the character pinned dead centre you can’t see what’s ahead, so a common combination is lowering Screen Position to open up the view along the direction of travel, and using Dead Zone so the camera doesn’t react to every lane change.

What the Rotation Composer does

The original’s summary — Follow doesn’t handle the camera’s own rotation, so you need Rotation Composer alongside it — is right. The official description:

This CinemachineCamera Rotation Control behaviour rotates the camera to face the Look At target. It also applies offsets, damping, and composition rules.

The main properties, in the docs’ own terms:

Target Offset doesn’t move the camera

The original explains Rotation Composer’s Target Offset as “relative X, Y, Z distance from the target / adjusts the camera position relative to the target’s position.” It isn’t a value that adjusts camera position. The official definition:

Offset from the center of the Look At target, in target-local space.

Rotation Composer is a rotation control module, so this value moves the point the camera looks at, in the target’s local space. It’s what you use to aim at the character’s head rather than their feet. Moving the camera’s position is Follow Offset, over on Cinemachine Follow.

The names are similar enough to mix up, so: Follow Offset is where the camera stands, Target Offset is where it looks.

There are two Dampings with the same name

Both modules have a Damping, which is its own source of confusion. They do different jobs.

That’s what decides which one to touch when the camera feels sluggish. Slow to keep up, look at Follow; slow to centre, look at Composer.

When reading Cinemachine 2 material

Search this topic and a lot of Cinemachine 2-era writing comes back mixed in. The component names changed wholesale, so it doesn’t even line up on names. The mapping from the 3.1 docs:

Cinemachine 2Cinemachine 3
CinemachineVirtualCameraCinemachineCamera
CinemachineTransposerCinemachineFollow
CinemachineComposerCinemachineRotationComposer
CinemachineFramingTransposerCinemachinePositionComposer
CinemachineOrbitalTransposerCinemachineOrbitalFollow
CinemachinePOVCinemachinePanTilt

The namespace also moved from Cinemachine to Unity.Cinemachine. And the structure itself changed: from 3 onwards the pipeline components sit directly on the camera GameObject rather than on a hidden child. The hidden child you see in version 2 screenshots doesn’t exist in 3.

The original is from December 2024 and already uses Cinemachine 3 names, so that part can be followed as written.

Summary

References


Share this post:

Previous Post
Subscribing to BACKND via AWS Marketplace: Start With Why the Warnings Are There
Next Post
Unity's PlayerInput: One Behavior Setting Rewrites Your Code