This is unrelated to this discussion:
“Mirror” was used as a shorthand for roughness 0 here, where the microfacet normal is the same as the macro normal. Not a dielectric specifically. It’s correct in general to handle Fresnel at the microfacet level, both for dielectrics and metals.
The main argument for having these controls is not accuracy, it’s usability and compatibility.
So does metallic edge and falloff affect only metallic materials (metallic at 1.0) or materials of any metallic value? If the latter is the case, why are they labeled “metallic”?
Yes, so is my main argument. If I just get a PBR texture set of a metallic object, let’s say a sword, which combines multiple different metallic materials, such as copper, bronze, iron and so on, how do I know Blender shows me the same material as the game engine does? Unreal doesn’t have any metallic edge and falloff input, and I’ve never gotten a PBR texture set which supplies metallic edge texture and metallic falloff texture.
Those parameters would only affect metallic materials.
Lukas was just explaining the general principle that handling Fresnel at the microfacet level can make a significant impact. Maybe for metals it’s always slight for typical parameter ranges, I haven’t checked. But in terms of design/implementation it’s simpler to handle all Fresnel consistently, and not make exceptions for some case that happens to be possible to factor out with little visual impact.
For game engines, the right solution will probably be to make nodes that have a subset of the Principled BSDF parameters compatible with them. We don’t want to hold back offline rendering and lag behind features offered by other renderers, just because those features are not available in game engines (yet).
I agree. Lukas originally said:
Which made it sound like he means separate color control for edges built right in the principled shader. I also don’t think offline renderers should hold back. I am still not sure the metallic edge and falloff are justified here. They are not that prominent in the the other software. Only minority of other renderers implement it on the material shader level. And it just adds UI and usability complexity with little to no reward in quality, compared to less accurate solution built out of the input nodes.
Unfortunately, it’s probably there to stay, but I think all it will do is make it more difficult to learn for the new users, allow them to make uglier and less realistic materials by misusing the feature, and increase room for error for experienced users.
I don’t think this is true for renderers with similar target use cases as Cycles (Arnold, Renderman, Clarisse, Corona, …).
I guess we’ll just have to disagree on this. If it’s a custom node group instead of being part of the shader itself, the option might as well not exist for many users, and the risk of setting it up incorrectly increases.
All the implementations that I looked at handle it in a similar way:
For me the opposite is the case, I’ve never heard of a single render engine that claims to be physically-based but uses a flat color for the metallic Fresnel term. I only know that from “legacy” engines like Blender Internal.
The problem here is that there are two opposing design goals: On the one hand, the shader should be intuitive and easy to control, but on the other hand people want it to be compatible with Principled v1, compatible with game engines, compatible with specular/glossy textures, compatible with glTF, compatible with MaterialX, compatible with other renderers etc.
My approach to this problem is to have a small set of “core parameters” that most users will focus on, and then additional parameters to tweak things for advanced cases.
For this case here, roughness, metallic and base color will be core parameters.
All the others are additional tweaks that you can just ignore, the default result will be fine for most cases.
For all three, I feel like it’s also quite clear what it controls. “Metallic Edge” controls the color of metallic reflections when you look at an edge, it doesn’t get more straightforward.
Same, which is why UI improvements are on the todo list. For example, we could have collapsible panels for the advanced inputs (e.g. one panel for SSS (Scale, Radius, Anisotropy), one for Specular (Metallic Edge/Falloff, Anisotropy), one for sheen (strength, roughness, color), one for non-physical controls…) so that the user only sees the basic inputs (base color, roughness, metallic, transmission, IOR) and a bunch of panels.
Yeah, that’s a good point that’s also made here, for example. There’s already so many fundamental simplifications going into modern renderers (no wave optics, no polarization, mostly no spectral rendering, …) that trying to be 100% perfectly exact in other areas is pointless since being “off” on one detail might actually end up moving you closer to the real-world truth. As in, what’s the point of modeling the microfacet shading term to 10^-8 numerical accuracy instead of 10^-7 if the entire microfacet distribution (GGX) is pretty much just “we tried a random nice-looking term and it kind of fit the data”.
That’s my motivation to not bother with the real conductive Fresnel equations for Principled v2, for example. Simpler models capture the qualitative behavior well enough.
I think there’s a misunderstanding. I expect fresnel term to be in any renderer which claims itself to be even remotely physically plausible, but I expect it to behave differently for metallic materials. I was specifically talking about the case where the Metallic value is set to 1.0. This setup:
We’re not allowed to post images from other software here, but the results I consistently get are that fully metallic materials would not be expected to reflect anything when the base color, which is supposed to drive overall reflectance when metallic is at 1.0.
I just don’t see that in many of the other renderers. Perhaps the edge color, if there’s any used, but not exposed to the UI, is scaled by the value of base color (?)
That was exactly my point - the list above is how each of the implementations handled the metallic Fresnel. All of them have the same gradient to white, as far as I can tell.
But yeah, of course the list is not exhaustive, it’s entirely possible that other software handles it differently.
Once the model is mostly complete, I’ll try to compare against other implementations to ensure similar behavior.
All that being said, I don’t think there’s any real-world conductor with a F0 value that’s even remotely close to black, so arguing realism in that case doesn’t make much sense anyways 
Yeah, I am fine with this argument. I mentioned it just because someone above, it was stated that the primary reason for metallic edge/falloff was compatibility rather than added quality of realism. If that was the case, then I’d expect the behavior to be a bit more consistent with other renderers.
I am slowly leaning towards agreeing that this may be okay to have. The issue may be more on the side of Blender’s node UI design. Maybe nodes could use a concept of (possibly also optionally labelled) separators, so that individual shading components could be better separated and compartmentalized/grouped in the UI, rather than being one vertical noisy list of options.
That’s not what I stated, but happy to hear you now have a better understanding of the topic now thanks to Lukas’ detailed explanations. What I said is that the primary argument for having it part of the node itself instead of a custom node group, is usability and compatibility instead of accuracy of macro vs. microfacet normal. The usefulness of control over edge color one way or another was not in doubt as far as I know.
I think Lukas showed that it is indeed compatible with various other renderers.
So did I misunderstand this? Or how did you mean it?
I think the context clarifies it? You were arguing it should be a node group, that’s what I was responding to, not the usefulness of metallic edge colors in general.
You probably could still get about the same realism with a separate node group, it’s just not great for usability.
FYI, I just pushed an update that replaces the metallic Fresnel model.
More infos, pictures and data here: ⚓ T99447 Principled v2 BSDF
I’ll trigger Buildbot.
What if I want my own subsurface setup with principled’s specular setup?
One aspect that is also true of Principled v1 is that the specular/metallic/roughness/fresnel layer is complex enough that it cannot be exactly replicated with separate nodes by users with their own custom nodegroup and mixing math (correct me if I’m wrong), which is important in case users want to use their own transmission/diffuse component, as it’s the case with custom multilayer subsurface approaches, but with the much better approach to specular that Principled offers. It would be nice if that specular layer was its own node that takes the transmission nodetree bsdf as input so the user doesn’t have to worry about the mixing math. Something like this:
The main difference being that this shader doesn’t pick up Base Color for tinting the specular or metal, that’s up to the user.
Are there before/afters somewhere? I am curious how much perceptual difference does it actually make.
Hello! I have a question. Real world materials have an effect of having more sharp reflection when looking at an angle (most visible in skin, concrete, asphalt). Look at the attached image: the skin becomes like a mirror at far side, despite it’s not that reflective when looking straight at it.
In the current principled this effect is not accounted and materials have “even” roughness regardless of viewing angle that makes them look like plastic. Will there be a control for this “out of the box” in the new principled to get similar behavior as on the photo? I’m fine with it if no, the effect can be reproduced by making other node groups and typing roughness values manually but principled is supposed to be unified shader and have some controls for such cases?
How do other renderers handle this?
Reading the task currently, these two points are really positive.
- The tint options will be replaced by a color input for every component of the model that is used as a multiplier on top of each component. Leaving them at (1,1,1) will result in a physically accurate model, while other values can be used for tweaking intensity and/or color.
- The subsurface [0…1] input will be replaced by a subsurface scale parameter that acts as a multiplier on top of the radius input. The subsurface color input is removed.
All this time in v1, in order to get specular tinting to fake iridescense or holostickers, I was relying on the subsurface color input as the diffuse, with the subsurface slider crancked up to 1, so that the specular tinting would pick up the color from the base color instead. If the specular input will become rgb as it says here, that is a great solution for that hacky thing I was doing all along.Preformatted text
Now, I know this is too much of a industry standard and it won’t change, but it’s worth ranting about the fact that metallic color will still have the same problem of not being independently controllable from diffuse color. Making diffuse and metallic use the color from the same texture has to be one of the WORST industry standards that society has arrived to. Concocted probably by a cabal of game engine technical directors that worried more about channel packing and memory constraints than practicallity. It’s a structure that offline cg artists may not need but have it imposed on them, and one that it’s obsolete by having nodes. Yeah, I understand the rationale “something can’t be both metal and non metal yadda yadda” but I don’t care, I want that better balance between standard and artist control. This node layer can alleviate that. Rant over, I don’t expect things to change, just need someone to tell me I’m not crazy, to know I’m not alone in this
Hi, I may be wrong, but are you sure that roughness decrease at grazing angles? To me, it looks like the sharp reflection you see on the edge of the table is just because the bright object reflected is closer to the surface , hence you can see it sharper.
I’m sure, distance doesn’t matter here. You can do the same thing looking at far objects and get sharp reflection.
