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.

[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.

[javagl]

Hm. I didn't have this extension on the radar until now (just became aware of it due to the CesiumJS PR). I'll have to read it more thoroughly, and try it out.

A veeery high-level brainstorming question: Could it be possible (and have there been any considerations) to "map" this to the https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_texture_transform/README.md extension? The point is that implementors will already offer the possibiity to add some offset/scale to the textures. And they will (likely) add the option to apply these offset/scale dynamically, at runtime (c.f. KHR_animation_pointer, e.g. https://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/AnimationPointerUVs ).

It sounds like the goal of this extension would largely be to apply a specific offset/scale, based on the current view configuration. But 1. maybe I misunderstood that, and 2. even if it is, it can still make sense to "package" this in one, specific extension, instead of trying to "emulate" it with small building blocks from generic (but very complex) extensions.

[eringram]

@weegeekps This is ready for your review whenever you have the chance

[weegeekps]

Thanks, @eringram. Been under water this week but I am planning on taking a look tomorrow PM.

[weegeekps]

@pmconne I know we decided to make this a Vendor extension, but do you remember why we decided to keep the EXT_ prefix? It's not a major issue; I just can't fully remember the reasoning and was unable to find it in my notebook. Thanks.

[pmconne]

do you remember why we decided to keep the EXT_ prefix?

My recollection of our discussion with @weegeekps regarding the evolving semantics around glTF extensions:

• BENTLEY_ prefix indicates the extension is tailor-made for Bentley's needs and we don't anticipate broader adoption/applicability.
• EXT_ prefix indicates we expect/hope other organizations might use the extension.

[weegeekps]

Looks really good. I have some small editorial changes for your consideration.

[weegeekps]

Things have slowed down a bit, and I finally had time for a deep editorial pass. I've made some minor suggestions. Once these changes are made, I will approve and merge.

[javagl]

I didn't check the math itself, but there's some broken formatting at

glTF/extensions/2.0/Vendor/EXT_textureInfo_constant_lod/README.md

Line 109 in 7467e5a

*Non-normative note: the addition of $\lfloor logDepth \rfloor + 1$ when calculating $textureCoordinates_2$ allows the result of the $mix$ function to blend between two adjacent mipmap levels.*

It currently looks like this:

[eringram]

Oops good catch, made a fix for this: #96