glTF feature support tracker

[appgurueu]

We have glTF support now, but presently it is pretty minimal: It only exists to have a more modern alternative for .b3d and .x with about feature parity. This means that there are still quite a few things that don't work out of the box which I would like to support (requires Irrlicht changes, some of which I would prefer to do after completing items on #15350):

• Support for STEP interpolation. Currently only linear interpolation is supported. This should be relatively easy to do.
• Support for multiple, named animations, which raises the question of how the API for these should look like. I'm currently thinking adding a name and/or index field to the {x = ..., y = ...} table (see also Allow combining multiple mesh animations #12663).
• Negative scale
• Morph targets (Add glTF morph animation support (PoC) #16096)
• Better material support
• Draco mesh compression (glTF extension). glTF exports can already yield significant size improvements vs. .x / .b3d because of format and exporter quality reasons, but it still isn't really compressed. With Draco we might be able to see something like 20x size reductions.

Things I don't want to support at all, or at least not anytime soon:

• CUBICSPLINE keyframe interpolation
• Embedded images: Doesn't work well with our architecture which assumes assets to be single file, embedded images are less accessible, how would that interface with texture packs etc etc.
• External resources more generally, i.e. data in .bin buffers, for similar reasons
• Cameras (depends on a proper camera API, maybe SSCSM to begin with IMO)

[kromka-chleba]

Are morph targets going to be included? Apparently Blender shape keys could be exported as morph targets.
We also had a discussion about animating UV map the other day with morph targets on IRC, not sure if that's possible.

[appgurueu]

Morph targets seem reasonably simple that I might add support for them in the future, though we'll see how much work it is to (re)extend Irrlicht to support them properly.

[kawogi]

(Sorry, if this is out of scope but I thought it might be related)
Would it make sense to document the current and planned support here: https://docs.luanti.org/models/ (and/or in blender/blockbench).
I just tried my first gltf model and expected that embedded textures would work. Took me a while to figure out that I had to export the textures.
Also a warning on loading the model in the logs would have been helpful. (à la "ignoring embedded textures in gltf; please store them externally in the textures directory")

[appgurueu]

Would it make sense to document the current and planned support here: https://docs.luanti.org/models/

Yes, that documentation should be extended. I've been meaning to get around to it but currently I'm wading through the swaps of MTG documentation, so by all means I'd welcome a helping hand...

You could take a look at the current state of lua_api.md which documents this tersely.

It should not be in the Blender / Blockbench article but rather in the general format support documentation.

Also a warning on loading the model in the logs would have been helpful. (à la "ignoring embedded textures in gltf; please store them externally in the textures directory")

Huh? There is an "embedded images are not supported" warning.

[kawogi]

Huh? There is an "embedded images are not supported" warning.

My bad and I'm super sorry for the noise! Must have mixed the logs when trying out several of variations to get this work.

so by all means I'd welcome a helping hand...

I'd love to but I still don't know how to find my way through all the various documentation sources. I always end up asking on Discord :(

Thank a lot for your work on gltf, btw. It's been a great enabler for me and my kids to actually start modding! I'll try to start a school course this week.

[appgurueu]

Related: #8854.