Khronos submitted the KHR_interactivity extension for glTF 2.0 for ratification on July 16, 2026, and it changes what a GLB file can hold. Instead of hard-coding "click this to open it" three separate times for a Unity build, a Godot build, and a browser scene, that logic can now live inside the asset itself as a behavior graph stored right in the glTF JSON next to the mesh and materials. A conformant runtime reads the graph and the interaction just plays. A runtime that doesn't understand it loads the geometry normally and ignores the graph entirely. Right now, in August 2026, Babylon.js is the only major engine with full playback. Unity, Godot, and Unreal all read the mesh fine — interactivity is a separate story for each one, and none of them match Babylon yet.
What's actually inside a behavior graph
A behavior graph is a directed graph of nodes with value sockets and flow sockets: an "on select" node's flow output feeds into a "play animation" node, which feeds into a "set visibility" node, each carrying its own configuration data. KHR_interactivity is the foundation extension; Khronos ships it alongside three companion extensions that cover the common triggers — `KHR_node_hoverability` for cursor-enter events, `KHR_node_selectability` for clicks and taps, and `KHR_node_visibility` for state-driven show and hide. Stack those together and you can build a proximity-triggered animation, an e-commerce-style product configurator, or a chest that only opens after a nearby lever fires, without writing per-engine glue code for any of it.
The timeline is longer than the July headline suggests. Khronos first described the extension as "approaching finalization" in a blog post back in May 2025, following the original public-comment draft from June 2024. It took another 14 months after that post to actually reach a ratification submission. Amazon, Adobe, Babylon.js, and Needle are the names Khronos lists with production or near-production support today. Amazon's Arik Barnett has specifically cited using it for interactive product demos and assembly instructions embedded in product pages, and Babylon.js creator David Catuhe put it plainly when the finalization work landed: "we're proud to say that Babylon.js fully supports KHR_interactivity."
Where it actually runs today
Support splits into three tiers, and none of the four engines BitSoul3D ships plugins for fully matches Babylon.js yet.
| Engine / runtime | KHR_interactivity today | What actually works |
|---|---|---|
| Babylon.js | Full playback | Runs authored behavior graphs as-is, confirmed directly by Babylon's own team |
| Unity | Export only | Needle's UnityGLTF exporter turns Visual Scripting into KHR_interactivity nodes; playback needs Magic Leap's third-party runtime, not core Unity |
| Godot | Partial | `KHR_node_visibility` merged and importing correctly; the value/flow behavior-graph executor isn't in Godot 4.7 or the 4.8 dev builds |
| Three.js | Load-only | `GLTFLoader` reads the extension into the parsed JSON; no built-in executor ships |
| Unreal Engine 5 | Unconfirmed | Not among the engines Khronos names with confirmed support; no public Interchange roadmap entry |
UnityGLTF's Needle-built exporter turns a Visual Scripting graph into KHR_interactivity nodes on export, but reading one back into a running Unity scene depends on Magic Leap's third-party runtime rather than anything shipping in core Unity. Godot merged initial `KHR_node_visibility` support, so a glTF file that only hides and shows nodes imports correctly — Khronos still tracks compliance gaps against it in GitHub tracker issue #111618 — but the core behavior-graph executor for value and flow logic isn't in Godot 4.7 or the 4.8 dev builds. Unreal Engine 5.7 is the biggest gap: Epic isn't among the engines Khronos names with confirmed support, and there's no public Interchange roadmap entry for the extension, so a GLB carrying a behavior graph currently imports as geometry-only with the interactivity silently dropped.
A concrete example: an openable chest
Take BitSoul3D's Reinforced Treasure Chest model. Today, "click the lid to open it" means writing that trigger three separate times if the same GLB ships in a Unity build, a Godot build, and a WebGPU scene — three animation controllers, three input handlers, three chances to get the timing inconsistent. With KHR_interactivity finished and adopted, the same file carries an on-select-to-play-animation graph exactly once, and any conformant runtime plays the identical open animation with zero engine-specific script. That's the actual pitch behind the extension — portable behavior, not just portable geometry. A free BitSoul3D account's two monthly downloads cover testing something like this; shipping it inside a commercial build needs a paid membership.
Checking whether a GLB already has one
Before building around this, check whether a file you're already using is quietly carrying a graph. Blender's glTF I/O plugin has started attaching some of the companion extensions behind experimental export flags, so a model exported last month might already have one sitting unused. In Three.js, the check is a single property read after `GLTFLoader` finishes parsing:
```js
import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';
new GLTFLoader().load(url, (gltf) => {
const used = gltf.parser.json.extensionsUsed || [];
if (used.includes('KHR_interactivity')) {
console.warn('Behavior graph present — Three.js has no executor for it yet');
}
scene.add(gltf.scene);
});
```
An empty `extensionsUsed` array means the file was authored without interactivity and nothing changes for you. A populated one means Three.js will still only load the geometry — see the load-only row above — but at least you get a logged warning instead of a silent mystery when an animation you expected never triggers on click. Load GLB files in Three.js: Draco, KTX2, and animations in 2026 covers the rest of the loader setup this check slots into.
What to verify before you rely on it
"Submitted for ratification" is not "ratified." Khronos's own record with recent extensions shows the gap between a release candidate and final sign-off running months rather than weeks — the `KHR_gaussian_splatting` extension missed its original Q2 target before eventually landing months later. Treat any behavior graph you ship this year as something that may need re-export once the spec locks for good. Test the actual round-trip through your DCC before depending on it in production: export from Blender, reimport, and diff the JSON, because some current exporters preserve mesh and materials perfectly while dropping the `KHR_node_selectability` block entirely — their glTF I/O predates the companion extensions and won't warn you it happened.
If a scene needs identical behavior across Unity, Godot, and a browser today, budget for hand-written fallback logic in at least two of the three engines rather than betting the interaction on the extension shipping in time. Interactivity extension or not, cross-engine behavior parity is still a harder problem than cross-engine geometry — which is the same gap glTF 2.1's complex-scenes work is aimed at closing from the scene-graph side rather than the behavior side. Watch the ratification status before you architect a shipping feature around it, and test in Babylon.js first if you want to see the extension working end to end today.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*