Supporting glTF version 2.0

[alteous]

The current draft of the 2.0 specification is mostly a refinement on the current 1.0 specification. One of the major changes is that shaders are removed from materials and replaced with Physically-Based Rendering (PBR) values. Once the 2.0 specification is released, the question is how should the library continue to support 1.0, if at all? I'm considering one of three options:

• Use the version field of the asset object to return either a Gltf::V1 or Gltf::V2 and let the user deal with it
• Convert 1.0 assets to 2.0 assets using gltf-pipeline or otherwise
• Not support 2.0 (or at least until 1.0 conformance has been achieved)

[alteous]

Another major change is the indexing pattern. In 1.0 objects were looked up by their stringly typed identifier e.g. "bufferView-123" into a map whereas in 2.0 they are looked up by an integer offset into an array / vector. This will probably improve performance but will also require drastic changes to the library data structures.

[alteous]

Draft of 2.0 implementation.

Remarks

Returning Option from find() was a constant annoyance in the 1.0 version. Now that all IDs are indices into arrays it would be nice to check during parsing that they're all valid so we don't have to return Option anymore. This is possible if we load top-level objects in this order:

1. Buffer, Image, Sampler
2. BufferView, Texture
3. Accessor, Material
4. Animation, Camera, Mesh, Skin
5. Node (n.b. self-referential)
6. Scene

[alteous]

Update

I think the best option will be to support both 1.* and 2.* and provide conversion methods as necessary however what the conversion process would involve is not yet clear.

The draft 2.0 implementation is complete. The draft 2.0 API differs from the existing (incomplete) 1.0 API meaning a bit of extra work is required to make the library consistent.

[alteous]

Example glTF 1.0 -> 2.0 conversion: https://github.com/AnalyticalGraphicsInc/gltf-pipeline/blob/updateVersion/lib/updateVersion.js

[alteous]

Continued at #14