Textures update for glTF 2.0

[lexaknyazev]

This PR contains updated schemas and description of texture data handling for glTF 2.0.

Mini-FAQ

Why move internalformat to image?

Because this property is deeply bound with supplied data. One could switch different images while keeping the same texture object.

Why remove type and format?

These two properties can be precisely derived from one internalformat value. No need to complicate asset validation with checking all possibly wrong combinations.

Why use OpenGL ES 3.0 enums instead of ES 2.0?

They provide distinct values for each format/type combination.

Why source.uris and source.bufferViews are defined as arrays?

To support PNG/JPEG-based cubemaps and texture arrays in future 2.x releases without breaking JSON syntax.

Why texture.sampler is optional now?

Because all fields of sampler object were already optional. So exporters won't need to create an empty sampler object as before:

{
  "textures": [
    {
      "sampler": 0, ...
    }
  ],
  "samplers": [ { } ]
}

What do "expand" and "repack" mean in the second table?

Expand means populating non-provided texture channels by some rule. For example, to expand LUMINANCE into RGBA, client should emit (L, L, L, 1.0) for each texel. See more on that topic in OpenGL specs.

Repack means changing the order of packed components to adapt to another API's convention.

Note, that ANGLE does such transformations when running on D3D backend.

---

CC @pjcozzi @sbtron

[pjcozzi]

For #835

[pjcozzi]

@lilleyse @lasalvavida can you both please review this to confirm that there is a reasonable update path from our current implementations (pipeline and runtime) to this? This is a significant, but hopefully isolated change.

[pjcozzi]

Once this is merged, please update #605 with changes like this, especially this one since it is breaking but the syntax doesn't change.

[pjcozzi]

Sounds like a conformant renderer is free to select any object in the sources array. Can the spec be more explicit about this?

[lexaknyazev]

sources are different representations of the same image. So choice is ultimately up to engine (based on mimeType and internalformat).

[pjcozzi]

Agreed, let's just be super explicit about it in the spec.

[pjcozzi]

Isn't it possible that a glTF asset will contain a texture format that a WebGL 1.0 client will not be able to render?

[pjcozzi]

Does this require an extension? https://www.khronos.org/registry/webgl/extensions/EXT_sRGB/

The spec should clarify this.

[lexaknyazev]

The best WebGL 1.0 runtime strategy is to use that extension, yes. Without it, the only correct option is to disable hardware filtering and perform it manually in GLSL (after manual colorspace conversion).

Supplying alternative image source with linear data could help such incapable clients. Quality will suffer from banding, obviously.

[lilleyse]

I don't see any problems here, just making conversions to the correct internalFormat, format, type whether it's a webgl1 or 2 context.

[lexaknyazev]

Retargeting to post-2.0.