orbital-engine
    Preparing search index...

    Function orbitPath

    • Sample points around the full ellipse EVENLY BY REAL ARC LENGTH — not by true anomaly, eccentric anomaly, or time — for drawing the orbit path itself, independent of where the body currently sits on it.

      Real, observed bug history: sampling evenly by true anomaly packed points tightly near periapsis and left apoapsis badly undersampled (for Halley's Comet, e ≈ 0.967, a ~60x gap-size disparity at any fixed segment count). Switching to even steps in ECCENTRIC anomaly narrowed that to ~4x — better, but for a large, eccentric, real-scale orbit (Eris, e ≈ 0.44; worse for Halley) that remaining ~4x still showed up as a visible gap between the body's own live position and its nearest point on the drawn line, worst right at apoapsis — exactly where a body spends most of its time, since it moves slowest there.

      Arc length is the actual, direct fix: points evenly spaced by real distance traveled along the curve are, by construction, evenly spaced everywhere, for any eccentricity. There's no closed form for an ellipse's arc length (it's an elliptic integral), so this walks a dense oversample of the curve (ARC_LENGTH_OVERSAMPLE raw points, evenly spaced in eccentric anomaly — plenty fine-grained to approximate true arc length well past what any requested segment count could resolve) and resamples that at even cumulative-distance intervals. Computed in the perifocal (pre-rotation) plane — the same 3D rotation into the parent's reference frame applied afterward is a rigid transform, which preserves arc length exactly, so measuring distance before rotating gives the same answer as after, more cheaply.

      This also means the resulting spacing is even in RENDERED (compressed) space too, not just real km — orbit-to-world compression (orbitCompressionRatio, in render.ts) is one uniform scale factor for the whole orbit, and uniform scaling preserves relative arc-length proportions exactly.

      Parameters

      Returns Vec3Km[]