What shading model did we use? That brings us to the next topic.
A surface standard to grow towards
As discussed, the classic metalRoughness model does not give us all the features we need, so over the last few years we started extending it into several semi-documented extension, each adding a single feature to it, such as coat, anisotropy, subsurface, etc…
We soon realized this was not tenable because the new surfaces and their parameters, from the outside, looked somewhat arbitrary.
On the other hand, expecting users to write their own brdf networks in MDL was a bad choice because plainly put, uberShaders are much easier to use and to exchange textures for.
We started looking into drafting a whitepaper to document our ideal surface, spurring from our existing tests. That was effectively creating a new standard.
This was just during Siggraph 2018, and that is when Autodesk approached us to ask for feedback on a draft whitepaper that was just about that: establishing a new standard shading model, called StandardSurface – which is inspired to the Arnold shaders as well as the Disney model and its descendants.
That was great timing, not just because we wanted to do the same, but also because Autodesk was already involving some of the best minds in the field.
While the word “perfect” rarely fits in the same sentence as the word “standard”, we like what we have found in StandardSurface. It strikes a good balance by extending the existing capabilities of common uberShaders to cover a vast majority of cases in the real world. It does this without overcomplicating the model with too many parameters and arbitrary rules. It provides guidelines for simplification, so real-time or less featured renderers can be still have good approximations. Perhaps most importantly, it is well reasoned and documented, which helps accept or discuss the choices made, and provides a guide to grow towards this standard.
In general, we think it is preferable to have a slightly over specified standard over an underspecified one. Especially on the authoring side, it is easy and safe to support an uncontroversial subset of a given standard. What is produced will be perfectly readable by any renderer that supports that standard. On the other hand, adding parameters to an underspecified standard puts us back in the situation we were in before, where we have no “rails” and we need to make up rules as we go, usually with the result that the new exports won’t be very widely used or supported.