Support vertical layering of opaque BSDFs

[jstone-lucasfilm]

This changelist extends vertical layering to opaque BSDFs, adopting the convention that every BSDF in the PBS library defines a vertical-layering transmittance: the fraction of incident light that passes through the BSDF to the layers beneath it. Interface BSDFs such as dielectric_bsdf and sheen_bsdf transmit all of the energy they do not reflect, while opaque BSDFs such as oren_nayar_diffuse_bsdf and conductor_bsdf treat their weight input as a statistical coverage of the surface, transmitting light only through the uncovered fraction.

Previously, an opaque BSDF used as the top input of a layer node fully occluded its base regardless of weight, so even a zero-weight lobe occluded the layers beneath it. With this change, layering an opaque BSDF over a base is equivalent to mixing the two BSDFs by the coverage, making a zero-weight lobe transparent to its base and preserving energy conservation throughout.

Specific changes:

• Update the throughput of the opaque BSDF closures in hardware shading languages from full occlusion to the uncovered fraction 1 - weight.
• Extend MDL shader generation to support vertical layering of opaque BSDFs, forwarding the IOR and volume of the base and blending the subsurface medium with that of the base by coverage.
• Add a Vertical-Layering Transmittance section to the PBR specification, defining the transmittance of each BSDF in the PBS library, its composition by the mix and layer nodes, the transmittance of a BSDF layered over a VDF, and the energy conservation invariant relating transmittance to directional albedo.
• Add test graphs validating that layering an opaque BSDF over a base matches the equivalent mix at coverages of 0, 0.5, and 1, that a mixed top layers as the mix of its individually layered inputs, and that a mix with an empty background reduces the coverage of an opaque top.

Notes for reviewers:

• No shading models in the standard libraries change appearance: all layer tops in libraries/bxdf are interface BSDFs or unit-weight opaque BSDFs. User materials that layer a partial-weight opaque BSDF will brighten, as the base now correctly receives the uncovered fraction of light.
• Compositions whose semantics are not yet portable across targets are intentionally reserved for a future revision of the specification: the transmittance of the add and multiply nodes, and the medium transmittance of a medium-bound BSDF nested as a top layer, which depends upon a slab thickness that no node in the library yet expresses. Each target retains its current behavior, so multiply-scaled tops such as the topMix of LamaLayer render as before. Follow-up issues on these topics are proposed in the discussion below.
• OSL layer closure semantics are implemented by host renderers, with the new specification section defining the expected behavior for those implementations. Note that tagged OSL releases render the mix-as-top test graphs with reduced coverage, due to a testrender bug in layer-opacity evaluation ([BUG] testrender drops earlier ADD branches in layer-opacity and background evaluation OpenShadingLanguage#2151) that has since been fixed on the OSL main branch.
• The extended CI build, which compiles the generated MDL of the test suite with mdlc, will be run on this branch via workflow_dispatch before merge.

Thanks to @tdavidovicNV for the renderer comparisons and OSL fixes that shaped the scope of this changelist, and to @anderslanglands for the layering discussions reflected in its treatment of media.

[jstone-lucasfilm]

In addition to the list of reviewers above, I'm CC'ing @krohmerNV and @jreichel-nvidia for their thoughts from the MDL perspective.

[tdavidovicNV]

I really like this, definitely good direction.

I have two concerns about the MDL, which just reinforce the call for my more MDL capable colleagues to take a look. I tried to point out the code that looks worrying, but I don't know enough about MDL to propose actually working fixes.

[tdavidovicNV]

The new SSS layering path forwards mxp_base.surface.scattering, but the returned volume is still constructed exclusively from the top SSS node.

Shouldn’t this be something along the lines of:

coverage = saturate(mxp_weight * mxp_top_weight)

result.surface =
    weighted_layer(coverage, top.surface, base.surface)

result.volume =
    volume_mix(coverage, top.volume,
               1 - coverage, base.volume)

result.ior = base.ior

In particular, layer(subsurface(weight=0), baseSubsurface) should preserve the base volume exactly. I will leave the exact code to more MDL-capable people.

[jstone-lucasfilm]

Good catch, and agreed: the volume should follow the coverage rather than the top alone. This is now addressed in a1a760a, which blends the scattering VDF, scattering coefficient, and absorption coefficient of the subsurface node with those of its base by weight * top_weight, following the volume_mix composition that mx_mix_bsdf already uses. Your case of layer(subsurface(weight=0), baseSubsurface) now reduces to the base volume exactly, and the unlayered case reproduces the previous coefficients. The material additionally forwards the IOR of its base, matching the other layerable materials in the module.

[tdavidovicNV]

The conductor now forwards mxp_base.volume, but the returned material still uses the conductor’s IOR unconditionally no matter the top weight:

ior: mxp_ior

The important point is that layer(conductor(weight=0), base) should preserve the base IOR, I think.

I don't think the conductor's IOR should affect the volume's IOR (at least that's my reading of this code), unless we go full IOR accumulation route.

