Class FollowRig

§44's follow rig and spring arm: a node held at an offset from a target, optionally smoothed.

// A chase camera 4 m behind and 2 m above the player, critically damped:
camera.addComponent(
  new FollowRig({
    target: player,
    offset: new Vector3(0, 2, 4),
    frame: "target",
    spring: new SpringDamper({ frequencyHz: 2, dampingRatio: 1 }),
  }),
);
Copy

One class, two §44 rows (decision, R-36 rig half)

§44 names "follow rigs" and "spring arms" separately, and they differ in exactly two independent bits: which frame the offset is read in, and whether the result is smoothed. Two classes would have shared every line and forced an application that wanted a smoothed world-axis follow (an isometric camera) or an unsmoothed target-frame arm (a rigid boom) to pick the wrong one and fight it.

• frame: "world" reads the offset along the world axes, so the camera keeps its bearing while the target turns — the isometric/side-on follow.
• frame: "target" reads it in the target's own frame, so it swings around behind the target as the target turns — the third-person boom. The basis is the target's world matrix columns normalized, so an ancestor's scale moves the arm's anchor without stretching the arm. A Vector3 target has no orientation, so it falls back to the world axes.
• spring omitted snaps to the goal every step; supplied, the placement is the exact exponential step of SpringDamper towards it, integrated in world space so the smoothing does not change when the rig is reparented.

The smoother's state is captured lazily, on the first step that writes: a rig starts from wherever its node actually is rather than easing in from the origin. It keeps advancing on a step whose write is refused by a degenerate parent — the goal is a property of the target, not of the write — but not on a step the §42 check refuses, because that step never reaches this component at all (ConstraintSystem freezes a refused node, exactly as KinematicSystem freezes a refused command).