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

    Module types/geometry-capabilities

    Which geometry types support which viewer features.

    The geometry vocabulary is single-sourced from the format contract (GEOMETRY_TYPES / GeometryTypeName, generated from format-contract/contract.yaml). But plenty of viewer code does not want the whole vocabulary — it wants "the types that can be a kind=lod child", or "the types stored in the instanced-quad element texture". Those are subsets, and before this module each one was an inline x === 'points' || x === 'lines' || x === 'gsplats' chain or a hand-written Set.

    Inline chains are the wrong shape for two reasons:

    1. They all look identical, so a sweep that widens the vocabulary widens the capability sets with it — silently enabling a feature for a type that does not support it. (This has already been caught twice in review.)
    2. They are invisible to the compiler, so adding a geometry type to the contract produces no error and no prompt to classify it.

    GEOMETRY_CAPABILITIES fixes both: it is a Record<GeometryTypeName, GeometryCapabilities>, so adding a geometry type to the contract is a compile error here until its capabilities are declared — and every runtime consumer then behaves correctly without further edits.

    Type annotations cannot read this table (a union cannot be derived from a value without more machinery than it is worth), so the handful of interface fields that spell a subset out by hand carry a comment pointing here instead.

    GeometryCapabilities
    GEOMETRY_CAPABILITIES
    isGeometryType
    supportsLod
    supportsPartition
    isPooledGeometry
    isDepthSortable
    defaultBlendingMode