Merge #11970 first!

Description

This PR implements the glTF extension KHR_materials_anisotropy in physically-based rendering of models.

How it works (and how it affects the code)

Parsing the extension at load time

When the glTF is loaded, GltfLoader reads factors and loads textures from the extension. See the new loadAnisotropy method, which is very similar to the loadSpecular method from #11970. The factors and textures are then attached to the material. See the updates to the Material class in ModelComponents.

Processing the extension properties in the pipeline

In MaterialPipelineStage, if material.anisotropy is defined, its properties are processed by the new method processAnisotropyUniforms, which is very similar to processSpecularUniforms. The sine and cosine of the anisotropyRotation factor are pre-computed, and combined with anisotropyStrength into one vec3 uniform.

The anisotropy extension, if used, will extend the metallic roughness model. As a result, the check for the extension usually takes place inside the same code branch that handles metallic-roughness processing.

Using the extension in the shader

The orientation of the anisotropic effect is defined relative to the "tangent" vector on the surface. The tangent vector is aligned in the direction of increasing u coordinate in the normal map. These tangent vectors are either supplied as a vertex attribute, or computed via derivatives of the normal map texture coordinates.

We already had code using and/or computing tangent vectors, but discarded the information early once the normals were prepared. To preserve the tangent information for anisotropic calculations, a new NormalInfo struct is defined, and returned from the new getNormalInfo function. Along the way, some of the tangent calculations were broken down into smaller functions to enable re-use for both the isotropic and anisotropic cases. The setAnisotropy function then stores the relevant anisotropic information on the material. See also the corresponding changes to the czm_modelMaterial and czm_pbrParameters structs.

The actual anisotropic lighting calculations can be found in pbrLighting and ImageBasedLightingStageFS. They only modify the specular reflection component of the final color.

Note that the implementation in ImageBasedLightingStageFS is complete only for the case of supplied environment maps in textureIBL. The proceduralIBL function will require a more significant rewrite as part of a wider IBL update, so the anisotropy calculation can be incorporated at that stage.

Other changes

• Minor cleanup in GeometryPipelineStage (done while tracing back normal calculations)
• Added more docstrings in MaterialPipelineStage
• Fixed normalization bug in ImageBasedLightingStageFS. See Normalization error in image-based lighting #11994

Issue number and link

Resolves #11976. Resolves #11994.

Testing plan

Load the development Sandcastle glTF PBR Anisotropy and toggle through the 4 testing models, comparing to the rendering in the reference implementation.

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have update the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

Other TODO:

• Load test dataset for the Sandcastle from a server
• Report normalization bug in IBL
• Describe code changes
• Add image comparisons
• Explain non-implementation in procedural IBL
• Clean up: use TBN matrix?