Initial scattering equations for the PBR specification

[jstone-lucasfilm]

This changelist expands the MaterialX PBR specification with the formal mathematical foundations of its shading nodes, so that the behavior of each BSDF, EDF, and VDF can be reproduced directly from the document rather than from the cited references or shading code implementations.

The following specific changes are included:

• Add a Scattering Framework section defining the formal notation, the BSDF and EDF distributions, and the descriptive terminology shared by the per-node equations.
• Add Reflectance Models and Light Transport sections covering the shared microfacet model, energy conservation, and the governing light transport and volume transfer equations.
• Add inline equation sections to each shading node, mapping its artist-facing inputs to the symbols used in its defining equations.
• Add an appendix with the extended derivations for the EON, Zeltner sheen, Chiang hair, and thin-film iridescence models.

This work was developed as a collaboration betweeen the AOUSD Materials Working Group and the ASWF. The first iteration of the Scattering Framework was written by Anders Langlands, and early review and feedback were provided by André Mazzone, Stephen Hill, and Arnon Marcus.

[dbsmythe]

This looks like a fantastic change, much needed. I will let others proofread the details of the descriptions and equations, I just had a few formatting notes:

[portsmouth]

Looks like a lot of work, nice job!

I will note that this gives quite a bit more detail in terms of formulas than the OpenPBR spec does. I assume the point is to make it more clear what the existing MaterialX spec should correspond to in an implementation.

In the OpenPBR spec we could have written similar formulas down, but we opted not to since:

• in most cases, a reference is enough to allow someone to implement it, so long as we make it unambiguous in the text what variant to implement. To give all the details, you'd have to write a book length document (and PBRT does exist..).
• the hope was to be fully specific only in the sense that we give unambiguous BSDFs, and layer structure, then require the rest be determined by light transport.
• though in some cases, even in the BSDFs we didn't want to commit to a particular formula , as not all implementations would be able (or want) to adhere to it. An example would be the microfacet multi-scatter, as various reasonable implementations are available.

For the layering model in particular, one outcome of having a more general description in terms of physical light transport in slabs is that certain physical effects come "for free" in the ground truth, e.g. darkening and roughening effects of the coat and fuzz, and the view-dependence of the coat absorption. Those would have to be put in by hand otherwise, and are missing from the current Material layering model.

You could argue this makes the OpenPBR spec harder to implement, but it also pushes implementations to be more physically correct and converge on the same underlying physical model, rather than committing to one looser approximation.

It would be good though to have the conversation about whether OpenPBR should be more specific, possibly to match what was done here in some cases.

[anderslanglands]

My view is that a specification should be precise about what the intended result is. Leaving it vague because some implementations have different requirements (eg realtime), just opens the door to divergence.

If a particular implementation wants to make a different choice about something, then that is their choice to make (eg because I have a hard real-time requirement, or I have a better model for later transport than what the spec proscribes) and a comparative conformance suite will clearly show those differences, but there should never be any confusion about what is the correct, intended behaviour.

there clearly is a correct, intended behaviour because you have a reference implementation that can be tested against. If the spec doesn’t match that exactly then the spec is of limited value IMO.

Basically it’s my opinion that it’s OK that an implementation doesn’t match the spec exactly, as long as everyone knows why it doesn’t match and how much and that’s an intentional choice, not just drift created by a vague specification.

[portsmouth]

My view is that a specification should be precise about what the intended result is. Leaving it vague because some implementations have different requirements (eg realtime), just opens the door to divergence ... there should never be any confusion about what is the correct, intended behaviour...

I think the OpenPBR spec doesn't leave the intended appearance vague, it defines it precisely via physical light transport in a layered slab structure with defined BSDFs. It deliberately omits a fully enumerated set of approximation formulas (for the BSDF or the layering), since those can be worked out or looked up, and prescribing them in the spec would actually narrow the definition unnecessarily.

This was an early design decision. Compared to something like Standard Surface, where the model is a hard-coded mix of (not fully defined) BSDFs with ad-hoc blend weights encoding an approximate layer structure, the slab-based formulation has some advantages:

• Physical effects like coat darkening, roughening, and view-dependent absorption arise naturally from the light transport rather than having to be hand-coded as separate terms. Implementations that do the physics correctly get these for free.

• Different implementations can choose different layering approximations to suit their constraints (albedo-scaling for most production cases, more rigorous layering in an offline renderer) and still be working toward the same well-defined physical ground truth. Convergence in the limit is guaranteed by the physics, not just hoped for.

The trade-off is that it requires more engineering work, but in practice various implementations are out in the wild and the results are close, since everyone is working to the same underlying light transport.

there clearly is a correct, intended behaviour because you have a reference implementation that can be tested against. If the spec doesn’t match that exactly then the spec is of limited value IMO.

The MaterialX graph we supply wasn't intended to represent the ground truth appearance of the model. It's an approximation we designed to be as close as possible to the spec, but the ground truth is defined by the spec, i.e. physical light transport in the slab, not by that graph.

Declaring the graph to be the reference would be problematic, because the current MaterialX layering model doesn't fully capture some of the physical effects the spec requires. For example the MaterialX layering operation currently ignores the effect of the internal bounces in the slab, or volumetrics within it, so to approximate that in the graph one has to insert some factors. The light transport tells you what those factors have to be, in a fairly straightforward way.

Designating it the reference in its current state would mean requiring all renderers to replicate its specific approximations, including the less accurate ones. I'd like to see work on improving the MaterialX layering model, but that's a separate issue.

a comparative conformance suite will clearly show those differences, but there should never be any confusion about what is the correct, intended behaviour.

Agreed, and we're working on developing this test suite to try to identify areas of divergence and work to iron those out. A suite that compares implementations against each other and against ground-truth renders would surface deviations clearly, whether intentional or not, and would be valuable regardless of whether the spec prescribes exact formulas.

It would be good to have a live discussion about this sometime, maybe in the OpenPBR meeting.