Apologies for my clumsy wording :P
GLTF 2.0 does not support basic non-negotiable features required for game-development.
I was not able to achieve basic goals with glTF 2.0. I specifically tried to work with its Blender, Godot 4 and UnityGLTF & GLTFast implementations, my experience is derived from working with these.
- The animation system doesn't support bezier interpolation (keyframe tangents with weights). Only cubic interpolation. Tools like Blender, Unity, Godot, and tools as such perfectly support bezier. It is the default interpolation mode for animation in most. This forces exporters to bake animations, effectively making them mostly useless. Game-engines will try to 'unbake' such an animation.
- Animations can't target anything other than node transforms and morphtarget values. The KHR_animation_pointer fixes that, and is as of the end of 2024 supported or about to be supported in many tools. This issue may be alleviated soon.
- GLTF does not explicitly represent the relationship between resources and resource instances.
The relationship is implicit, based on the system of Buffers, Buffer Views, Accessors and Sparse Accessors, to which ameshpoints.
Some implementations may deduplicate the buffer views, however this is not in the spec. Some glTF implementations may just load the same mesh resource twice. In the context of a distribution format this works fine, as the whole buffer gets shoved into GPU memory, taking the role of the resource. - GLTF materials support a few hard-coded properties.
Materials are arbitrary, and so are their properties. Additional properties get slowly added as extensions, which are likely not supported in your glTF implementation. What if I want to add an 'Audiolink Baseband Emission' texture? - Morphtarget names are not present in the spec. If glTF was intended for video game development, then that's a mistake. Applications put morphtarget names in the
extrasfield of either themeshobject, or the firstprimitiveof themesh. For a supposedly well standardized format for interchange/authoring, this is broken. - The buffer system is complex and does not map onto any data model in authoring tools.
Until late 2023, Blender would produce comically large files (over 100 MB instead of under 4 MB in the case of this example model), because it didn't implement Sparse Accessors. Why aren't morphtargets stored as just simple indexed buffers?
The construct of Buffers, Buffer Views, Accessors and Sparse Accessors does not make sense if you are trying to load it into Blender or Unity. It does work for a distribution format to be efficiently loaded into GPU memory, not for interchange/authoring.
On paper, glTF 2.0 looks supremely extensible.
In practice, implementing extensions is either not supported at all (UnityGLTF, GLTFast), when it is, it is either barely documented (Blender), or at least partially broken (Godot 4).
Actually trying to implement a custom extension (for example one for social-VR avatars), requires in some cases having to fork the entire glTF library, hard-coding your extension into it, and getting your users to use your fork.
If one extension is not supported, its data will just be thrown away upon import. What if I need to add a Unity specific extension and a Godot specific extension to the same file? In the case of VR avatars, which optimally would support many target applications across many game engines, this is a necessity.
Just implementing a new extension across all relevant glTF implementations is practically impossible, and nobody does it either. Even official extensions like KHR_animation_pointer, which would at least half fix the animation system, is implemented next to nowhere. An extension existing only a JSON schema file in the Khronos GitHub account is not very useful.\
glTF 2.0 was released over 7 years ago. This is its current state.
I am not convinced glTF 2.0 is intended for 3d Assets in a video game development context.
I would like for a format to exist which is. I'm stuck with FBX.
In order for video game development with open-source tools to become viable for anything other than limited-in-fidelity indie games, an ecosystem with proper asset-pipelines is needed.
I think an open, interoperable & extensible 3d format could significantly help in making open source tools viable for many and improve the industry as a whole.
I created a proof-of-concept 3d format - Repository Link
The goals I tried to prove:
- Devise an extensible data-model which maps onto authoring tools like Blender, Unity or Godot. Fully disregard any optimizations for runtime loading.
- Easy practical extensibility. Just chugging JSON between applications should be as easy as it sounds.
- Proof the practical possibility of an arbitrary material system, agnostic of any specific shader or game-engine.
This is developed in a subproject called MTF - Repository Link
As an individual I can hardly develop that to production readiness.
As a proof-of-concept I dare to say it succeeds, however you be the judge!
I devised a FBX extension system - Repository Link
'NNA - Node Name Abuse' is a system to store information in a 3d models node-names. It's an abomination and works way too good for what it is.
As it relies on existing formats, especially FBX, I can get this into a production ready state quickly.
Edits:
- Clarified the point about keyframe tangents. GLTF does support them, but not with weights, making glTF still pointless for exporting models with animations.
- The KHR_animation_pointer extension is about to be widely enough rolled out soon, which would fix the animation targeting issue.