EXT_textureInfo_constant_lod

[markschlosseratbentley]

This PR is one result of splitting up #87 into more granular work.

This PR exists strictly for planning/feedback - this extension (EXT_textureInfo_constant_lod), once ready, should be submitted as a separate PR to KhronosGroup. This starts with Bentley's minimum requirements as a baseline.

[eringram]

@markschlosseratbentley @pmconne This first draft is ready for review. Feedback especially needed on the implementation notes part and if the formula is explained accurately and clearly, and how many shader-specific details to include here.

Questions for reviewers:

1. The constant LOD calculation lets you apply an offset to the texture in world units, which from my understanding is meters in glTF. There's already an existing KHR_texture_transform extension that lets you specify an offset as a factor of the texture dimensions. Is there any issue with having these both named offset, or not because they are on separate extensions?
2. Our other extensions have used the BENTLEY prefix. Should this also use BENTLEY?

[pmconne]

Our other extensions have used the BENTLEY prefix. Should this also use BENTLEY?

No, we agreed that this one is of potential general utility (we know of at least one other organization that has expressed interest in something similar), hence the EXT prefix.

[danielzhong]

Great job! Just some small suggestions.

[danielzhong]

cordinates → coordinates

[eringram]

Fixed

[markschlosseratbentley]

Good job with this spec so far. As discussed earlier (with @pmconne), we could consider adding some more clear legalese in this section which makes it clear how these extension properties directly affect the on-screen appearance. For example: "when these properties are specified in a certain way, the following shows up on screen" (flesh that statement out).

[eringram]

I updated the "Specifying Constant LOD Texture Mapping" section with an example json snippet and an explanation of what each property in the example extension means for the on-screen appearance. Let me know if this is what you meant, or if it should be more detailed.
I decided to keep the formulas in this latex format because it provides subscripts, superscripts, and the floor symbol which are useful in this context. It also is displayed correctly in the github markdown preview. Other extensions like the PBR glossiness formulas use a code-like style for formulas though, which I am also open to switching to.

[pmconne]

The specification should define what the TextureInfo's texCoord field means when this extension is defined. The extension specifies an alternative way of computing the texture coordinates, so presumably a client that supports the extension would ignore texCoord. If that's the end of it, then the specification should state that this extension MUST appear in the requiredExtensions array; otherwise clients who don't support it will try and fail to find the texture coordinates accessor.