This looks like a thoughtful implementation of the Fresnel effect of the coating, though I wonder if we could leverage the standard generalized_schlick_edf node instead:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.PBRSpec.md#node-generalized-schlick-edf

I agree, that was my first idea, and use multiply_edfC with the emission_color or pipe the uniform_edf into the base-input.

But there are some implementation details of generalize_schlick that I think differ from the gltf_spec formula, as well as not allowing me to supply the normal (as it needs to be the clearcoat normal).

This is the fresnel described by the glTF spec, KHR_materials_clearcoat.

clearcoat_fresnel = 0.04 + (1 - 0.04) * (1 - abs(VdotNc))^5

In the mx_generalized_schlick_edf glsl implementation it seems that NdoV is clamped and not the absolute value.

also the mx_fresnel_schlick function in glsl uses mix with the arguments in another order then expected for clearcoat interaction.

float mx_fresnel_schlick(float cosTheta, float F0, float F90, float exponent)
{
    float x = clamp(1.0 - cosTheta, 0.0, 1.0);
    return mix(F0, F90, pow(x, exponent));
}

According to GLSLangSpec.4.40.pdf, page 146, this is the definition of mix :

mix(x,y,a) = x⋅(1−a)+ y⋅a

to be equalent to glTF implementation the mix should be called with

mix(pow(x, exponent), F90, F0) = 0.04 + (1 - 0.04) * (1 - abs(VdotNc))^5

I should say that I havn't tested the code (because I couldn't figure out how to supply the clearcoat normal to the edf func).

Regarding the use of clamp vs abs as in the spec. It seems like the gltf-sample-renderer uses clamp here as well and not abs as in the spec. Code reference. So that may not be an issue.

Also realized that there is a Standard Schlick Fresnel in the mx_microfacet lib. That is what I'm after, it will sort out the "mix"-problem I wrote about in an earlier reply. But I cannot see a way to access it from generalized_schlick_edf, is that possible?

All good points, @bowald, and I'm CC'ing @niklasharrysson for his expertise with the definition and implementation of generalized_schlick_edf.

Our original goal for the generalized_schlick_edf node was to handle the very situation you've encountered here, where the shape of an EDF lobe is influenced by the clearcoat layer above it, so if there are limitations in our current definition I'm hoping we can address them to encompass the needs of gltf_pbr as well.

As a second reference point, here's where we use generalized_schlick_edf in the definition of standard_surface to handle a similar situation:

https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/standard_surface.mtlx#L399

Hej Johan!

Sorry for the late reply.

An explicit implementation of the Fresnel effect using the viewdirection is certainly possible, as shown in your PR. However, there are a few important considerations to keep in mind:

Portability:
Relying on the view direction explicitly within a graph can introduce portability issues for certain targets. In particular, for bidirectional rendering techniques, using the camera-based view direction becomes problematic, since it may be undefined when tracing paths from a light source (or EDF). This is why the viewdirection node lives in the NPR library rather than the PBR library. Ideally, it should only be used for effects that are strictly camera-dependent, such as facing-ratio adjustments or other NPR-style shading.

Performance:
Distribution functions have known analytic shapes that renderers can importance-sample efficiently. When reproducing the same behavior through an explicit graph, this advantage is lost, which can make the result significantly less efficient on some targets.

In general, we should prefer distribution functions whenever possible. In this particular case, I believe the main limitation is that we don’t currently support using a custom normal to steer the distribution, the coat normal in this case. However, since the underlying EDF is diffuse, I suspect this has minimal impact on the visible result.

The proposed setup with generalized_schlick_edf is already used for both the Standard Surface and OpenPBR graphs in MaterialX, and we haven’t received any reports of issues related to not accounting for the coat normal in the emission. With that in mind, it might make sense to hold off on further changes to generalized_schlick_edf until there is a demonstrated need.

Hej @niklasharrysson :)

No worries, there is no rush to get this into MaterialX from our part.

I agree that portability and performance is preferred over staying close to the glTF spec.
We should not go forward merging this PR as is.

There was two limitations I couldn't fix using the generalized_schlick_edf to implement clearcoat interaction.

1. Not being able to supply the clearcoat normal to generalized_schlick_edf (as you stated)
2. Not being able to call Standard Schlick Fresnel (Without the F90) from the generalized_schlick_edf to get the correct mix-function for the clearcoat interaction.

I think having the limitation to not account for the clearcoat normalmap, and use the surface normalmap, would be a good middle way.

Do you know if there is a way to call the Standard Schlick Fresnel (Without the F90) from the generalized_schlick_edf or if there is another pbr node that could be used?

Where we get this instead:
clearcoat_fresnel = 0.04 + (1 - 0.04) * (1 - abs(VdotN))^5
(Using, N = surface normal, skipping the N__clearcoat_ from the glTF clearcoat extension spec)

Just set F90 to 1.0 (white), and exponent to 5. The Generalized Schlick Fresnel is then reduced to the Standard Schlick Fresnel.

The generalized equation:

float x = clamp(1.0 - cosTheta, 0.0, 1.0);
fresnel = mix(F0, F90, x^exponent);

is reduce to:

fresnel = mix(F0, 1.0, x^5));

fresnel = (1 - x^5) * F0 + x^5 * 1.0

fresnel = F0 - x^5 * F0 + x^5 * 1.0

fresnel = F0 + (1.0 - F0) * x^5

You can then hardcode F0 to 0.04 if that is desired (this corresponds to an IOR of 1.5, is that always fixed in glTF's coat layer?)

You are right. I screwed up the math. The second limitation I listed is not an issue.

this corresponds to an IOR of 1.5, is that always fixed in glTF's coat layer?

Yes, currently IOR of clearcoat is always 1.5, there is a proposal to the glTF spec allowing IOR to be supplied to the coat layer KhronosGroup/glTF#2530 but its not yet part of the glTF spec.

I can update the PR with the generalized_schlick_edf, I think the limitation with surface normal is better then no interaction.

Excellent! :)