[Proposal] Add support to GLTF model format

[Yanrishatum]

First section is more a reasoning as to why I even do this proposal, for tl;dr; - see actual proposal.

As we know, FBX is very thoroughly documented and effortless to use format, that doesn't cause any issues to us regular people from community. /sarcasm While FBX->HMD conversion works fine enough, I can't say it's easy to setup and when it comes to animations, it gives a lot of headaches not only when using Blender, but also Autodesk software. While discussing how we love FBX format with @nspitko, he pointed out an GLTF scene/model format and said maybe it's worth adding an imported for better documented format. After taking a quick look, it seem to be pretty reasonable to add GLTF importer as alternative source format that would require less hassle to export, have actual specification and not "we guess it works that way" from Blender guys, as well as one that have pretty wide support of editors and tools.

GLTF format info: https://www.khronos.org/gltf/

Proposal:

1. Add GLTF format reader akin to FBX.
   • A) We can write our own reader.
   • B) Make whole support of it opt-in by adding haxe-gltf library
   • C) Make it two-stage, with library as proof-of-concept and then adding built-in support if it will prove practical.
2. Implement GLTF->HMD converter
3. Provide documentation on how to get export going in wiki.

Main challenges I expect as of now and other notes:

• Converter will have to handle Y-up to Z-up axis conversion, since format is strictly Y-up.
• Adapting and validating data according to HMD restrictions.
• Animations. I'm not sure if exporters for Autodesk/Blender support baking them, meaning that it have to be baked at import time by interpolating (Or alternatively implementing support for non-baked animations in HMD?)
• Support .gltf + .bin, .gltf with base64 data as well as .glb files.
• Since there'll be 2 formats that convert to HMD, it would increase the upkeep cost when advancing HMD format features.
• At least it's well documented and have many sample models to check for proper implementation of importer.

P.S.: If there are going to be objections, please don't use "FBX works just fine", it bloody doesn't. It's a pain to use, especially when using Blender, and there is quite a few of people in Discord channel that would back me up on that. :)

[Yanrishatum]

Upon further inspection, it (as actually expected) is much more complicated.

• Default PBR mode for gltf is Metallic-Roughness, while Heaps utilize Specular-Glossiness, and when converting it's required to convert textures from one to another. Or enforce that models should be exported with KHR_materials_pbrSpecularGlossiness extension (I'm hesitant on doing so, as it complicates the export)
• HMD is surprisingly barebones format and information loss during conversion will be seriously big. I see several solutions to that.
  • Standardize the Library class to an interface (rough estimation, as I'm unsure about what arguments to pass):

    interface IModelLibrary {
    function loadObject
    function loadMaterial
    function loadMesh
    function loadAnimation
    }

    and enforce it on all HMD, FBX and GLTF library loaders. In that case GLTF wouldn't be converted to HMD but remain as is (at least until HMD gets on par with feature set). Big downside of that is loading speed, because GLTF is basically a JSON structure. Can be somewhat mitigated by partial conversion to custom binary gltf declaration.

  • Improve the HMD format, bump version and add more information stored.
  • Try to store the information via Props in current format.
  • Just bite the bullet and deal with information loss and in turn imperfect conversion.

[ncannasse]

Yes I think than trying to convert glTF to HMD would result in several problems and complify things without much gain.

So yes abstracting the Model Library seems the right abstraction point here.

Regarding PBR it's not a big problem: we use Metalic-Roughness in engine, just our roughness maps are in glossiness format by default, but that's just some different shader to inject when doing the decoding from textures, see https://github.com/HeapsIO/heaps/blob/master/h3d/shader/pbr/PropsTexture.hx