Luxar Viewer API Documentation - v2026.9.22
    Preparing search index...

    A loader's ladder footprint.

    TWO TERMS, AND OMITTING THE SECOND BREAKS THE BUDGET ASYMMETRICALLY. The decoded payload is only part of what a committed node costs: each element also occupies a fixed row in the renderer's element texture, and that row's size differs sharply per geometry — 96 B/segment for Lines (6 RGBA32F texels), 64 B/splat for GSplats (4), 48 B/point for Points (3).

    Measured against the decoded payloads those elements come from (~27 B/vertex for Lines, ~43 B/splat for GSplats), the texture row is ~3.6x the payload for Lines but only ~1.5x for GSplats. So a budget fed the payload alone does not merely under-count — it under-counts LINES BY ~2.4x MORE THAN GSPLATS, and the shared sweep ceiling then declines a 598 MB gsplat node while admitting a 901 MB lines node. That is exactly what was observed when the cap was first measured under forced pressure, and it made the cap useless for the geometry it was written for.

    The element-row term is derived from each geometry's own authoritative layout constant (rendering/element-texture-layout), not estimated. It deliberately excludes the renderer's separate 8 B/element ordering pair documented in the module header.

    interface LadderResidency {
        residentBytes: number;
        loadedRungs: number;
        elementCount: number;
        bytesPerElement: number;
    }
    Index
    residentBytes: number

    Total bytes of every typed array the loaded rungs hold.

    loadedRungs: number

    How many rungs those bytes represent.

    elementCount: number

    Committed element-texture rows (segments / splats / points; Mesh has none).

    bytesPerElement: number

    This geometry's element-texture row size, from its layout constant.