Either fix the OSL code or change aiStandard to match.
Alternatively: clearly state that one or the other is not meant to be an implementation of this standard.

See also #11.

At the Physically Based Shading course at Siggraph this year Naty Hoffman presented issues with established Fresnel models. Both how it's incorrect to use the physical Fresnel equations directly in an RGB renderer, and also how Gulbrandsens method for making the parameterization artist friendly in fact fails at this on several counts.
slides

In addition Laurent Belcour presented a new Fresnel model, that is more accurate than Schlick's approximation and still works well for both offline and real-time rendering.
slides & code

Since Standard Surface is using Gulbrandsens methods, and definitely needs to be usable and accurate for non-spectral renderers, this is something we need to look into. Should we move away from Gulbrandsens method? And if so, what should we use instead?

Feedback from the rendering community is much appreciated!

I have seen a few people getting stomped on the clearcoat layering logic.

Here are a few thougths:

1. This regards the doc only: lerp(t, a, b) is not typical. Osl's mix(), glsl's mix(), MDL's lerp all have the syntax as lerp(a, b, t). It's a small change in the doc but might help simplify a bit.

2. if coat_affect_color default to 0.0 and is "optional", then coat_color should be optional too, because in the simplified model it will have no effect at all and confuse users.

3. I realize it might be late for this, but the name coat_color is a bit misleading as most of the time a color associated to a lobe should affect the lobe, while here it's affecting everything BUT the lobe. "coat_filter_color" or something more intuitive could have helped.

Thanks for the reference OSL shader. It is quite nice except for one peculiarity.

It makes use of two closures "sheen" and "metal" that are non-standard OSL closures. We should probably state that in the OSL shader.

Maybe one should try to get "sheen" and "metal" accepted as part of the OSL standard shader specification?

They are not listed as part of the official OSL specification:
https://github.com/imageworks/OpenShadingLanguage/blob/master/src/doc/osl-languagespec.pdf

They are not supported by Blender's Cycles OSL:
https://docs.blender.org/manual/en/latest/render/shader_nodes/osl.html

It doesn't appear in the V-Ray's OSL support either:
https://docs.chaosgroup.com/display/VRAY3MAX/OSL+Support

Nor do they seem to be documented as supported by Arnold:
https://docs.arnoldrenderer.com/display/A5ARP/OSL+Shaders

Although I did find a hint they are supported by a version of Arnold according to this PR to MaterialX's Arnold OSL translation node: https://github.com/autodesk-forks/MaterialX/pull/420/files/aea870f3a33744c6f10c8c5e30768e0437beee08

In the OSL implementation, I am sure that I correctly understand how total internal reflection is handled. One possibility is that the fresnel term for specular takes care of that since it goes to 1 in the case of TIR, thus not issuing a transmission btdf at all. If that is the case, I have two questions

1. how do you handle rough glass, that should have a btdf that depends on 1 - fresnel(w_h)
2. how do you decide whether to "flip" eta depending on inside-out test

Hello,

I am finding what looks like a conflict in the documentation for transmission_color.

1. in the graph definition we see a coefficient to transmission:
   transmission_sheen_mix = transmission * transmission_color * specular_btdf(...) + (1 - transmission) * sheen_layer;
   That implies a constant (or textured) color plugged straight as a multiplier.

2. transmission_color: tint due to absorption
   transmission_depth: the distance travelled inside the material by white light before its color becomes exactly transmission_color by Beer's law
   This implies a depth-based effect. In this case texturing it is not recommendable as it would be a volume effect.

Which one should it be?

Hello there,

I've been doing some look development tests and I wonder if sheen shouldn't be placed all the way on top, over coat.

The reason for this is that sheen most usually represents phisical properties that happen on top of a possible layer of coat: fuzz, fibers, more often than not just dust.

For the same reason, probably coat tint should not affect sheen.

It would be great to have a set of reference images for each layer and each common combination of layers for which renderers who add an implementation of this shader could test their implementation against for look consistency.

Certainly, some implementation may choose to use another specular BRDF or expose some additional closure parameters that the reference implementation lacks.
But when those are at default values the produced look should match the reference implementation as closely as possible.

Only then will this be useful for stuff like sharing shading networks that have this as the final node between renderers/DCC packages or cross facility asset transfer.

Currently opacity is defined as a float in ND_surface. There are many use cases (stained glass) where it would be good to have opacity defined as a color3.

There's even a documented work-around in standard_surface.mtlx to convert the incoming color to a scalar value. Full color opacity is needed to reproduce the standard surface faithfully.

    <!-- Surface construction with opacity -->                                   
    <!-- Node <surface> only supports monochromatic opacity so use the luminance of input opacity color -->
    <luminance name="opacity_luminance" type="color3">  

It's easy to get a scalar value out of a color, it's not possible to get a color out of a scalar.

The documentation claims the roughness to be 0.2 by default. The materialx reference uses 0.1.

I want to add some retro reflection while keeping the Diffuse reflection unchanged. What is the relationship between reflectance(sheen_brdf) and hemispherical directional reflectance?

Hi! The spec describes a default value of 0.8 for the weight of the sheen BRDF:
https://autodesk.github.io/standard-surface/#closures/sheen

However, in the implementations, the value is actually set to 0.0:

Is this because the layer is optional and the input serves as both weight and toggle?

The current logo in the whitepaper is no longer the logo Autodesk uses. It should be updated to the current branding.

The anisotropy rotation specification says :
orientation of anisotropy; range [0,1] (where 1 means 180 degrees)

Instead if should be :
orientation of anisotropy; range [0,1] (where 1 means 360 degrees)

The reference implementation implements the correct behavior.

Because I want to use this standard material in cycles, but cycles does not provide the implementation of metal and sheen

Hello,

We have noticed an unexpected behavior about the thin film when using it with a specular and transmission. It seems that when the thin film is enabled the transmission is not handling the TIR anymore. Is this the expected behavior ?

Here some images from Maya Arnold (MtoA 4.0.2 - 46d4a92e (master) - Feb 13 2020 03:01:44) that shows the issue :

Here we can see that increasing the depth transmission change nothing when the thin film is enabled :

And if we are visualizing this LPE : CTT+TL which correspond to internal reflection we have the TIR for the case when there is no thin film for the depth 3 and 4 but there is nothing when the thin film is enabled.

Thanks,

Kevin