Preserving CAD Assembly Metadata in glTF

Converting Computer-Aided Design (CAD) models to glTF often risks flattening product hierarchies and stripping engineering data. However, glTF natively supports hierarchical scene graphs and metadata storage that can fully preserve original CAD assembly trees, component names, and part-level attributes. This article details the specific core glTF nodes, properties, and official extensions required to retain structural fidelity and metadata during CAD-to-glTF translation.

Core Node Hierarchy: Preserving the Assembly Tree

The structural relationship of an assembly—such as top-level assemblies, sub-assemblies, and individual parts—is maintained using the core glTF nodes array within the scene graph.

• nodes[]: Each entry represents an element in the CAD tree (an assembly, component instance, or solid body).
• children: Inside a node, the children array contains the indices of lower-level nodes. Nesting indices within children recreates the original parent-child relationships of the CAD assembly structure without merging bodies into a single mesh.
• matrix or translation / rotation / scale (TRS): Each node retains its local transformation relative to its parent node, ensuring components remain oriented correctly in 3D space according to the original CAD coordinate system.

Part and Assembly Identification: The name Property

Every glTF node includes an optional name property defined as a UTF-8 string:

{
  "name": "Front_Suspension_Assembly_RevB",
  "children": [1, 2]
}

• Node Names: Assigning the original CAD part number, instance name, or assembly label directly to node.name preserves human-readable identification.
• Mesh Names: The mesh.name property can store the identifier of the underlying geometry or solid body representation, distinguishing the geometric definition from instance occurrences.

Custom Engineering Data: The extras Node

Standard glTF does not have dedicated engineering fields for CAD parameters like material densities, tolerance classes, or supplier part numbers. To store arbitrary CAD data, use the native extras property.

The extras object can be attached to any glTF element, most notably nodes:

{
  "name": "Hex_Bolt_M8x20",
  "mesh": 0,
  "extras": {
    "PartNumber": "ISO4017-M8x20-8.8",
    "Material": "Steel Grade 8.8",
    "Mass_kg": 0.015,
    "CAD_GUID": "e3b0c442-98fc-1c14-9afbf4c8996fb924",
    "Layer": "Fasteners"
  }
}

extras accepts valid JSON types (objects, arrays, strings, numbers, booleans) and is universally supported across glTF loaders, making it the most common method for preserving unstructured CAD metadata.

Standardized glTF Extensions for CAD/BIM Metadata

For high-volume datasets or standardized enterprise pipelines, relying purely on extras can cause performance overhead or data ambiguity. Two official extensions address structured metadata:

1. EXT_structural_metadata

Designed for complex BIM and CAD workflows, this extension provides a formal schema system:

• Defines strongly typed property tables (integers, floats, strings, enums).
• Attaches metadata directly to nodes, instances, or geometry vertices without duplicating string keys.
• Dramatically reduces file size when dealing with large assemblies containing thousands of repeated parts.

2. KHR_xmp_json_ld

This extension embeds standard Adobe XMP (Extensible Metadata Platform) metadata directly into the glTF model using JSON-LD. It is ideal for preserving document-level CAD attributes such as authoring software, revision history, copyright, and lifecycle states.