Luxar Viewer API Documentation - v2026.9.22
    Preparing search index...
    interface LODProgressProviderDeps {
        loaderMaps: readonly ReadonlyMap<string, unknown>[];
        lodGroupRegistry: LODGroupRegistry | null;
        partitionGroups?: readonly { path: string; partCount: number }[];
        committedLODCounts?: () => ReadonlyMap<string, number>;
        refinementHold?: (path: string) => RefinementHoldReason | null;
    }
    Index
    loaderMaps: readonly ReadonlyMap<string, unknown>[]

    The four per-geometry loader maps (points / lines / gsplats / mesh), keyed by scene-graph path. Additive nodes connect a single progressive loader at the node path. Mesh joins them because a reveal ladder is a progressive loader with the same three getters, even though mesh takes part in none of the monitor's other per-type providers.

    lodGroupRegistry: LODGroupRegistry | null

    The scene's LOD-group registry (substitutive levels), or null.

    partitionGroups?: readonly { path: string; partCount: number }[]

    Snapshot of partition groups ({ path, partCount }) captured at scene build. A partition's frustum selector changes child visibility, not its structural part count, so a one-time snapshot is sufficient — groups surface in the monitor's scene-graph summary as kind:'partition' states. Empty/omitted for scenes without partitions.

    committedLODCounts?: () => ReadonlyMap<string, number>

    Rungs actually COMMITTED per node path, from the committedLODCount stamp each commit writes to the mesh userData. Supplied by the caller because it owns the live THREE root group (same arrangement as the draw-order provider).

    Without it the panel reports the LOADER'S CURSOR, which advances as each rung ARRIVES rather than when it is drawn. A pass whose commit fails or is superseded therefore leaves the two disagreeing — and it disagrees loudest in exactly the situation a user is trying to diagnose. On the hosted Laniakea demo, basins showed "LOD 7/7 ~100%" while rendering a coarse prefix and no longer refining; the monitor was the one surface that could have revealed the stall and it actively concealed it (#2426).

    Optional so a caller without a root group (tests, headless wiring) keeps the previous behaviour rather than losing the panel entirely.

    refinementHold?: (path: string) => RefinementHoldReason | null

    Why this path's next rung is HELD back, if it is (SceneLoader. refinementHoldReason: the density gate at the current framing, or the residency ceiling). Lets the monitor tell a held rung from one still streaming; both read as refining to the loader.