IFClite TypeScript API
    Preparing search index...

    Interface MeshData

    Individual mesh data with geometry and metadata.

    interface MeshData {
        color: [number, number, number, number];
        express_id: number;
        geometry_class?: number;
        geometry_item_id?: number;
        global_id?: string;
        ifc_type: string;
        indices: Uint32Array;
        material_id?: number;
        material_name?: string;
        metallic?: number;
        name?: string;
        normals: Float32Array;
        origin?: [number, number, number];
        positions: Float32Array;
        presentation_layer?: string;
        properties?: Record<string, string>;
        roughness?: number;
    }
    Index
    color: [number, number, number, number]

    RGBA color [r, g, b, a] in 0-1 range

    express_id: number

    Express ID of the IFC element

    geometry_class?: number

    Geometry provenance for the viewer's Model/Types switch (issue #1841), mirroring the canonical MeshData.geometryClass: 0 = occurrence, 1 = orphan type-product map, 2 = instanced type-library template (must NOT be drawn in the normal view — doing so duplicates geometry). Absent ⇒ 0.

    geometry_item_id?: number

    The IfcRepresentationItem this (sub-)mesh was tessellated from — ALWAYS a representation item, never a material. Before #3199 the server sent an IfcMaterial id here for material-layered walls, so a consumer following it to source landed on the wrong entity. Absent where the identity is genuinely merged away (single-mesh fallback, cached IfcMappedItem, instanced).

    Never 0: #0 is not a STEP instance name. The same filter applies to material_id below.

    global_id?: string

    IfcGloballyUniqueId of the source element, when extracted.

    ifc_type: string

    IFC type name (e.g., "IfcWall")

    indices: Uint32Array

    Triangle indices

    material_id?: number

    The IfcMaterial whose layer this (sub-)mesh slices — ALWAYS a material, never a representation item. DISJOINT from geometry_item_id: the server never sends both. Never 0 either, and here that is load-bearing rather than trivially true: an unreferenced layer (an air gap) decodes to material_id 0 in the mesher, and is sent as ABSENT rather than as IfcMaterial #0, which is not an entity anyone can navigate to (#3199).

    material_name?: string

    Resolved material name for this (sub-)mesh, when known.

    metallic?: number

    IFC-authored metallic factor in [0, 1] (#5984), from the IfcSurfaceStyleRendering the mesh's colour came from. Absent when the file authored no metal evidence; the renderer then keeps its default.

    name?: string

    Element Name attribute, when extracted.

    normals: Float32Array

    Vertex normals as flat array (x, y, z triplets)

    origin?: [number, number, number]

    Per-mesh local-frame origin in Y-up metres: world vertex = origin + position (issue #1841). Mirrors the canonical @ifc-lite/geometry MeshData.origin. Absent (⇒ [0,0,0]) means positions are already absolute world coords — the world-baked default. The renderer applies it as a per-batch translation, so building/georef-scale placement never collapses to the world origin and repeated (instanced) elements place correctly.

    positions: Float32Array

    Vertex positions as flat array (x, y, z triplets), in Y-up metres. Every server transport (JSON, parquet, optimized parquet) emits the same Y-up frame — the server converts from IFC Z-up once, in one place. See origin: the world position of vertex i is origin + positions[3i..3i+3].

    presentation_layer?: string

    Presentation layer assignment, when extracted.

    properties?: Record<string, string>

    Space/zone properties attached to the element, when extracted.

    roughness?: number

    IFC-authored roughness in [0, 1] (#5984), same source as metallic. Absent when unauthored. 0 is a real value (mirror-smooth glass), so test it with !== undefined, never for truthiness.