true iff totalElements is greater than zero and nothing made the counts
a property of this RUN rather than of the store: no elements dropped by
renderer capacity limits, no refinement stop at the residency ceiling, no
GPU-pool eviction on the byte budget. HIDDEN nodes count, and every level
of a substitutive kind=lod group counts, exactly as in DebugState;
so ok: true does not guarantee a non-blank screenshot. A false verdict
can therefore mean "retry later", "loaded but truncated", or "loaded but
capped"; callers must use reason to distinguish them.
OptionalreasonWhy the verdict is not ok — dropped elements, a residency stop, a
byte-budget pool eviction, an empty scene, an unusable snapshot shape — or,
on an otherwise-ready verdict, a caveat about the reported numbers (a total
that had to be counted as 0 because it was non-finite, or because the
snapshot did not carry it at all). Concurrent causes are reported together,
; -joined, rather than the first one shadowing the rest. No clause can
contain that sequence — the residency clause separates its own parenthetical
fields with commas, the unreadable-totals caveat separates its two halves
the same way, and every snapshot-supplied string this module echoes has its
semicolons flattened first (see echoable) — so splitting on '; '
recovers exactly the causes and nothing else. Absent when the scene is ready
and every total read cleanly.
Drawn points summed over all point-cloud nodes.
Drawn splats summed over all gsplat nodes.
Drawn line segments summed over all line nodes.
Drawn triangles (current draw range) summed over all mesh nodes.
The readiness number: the maximum of the snapshot's own reported
totalElements field and the sum of the four per-type totals above.
The max is a VERSION-SKEW hedge, not arithmetic. The tool talks to
whatever viewer build happens to be served at APP_URL, so the snapshot
may be stale or partial; taking the max means such a snapshot's own
totalElements can only under-claim relative to itself, never under-claim
against the per-type totals it is carrying (which is exactly how #1579
printed 1200 triangles next to "nothing loaded"). The current viewer sets
the field to precisely that sum (debug-state.ts), so on a live snapshot
the max is inert and this is simply the sum.
Elements omitted by renderer capacity clamps.
Distinct node paths progressive refinement declined at the residency byte
ceiling. 0 when refinement never stopped — and also 0 when the snapshot
carried a stop whose count was unreadable, in which case the verdict is
still a refusal and reason says the count could not be read (presence of
the stop is the signal, not its magnitude).
Cumulative GPU buffer-pool evictions forced by the VRAM byte budget. 0
when the pool never evicted on bytes, when the snapshot carries no pool
stats, or when the field was unreadable. Deliberately NOT the pool's total
evictions, which is dominated by routine LRU recycling on any nD scene
and would refuse every normal capture.
Number of point-cloud nodes in the scene.
Number of gsplat nodes in the scene.
Number of line nodes in the scene (lineMeshes).
Number of mesh (triangle-surface) nodes in the scene (meshNodes).
JSON-serialisable readiness summary — what a capture tool logs and branches on. Reports all FOUR geometry types: a mesh-only or lines-only scene is as legitimately "loaded" as a points one, and naming only points/gsplats (as the old inline read did) makes a fully-populated mesh scene read as empty.
reasonis NOT exclusive took: false. A scene can be ready AND carry a caveat about the numbers printed alongside it (a total that was present butInfinity/NaN, or absent from the snapshot altogether, is counted as 0, so the counts under-state the scene). A count the tool could not read must never print as a bare0with nothing said about it — that silent zero is the class of bug #1579 was.