Largest vertex count a mesh node may declare, 2^27.
This is the pick vote-key stride: mesh's pick elementId is gl_VertexID
— the one geometry type whose element ordinal is not bounded by the
element-texture capacity — and the largest ordinal a node contributes is
n_vertices - 1, so n_vertices <= 2^27 is the exact alias-free bound.
One vertex more and the vote key wraps into a neighbouring node's range,
which resolves picks to the wrong node with nothing to signal it.
Enforced by the loader's Stage-1 metadata preflight (see
data/mesh/preflight.ts), i.e. before any CHUNK is fetched, so an
oversized declaration costs no geometry allocation.
Precisely "no chunk", not "no allocation": the preflight has to read .zarray
and .zattrs to learn the shapes and encodings it decides on, and a hostile
store's .zattrs is not itself bounded by anything here — a lut_uint16
encoding legitimately carries its lookup table inline as a JSON list, so that
blob could be made arbitrarily large. Bounding a metadata response is a
store-layer concern (every sibling loader reads .zattrs the same way), not
something this gate can do, so the claim is scoped to what it actually buys.
MIRROR: MAX_MESH_VERTICES in
packages/luxar/src/luxar/typing_utils/constants.py must hold the same
value — it is the write-time twin of this gate, so that add_mesh cannot
emit a store Luxar's own viewer then refuses. Both sides are pinned by
tests that name each other.
Largest vertex count a mesh node may declare,
2^27.This is the pick vote-key stride: mesh's pick
elementIdisgl_VertexID— the one geometry type whose element ordinal is not bounded by the element-texture capacity — and the largest ordinal a node contributes isn_vertices - 1, son_vertices <= 2^27is the exact alias-free bound. One vertex more and the vote key wraps into a neighbouring node's range, which resolves picks to the wrong node with nothing to signal it.Enforced by the loader's Stage-1 metadata preflight (see
data/mesh/preflight.ts), i.e. before any CHUNK is fetched, so an oversized declaration costs no geometry allocation.Precisely "no chunk", not "no allocation": the preflight has to read
.zarrayand.zattrsto learn the shapes and encodings it decides on, and a hostile store's.zattrsis not itself bounded by anything here — alut_uint16encoding legitimately carries its lookup table inline as a JSON list, so that blob could be made arbitrarily large. Bounding a metadata response is a store-layer concern (every sibling loader reads.zattrsthe same way), not something this gate can do, so the claim is scoped to what it actually buys.MIRROR:
MAX_MESH_VERTICESinpackages/luxar/src/luxar/typing_utils/constants.pymust hold the same value — it is the write-time twin of this gate, so thatadd_meshcannot emit a store Luxar's own viewer then refuses. Both sides are pinned by tests that name each other.