Can a 3D file contain its own interactivity? KHR_interactivity in 2026

Yes, a glTF file can potentially contain its own interaction logic through the KHR_interactivity extension. The proposal allows behaviour graphs to be embedded in the file, so a compatible viewer can interpret events and actions without requiring all the logic to be programmed separately in the application.

This matters if you are commissioning a product configurator, an interactive demo or a 3D experience that needs to run across several channels. There is, however, one essential qualification: as of 14 October 2026, KHR_interactivity has not yet been ratified. Including logic in a file also does not guarantee that every viewer can execute it.

What changes compared with a conventional GLB?

glTF is a format for distributing 3D scenes and assets. In a typical project, a GLB file can carry geometry, materials and other supported data. Interactivity, by contrast, is often implemented in the viewer, a web application or the software controlling the experience.

KHR_interactivity proposes moving some of that logic into the file itself. According to Khronos, behaviour graphs can travel inside glTF. This allows relationships between events and actions to be described in a format that compatible environments can interpret.

Consider a simple configurator: a user selects an option, changing a product property, triggering an animation or activating another behaviour. With a compatible implementation, some of this logic could be defined in the 3D file rather than relying entirely on viewer-specific code.

The proposal does not turn every GLB into a universal application. The file still needs an environment capable of interpreting its instructions, and available features depend on what each viewer implements. Nor does it automatically remove the need for a web interface, business logic or connections to other systems.

What support exists in October 2026?

On 16 July 2026, Khronos announced that KHR_interactivity had been submitted for ratification. Its announcement identifies product configurators as one of the intended use cases and describes tools and implementations already working with the extension.

The announced examples include Babylon.js, which can play back these behaviours; Needle's UnityGLTF, which supports exporting them; glTF-Sample-Viewer, which implements the extension; and Android XR, which plans to support it through Jetpack XR.

These examples help explain the state of the ecosystem, but they do not establish universal compatibility or mean the extension has been ratified. Before choosing a tool, check which version supports the feature you need and whether it can both export the behaviour and reproduce it in your intended environment.

Do not assume support in three.js or Blender: the sources reviewed do not indicate that either implements the extension. If your workflow depends on one of them, verify compatibility before committing to a delivery.

When an embedded-interactivity file could help

KHR_interactivity is worth investigating when you want to reuse relatively simple behaviours alongside a 3D model across several compatible environments. It could reduce duplicated rules and make it easier to distribute behaviour with the asset rather than maintain a separate implementation for every viewer.

This complements the approach discussed in one GLB for four channels. That approach focuses on reusing 3D content, while KHR_interactivity introduces the possibility of carrying interaction logic as well. These are different layers and should be evaluated separately.

A commercial configurator may still need pricing rules, availability checks, product selection, validation, analytics, saved configurations or a connection to a catalogue. Such requirements may need application code and external services. Embedding some behaviours in the model does not replace the wider product architecture.

When a custom-built configurator still makes sense

If you need complex rules, server-driven data, e-commerce integration or a purchase journey, you will probably need to build the configurator as an application. The 3D file can provide the content and, where supported, reusable behaviours, while the application handles features that depend on the business itself.

You must also test the actual experience on the devices and browsers your customers will use. An extension may be available in a development tool but absent from the final viewer. Establish a list of essential features and verify each one in every target environment.

If the project depends on graphics technologies with uneven support, prepare a fallback as well. The guide to WebGPU across three browsers provides a useful framework for this decision: a technology being available does not necessarily mean it will work in the environments your audience needs.

What should you decide this week?

If you are commissioning a demo or configurator, ask for a working test of the project's most important interaction, not just a visually polished scene. Request the exported file, identify the viewer that runs it, and repeat the test across your intended channels. Document which interactions are embedded in the file and which will remain part of the application.

KHR_interactivity points towards more reusable ways to distribute 3D experiences, but its value will depend on ratification, implementation and real-world compatibility. At Contrast 3D, we develop web 3D experiences and configurators around commercial objectives. Tell us which product you want to turn into an interactive experience and we can help define an architecture and compatibility test before development expands.