Handling of glTF extensions (used or required)

[javagl]

There are a few open issues related to glTF (most of them opened by @stephengold , so I hope it's OK to tag here). Some of these issues are probably plain bugs (and I'll try to have a closer look at them soon). But there is an overarching question about how to handle glTF extensions.

In glTF, extensions are declared at the top of the glTF json. And as described in 3.12. Specifying Extensions, these declarations fall into two categories:

• All extensions that are used must be declared in extensionsUsed
• All extensions that are required must be declared in extensionsRequired

This is pretty straightforward (skipping philosophical discussions about what "required" means).

The main point from the view of a loader is:

When there is an unsupported extension in extensionsRequired, then the loader should probably reject loading the asset.

(The loader could still try to load it, but it could crash and burn arbitrarily, so this is not recommended)

A specific example where this is relevant:

The issue #2385 boils down to a NullPointerException. Under the hood,, this is caused by the EXT_texture_webp extension not being supported by jME. This could be derived from

  "extensionsRequired": [
    "KHR_texture_transform",
    "EXT_texture_webp"
  ],

and the loader could respond with a somewhat clean AssetLoadException that explicitly says:
"The asset could not be loaded, because it requires the 'EXT_texture_webp' extension, which is not supported"

---

An aside: The issue refers to an asset that uses the KHR_materials_sheen extension. This is also not supported. But this extension is only in the extensionsUsed:

  "extensionsUsed": [
    "KHR_materials_specular",
    "KHR_materials_sheen",
    "KHR_texture_transform",
    "EXT_texture_webp"
  ],

This means that the asset could still be loaded by jME (even though it would likely not look perfect). If the goal of the issue was to talk about support for KHR_materials_sheen, then this should be a dedicated issue (with the name of that extension in the title), and probably a pointer to the asset at https://github.com/KhronosGroup/glTF-Sample-Assets/tree/a4c33332cfe67130a9e005bc9f5e603f9f86b1c8/Models/CompareSheen which is a simple test that only uses this extension, intended for feature comparisons/tests in renderers.

[riccardobl]

and the loader could respond with a somewhat clean AssetLoadException that explicitly says:
"The asset could not be loaded, because it requires the 'EXT_texture_webp' extension, which is not supported"

I think this is a good idea.
Imo this should be the default behavior, and a true by default boolean strict=true field should be added to GltfModelKey, with a setter that lets the dev setStrict(false) to not throw if a required extension is missing.

[stephengold]

I agree. In keeping with fail-fast coding philosophy, the glTF loader should throw an exception when faced with a required extension it doesn't support.

Thanks for investigating the root cause of #2385. At the time I filed that, I was too busy to investigate. Altering the glTF loader to throw AssetLoadException when faced with an unsupported extension should resolve #2385. Then separate issue(s) could be opened for supporting KHR_materials_sheen and EXT_texture_webp, assuming no such issues are already open.

By the way, I expect support for EXT_texture_webp could easily be added by leveraging a 3rd-party image library such as TwelveMonkeys or libwebp. The MonkeyWrench loader uses the TwelveMonkeys library to decode webp textures, and it's worked well so far.

[javagl]

The list of extensions that could be added (and tracked in dedicated issues) is pretty long (https://github.com/KhronosGroup/glTF/tree/main/extensions). Many of them are "material extensions", and I'd have to map them to the rendering features that are currently supported by jME. The WebP extension is a very special case, and I recently opened #2616 about that.

However, I'll have a closer look at the fail-fast (or rather "fail-with-sensible-error message") behavior that could probably be implemented first and hopefully with reasonable effort.

[javagl]

A small update: I just wanted to address this, but noticed that there already is a check for this at

jmonkeyengine/jme3-plugins/src/gltf/java/com/jme3/scene/plugins/gltf/CustomContentManager.java

Line 107 in a8b89f8

JsonArray extensionUsed = gltfLoader.getDocRoot().getAsJsonArray("extensionsUsed");

. But it only prints a SEVERE message for extensions that are in extensionsRequired but not supported.

I'll see how that can be changed to behave as discussed above.