Luxar Viewer API Documentation - v2026.9.22
    Preparing search index...

    Type Alias AutoRotateAxis

    AutoRotateAxis:
        | "vertical"
        | "horizontal"
        | "view"
        | "world-x"
        | "world-y"
        | "world-z"

    Axis the orbit turntable (auto-rotation) revolves around. Two families:

    Camera frame — named for what the viewer sees, so the choice means the same thing whatever the scene's orientation:

    • vertical — the screen-up axis. The historical (and default) behavior: the scene spins about a vertical line on screen.
    • horizontal — the screen-right axis. The scene tumbles over the top, like a wheel rolling away from the viewer.
    • view — the view direction. A pure roll: the camera never moves, the scene spins in the image plane (the same axis and right-hand sign a positive Shift+scroll roll delta uses).

    World frame — a fixed scene axis, the classic turntable: the subject spins about its OWN axis at any camera elevation, where a camera-frame vertical turntable makes that axis precess (a spin plus a wobble):

    • world-x / world-y / world-z — the scene's ±X / ±Y / ±Z.

    The naming split is deliberate and matches what each family can promise: a bare letter names a WORLD axis here exactly as it does in the gallery harness (tests/screenshots/orbit-axis.ts's per-demo orbitUp), while the camera-frame options get words because the camera frame has up = +Y and a letter would read as a DATA axis in an nD scientific viewer.

    No axis can destabilize the orbit. A camera-frame axis is re-derived from the live orientation each frame but is invariant under its own rotation; a world axis is a constant with no feedback at all. Neither can hit a pole, because camera.up is derived from the orientation quaternion rather than clamped to world up. The one degenerate case is benign: a world axis parallel to the view direction leaves the camera where it is and rolls the image, exactly as view does.