Interface LoadedLinesData

Vertex positions (N vertices * ndim dimensions), flattened row-major

Segment index pairs (M segments * 2) - local indices into positions array

Vertex widths (N,) or (1,) if broadcast

Vertex colors (N * colorComponents) RGB or RGBA, null if not present Supports Float32Array (HDR), Uint8Array (SDR), or Uint16Array

Number of channels per color entry: 3 (RGB) or 4 (RGBA — the alpha column is per-vertex opacity, volumetric phase 4). Defaults to 3 when omitted. Mirrors LoadedPointsData.colorComponents.

Vertex sharpness (N,) null if not present

Per-vertex scalar values for colormap lookup (N,). Optional — when omitted (undefined), the line shader's USE_COLORMAP path stays inactive and ProcessedLinesData.startScalars/endScalars are also undefined.

Aligned with LoadedPointsData.scalars?: ScalarArray (both optional + undefined absence) so consumer truthy-checks read uniformly across node types.

Dtype aligned with ScalarArray (Float32/Float16/Uint8) so Uint8 loaders can keep native dtype through the accumulator and pay a single widening at projection time rather than 4× memory up front.

Number of segments loaded

Number of vertices loaded

Dimensionality for interpreting vertices array

The ascending, pairwise-disjoint ON-DISK VERTEX ranges that the loaded per-vertex arrays — positions, widths, colors, sharpness, scalars — concatenate, FLATTENED as [start0, end0, start1, end1, …]: each range is a half-open [start, end) pair, so the array's length is always even and length / 2 is the range count. This is index space A in the lines picking chain (see rendering/picking/picking-system/element-id-map.ts): line labels are PER-VERTEX and their CSR is keyed by the on-disk sorted vertex row, so these ranges are the second half of the slot → on-disk map picking resolves labels through (data/loaders/element-ids.ts).

A FLAT Uint32Array rather than an object array precisely because this payload is cached: data/loaders/progressive/slice-cache-helper.ts bills only own typed-array properties, so an object array would be retained by the LRU at a billed 0 bytes (a fragmented labelled slice — the loader logs a fragmentation "efficiency" diagnostic, so high range counts are expected — could hold roughly twice the bytes the budget believes), and cloneLodSnapshot would pass the very same mutable objects into the stored snapshot by reference. A typed array is measured and deep-copied for free, and costs ~6x fewer retained bytes per range.

Note this is a VERTEX space, not the segment space SegmentRange names: LinesSpatialIndexLoader queries visible SEGMENT ranges, then derives the vertex ranges those segments reference and loads only those.

Published ONLY when the node declares a per-element string/image CSR (has_labels / has_image_labels / has_keys): nothing else reads the map, and the field would otherwise ride along in every SliceCache snapshot for free. Absent ⇒ no map is composed and picking falls back to the raw slot.