# OMI glTF Interactivity Blog Draft

- https://www.khronos.org/blog/gltf-interactivity-specification-released-for-public-comment latest post
- https://www.khronos.org/events/delivering-interactive-experiences-with-gltf
- https://www.youtube.com/watch?v=EmpPw2VSNZs presentation at MSF
- https://github.com/KhronosGroup/glTF-InteractivityGraph-AuthoringTool/tree/initial-work-merge create / view gltfs with interactivity

Here's a draft blog post incorporating the points you've provided:

Title: glTF Interactivity Extension: Shaping the Future of 3D Content

The Khronos Group is currently developing an exciting new extension for glTF: the Khronos Interactivity (KHR_interactivity) extension. This work-in-progress specification aims to bring standardized interactivity to 3D assets, potentially revolutionizing how we create and interact with 3D content across platforms.

### X Spaces Notes

- https://x.com/i/spaces/1LyxBnnLdBPxN Thursday
- https://x.com/i/spaces/1dRJZEEldVQGB Friday

Key Points from KHR_interactivity discussion on X:

• Origin: Inspired by Adobe's work on trigger-action lists for USDZ and Adobe Aero
• Approach: Uses behavior graphs after considering alternatives like trigger-action lists and WASM
• Foundation: Builds on the glTF object model, events, and variables
• Design Philosophy: Aims to consolidate best practices rather than innovate radically
• Security: Designed with a layered approach, allowing different levels of capability and security
• Flexibility: Introduces custom events for inter-glTF communication
• Performance: Implementations expected to limit execution time for optimal performance
• Ecosystem: Component for a larger set of glTF extensions, including physics and audio
• Industry Interest: Companies like Google exploring implementation
• Challenges: Balancing flexibility with performance and security considerations
• Current Status: Work in progress, seeking community feedback and implementation efforts
• Future Potential: Could serve as a foundation for more complex features, possibly including WASM integration

While the specification shows great promise, there are still areas that need refinement. The community has raised concerns about the current lack of examples, JSON schemas, and other supporting materials. Godot developers participated in the discussions, raising points about needed features like consistent UUIDs for nodes across exports. Additionally, there's ongoing discussion about the spec's scope, performance implications, and how it will be implemented across various engines and viewers.

The development of this extension is an ongoing process, and the Khronos Group is actively seeking community input. If you're interested in open standards and metaverse interoperability, we also invite you to join the Open Metaverse Interoperability (OMI) group's glTF extensions meetings which are open to everybody. These take place every Thursday and provide an excellent opportunity to contribute to the future of 3D content standards.

As we move forward, your input is crucial. Whether you're a developer, designer, or 3D enthusiast, your perspective can help shape this important standard. Join us in the OMI group meetings, try out the reference implementation when available, and share your thoughts. Together, we can create a more interactive and interoperable future for 3D content.

Stay tuned for more updates on the KHR_interactivity extension and other exciting developments in the world of glTF!

---

## X Space Thursday

Here's a summary of the key points discussed in the Twitter space about the glTF interactivity specification:

• The interactivity spec originated from Adobe's work on trigger-action lists for Adobe Aero and USDZ.

• There was debate between trigger-action lists and behavior graphs approaches, with behavior graphs ultimately chosen.

• The spec development process involved studying existing systems like Unreal Blueprints and Unity Visual Scripting.

• The goal was to create a "boring" standard that consolidates best practices rather than innovating.

• The spec introduces concepts like the glTF object model, events, and variables that can be built upon by future extensions.

• It's designed with a layered approach, allowing different levels of capability and security.

• There are concerns about the spec being incomplete, lacking examples, JSON schemas, and other expected components.

• The current implementation is limited in terms of data types and capabilities compared to full programming languages.

• There's discussion about potential future work, including adding more complex data types and operations.

• Security considerations include limiting node execution time and restricting memory allocation.

• There's debate about whether the spec could support compilation from text-based languages to behavior graphs.

• The spec is seen as a foundation for future developments, potentially including WASM integration.

• There are questions about how the spec will be implemented in various engines and viewers.

• The community is encouraged to try the reference implementation and provide feedback.

• There are plans for more discussions and spaces to gather community input before ratification.

• The spec is part of a larger ecosystem of glTF extensions, including physics, audio, and procedural materials.

---

## X Space Friday

Here's a summary of the key points discussed in today's Twitter space about the glTF interactivity specification:

• The genesis of the interactivity spec came from Adobe's work on trigger action lists for USDZ and Adobe Aero.

• There was debate between trigger-action lists, behavior graphs, and WASM approaches, with behavior graphs ultimately chosen.

• Security considerations were a major factor in the design, leading to a more constrained system than arbitrary JavaScript.

• The spec builds on the glTF object model and the Animation Pointer extension.

• Custom events allow GLTFs to send and receive messages, potentially enabling communication between nested GLTFs.

• The spec is designed to be flexible but with performance considerations in mind.

• Implementations are expected to limit execution time to maintain performance.

• There are ongoing efforts to finalize related extensions like audio and physics.

• Google is working on implementing the spec for use in Google Maps and other products.

• There are concerns about the timeline feeling rushed and the need for more example assets and supporting materials.

• The Godot engine team expressed interest in the spec but also raised concerns about other needed features, like consistent UUIDs for nodes across exports.

• There was discussion about the challenge of maintaining unique identifiers for nodes when optimizing or merging assets.

• The Blender team is exploring how to integrate the spec with their geometry nodes system.

• There are some concerns about the expansion of glTF's scope and potential performance implications.

• The importance of having multiple implementations before ratification was emphasized.

• The community was encouraged to contribute to the implementation efforts, particularly in projects like three.js.

• The spec is not intended to replace game engines but to enable interactivity for simpler use cases.