Develop a concept for glTF version handling

[javagl]

The jgltf-impl classes are currently auto-generated from the schema. Fortunately, the changes between glTF 1.0 and 1.1 are "backward compatible" in the sense that the generated classes can still be used to read a glTF asset with version 1.1 using the classes that had actually been generated for version 1.0.

But this might no longer be the case for future versions.

The question of how incompatible version changes are handled using the auto-generated classes (or whether auto-generation is still feasible at all in the future) has to be tackled.

This also refers to the version handling in the jgltf-validator, although it is still incomplete and in a very early state.

[javagl]

In view of KhronosGroup/glTF-Sample-Models#9 (comment) : There should also be an option to explicitly upgrade an asset. Right now, the libraries can load both 1.0 and 1.1. When converting an OBJ file, the result will be 1.1. But it is no (yet) possible to load an 1.0 asset and save it as 1.1.

[javagl]

This issue was opened before glTF 2.0 was announced.

The incompatibilities between 1.0 and 1.1 could have been managable, maybe with some minor (!) custom, local schema tweaks.

But the changes between 1.0 and 2.0 basically burn down everything that "glTF" was until now, and re-build it from scratch - similiar, conceptually, but different enough to make it hard to justify keeping an existing class structure (at least for a typed language).

My current roadmap is as follows:

• Rename the project jgltf-impl to jgltf-impl-v1, and also rename the package from de.javagl.jgltf.impl to de.javagl.jgltf.impl.v1
  • These old jgltf-impl-v1 classes would then basically be "deprecated". There would be no reason for clients to explicitly use them (and using them will explicitly be discouraged)
• Generate new classes for version 2.0 of the schema, in a project called jgltf-impl-v2, with the package name de.javagl.jgltf.impl.v2
• Replace the usage of the former jgltf-impl classes (in all dependent projects) with the jgltf-impl-v2 classes

However, there still has to be the option to read glTF 1.x files. There are too many glTF 1.x models out there to just ignore them. Options here include:

• Read the JSON data as a DOM, and manually convert it into the new glTF v2 class structure. This could be fiddly, and much of the original convenience that was achieved with the automatic Jackson data binding would be lost.
• Create a converter from glTF v1 to v2 classes. I really do not like this this solution, and it feels like bungling. (Likely, because it is bungling). But one has to face it: glTF 2.0 is an entirely new format, and there are not many options to cope with such a drastic change.

In any case, during this refactoring, I will try to minimize the explicit, version-specific dependencies of the "high-level" classes to the auto-generated ones. (In some cases, this may be done by introducing abstraction layers. A completely independent implementation of the high-level classes would be nice, but hard to achieve in reasonable time). I hope that future glTF versions will not include such drastic changes, but ... I won't rely on this, because I also assumed this for glTF 1.0, and it turned out to be very wrong.

[javagl]

With the updates for glTF 2.0, the jgltf-model package has been refactored to represent a thin abstraction layer around the auto-generated classes of glTF 1.0 and glTF 2.0.

Suggestions for improvements are always welcome (possibly, in dedicated issues)