GLTF is too complicated

I’m on the final parts of my GLTF loader, after working on it over a year (not continuously). I’m noticing that many importers have problems with the format. Blender for example will fail to load this model’s textures, though my own loader and Windows 3D Viewer succeed:

This means the format is too complicated. Maybe not for me, but if common applications can’t support it reliably (after how many years?) it affects my ability to recommend the format for model IO.

These elements should be considered for removal or streamlining in version 3.0:

  • Data from multiple files, other than textures.
  • Skins (completely unnecessary for weighted vertices)
  • Default bone pose should be weighting pose.
  • Buffer views / accessors / buffers design is extremely over-engineered.
  • Get rid of Base64 data, just use text or binary.
  • Flipped faces when matrix determinant < 0

I know somebody lovingly crafted the design of each of these items and thought they were being oh-so-clever, and that is the problem. A common file format should be as simple as possible while still supporting the requirements. For me the benefits were worth investing time, but I personally know people in charge of software products who won’t touch it for these reasons.

There is some point where complexity of the specification can be considered a bug, and effort should be made to fix that bug rather than trying to fix all the bugs in all the importers and exporters out there. I managed to wrangle the whole thing, but its complexity is holding back adoption and compromising the quality of its support.

Anyways, after working with the format extensively, that’s my $0.02.

I find this to not be particularly well reasoned. The specific piece of evidence you give for glTF being “too complicated” is that Blender3D failed to load the textures of a model correctly. But your suggestions for changes is to remove all external files except textures. So… how does that fix your problem?

It seems to me that a better set of reasoning would be to show specific areas that different glTF loaders are having problems with conformance, which would constitute reasonable motivation for removing them. But as it currently stands, your argument is that some loaders don’t quite work, so let’s make a bunch of changes that… don’t actually make those malfunctioning loaders work.

It would likely fix the problem, indirectly. There’s an upper limit to how much complexity people can handle. If the author of that import plugin was not putting a lot of effort into some of the things I mentioned, they would have more time to perfect the basic functionality.

I could compile a list of a lot of other issues in different software, but nobody is paying me to do that. The point is, on a macro level, the spec is too complicated for reliable implementation across the board in the real world. I like GLTF a lot, but if complexity can be reduced in the next major version it would result in better support.

You can’t go back in time and uncreate those features. Your suggestion is about what to do in the future, not the past. So we have to talk about a world where all of that effort has already happened (or failed to happen properly).

From a practical perspective, glTF v2 already exists and has a bunch of assets for it as is. Assets that people will expect something calling itself a glTF loader to be able to handle. So it’s not like tool writers can just drop compatibility with the older format for the forseeable future. So whatever work needs to be done to implement those features in a glTF loader will still need to be done.

Look at how effective the switch from Python 2 to Python 3 has been. Or rather, how effective it has not been. There are automated tools that can successfully translate a significant amount of Python 2 code to v3, but there is still a bunch of Python 2 that keeps getting written and maintained. Despite support for Python 2 being dropped this year.

glTF v2 is successful; there are a lot of loaders for it and a lot of assets for it. So, would people wholesale switch to your hypothetical glTF v3? If not, then how would such a change improve things? It could easily get us into a place where the two formats have to coexist, and therefore everyone needs to maintain code that can load both of them. That doesn’t actually solve the problem.

The best you might be able to do is create a “simplified” glTF v2 variant, which is just glTF v2 without certain features. This would allow such assets to be able to be loaded into a proper glTF v2 system, while also allowing for “simplified glTF loaders” that exclude files with those features. Essentially, Khronos be sanctioning the production of loaders that don’t handle all of glTF.

That cuts both ways. You don’t have to provide evidence for your position. But we don’t have to accept a position that lacks evidence.

If you want to get this to actually happen, you need to be able to make a convincing argument for it. And that means you need to demonstrate that 1) there is a problem and 2) this is the proper solution to it. Compiling a slate of evidence for these positions is a great way to do that.

After all, my point wasn’t that your suggested changes are bad; it’s that they are not well founded, that you aren’t providing a convincing argument along with evidence for these changes needing to be made.

If you want to proceed with pushing for this idea, I would suggest visiting the glTF GitHub repo and filing an issue. However, if you wish to do so, it would be far more effective if you took the time and effort to substantiate your positions with solid evidence.