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

    Interface PartitionGroupMetadata

    Metadata stored on a kind=partition Group node's .zattrs.

    interface PartitionGroupMetadata {
        type: "group";
        kind: "partition";
        display_type: "points" | "lines" | "gsplats" | "mesh";
        max_elements: number;
        position_bounds?: { min: number[]; max: number[] };
        bsp_tree?: BspTreeNode;
        transform?: number[];
        opacity?: number;
        absorption?: number;
        gamma?: number;
        intensity?: number;
        offset?: number;
        blending_mode?: BlendingModeName;
        layer?: boolean;
        visible?: boolean;
        nd_transform?: Record<string, unknown>;
        extend_to_all?: string[];
    }
    Index
    type kind display_type max_elements position_bounds? bsp_tree? transform? opacity? absorption? gamma? intensity? offset? blending_mode? layer? visible? nd_transform? extend_to_all?
    type: "group"

    Node type identifier.

    kind: "partition"

    Specialized-group discriminant.

    display_type: "points" | "lines" | "gsplats" | "mesh"

    Geometry type the user sees this layer as. All children must resolve to this same display type (homogeneity is mandatory for Partition — you cannot decompose a single logical layer into mixed-type parts).

    Spelled out rather than GeometryTypeName: this is the PARTITION-CAPABLE subset of the vocabulary, so do not widen it when a geometry type is added — declare that type's partition capability in types/geometry-capabilities instead, and extend this union only if it comes out true. It happens to cover the whole vocabulary today (mesh's partition flag is now true), which does NOT make it the vocabulary — a future type may answer false.

    max_elements: number

    Per-part element cap that drove the BSP recursion. Recorded for diagnostics and for future partition-aware tools.

    "Element" is the drawn primitive of display_type, so for 'mesh' this counts FACES, not vertices — the BSP recurses on face centroids and a part's vertex count is whatever its faces happen to reference.

    position_bounds?: { min: number[]; max: number[] }

    Union of children's position_bounds. Lets picking / framing / scene-bounds-cache treat the layer as one logical entity rather than as N independent meshes.

    bsp_tree?: BspTreeNode

    Split-plane record of the recursive decomposition that produced the parts. Enables the depth-sort coordinator's BSP traversal; absent → it falls back to a per-part centroid-distance heuristic, which is NOT a valid painter's order and pops at the seams as the camera moves.

    Written by every producer that has one: native points/lines/gsplats/mesh partition= adders, to_spatial_partition (the tiles / adaptive recipes, gsplat partition), content- and uniform-tiled fits, and the batch-fit streaming merge. Absent on a pre-2026.7 store, or where a transform could not carry the planes through.

    Exact for point/gsplat BSP cells. Approximate for centroid-split lines/mesh and uniform tiling, whose apodized parts keep their overlap band; those cuts still bound ambiguity to geometry crossing a plane. See BspTreeNode.

    transform?: number[]

    4x4 transform matrix (column-major for THREE.js).

    opacity?: number

    Optional compositing rendering attrs (inherited via scene-graph composition).

    absorption?: number
    gamma?: number
    intensity?: number
    offset?: number
    blending_mode?: BlendingModeName
    layer?: boolean
    visible?: boolean
    nd_transform?: Record<string, unknown>

    Optional nD transform (per-dimension affine / permutation).

    extend_to_all?: string[]

    Visibility extension across non-displayed dimensions.

    Settings
    Member Visibility

    On This Page
    Properties