add support for glTF Interactivity KHR_interactivity

[arpu]

https://github.com/KhronosGroup/glTF-Test-Assets-Interactivity

https://www.khronos.org/blog/gltf-interactivity-extensions-approach-finalization-your-feedback-needed

[arpu]

ok looks like this is still in DRAFT KhronosGroup/glTF#2293

[zeux]

This extension was merged to glTF repository but I strongly doubt it will be supported by gltfpack. Obviously it's not currently supported by cgltf which blocks the implementation, but in general I think this as well as other similar extensions might have to be declared out of scope at some point. gltfpack originally was designed as a 3D scene processing tool; unfortunately, glTF format keeps growing past its original clean and simple definition and I am not really keen on supporting all possible extensions.

The current policy of extension support is "most KHR extensions are supported unless the extension is too involved to implement". I'll need to think about what the policy that is sustainable long term might look like, but I doubt this extension would make it...

Worth noting is that if glTF 2.1 is ever specified/implemented, there would likely be a clean way to split the assets along the more natural boundaries. I do not think that is currently planned as official recommendations, but just hypothetically with multi-file scenes, you could imagine having an "inert" scene file (with no semantics/behavior) be separate from "interactivity" file (that defines useful behaviors). The latter would link to the former using persistent IDs I would imagine; when that is added, gltfpack will definitely support a version of current "-kn" switch that keeps nodes with ids in tact. All of this is theoretical and just musings about possible future state here that might make interactive assets viable to preserve in pipelines that use gltfpack.

[arpu]

some test assets
https://x.com/superhoge/status/2092542218880139610
https://github.com/takahirox/threejs-gltf-khr-interactivity/tree/main