[jstone-lucasfilm]

Also a good point, and agreed. That ior: mxp_ior predates this PR (it entered the 1.9 module in #2102 and was carried into 1.11), but making the conductor layerable is what makes it matter, and assigning a conductor's complex IOR to the material IOR was never meaningful for a non-transmissive lobe. With the update in a7d18f8, all three conductor definitions forward ior: mxp_base.ior, matching mx_dielectric_bsdf and mx_sheen_bsdf. Since material IOR is uniform in MDL, as the note in mx_mix_bsdf observes, forwarding the base is the consistent choice rather than any form of accumulation.

[tdavidovicNV]

After looking into this more, I need to walk back my earlier agreement with this PR. I agree with most of the change, but not with the proposed behavior of multiply.

The proposed spec currently says two things:

1. For an opaque BSDF, its weight controls coverage, with the remaining throughput to lower layers given by (T=1-w). (spec text)
2. A multiply scales the BSDF response but leaves its throughput (T) unchanged. (spec text)

This gives these two graphs different meanings:

oren_nayar_diffuse_bsdf(weight=0.5)
multiply(oren_nayar_diffuse_bsdf(weight=1), 0.5)

The first one covers half of the surface and lets half of the base show through. The second one still covers the whole surface. It only makes the Oren–Nayar response darker, with the removed light treated as absorption.

At zero, the difference is even clearer:

oren_nayar_diffuse_bsdf(weight=0)

means no top layer, while:

multiply(oren_nayar_diffuse_bsdf(weight=1), 0)

means a completely black layer which still hides the base.

I don’t think these should be different. This is also not what I intended in #2971, where multiply(top, 0) was meant to be empty and therefore leave the base unchanged. That PR only discussed the zero case, so it did not define the behavior of partial multipliers.

There is also a practical cross-target problem. Current genosl writes both a node’s weight and an external multiply as scalar multiplication of an OSL closure. OSL’s reference layer implementation uses that scalar when deciding how much of the base is visible. It therefore treats both cases as coverage.

OSL could probably be extended to support the distinction proposed here, but this would require a change to the closure contract and corresponding changes in OSL renderers. It is not just a MaterialX codegen change.

MDL can represent the distinction because it has separate operations for layer weight and BSDF tinting. However, MaterialX’s MDL layer codegen does not currently handle a multiply node as the layer top, and this PR does not add or test that case.

I would prefer that multiply(bsdf, s) scales the effective weight of the BSDF by (s). In other words, multiplying a fully weighted BSDF by 0.5 should be equivalent to setting its weight to 0.5.

For an opaque BSDF, this means reducing its coverage. Multiplying by 0.5 leaves half the surface uncovered, while multiplying by zero removes the layer completely.

Since the spec defines throughput as (T=1-w) for opaque BSDFs, scaling the effective weight by (s) gives:

$$ T_{\mathrm{out}}=1-s(1-T_{\mathrm{in}}) $$

Given GLSL and OSL are our reference renders, and this proposal introduces something OSL currently cannot easily express, I am worried.

[tdavidovicNV]

(I am gonna walk back the recommendation, because LamaLayer and LamaConductor utilize the multiply in conflicting ways, the first one reducing coverage while the second one keeping coverage and just changing tint.. so the story is way more complicated with compatibility in mind)

[tdavidovicNV]

After looking into this much more, I need to walk back both my earlier agreement with the multiply part of this PR and my first suggestion for fixing it. The current behavior is less consistent than I expected, and I don't think either meaning of multiply is ready to standardize yet.

The underlying problem is that scaling a BSDF response and scaling its coverage are different operations. At zero, this is the difference between an absent BSDF, which reveals the layer below, and a black absorbing BSDF, which still hides it.

#3022 currently makes that distinction by saying that an elemental BSDF's own weight controls coverage, while multiply scales only the response and leaves vertical-layer transmittance unchanged.

I tested the same material with a neutral, reflection-only dielectric top in several backends:

layer(top(weight=s), base)
layer(multiply(top, s), base)

The results are not consistent (the base is green, the top is dielectric):

Backend	top.weight=s	multiply(top,s)
GLSL	Top response decreases and base pass-through increases	Top response is scaled, but attenuation of the base is unchanged
OSL	Top response decreases and base pass-through increases	Same result as weight=s
Arnold using generated OSL	Same as OSL	Same as OSL
Karma CPU	Top response decreases and base pass-through increases	The complete layered result is scaled
MDL code generation	A direct elemental top maps to a weighted layer	A multiply top does not carry the outer base

This behavior is not inferred from the renders alone. GLSL includes the dielectric weight in the directional albedo used to compute pass-through, and OSL uses the weighted closure when deciding how much of the base remains. In the vertical-layering calculation, both therefore treat a reduced dielectric weight as reduced effective coverage. The renders confirm that behavior. They also show that multiply has no shared behavior today. Arnold confirms the generated OSL behavior, but is not an independent lowering.

OSL has no way to scale only the response of an arbitrary closure while leaving its layering weight unchanged. Closure multiplication changes the closure weight, which is also used for coverage. Pushing the multiplier into the BSDF's color or tint parameters is not an option either: the input may be an arbitrary composition, and the language has no operation that can inspect that composition and modify its parameters.

Mixing with opaque black does not solve this. Consider:

multiply(white_bsdf(weight=0.5), 0.5)

Response-only scaling would produce a half-covered grey BSDF. OSL closure multiplication produces a quarter-covered white BSDF. Mixing the half-covered white BSDF with opaque black produces half black, one quarter white, and one quarter uncovered: 75% coverage.

All three look the same over black, but behave differently when layered. So the proposed response-only meaning of a generic BSDF multiply cannot be expressed using the current OSL closure operations. It would require a new closure operation and renderer support.

MDL can represent response scaling with df::tint, but the current MaterialX layer lowering cannot carry the outer base through an arbitrary multiply, mix, or add top.

My #3017 proposal did not settle multiply either. It introduced pass-through as something separate from directional albedo, and its implementation notes were compatible with closure weight affecting pass-through, but that was not enough to define the semantics of the multiply node.

There are also two separate questions involving mix.

An ordinary mixed top:

layer(mix(fg=A, bg=B, mix=w), base)

needs a pass-through value of its own. glTF and OpenPBR already use this form, and the linear rule proposed in #3022 is the natural one:

$$ T_{\mathrm{mix}} = (1-w)T_B + wT_A $$

I think this should remain part of the 1.39.6 definition.

The separate question is how to reduce the coverage of an arbitrary compound top. Under the proposed rules this can be written as:

layer(mix(bg=zero, fg=compound, mix=s), base)

Here zero means an absent BSDF, not an opaque black BSDF.

GLSL and OSL give the expected coverage behavior for this graph. In my tests Karma produces black at s=0, and the current MDL lowering loses the outer base. This does not make the ordinary mix rule ambiguous, but it does show that compound-top coverage is not portable today.

Lama also shows why this is not merely theoretical. LamaLayer.topMix applies to an arbitrary top material and is currently implemented with multiply(materialTop, topMix), while other Lama nodes use multiply to tint a response. The same MaterialX operation is already serving two different purposes.

Other material systems generally give these operations separate names. MDL has df::tint for response scaling and df::weighted_layer for presence, while Manuka and OpenPBR expose explicit material mixing and weighted layering. This does not establish either meaning as the natural behavior of a generic BSDF multiply.

So, for 1.39.6, I would suggest the following scope:

• Define vertical-layer pass-through separately from directional albedo and path throughput.
• Define it for the existing interface BSDFs, elemental opaque BSDFs, ordinary mix results, and nested layer results.
• Extend the existing vertical_layering.mtlx cases to cover opaque weights 0, 0.5 and 1, and actually compare layer(top(weight=s), base) with mix(bg=base, fg=top(weight=1), mix=s) within both GLSL and OSL.
• Add a normal mix-as-top test, since the standard glTF and OpenPBR graphs depend on it.
• Add MDL generator and compile coverage for the elemental opaque cases changed by this PR. The same MaterialX documents can be used as manual downstream tests in Karma.

The effect of multiply on layer pass-through still needs a separate decision. The same is true for add, the meaning of BSDF weight when the BSDF is standalone or at the bottom of a stack, and a portable way to control the coverage of an arbitrary compound top.

I think those questions should become focused follow-up issues. One should cover the relationship between response, coverage, weight, and multiply, including the difference between an absent BSDF and an absorbing black BSDF. Another should cover compound-top coverage, including Lama's topMix and whether MaterialX eventually needs an explicit weighted-layer operation. The renderer matrix and the test materials above can be used as starting cases for both.

That would still give #3022 a useful result for 1.39.6: opaque BSDFs become usable as top layers, while the unresolved multiply and compound-coverage questions get a proper investigation instead of being decided indirectly by the first formal definition.

[anderslanglands]

Does it make sense to try and shoehorn these semantics into nodes that aren't really designed for that? Should we not have dedicated nodes for this, e.g. by actually defining the lama nodes as nodedefs to do proper physical layering rather than the broken graphs they currently are?

[anderslanglands]

...especially as I don't see any discussion of ND_layer_vdf semantics here either...

[jstone-lucasfilm]

Thanks for the renderer matrix and test materials, @tdavidovicNV. That's very helpful additional context, and I agree with the scope you've proposed for 1.39.6.

With the update in 05affd7, the transmittance rules for add and multiply have been removed from the PBR specification, which now states that their composition is reserved for a future revision. It's worth noting that those sentences only documented the pre-existing behavior of the hardware shading languages (mx_multiply_bsdf_float.glsl has carried result.throughput = in1.throughput since before this PR), so removing them doesn't affect any renders: GLSL retains its current behavior, and multiply-scaled tops such as LamaLayer.topMix render as before. The mix and nested-layer rules remain as defined, since glTF and OpenPBR depend on a mix as a layer top today.

On improvements to testing, 3e1b033 extends vertical_layering.mtlx along the lines you outlined: a unit-coverage opaque top completes the set of weights at 0, 0.5, and 1, with the partial-coverage case paired against its mix equivalent; a two-sided mix of a conductor and a dielectric is paired with its horizontal re-expression to validate the linear mix rule; and a final graph scales a conductor through a mix with an empty background. On the MDL side, your two inline comments are addressed in a1a760a and a7d18f8, and I'll plan to run a manual CI build on this branch, which compiles the generated MDL of the test suite with mdlc.

Since the renderer matrix and test materials are yours, would you be willing to open the two issues you outlined -- one on the relationship between response, coverage, weight, and multiply, including absent versus absorbing-black BSDFs; and one on compound-top coverage, including LamaLayer.topMix, the single-sided mix lowering, and whether MaterialX needs an explicit weighted-layer operator? I'll link them from the PR description once they exist, and I'm happy to open placeholders myself if that's easier.

[jstone-lucasfilm]

Thanks @anderslanglands -- I think we agree on the overall direction, though I'd frame it slightly differently. The dedicated operation you're describing could be a coverage weight on the layer node itself, as in MDL's df::weighted_layer: a new weight input defaulting to one, which would leave every existing graph unchanged while better aligning layer with Lama. With it, LamaLayer would become layer(top, base, weight=topMix) -- a direct expression rather than a workaround through multiply -- without the Lama nodes needing to become native nodedefs with per-target implementations. If we proceed in this direction, we'd want to start with a TSC discussion, and we'd value your input in that forum.

This PR is the node-level piece that any such operator would build on. Today an opaque top silently occludes its base in full regardless of weight, and the coverage reading adopted here is what MDL's weighted_layer and OSL's closure weight already compute for these nodes, and how OpenPBR defines its coat and fuzz weights, which our realization expresses as the weight of the top BSDF. A layer weight would compose with it consistently -- layer(top(weight=w), base) and layer(top, base, weight=w) expand to the same result for an elemental top -- so nothing here would need to be revisited. The contested multiply question has been carved out, per Tomas's analysis above.

On layer_vdf: the "Layering over a VDF" subsection was added in an earlier revision, and as of 8477479 it's now explicit, defining the medium transmittance from the VDF's existing extinction equations, giving the composite as a reflection lobe unaffected by the medium plus a transmission lobe attenuated along its path, and a transmittance equal to the product of those of the surface and the medium, matching the reference implementation in mx_layer_vdf.glsl. If that's not the gap you had in mind, I'd welcome more detail on what you were looking for.

[anderslanglands]

The VDF question was more about what happens when I e.g. layer or add two dielectrics which themselves have VDF children? And what happens with multiply?

Similarly, the important part of lama that is currently omitted in materialx is layering a thick dielectric over something else, and without the concept of layer thickness we can't really properly represent OpenPBR or any other slab-based model.

[jstone-lucasfilm]

Ah, thanks for clarifying, @anderslanglands. My take is that a BSDF bound to a medium is a BSDF like any other, with the response and transmittance defined in the "Layering over a VDF" subsection, so the cases you describe follow from the existing rules. For layer(layer(d1, v1), layer(d2, v2)), the nested-layer rule applies: the inner surface is seen through both the outer interface and its medium, and the transmittance of the stack is the product of all four factors. For add and multiply, the response is defined but the transmittance is reserved as of 05affd7, so what a medium-bearing top contributes through either node is deliberately left undecided here. The backends differ in ways that predate this PR: GLSL folds the VDF into the throughput of the transmission lobe at the layer, OSL emits layer, +, and * on closures verbatim and leaves the combination of two media to the renderer, and MDL, which carries a single volume per material, merges the two in mx_add_bsdf and forwards the result unchanged through multiply. Which medium a refracted path enters when two are summed is a closure-level question the specification has never addressed, and it belongs with the add/multiply issue discussed above.

On thickness, I agree this is an important missing piece, and it's a pre-existing one: LamaLayer.topThickness is declared but explicitly unsupported in lama_layer.mtlx, and glTF's thickness is likewise unconsumed. The transmittance product for a medium-bound surface, T = T_top * T_vdf with T_vdf = exp(-sigma_t * t), is exactly where a thickness would plug in. For a closed transmissive object, the path length t comes from geometry, while a slab layered over a base has no geometry to provide it, which is why the specification currently allows a fixed-distance approximation. OpenPBR avoids the question by parameterizing coat absorption through coat_color, the transmittance of the coat slab, which our realization applies as a tint beneath the coat, while its base medium is traced through geometry; a thickness is what LamaDielectric's interior would need in order to act as a coating color at the rate topThickness intends.

Notably, LamaLayer's two remaining inputs are topMix and topThickness, so the weight input I proposed above and a companion thickness input would together let LamaLayer map directly onto layer, and the LamaLayer documentation already spells out how thickness should propagate through nested layer, mix, and add tops, which would be a natural starting point for the specification text. Neither MDL's layering functions nor the OSL closure set express a slab thickness today, so this would need renderer-side work alongside the specification, and I'd suggest we take it up at the TSC together with the weighted-layer question. Would you be willing to open an issue capturing the slab-based requirements from Lama and Manuka? That would let the three follow-up threads -- response and coverage, compound-top coverage, and layer thickness -- each be discussed with their own evidence, and I'll link them from the PR description as they appear.

[tdavidovicNV]

I agree with this scope. Notably, there is now a bug in OSL (AcademySoftwareFoundation/OpenShadingLanguage#2151) that: layer(mix(red_opaque, blue_opaque, 0.5), green_opaque) will produce magenta top with 50% coverage, despite the fact it should be 100% opaque.

That will probably affect a lot of tests for this proposal, so should be known about.

[anderslanglands]

My take is that a BSDF bound to a medium is a BSDF like any other, with the response and transmittance defined in the "Layering over a VDF" subsection, so the cases you describe follow from the existing rules. For layer(layer(d1, v1), layer(d2, v2)), the nested-layer rule applies: the inner surface is seen through both the outer interface and its medium, and the transmittance of the stack is the product of all four factors.

The trouble is this is not defined unless you also define the thickness of the top layer (as in lama). In the absence of that, the only sensible option imo is to say the thickness of the top layer is 0, in which case its medium will be ignored.

[jstone-lucasfilm]

Thanks @tdavidovicNV, and for going beyond the report to fix the issue upstream in AcademySoftwareFoundation/OpenShadingLanguage#2152. Since no tagged OSL release yet contains that fix, the mix-as-top graphs in vertical_layering.mtlx will render with reduced coverage in current OSL builds, including the v1.14.10.0 build used by our extended CI, and this issue is now noted in the PR description for future reference. Once a corrected OSL release is available, updating the CI pin would make these graphs meaningful in OSL render tests, and I'd suggest we take that as its own changelist.

[jstone-lucasfilm]

That's a fair point, @anderslanglands, and you've changed my view on this. My earlier note that the nested case follows from the existing rules assumed a path length that nothing in the graph defines: when a medium-bound BSDF is nested as the top of another layer, its medium is a virtual slab with no geometry to provide $t$, and the transmittance product is well-defined only in form. As of 2bca2a8, the specification now scopes the geometric path length to a composite bounding a closed object, and reserves the medium transmittance of a nested medium-bound top for a future revision, following the same pattern as the add and multiply carve-out. The subsurface_bsdf node remains well-defined as a top layer, since its transmittance is given by its opaque coverage rather than by its interior medium.

On your proposed default, I agree that zero thickness is the natural choice, and it matches the default of LamaLayer.topThickness. I'd prefer to adopt it alongside an explicit thickness input rather than in this PR, since a zero-thickness rule on its own would conflict with the interior reading that path tracers apply today, where MDL forwards a nested volume into the material interior and traces it through geometry, and hardware shading languages approximate the outermost medium with a fixed distance for attenuation. Defining the slab semantics and their default together, with renderer input from the Lama/Manuka perspectives, seems the safer path, and the follow-up issue on layer thickness proposed above would be the natural home for it. Your earlier framing of slab-based requirements would make a strong starting point for that GitHub Issue, if you have the bandwidth to write this up.

[tdavidovicNV]

@jstone-lucasfilm all my concerns are resolved for this PR. The thickness debate is definitely interesting, but probably longer and maybe should be split away, but I will leave that up to you and @anderslanglands, no strong opinions from me.

[jstone-lucasfilm]

Since we've resolved a number of issues brought up earlier in this PR, I wanted to bump the discussion, to see whether any reviewers are aware of issues that still need to be addressed.

I'm specifically CC'ing @tdavidovicNV and @anderslanglands, who have provided great review so far, as well as @niklasharrysson, @krohmerNV, and @jreichel-nvidia, who may have additional perspectives that would be valuable to include.