Discussion: Overlap with KHR_interactivity support in Babylon.js

[hybridherbst]

Babylon.js is also moving towards supporting KHR_interactivity and the related nodes* extensions.
https://forum.babylonjs.com/t/gltf-interactivity-specs/51770/7?u=herbst

This introduces overlap with the implementation here – when updating Babylon in this repository to v7, there are two conflicting KHR_interactivity plugins.

Opening this issue to understand what the plan there is. One option would be if this repository consumes the Babylon implementation and adds graph authoring on top.

cc @mattmacf98

[mattmacf98]

The Babylon extension registry is a last write wins, so as long as you do something like this

GLTFLoader.UnregisterExtension(KHR_INTERACTIVITY_EXTENSION_NAME);
GLTFLoader.RegisterExtension(KHR_INTERACTIVITY_EXTENSION_NAME, (loader) => {
   return new KHR_interactivity(loader);
});

you can essentially ignore the overlap conflict and use the engine in this repo.

In the long term – once the spec and Babylon's implementation are solidified – then I would just use Babylon as the engine for the Babylon component piece and move this engine to only support the logs viewer (and maybe port it to another js based viewer like Three).

In general, this version of the engine – by not being a public library– is able to be more experimental and faster moving, allowing for quicker spec feedback and testing than using Babylon core.

[hybridherbst]

Sounds good to me! So we just have to be somewhat wary of doing too many changes to the KHR_interactivity engine here because they may already be implemented in Babylon itself. One such example is the KHR_node_visibility extension which I partially copied from the existing Babylon v7 implementation.