Interface DebugState

Line segments summed over ALL line meshes, hidden ones included — the per-node lineMeshes entries carry visible for filtering.

Current-draw-range TRIANGLES summed over ALL mesh nodes. Like every aggregate above, a hidden node still counts (its draw range is intact) — the per-node meshNodes entries carry visible for filtering.

Elements omitted by per-node element-texture capacity clamps across ALL nodes, including hidden nodes and every substitutive-LOD level. Mesh is not texture-backed.

Per-mesh line summary.

Per-node mesh (triangle-surface) summary.

Substitutive LOD groups (kind=lod) with their active level.

Partition groups (kind=partition) with part / visible-part counts.

GPU buffer pool byte stats (undefined when the pool is disabled).

The progressive-refinement BYTE-ceiling stop, when refinement declined at least one rung while this scene was loaded; ABSENT when it never did. Loader-scoped and cumulative within that life — see RefinementResidencyStop for the contract.

Absence is "no stop", NOT "no information": an older viewer build simply does not carry the field, and a consumer must not read that as a scene in trouble. Presence is the whole signal — the counts in this snapshot then describe a PARTIAL scene whose composition is nondeterministic, which is why capture-readiness.ts refuses on it (#2508).

Flat camera position kept for debug-state compatibility.

Flat camera field-of-view kept for debug-state compatibility.

Whether a LOAD PASS is outstanding on at least one registered scene loader: an updateView sweep (fetch / decode / upload) up to its geometry commit, a failed-loader retry sweep, which takes the same lock, or a view-state QUEUED behind either (the requested slice has not begun loading, so it is still an unfinished pass — without it a nav that lands during a refinement hold would read idle immediately).

It does NOT cover, and must not be read as covering:

• the INITIAL loadScene — that path only touches the loader's lock at its very end (to hand it to the post-load refinement kick). For the first load initialized is the flag to wait on; for an in-page DATASET SWITCH neither helps, because initialized stays true and the fresh loader is registered before its loadScene runs, so isLoading reads false throughout the switch's load.
• lazy substitutive-LOD / deferred-partition ensureLoaded promotions, which run outside any updateView cycle and surface as content-change notifications instead.
• the progressive-LOD refinement drain, which inherits the same lock after the current view has committed. Excluded deliberately: this is first-commit latency, not full-ladder latency — see SceneLoader.isLoadPassInProgress.

The E2E "wait for data" helpers in tests/e2e/helpers.ts poll this field to decide when a load has settled — waitForDataLoaded, waitForDimensionNavigation, waitForSpatialQuery, waitForSpatialQueryOrThrow, waitForNavigationComplete, waitForNavigationCompleteOrThrow, and the state-based fallbacks in waitForRenderStable / waitForNextRender (eight in all) — as do tests/e2e/real-dataset-loading.spec.ts and the two capture specs under tests/screenshots/. So it must always be a real boolean rather than absent: !undefined is true, which would gate on nothing.