BabylonJS/Babylon.js · error · Error

Error parsing variables

Error message

Error parsing variables

What it means

Thrown by _parseVariable when a variable (or event value) references a `type` index that does not exist in the parser's parsed type table. The type table is built from the graph's `types` array signatures; an out-of-range index or an unrecognized signature (which pushed `undefined` into the table) causes this throw.

Source

Thrown at packages/dev/loaders/src/glTF/2.0/Extensions/KHR_interactivity/interactivityGraphParser.ts:146

        }
    }

    private _parseVariables() {
        if (!this._interactivityGraph.variables) {
            return;
        }
        for (const variable of this._interactivityGraph.variables) {
            const parsed = this._parseVariable(variable);
            // set the default values here
            this._staticVariables.push(parsed);
        }
    }

    private _parseVariable(variable: IKHRInteractivity_Variable, dataTransform?: (value: any, parser: InteractivityGraphToFlowGraphParser) => any) {
        const type = this._types[variable.type];
        if (!type) {
            Logger.Error(["No type found for variable", variable]);
            throw new Error("Error parsing variables");
        }
        if (variable.value) {
            if (variable.value.length !== type.length) {
                Logger.Error(["Invalid value length for variable", variable, type]);
                throw new Error("Error parsing variables");
            }
        }
        const value = variable.value || [];
        if (!value.length) {
            switch (type.flowGraphType) {
                case FlowGraphTypes.Boolean:
                    value.push(false);
                    break;
                case FlowGraphTypes.Integer:
                    value.push(0);
                    break;
                case FlowGraphTypes.Number:
                    value.push(NaN);

View on GitHub (pinned to 0592b347b8)

Solutions

  1. Upgrade Babylon.js packages so gltfTypeToBabylonType covers the type signatures used by the asset
  2. Validate that every variable's `type` index is < the length of the graph's `types` array before loading
  3. Check the logged variable in the console to identify which variable/type index failed, then fix the asset
  4. Re-export the asset with an up-to-date exporter that emits supported type signatures

Example fix

// before: variable references type index out of range
{ "variables": [{ "type": 5 }], "types": [{ "signature": "float3" }] }
// after
{ "variables": [{ "type": 0 }], "types": [{ "signature": "float3" }] }
Defensive patterns

Strategy: type-guard

Validate before calling

const typeCount = graph.types?.length ?? 0;
for (const v of graph.variables ?? []) {
  if (!(v.type >= 0 && v.type < typeCount)) throw new Error(`Variable type index ${v.type} out of range`);
}

Type guard

function hasValidType(v: { type: number }, types: unknown[]): boolean {
  return Number.isInteger(v.type) && v.type >= 0 && v.type < types.length && types[v.type] != null;
}

Try / catch

try {
  const parser = new InteractivityGraphToFlowGraphParser(graph, gltf);
} catch (e) {
  if (e.message === 'Error parsing variables') {
    console.warn('Interactivity variable references an unknown type; skipping interactivity graph');
    return null;
  }
  throw e;
}

Prevention

When it happens

Trigger: A variable/event value's `type` index points past the end of the graph's `types` array, or the type at that index has a `signature` not present in gltfTypeToBabylonType (e.g. a newer glTF type like an opaque/declared type not yet supported), so this._types[i] is undefined.

Common situations: Assets authored with newer KHR_interactivity type signatures (e.g. string, or declared types) against an older Babylon.js build; hand-edited glTF with a bad type index; exporters writing types arrays incorrectly.

Related errors


AI-assisted analysis of BabylonJS/Babylon.js@0592b347b8 (2026-08-30). Data as JSON: /api/errors/23c7718eeba15fc1. Report an issue: GitHub.