Cameras that frame, not follow

orblit_camera treats a camera as a shot rather than an object. You don’t say where the camera is. You say what it should be framing, and the engine works out where to put it.

final shot = VirtualCamera(
  name: 'over the shoulder',
  priority: 20,
  lens: const Lens(fieldOfView: 40),
);
return shot;

Body and aim are separate

A shot has a body, which decides where to be, and an aim, which decides where to look. They are independent, and that is the point. “Orbit the player at four metres” and “keep the boss in the upper third of frame” are different questions, and a camera that ties them together can only answer one of them.

StaticBody is the default. It sits where you put it.

Priority decides which one is live

Several shots can exist at once, and the enabled one with the highest priority is the one you see. A cutscene raises its shot’s priority and lowers it again afterwards, and nothing else has to know what the camera was doing before.

The CameraBrain runs the blend between them.

Blends

You can cut between shots. Blending is usually better, and BlendStyle picks the curve using the words a camera operator would use rather than the name of an easing function.

Blends are sampled, like everything else with a playhead, so one that gets interrupted halfway through and sent somewhere else still does the sensible thing.

Damping

damp and dampingFactor are the frame-rate-independent smoothing that every follow camera needs. The obvious position += (target - position) * 0.1 is wrong, because it smooths twice as fast at 120 fps as at 60. A camera tuned on one machine is then wrong on another.