He posted a screenshot of Unreal though, I am not sure what the specular map in that UE screenshot is doing. Looks like its alpha gets plugged to a specular input, the red channel gets plugged into roughness. This is rather weird.
This looks like the kind of Node setup that I’d love to see included in Blender or NodeWrangler as an instant node group that can be added directly. 
1 Like
Look at it from another angle, this is what we used to need to do to get just the IOR right previously, now we no longer need to do that for IOR. Are you sure your specular map is the kind of specular? If it’s not, you can just invert it and use it as a roughness.
3 Likes
I wasn’t complaining about it … I just noticed that we sometimes do have rather elaborate node setups for conversions or standard setups like the Ctrl-T node setup in Node wrangler. This was more a general angle of “Blender should start shipping with node setup groups that might be used on more than one occasion”. It was more of a general note than specific to this kind of setup. Sorry … a little off topicish.
1 Like
Why on does it have metallic edge and metallic falloff? Why would there be a hardcoded gimmick for just a metallic mode, which is just a primitive falloff between facing and grazing color? By the same logic, we should have also diffuse edge and diffuse falloff, clearcoat tint edge and clearcoat tint falloff.
Hardcoding in random gimmicks should not be done for something as standardized as principled materials. There are such things as PBR texture sets and so on, which expect at least some standard to be displayed and rendered correctly between software (Let’s say between Blender and Unreal Engine for example). This can’t be taken so lightly.
It doesn’t make sense to do it for a Principled material, where some standard is required, and it especially makes no sense to hardcode random gimmicks in such a flexible environment as node based material editor, where user are free to very quickly put together any effects they want.
This is red metallic edge with falloff of 0.5:
This is the same gimmick recreated using just a few nodes:
The result is absolutely identical and it’s trivial to set up
And it can then be nodegrouped for convenient reuse:
Which would also not be restricted just to a base color slot and just to a metallic component.
It’s pointless to have that built in, because now Blender no longer has a reliable, standardized Principled shader but instead has some gimmicky version which is lot more involved to set up. Considering how incredibly trivial it is to set up, it doesn’t justify two new UI elements in the BSDF itself, which don’t add any true new flexibility.
Here’s and example:
The metallic falloff defaults to 0.2!:
Previously, when I wanted to set up golden material, the following steps needed to be taken:
- Set metallic to 1.0
- Reduce roughness
- Set base color to golden color
Now, with the gimmick, there’s one additional step user need to know and be aware of to have their material set up correctly
- Set metallic to 1.0
- Reduce roughness
- Set base color to golden color
- Set metallic falloff to 0.0 so that the metallic edge color does not interfere with the base color
This can be all the more destructive when bringing in a PBR texture set, let’s say from a Megascan asset. Before, you’d just plug all the maps in, and get the correct result. Now, you won’t get the correct result until you also set the metallic falloff to 0, otherwise the default metallic edge color will interfere with the base metallic color specified on the texture at grazing angle. Artist should be able to introduce that if they will, but it should not happen uncontrollably by default.
I am against hardcoding gimmicks which can be simply replicated by the input shading nodes, but if it’s there to stay, then at the very least the metallic falloff value should default to 0.0, so out of the box, users get the result expected from an average Principled material.
Also, is the diffuse translucency done yet? I am not seeing any obvious way to set it up (paper, thin fabric, leaves, grass, etc…)
8 Likes
Standard Surface and PxrSurface have similar metallic controls. It’s an an artist friendly parametrization of complex IOR, which a pretty standard feature for metallic materials, but not diffuse or clearcoat. MaterialX also supports complex IOR as part of the closure. Compatibility with those kinds of shaders is important, not just simpler game engine shaders.
I think there is a difference in handling it at the microfacet level even if can be slight. And in the context of bidirectional path tracing, any shader node setup involving the view direction is also problematic, if we ever implement that.
We intended Principled Surface to become more complete surface shader, where users can tweak parameters rather having to use more complicated node setup. Having this parameter available is easier to learn than a separate edge color node setup. Having it as part of the node also makes presets and texturing easier.
Probably the default falloff could be changed to 0.
22 Likes
Hello,
is there any way to control transmission color independently from the Base Color channel with the new shader? Apologies in advance, if I am missing something simple here.
Not sure what you mean, AFAIK base color no longer controls transmission color, the “correct” way to do glass or water color is with volume shaders, the unphysical way that works sort of like before is to use the clearcoat tint, it works well in my test.
Thank you @Eary I didn’t know one was supposed to use volume color to affect transmission of water or glass materials, this surely makes sense. I will try the trick with Clearcoat Tint, you have mentioned.
which volume node am I supposed to use?
also, isn’t it specular tint rather than clearcoat?
Note we are talking about the Principled V2 here, in v2 the “specular” (which is just another IOR) has been merged to the IOR setting as it should be, and clearcoat tint becomes a proper color input. The legacy specular tint was a very subtle tinting using the base color, very subtle to the degree that I think most people would ignore the setting.
What I meant by using clearcoat tint:
I personally use Principled Volume more, for most cases you would want to have some absorption so thicker parts will have thicker tints:
You can turn up the scattering a little if you want, depends on your use case.
Note you might need to turn up the volume bounces a bit to see ideal result (hope the default can be higher at some point, current default is 0):
I hope this comes soon, for not only convenience, but also discoverability, as there are many users out there still not aware the approach of using volumes for glass and water color.
5 Likes
is the absorption color for principled volume part of principled V2?
Not yet, but I think it’s planned.
Thank you very much, I tried your nodes and they worked fine.
Hello, I found that with the new Principled there is a little more noise:
No lights
Environment HDRI
Samples 64. GPU. Noise threshold 0.01
GGX
Principled V2
if you need that I upload the images with more zoom tell me
This is probably expected at this current point in time. Future updates to the Principled v2 will improve this.
3 Likes
Yes, but not in this node. The Principled BSDF is supposed to be an artist-friendly node, not for exact measurements. I think n/k IOR data makes more sense in a dedicated “Metallic BSDF” or so node.
Not planned currently, the standard approach seems to be to default it to 1.5 and I’m following that. It’s not really refracting anyways, so the only thing it’d control is strength, which already has a slider.
It controls absorption, yes. I might end up renaming it I guess, since I wanted to use “tint” as a term for the nonphysical multipliers.
This isn’t some random gimmick, but comes from the 2017 SPI shading presentation at Siggraph. The idea is to take the basic lerp(F0, 1.0, pow(1-cosI, 5)) Schlick Fresnel model that’s used in pretty much every realtime engine as well as Principled V1 and replace it with a generalized lerp(F0, F90, pow(1-cosI, 1/falloff)) model. Note how you get exactly the old behavior when F90=1.0 and falloff=0.2, which is why these parameters are the default. This way, you get the old behavior while still having extra control when wanted. Also note that falloff=0 does not give the same result as the old model.
In other words, if you liked the old behavior, just literally don’t touch the new controls and you’ll still get it.
Also, the behavior you get when building your own node group is close, but not identical - you’re computing cosI based on the macrosurface normal (aka the Normal input), but Principled (for v1 and v2) is computing it based on the microfacet normal. Doing that in a nodetree is impossible. For mirrors this doesn’t matter, but at high roughness it can make a notable difference (most importantly in glass).
Good point, the current Principled v2 is not bidirectional-friendly since all the albedo correction depends on the view direction. From what I can see, the standard way of handling it is computing the correction with both view or light direction and taking the minimum. However, that would mean that we have to do it inside the closure rather than baking it into the weight during SVM evaluation, which I’d like to avoid as long as we don’t need it.
Not yet, will be part of the nonphysical controls. Basically, there will be an additional multiplier for:
- Diffuse/SSS
- Dielectric reflection
- Metallic reflection
- Clearcoat reflection
- Transmission
- probably something else I’m not thinking of right now?
Advanced users can use these for some tricks, while just leaving them alone gives a physically-based result.
In general, regarding specular input - I’ve just posted a longer comment about this on T99447, but the summary is: I’ll probably go ahead with the parametrization that’s used by glTF, which means that in addition to the (physical) IOR input, there will be (nonphysical) inputs for specular tint (a multiplier on top of the IOR-derived F0, so like the Principled v1 specular input) and overall specular strength (which controls not only F0, but also grazing angles).
That way, if you really prefer this control style, you can continue to use it.
Also, by setting IOR to zero, this should make it possible to use “specular/glossy”-style textures as with the Eevee Specular BSDF node.
9 Likes
I don’t think that’s true. Blender is an outlier here. In most other software with PBR shader, material with the Base Color value of 0.0, Roughness of 0.5 and Metallic of 1.0 will result in pitch black material. In Blender, that is not the case:
It indeed seems like this falloff is just straight up hardcoded at some value in the old Principled though, which I am really not happy about. If i set the overall reflectance of my material (Base Color) to 0, I expect the material to not reflect any light whatsoever.
It also leads to an embarrassing scenario where the Specular value has effect even on fully metallic materials. So while the user expectation for a setup of simple metallic PBR material would be interdependence of these few parameters (Once metallic is set to 1.0):
- Base Color
- Roughness
With the metallic edge approach, the cobweb of interdependent parameters gets way more ugly:
- Base Color
- Edge Color
- Roughness
- Specular
- Metallic Falloff
My main problem is that the Principled material is going to become a long overcomplicated stick of a node. I am checking the software I am most experienced with, Blender aside - Houdini and UE4, and I just don’t see any metallic edge value in their implementation.
1 Like
This also confuses me. I assumed this effect is entirely related to metals. Glass is a dielectric. Even if it made a difference there, glass is not a metal so it should not have any effect on glass material in the first place.
I suspect that even the most notable difference it would ever make, compared to a node group setup would not be nearly as significant to warrant overcomplication of the BSDF node.
There are some people, who think that the reason their renders don’t look realistic is that the shading model is missing some advanced feature, like better reflectance lobe, and that once it’s in, their images will magically become photoreal. That is almost never the case. I’d bet that even in synthetic scenario, explicitly constructed just to showcase a difference between a custom nodegroup vs microfacet level metallic color falloff, the difference between the two would not result in overall improvement in the degree of photorealism. You’d just have two slightly different images, but you could hardly point at one or the other and say “yeah, this one looks much more like a photo”.
Mirrors are composite objects in real life.
They have glass as substrate and thin layer of silver oxide on one side. Silver is a metal, and it is responsible for creating reflection. Not the glass, which only provides structural stability and smooth surface.
6 Likes