Where to fly the camera for a selected body: centred on the body itself,
at a distance chosen by framing:
'body' (the default — what a fresh selection arrives at): the body's
own diameter fills BODY_VIEW_FILL of the view, widened just enough to
keep a ring system in (RING_VIEW_FILL). Moons and stations are
deliberately ignored. Arriving used to always use the 'system'
framing below, which framed a planet together with its whole moon
system — Jupiter's outer moons put Jupiter itself at a few pixels — so
planets arrived as small dots and real surface textures were barely
visible. The moon-system view is still one action away (selecting the
selected body again — see useSelectionNavigation).
'system': a distance that fits every real LOCAL child (a body whose
parentId is this one AND that actually orbits it nearby — moons,
stations, whatever's genuinely close — see CelestialBody.
coOrbitalWithParent) rather than a fixed zoom level. A leaf body with
nothing orbiting it frames at 4x its own radius. Uses the dataset's
own parent/child links directly — no geometric "what's nearby"
heuristic needed, because this engine's bodies already carry their
real orbital relationship. computeFocusForSystem is this framing of
the star.
A child with coOrbitalWithParent: true (a Lagrange-point station,
grouped under its reference planet for labelling but really orbiting the
star independently, millions of km away) is deliberately excluded from
the 'system' fit — including it would zoom a planet's own view out to
interplanetary scale just to fit a station that was never actually
"nearby" in the first place, defeating the point of zooming to the planet
at all. It's still a real child for every other purpose (selection,
dropdown grouping, goDown) — only the camera-framing extent skips it.
Both framings size from trueRadius, the same radius BodyShape renders at
close range — never the pixel floor (see pixelFloor.ts), which is a
screen-space visual aid only. A body loaded from a real model (modelUrl)
is normalised to unit radius and scaled by that same radius (see
BodyShapes.tsx), so it frames the same way as a placeholder sphere —
a true-scale-tiny satellite (the ISS, Hubble) included, now that the
precision floor sits far below it (see ABSOLUTE_MIN_CAMERA_DISTANCE).
simDate doesn't have to be "now" — OrbitalSystemScene deliberately
passes a date advanced by the coming flight's own duration's worth of
simulated time (when playing — see flightDurationMs and
FocusTarget.flightDurationMs) for a FRESH selection, so this resolves to where the
body will actually BE once the resulting flight finishes, not where it
was at the moment of selection. See CameraRig.tsx's own header comment
for the real, reported bug this fixes: re-aiming a flight at a body's
live position every frame turns into visible violent jumping once that
body's orbital period gets shorter than the flight's own duration (a
close, fast orbiter like the ISS, at high simulated time — it can
complete dozens of full laps within a single flight of a second or two). Framing a
single, deterministic PREDICTED destination instead needs no per-frame
re-aiming at all — it's exactly as accurate (orbital motion is fully
deterministic) and cannot alias into jitter no matter how fast the
orbit is.
Where to fly the camera for a selected body: centred on the body itself, at a distance chosen by
framing:'body'(the default — what a fresh selection arrives at): the body's own diameter fills BODY_VIEW_FILL of the view, widened just enough to keep a ring system in (RING_VIEW_FILL). Moons and stations are deliberately ignored. Arriving used to always use the'system'framing below, which framed a planet together with its whole moon system — Jupiter's outer moons put Jupiter itself at a few pixels — so planets arrived as small dots and real surface textures were barely visible. The moon-system view is still one action away (selecting the selected body again — see useSelectionNavigation).'system': a distance that fits every real LOCAL child (a body whose parentId is this one AND that actually orbits it nearby — moons, stations, whatever's genuinely close — see CelestialBody. coOrbitalWithParent) rather than a fixed zoom level. A leaf body with nothing orbiting it frames at 4x its own radius. Uses the dataset's own parent/child links directly — no geometric "what's nearby" heuristic needed, because this engine's bodies already carry their real orbital relationship. computeFocusForSystem is this framing of the star.A child with
coOrbitalWithParent: true(a Lagrange-point station, grouped under its reference planet for labelling but really orbiting the star independently, millions of km away) is deliberately excluded from the'system'fit — including it would zoom a planet's own view out to interplanetary scale just to fit a station that was never actually "nearby" in the first place, defeating the point of zooming to the planet at all. It's still a real child for every other purpose (selection, dropdown grouping, goDown) — only the camera-framing extent skips it.Both framings size from trueRadius, the same radius BodyShape renders at close range — never the pixel floor (see pixelFloor.ts), which is a screen-space visual aid only. A body loaded from a real model (modelUrl) is normalised to unit radius and scaled by that same radius (see BodyShapes.tsx), so it frames the same way as a placeholder sphere — a true-scale-tiny satellite (the ISS, Hubble) included, now that the precision floor sits far below it (see ABSOLUTE_MIN_CAMERA_DISTANCE).
simDatedoesn't have to be "now" — OrbitalSystemScene deliberately passes a date advanced by the coming flight's own duration's worth of simulated time (when playing — see flightDurationMs and FocusTarget.flightDurationMs) for a FRESH selection, so this resolves to where the body will actually BE once the resulting flight finishes, not where it was at the moment of selection. See CameraRig.tsx's own header comment for the real, reported bug this fixes: re-aiming a flight at a body's live position every frame turns into visible violent jumping once that body's orbital period gets shorter than the flight's own duration (a close, fast orbiter like the ISS, at high simulated time — it can complete dozens of full laps within a single flight of a second or two). Framing a single, deterministic PREDICTED destination instead needs no per-frame re-aiming at all — it's exactly as accurate (orbital motion is fully deterministic) and cannot alias into jitter no matter how fast the orbit is.