autodesk / standard-surface Goto Github PK
View Code? Open in Web Editor NEWWhite paper describing the Autodesk Standard Surface shader.
License: Apache License 2.0
White paper describing the Autodesk Standard Surface shader.
License: Apache License 2.0
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?
Hello,
I am finding what looks like a conflict in the documentation for transmission_color.
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.
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?
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.
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
The current logo in the whitepaper is no longer the logo Autodesk uses. It should be updated to the current branding.
The documentation claims the roughness to be 0.2 by default. The materialx reference uses 0.1.
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.
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
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.
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.
Because I want to use this standard material in cycles, but cycles does not provide the implementation of metal and 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.
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!
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
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?
I have seen a few people getting stomped on the clearcoat layering logic.
Here are a few thougths:
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.