Tracking the KTX 2.0 ecosystem

[pjcozzi]

@weegeekps @javagl any thoughts on how we should do this?

E.g., new JSON for a standalone database of the KTX 2.0 ecosystem, just start simple with a new boolean field in the current project JSON, etc.

[javagl]

There are some degrees of freedom for further information that could be included, and how it could be included. It's hard to pin this down, so mentioning some points that are vaguely related to that:

• I once wondered whether we should differentiate between "glTF" and "GLB" at some point (but that was only a comment, and was settled by assuming that all tools that support glTF will also support GLB)
• There was the consideration to include some field for "the type of JSON loader" that is used, https://github.com/KhronosGroup/glTF-Project-Explorer/issues/13
• One could consider adding a dedicated "supportedExtensions" property, as an array of strings, with all KHR/EXT extensions as valid values (but obviously, people could mention proprietary ones there). This would be easy to do technically (because it's structurally equal to basically all other properties that we already have). The challenging part there would be to gather this information, unless it's added by the individual project owners
• The support for KTX ... this could be structurally similar. Instead of a boolean, it would (for consistency and extensibility) also be some "specialFeatures" property, with "KTX" being one (and right now: the only) possible value.

But when you talk about the whole ecosystem, one could even consider to place this a tad higher (ktx-Project-Explorer anyone? :D ), because there may be e.g. conversion or compression tools that are otherwise totally unrelated to glTF...

[lexaknyazev]

We may need to better define what does "support for KTX" mean.

• glTF loader / renderer that minimally supports KHR_texture_basisu, i.e. includes some or all transcoders.
• An exporter / pipeline tool that supports producing compressed textures from original PNGs, i.e. includes ETC1S / UASTC encoders and performs the required glTF transformations.
• KTX-only software that does not involve glTF at all (e.g. toktx and basisu CLI).

[pjcozzi]

when you talk about the whole ecosystem, one could even consider to place this a tad higher (ktx-Project-Explorer anyone? :D ), because there may be e.g. conversion or compression tools that are otherwise totally unrelated to glTF...

As the KTX ecosystem grows, I would imagine this would indeed happen. 😄

Meanwhile, do we track all three of @lexaknyazev bullets in glTF Project Explorer with a simple "KTX" checkbox/filter? Or just start with a README with a bulleted list? Or even a GitHub issue or issues just so we have a pulse on the ecosystem, gaps, and growth?

[madjin]

This is a great idea, highly relevant to this feature request for allowing one to filter projects by supported extensions: https://github.com/KhronosGroup/glTF-Project-Explorer/issues/144

when you talk about the whole ecosystem, one could even consider to place this a tad higher (ktx-Project-Explorer anyone? :D ), because there may be e.g. conversion or compression tools that are otherwise totally unrelated to glTF...

As the KTX ecosystem grows, I would imagine this would indeed happen. 😄

Meanwhile, do we track all three of @lexaknyazev bullets in glTF Project Explorer with a simple "KTX" checkbox/filter? Or just start with a README with a bulleted list? Or even a GitHub issue or issues just so we have a pulse on the ecosystem, gaps, and growth?