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.

[javagl]

need some sort of glTF extension or meta-extension specifying how to achieve what we want here.

That would pretty undoubtedly be the case. The core of the question did not even aim at any form of explicit dependency between the extensions. It was really about mapping the texture transform that seems to be done here to what already exists for the texture transform extension. This might have been on a low level (think of something like replacing repetitions with scale (=1/repetitions)), with the idea that implementors might then be able to re-use existing code paths. But given that the texture transform also allows rotations, and the offset/scale here has to be computed dynamically, there may not be much overlap in practice.

[eringram]

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

From looking at precedents from other texture-related extensions, I think it makes sense for encoders to have the option of either omitting texCoord and adding this to extensionsRequired, or keeping texCoord as a fallback if the client doesn't support constant LOD. This is similar to what KHR_texture_tranform and those related to texture image formats do. I added some sentences in the overview section for this.

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

Is this note meant to be normative or non-normative? It looks non-normative to me, so the Note: portion should say Non-normative note:

FYI, a normative note dictates that the implementer must follow the note exactly. A non-normative note typically provides guidance to the implementer to be aware of edge cases or the intent of a normative piece.

Also, there's no strict style guide, but typically notes are italicized within glTF extension specifications and not within a quote box. I don't care strongly either way tbh, but I wanted to at least let you know in case you wanted to change it for consistency.

[eringram]

It's meant to explain the purpose of the + 1 in the equation, so I guess in that sense it clarifies the intent of a normative piece (the formula). I added "non-normative" to the beginning and switched to italicized

[markschlosseratbentley]

Consider adding a "Known Implementations" section and adding iTwin.js with a link to your PR. (Perhaps CesiumJS w/ link to that draft PR as well). Feel free to resolve this comment on your own.

[markschlosseratbentley]

See https://github.com/CesiumGS/glTF/tree/vendor-extensions/extensions/2.0/Vendor/BENTLEY_materials_planar_fill#known-implementations for an example.

[eringram]

Good point, added both of those