Cycles: Remove MultiGGX code, replace with albedo scaling #107958

While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time.

In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses.

This can simply be achieved by adding a second lobe or scaling the single-scattering GGX lobe. Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient.

Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases).

In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models).

The code is generally ready for review, there's just one TODO: Currently, the weight increase due to the albedo scaling affects the Glossy/Transmission Color passes. It shouldn't.

This also brings up a UX issue that we should consider for Principled v2: The saturation increase at high roughness is physically correct, but do we actually want it? From a user perspective, it generally would probably be better if the albedo always matched the Base Color input, that direct artist control with no interdependency between inputs is the entire point of the "principled" models after all. Maybe we should apply it for the Glossy and Glass BSDF nodes, but not for Principled BSDF.

While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time. In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses. This can simply be achieved by [adding a second lobe](https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or [scaling the single-scattering GGX lobe](https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient. Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases). In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models). The code is generally ready for review, there's just one TODO: Currently, the weight increase due to the albedo scaling affects the Glossy/Transmission Color passes. It shouldn't. This also brings up a UX issue that we should consider for Principled v2: The saturation increase at high roughness is physically correct, but do we actually want it? From a user perspective, it generally would probably be better if the albedo always matched the Base Color input, that direct artist control with no interdependency between inputs is the entire point of the "principled" models after all. Maybe we should apply it for the Glossy and Glass BSDF nodes, but not for Principled BSDF.

Seems that you didn't include some changes in osl? I couldn't compile.

Seems that you didn't include some changes in osl? I couldn't compile.

Ah yes, I was building without OSL, that still need to be updated. Will do, thanks.

> Seems that you didn't include some changes in osl? I couldn't compile. Ah yes, I was building without OSL, that still need to be updated. Will do, thanks.

Updated to include OSL support.

I also ended up kicking out most of the Cycles-specific OSL microfacet closures, we only need three special ones now (and one can be removed along with Principled v1 later).

If we really want to keep those for user's OSL scripts, we could implement them as wrappers around the standard functions in the header, but I don't think that's needed.

Updated to include OSL support. I also ended up kicking out most of the Cycles-specific OSL microfacet closures, we only need three special ones now (and one can be removed along with Principled v1 later). If we really want to keep those for user's OSL scripts, we could implement them as wrappers around the standard functions in the header, but I don't think that's needed.

We can break OSL closure compatibility in 4.0.

Updated to fix the color passes. They now even include the high-roughness saturation increase, so that with a white background the "glossy direct" channel appears white regardless of the roughness and object's color.

The match is not perfect at the edges at high roughness, but that was already the same before, and I don't see a way of improving it without increasing the size of ShaderClosures.

Updated to fix the color passes. They now even include the high-roughness saturation increase, so that with a white background the "glossy direct" channel appears white regardless of the roughness and object's color. The match is not perfect at the edges at high roughness, but that was already the same before, and I don't see a way of improving it without increasing the size of `ShaderClosure`s.

Now that the new Multi GGX is much faster, wouldn't it be good to remove the "Slower than GGX" from the description? I guess it's still slightly slower but doesn't seem very obvious.
Also maybe mentioning it's energy-preserving, I'm thinking of something like "Gives energy-preserving results by compensating for multiple scattering, preventing excessively darkening especially at high roughness values."

Now that the new Multi GGX is much faster, wouldn't it be good to remove the "Slower than GGX" from the description? I guess it's still slightly slower but doesn't seem very obvious. Also maybe mentioning it's energy-preserving, I'm thinking of something like "Gives energy-preserving results by compensating for multiple scattering, preventing excessively darkening especially at high roughness values."

Good point about the description, thanks! I'll need to update that.

In general, this will need an extensive entry in the release notes, so I'll wait with merging until Thursday when I'm back home so I can update those properly. Also, the tests need to be updated, and I'd like to add a few more tests.

For now, I've rebased the branch since it turned out that part of the color pass fix here is also the fix for #108211, so I already merged that bit.

Good point about the description, thanks! I'll need to update that. In general, this will need an extensive entry in the release notes, so I'll wait with merging until Thursday when I'm back home so I can update those properly. Also, the tests need to be updated, and I'd like to add a few more tests. For now, I've rebased the branch since it turned out that part of the color pass fix here is also the fix for #108211, so I already merged that bit.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: Remove MultiGGX code, replace with albedo scaling #107958

Reviewers