glTF 1.1 will be 2.0!

[pjcozzi]

We started glTF 1.1 as a bug fix update to glTF 1.0. In parallel, @lexaknyazev developed the glTF Validator, which helped find corner cases that the 1.1 spec has tightened up.

Also in parallel, something big happened: @mlimper and a large community have nearly finalized the glTF PBR extension. We have also decided that the metallic-roughness PBR material model will be in the core glTF spec (specular-glossiness will remain in the extension). There is so much spec and implementation progress here that we do not want to hold it back, so PBR will be part of the next glTF version, now named 2.0 to signify the huge advancement with PBR. We believe PBR in glTF will help the industry move to PBR given the carefully defined spec and emerging ecosystem of tools, runtimes, and sample code.

In addition, we want glTF 2.0 to be a stable base for the future and to support practical runtime implementations for many graphics APIs, so we are including a few other changes to improve consistency, API-neutrality, or performance. These are:

• Moving GLSL to an extension since API-neutral PBR will be in the core spec. GLSL, Vulkan, and portable materials #733
• Adding image.bufferView so that textures/geometry/keyframes can be stored in one binary blob if desired, and that the KHR_binary_glTF extension can be replaced with core glTF spec. image.uri will still be supported.
• Moving lights in the KHR_common_materials extension to a separate light extension that can be used by both PBR and common_materials. Engines can, of course, use their own lights as well.
• Replacing top-level glTF object properties that are currently accessed by property name, e.g., the accessors object, with arrays that are accessed by index. This allows faster parsing in JavaScript and native loaders. We'll post performance numbers in this repo soon. glTF 2.0 syntax changes and JSON encoding restrictions #831
• Adding morph targets, e.g., for facial animation. This is not a breaking change. Basic Morph Syntax #210, Sparse Array storage. #820

It is exciting to see the industry move forward together with this next version of glTF. @cx20 is tracking the progress of several engine adoptions: three.js, Babylon.js, and GLBoost. Updates to COLLADA2GLTF, gltf-pipeline, and Cesium are also imminent. @javagl has also prepared a glTF tutorial series including simple sample models.

There's lots of implementation work towards glTF PBR: the WebGL reference implementation by @moneimne, Babylon.js by @bghgary and @sbtron, x3dom by @mlimper, OSGJS/Sketchfab by @cedricpinson, and the Laugh Engine (Vulkan) by @jian-ru.

Next up, we'll make the 1.1 to 2.0 renames and prepare the spec for Khronos ratification. As always, please provide your feedback and let us know what you are building with glTF!

[pjcozzi]

Also, here's the:

• Overview of spec changes made so far, Spec changes from 1.0 to 2.0 #605
• Draft spec, glTF 1.1 draft #784

[xelatihy]

Very exciting work!

Are these schemas already available for the new glTF 2.0 (and extensions)?

[pjcozzi]

Things are nearly complete. The spec is in #784. The PBR extension is in #643 (note that basically the metallic-roughness section will be cut-and-pasted into the core spec).

[xelatihy]

Sounds good. I have manu large models in glTF 1.1 (I guess 2.0). I will publish them soon on my site and plan ti publish more models in the coming months. Adding PBR next.

[pjcozzi]

@xelatihy sounds great. When ready, we would be happy to add a link to your models from here: https://github.com/KhronosGroup/glTF-Sample-Models#other-gltf-sample-models. Please open a pull request.

[cx20]

@pjcozzi Does renaming from glTF 1.1 to 2.0 mean that 1.1 is missing?

Do the following samples also change from 1.1 to 2.0?
https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/1.1

[pjcozzi]

@cx20 yes, everything will change to 2.0: the spec, the sample models, tools, tutorials, etc. So there will be just glTF 1.0 and glTF 2.0, not 1.1.

[cx20]

@pjcozzi thanks, I understand.

[lexaknyazev]

First 2.0 draft #826.

[pjcozzi]

@lexaknyazev can you please check the boxes in the tasklist at the top of this issue if they are already included in #826? I checked the ones I know for sure.

[javagl]

How will the extensions be updated? E.g. for KHR_binary_glTF:

Binary glTF introduces a buffer with id equal to "binary_glTF"

Will there be a KHR_binary_glTF_2 where the buffer is e.g. defined to have an index (and maybe always have index 0)?

Will the removal of lights from KHR_materials_common be handled by creating a (new!) KHR_materials and a new KHR_lights?

[lexaknyazev]

@javagl

Will there be a KHR_binary_glTF_2 where the buffer is e.g. defined to have an index (and maybe always have index 0)?

See #828

Will the removal of lights from KHR_materials_common be handled by creating a (new!) KHR_materials and a new KHR_lights?

KHR_materials_common hasn't been ratified yet, so it will be updated to not include lights.
They will go to a new KHR_lights. I'll push drafts soon.

[cx20]

I have created a branch to test the glTF 2.0 models.
https://github.com/cx20/gltf-test/tree/2.0

[pjcozzi]

Very nice, thanks @cx20. We will soon see those red x's turn to green checkboxes!

[javagl]

Not sure whether it fits here, but there's another API appearing at the horizon: https://www.w3.org/community/blog/2017/02/07/proposed-group-gpu-for-the-web-community-group/ ( https://webkit.org/wp-content/uploads/webgpu-api-proposal.html ). Something to have an eye on for glTF 3.0 ;-)

[pjcozzi]

Closing, no action here.