Interface FocusTarget

Vector from the focused body toward its parent (not normalized, not necessarily even close to unit length — just a direction), or null when there's no parent to bias toward (the star, a belt). Used to bend the camera's FINAL viewing angle partway toward "looking back at the parent" when flying to a child, rather than blindly preserving whatever direction the camera happened to arrive from forever — see computeEndDirection.

The smallest angle, in degrees, the parent (see lookBias) must sit off the settled view axis so the framed body doesn't eclipse it — see computeEndDirection. 0 (or omitted) means no constraint: there's no parent, or the parent already looks bigger than the body and so can't hide behind it (a satellite over its planet).

Unit direction from the focused body toward the system's star (true positions — the direction star lighting shades from), when the scene is lit from the star (lightFromStar) so the settled view should be on the body's day side — see computeEndDirection. Null or omitted: no day-side constraint, the unlit behaviour.

The nearest shared ancestor of the body just left and the one being flown to (see findContextBody) — Earth, when switching between the ISS and Hubble; the Sun, when switching between Earth and Mars; null when there isn't one worth showing (see findContextBody's own comment for exactly when). Used only DURING the flight (see camera.ts's applyContextBulge / CameraRig.tsx) to keep this body in frame as an establishing-shot anchor, not part of the settled, true-scale framing itself — null here just means "no CalledFrom previous body was known (a fresh page load, say), not "definitely nothing to show."

Where the focused body will REALLY be at each moment of the flight toward it, not just at its very end (position above already is that end point) — see safePredictFlightTarget. Optional (and typically undefined/null for a belt, the whole system, or a flight computed while paused, where every sample would be identical anyway) rather than a required field: computeFocusForBody itself doesn't compute this (it has no daysPerSecond to predict FROM — see OrbitalSystemScene, which computes it separately and merges it in for a body selection). Consumed by CameraRig's sampleFlightPath call to keep the flight's own look-at point tracking the body's real predicted trajectory, the same "consider future locations" behaviour routeCameraSimulator.ts already models for the fixed test fixture.

How long the flight to this focus will take, when the caller already decided — the duration position and predictedTargetAt were predicted for (see useSelectionNavigation, which plans it from the live camera pose before predicting the arrival). The flight must use this same number, or a moving body's predicted arrival and the flight's real arrival happen at different moments. Omitted, the flight computes its own from its endpoints (see flightDurationMs).