Verify BRDF for image-based lighting

[jjhembd]

Cesium uses the squared roughness to select the LOD of the specular environment map, which appears to be incorrect. The glTF reference implementation uses "perceptual roughness" for environment map LOD selection.

Here are some rough comparisons in Cesium, compared to the reference implementation. Note: for these comparisons, all are using the "Helipad Golden Hour" environment map for the specular component. But Cesium is not using the corresponding coefficients for the diffuse component.

Clearcoat Car Paint model, using squared roughness (current behavior):

Clearcoat Car Paint model, using perceptual roughness (test):

Clearcoat Car Paint model, reference implementation:

At first glance, the squared roughness result in Cesium appears to be noisier. Also the environment map appears to be mirror-flipped relative to the reference?

Barn Lamp model, using squared roughness (this affects both LOD selection and anisotropy calculations):

Barn Lamp model, using perceptual roughness:

Barn Lamp model, reference implementation:

The squared roughness result does not show as much smearing along the brush strokes in the metal, indicating that perceptual roughness should be used for the anisotropy calculations.

We will need to verify the correctness before switching. Cesium's approach has some fundamental differences with the glTF reference implementation which can make comparisons challenging:

• For the specular component: Cesium renders environment maps to an octahedral projection for sampling, with a custom setup for generating and sampling mipmaps. The reference implementation samples the cubemap directly, using the native WebGL2 function textureLod for mip selection.
• For the diffuse component: Cesium samples pre-generated spherical harmonic coefficients. The reference implementation samples a pre-generated diffuse environment map along with a BRDF look-up table.

[jjhembd]

Material roughness is used in three places for IBL:

1. Generating the bent normal for anisotropic materials, to point to the appropriate location in the environment map.
2. Reading the BRDF from a look-up texture.
3. Selecting the appropriate LOD from the environment map.

We will need to verify which roughness to use in each place. See BrdfLutGeneratorFS.glslto for the generation of our BRDF look-up.

Assuming we store both perceptual roughness and squared ("alpha") roughness on the czm_modelMaterial struct, there are 2 things to keep in mind:

• The current roughness property should really be named alphaRoughness or squaredRoughness for clarity. But would this be a breaking change? The czm_modelMaterial struct is indirectly part of the public API, via CustomShaders.
• We may need to store two values for clearcoat roughness as well. The clearcoat is never anisotropic, but we do need to be able to compute both direct and image-based lighting.

[jjhembd]

A bigger issue for our IBL is the way we handle the diffuse component. We currently expect the user to compute the spherical harmonic from the environment map and set the coefficients manually. Then we sample it and add it directly to the specular component, without any BRDF or Fresnel terms.

[jjhembd]

A bigger issue for our IBL is the way we handle the diffuse component.

The BRDF and Fresnel terms for the diffuse component in the glTF Sample Viewer are actually part of a multi-scattering approximation. The terms are explained toward the end of this very helpful article.

These multi-scattering terms fix energy conservation problems in two main areas:

1. Brighten the appearance of rough metals. Without the terms, rough metals absorb energy.
2. Reduce the excessive Fresnel reflection at glancing incidence on dielectrics.

Despite the name, the approximate "multi-scattering" terms are actually cheap to compute, so we should incorporate them into our code in ImageBasedLightingStageFS.glsl.

[ggetz]

As noted in #12082, once this is complete, some Sandcastles may need updating to ensure the brighter side is facing the camera on initial load.