ReadonlylodMay appear as a kind=lod group's display_type, i.e. can be a level in a
substitutive LOD ladder. Implies the leaf stamps loadedViewVersion so the
LOD registry can judge per-slice freshness.
ReadonlypartitionMay appear as a kind=partition group's display_type, i.e. can be split
into spatially-culled parts. Mirrors the Python-side allowlist in
luxar/typing_utils/geometry_capabilities.py (which
core/node/specialized_groups.py calls to gate the wrapper).
ReadonlypooledRendered through the instanced-quad path: per-element attributes live in a
GPU element texture drawn from the buffer pool, and the data monitor tracks
a per-type accumulator. A type rendered from a plain BufferGeometry is
not pooled. The compile-time keying of the monitor's per-type records is
POOLED_GEOMETRY_TYPES in types/data-monitor-types.ts — the test suite
pins the two to agree.
ReadonlydepthRegisters per-element centers with the depth-sort coordinator, so switching blending mode has to start or stop sorting for the layer.
"Center" is per-type — splat/point centers, line segment midpoints, triangle
centroids — and so is the APPLY: the three instanced types permute an
aSortedIndex draw-slot indirection, mesh permutes geometry.index itself.
Neither distinction belongs here. What this flag answers is the one question
its consumer asks (ui/layers/layer-apply.ts →
noteDepthSortBlendingModeSwitch): does a mode change into or out of an
order-dependent mode have to reprocess/release this node?
The viewer features a geometry type may participate in.
Every flag is a capability question that some call site asks at runtime. A
falsemeans there is no viewer path for that pairing today, so admitting the type would take a code path that cannot represent it. Why there is no path differs from flag to flag — see the per-flag notes on themeshrow.