Implement constant LOD glTF extension

[eringram]

This is ready for review, but likely waiting to merge until extension spec is finalized: CesiumGS/glTF#92

This PR adds support for reading glTF models that use the new EXT_textureInfo_constant_lod extension. Constant LOD texture mapping mode is already supported for textures in iModels, so this PR just passes the required properties to render material creation from the GltfReader.

I also added unit tests to GltfReader.test.ts, and a new file TextureMapping.test.ts with tests to ensure TextureMapping uses the constant LOD default values when they are not provided.

Simple test model that uses EXT_textureInfo_constant_lod: constant_lod_example.zip

This is what the effect looks like for this test model:

With a normal map of a bumpy texture:

Image tests didn't produce any side effects (test cases for this new feature aren't there yet but will be added in the future).

[Copilot]

Pull request overview

This PR implements support for the EXT_textureInfo_constant_lod glTF extension, enabling glTF models to use the constant LOD texture mapping mode already supported for iModel textures. The extension properties (repetitions, offset, minDistClamp, maxDistClamp) are extracted from glTF materials and passed through to render material creation.

Changes:

• Added extension parsing logic in GltfReader to extract constant LOD parameters from baseColorTexture, emissiveTexture, and normalTexture
• Extended MeshArgs interface to include useConstantLod and constantLodParams fields
• Added comprehensive test coverage for the extension including property validation, fallback behavior, and normal map support

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
core/frontend/src/tile/GltfReader.ts	Parses EXT_textureInfo_constant_lod extension from materials and converts to MaterialTextureMappingProps
core/frontend/src/test/tile/GltfReader.test.ts	Adds test suite covering extension parsing with various configurations
core/frontend/src/render/MeshArgs.ts	Extends MeshArgs interface with constant LOD properties
core/frontend/src/common/internal/render/MeshPrimitives.ts	Passes constant LOD parameters from displayParams to MeshArgs
core/frontend/src/common/gltf/GltfSchema.ts	Defines TypeScript interface for the extension in GltfTextureInfo
core/common/src/test/TextureMapping.test.ts	Tests TextureMapping.Params constructor default value handling
common/changes/@itwin/core-frontend/eringram-constant-lod-gltf_2026-01-09-17-16.json	Changelog entry for core-frontend
common/changes/@itwin/core-common/eringram-constant-lod-gltf_2026-01-09-17-16.json	Changelog entry for core-common
common/api/core-frontend.api.md	Updates API documentation for modified method signatures

[markschlosseratbentley]

Approving, but I recommend waiting for Image Tests.

[eringram]

@markschlosseratbentley Mind taking a look at my latest commit? I added some code comments and clarified the limitations of our support for the extension in the NextVersion entry.

Based on our discussion earlier, I concluded the extension can be present on anything that extends textureInfo like normalTextureInfo, occlusionTextureInfo, etc. as well as textures like metallicRoughnessTexture. However, this implementation only supports it for baseColorTexture fully, and emissiveTexture and normalMapTexture to a limited extent.

I think this is fine since it's the same scope that we support for glTF models in general (i.e. we never use metallicRoughnessTexture or occlusionTexture), and for iModels that use constant LOD (i.e. iModels also only support constant LOD for normal maps to a limited extent).

[eringram]

Also, the image tests results showed no differences of note

[mergify]

This pull request is now in conflicts. Could you fix it @eringram? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

[mergify]

This pull request is now in conflicts. Could you fix it @eringram? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

[markschlosseratbentley]

Looks good to me, @eringram.