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
- Upgrade Babylon.js packages so gltfTypeToBabylonType covers the type signatures used by the asset
- Validate that every variable's `type` index is < the length of the graph's `types` array before loading
- Check the logged variable in the console to identify which variable/type index failed, then fix the asset
- 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
- Verify every variable/event value type index is within the types array bounds
- Use an exporter that only emits type signatures supported by gltfTypeToBabylonType
- Upgrade Babylon.js before loading assets authored with newer interactivity types
- Run glTF schema validation as part of your asset pipeline
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
- Error parsing declarations
- Error parsing events
- Error parsing nodes
- Error parsing node configuration
- Error validating interactivity node ${this._interactivityGra
AI-assisted analysis of BabylonJS/Babylon.js@0592b347b8 (2026-08-30).
Data as JSON: /api/errors/23c7718eeba15fc1.
Report an issue: GitHub.