Clarifying KHR_materials_sheen implementation section

[al-ro]

Although non-normative, the implementation section of the KHR_materials_sheen extension could be clarified to make adoption more straightforward.

Some points that could be useful:

• Inclusion of IBL lighting section for sheen
• Specifying that the E(x) term is the directional albedo
• Specifying that the BRDF LUT blue channel already stores E(x)

Sheen IBL

The section could include a short description about IBL for sheen which is often achieved by storing a DG term in the blue channel of the BRDF LUT used for the split-sum approximation, as Fresnel is omitted. The UE documentation by Karis gives the term as:

$$\int_{H} f(l, v) \cdot cos\theta\ d\omega_l$$

The Khronos sample viewer also follows this approach.

E(x) is directional albedo

The directional albedo used for albedo scaling comes across as a bit of a mystery and is only called "the E(x) values". This makes it difficult to research.

The source paper for coupling diffuse and specular lobes gives the scaling equation as $a_{matte} = 1.0 - a_{spec}$, where $$a_{spec} = \int_{\Omega} f(L, V) \cdot cos\theta\ d\omega_V$$

The reader is referred to two external sources without specifying what the LUT stores. The implemention is tied to images hosted or generated by 3rd party sites. It's not easy to verify implementation correctness as pre-generated images can include minor tweaks like clamping values. Additionally there is risk of link rot. In fact, Enterprise PBR already does not seem to use the LUT themselves.

The issue of the nature of the LUT has come up before.

E(x) is the same as the DG term

As long as the sheen BRDF is reciprocal, the above equations are equal. The directional albedo used for albedo scaling is the same as the DG term used for IBL. The UE documentation also states:

This is the same as integrating the specular BRDF with a solid-white environment, i.e. $L_i(l_k) = 1$.

There is then no need for another texture as the data is stored in the blue channel of the BRDF LUT. This is also mentioned in BabylonJS. The extension text can then refer to the Khronos GLTF Sample Viewer IBL code, maintaining ownership of the link and providing an example implementation.

Clamping directional albedo

The DG term is clamped to [0, 1] (either explicitly or by storing it in a non-floting-point texture) which is not clear from any documentation. Because no citation is provided, it's not clear if and why this is required mathematically. To be fair, this one is a somewhat moot point as the numerical aspects of models are not what the extension text is about. Still, it causes confusion when implementing KHR_materials_sheen.

---

The above is not really a comment on the correctness or suitability of the extension text itself. These are just some suggestions for making the adoption and implementation of the KHR_materials_sheen extension easier. If there are obvious mistakes in the points above, that would also hopefully demonstrate that the subject is not as clear as it could be.