Cameras that frame, not follow

orblit_camera treats a camera as a shot rather than as an object. You don’t say where the camera is. You say what it ought to 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’re independent, and that’s the whole point. “Orbit the player at four metres” and “keep the boss in the upper third of frame” are different questions, and a camera that couples them can only ever answer one of them.

A 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

Cutting between shots is one option. Blending is usually the better one, and BlendStyle picks the curve, using the vocabulary a camera operator would reach for 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 does the sensible thing.

Damping

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