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

    Variable GEOMETRY_CAPABILITIESConst

    GEOMETRY_CAPABILITIES: Readonly<Record<GeometryTypeName, GeometryCapabilities>> = ...

    Capability matrix for the geometry vocabulary.

    Adding a geometry type to format-contract/contract.yaml will fail to compile here. That is deliberate: the new type's support for LOD, partitioning, pooled storage and depth sorting is a decision that must be made explicitly, not inherited by accident from a widened literal.

    Points / Lines / GSplats are uniformly capable — they are all soft, emissive, per-element primitives drawn as instanced quads. mesh is the row that proves the table earns its keep: three of its flags are TRUE and one is FALSE, each for its own unrelated reason. lod is TRUE because a kind=lod group's levels REPLACE one another and luxar.mesh.decimate is the producer that was missing. partition is TRUE because a BSP cut runs between faces and each part gathers + renumbers its own vertices (luxar.mesh.split) — it was false only for want of that bookkeeping. depthSortable is TRUE because a triangle's center is its vertex centroid, so centers, worker and kernel are all shared and only the apply differs. pooled is FALSE architecturally — a mesh is an indexed BufferGeometry, so there is nothing to pool, and that column can never become true. The row comment below gives each flag its own reason; do not read "impossible" into a column that means "not yet".

    Readonly + frozen: every predicate reads this object live, so a mutation would globally flip a capability for the whole session. (The record is frozen; the rows are readonly at the type level only, so the wiring test can flip one flag at a time through a deliberate cast.)