Custom Attributes in Blender glTF Export Workflows

Exporting custom attributes from Blender to the glTF 2.0 format allows technical artists and developers to pass specialized data—such as procedural masks, gameplay parameters, and custom vertex data—directly into real-time engines and web viewers. Blender handles this process through its integrated glTF 2.0 exporter, which converts internal mesh attributes into standard glTF primitive attributes. Understanding the mapping rules, domain limitations, exporter settings, and naming conventions is essential for ensuring this data transfers seamlessly into your downstream pipeline.

Enabling Custom Attributes in the Exporter

By default, Blender’s glTF exporter does not include non-standard mesh data. To include them, you must configure the export settings:

  1. Open the glTF export menu via File > Export > glTF 2.0 (.glb/.gltf).
  2. In the right-hand settings panel, expand the Data section, then expand Mesh.
  3. Check the Custom Attributes box.

When this option is disabled, only standard properties—such as POSITION, NORMAL, TANGENT, TEXCOORD_0, and COLOR_0—are written to the file.

Naming Conventions and the glTF Specification

The glTF 2.0 specification requires all application-specific custom attributes to begin with an underscore (_).

Blender's glTF exporter manages this prefixing automatically:

  • If your attribute in Blender is named AO_Mask, the exporter translates it to _AO_MASK or _AO_Mask in the glTF primitive attributes dictionary.
  • If your attribute already starts with an underscore (e.g., _damage), the exporter preserves it.
  • Standard names that align with glTF conventions (such as standard color attributes or secondary UV sets) are mapped directly to standard glTF semantics like COLOR_1 or TEXCOORD_1.

Keep your custom attribute names alphanumeric to prevent compatibility issues across different glTF loaders (such as Three.js, Babylon.js, or Godot).

Supported Attribute Domains and Data Types

glTF stores data per-vertex within mesh primitives. Because Blender supports multiple attribute domains, the exporter must reconcile Blender's internal data layout with glTF’s vertex-only requirement:

  • Point / Vertex Domain: This is the most direct mapping. Float, Vector, and Color data mapped to vertices convert cleanly to corresponding buffer views without data alteration.
  • Corner (Face Corner) Domain: Since Face Corner data can define split attributes (different values for the same geometric vertex across different faces), the exporter will duplicate vertices along seams where values diverge to preserve data fidelity.
  • Edge and Face Domains: These domains are generally not supported for direct export into vertex-based glTF primitives. Attributes assigned to edges or entire faces must be converted to the Point or Corner domain (for example, using a Store Named Attribute node in Geometry Nodes) prior to export.

Data types like Float, Float Vector (2D, 3D, and 4D), and Color (Byte or Float) map to standard glTF component types (FLOAT, UNSIGNED_BYTE, or normalized integers). Boolean and Integer attributes are typically converted to floats during the export process.

Working with Geometry Nodes

Attributes created procedurally using Geometry Nodes are fully compatible with glTF export, provided they meet two criteria:

  1. The data must be explicitly written using a Store Named Attribute node.
  2. The modifier must either be evaluated during export (enabled by default via the Apply Modifiers setting in the glTF export panel) or manually applied to the mesh before export.

Ensure the attribute is stored on either the Point or Face Corner domain within the Geometry Nodes tree to avoid conversion errors during export.

Consuming Attributes in Downstream Engines

Once exported, custom attributes reside inside the attributes dictionary of the mesh primitive in the resulting JSON or GLB binary:

"primitives": [
  {
    "attributes": {
      "POSITION": 0,
      "NORMAL": 1,
      "_CUSTOM_MASK": 2
    },
    "indices": 3
  }
]

Game engines and WebGL frameworks access these directly:

  • Three.js: Accessed via geometry.attributes._custom_mask.
  • Babylon.js: Accessed through vertex buffer queries using the custom attribute identifier.
  • Custom Shaders: Bound as custom vertex shader inputs for specialized rendering techniques like vertex-driven wind, terrain blending, or simulation caching.