Soft limits are there to inform the user about realistic/sensible ranges. Hard limits on the other hand can be much wider or non-existent
@lsscpp there are already two coexisting ways of compacting nodes, now we’ve got panels too, and you’re suggesting a fourth layer on top of all that. I see the reasoning, but shouldn’t this be handled by a more generalized socket-hiding/compacting method ?
May be one year later this variant for principled node UI become actual? 
I think what you’re suggesting here could be a solution to the ‘Hide Unconnected Sockets’ state not indicating to users that there are hidden parameters, which is currently a problem when people open someone elses file. Personally I’d go for a solution that indicates this without making the panel longer, though, such as a symbol in the header that has a more verbose tooltip that clarifies what it means.
Actually, we already have the rollup arrow in the header, a second one that only displays when there are hidden nodes makes sense to me. Like the conditional button that appears above the viewport when you’re in Local View.
But yes, this is an unrelated discussion, so I’d also welcome another thread.
Not only that, but the way it’s set up I think it’s sensible in the way that it sets the soft limit in a stepped way once you go past it. (if you type in 3, your new soft limit will be 5, so you still have room to drag the slider up, but if you put in 12 you can drag it as up as 20 before having to input another one manually…and you can always drag down to 0 again directly). To me, that’s a balanced compromise. Maybe you could set up a preference for “always be able to drag indefinitely” or a modifier key to overcome the soft limit when dragging…I personally don’t think it’s that sorely needed, but maybe I’m wrong.
Why is that clamped?
This means it is clamped in the shader itself.Makes not much sence to me,since you could choose what type of phase function you need.
I guess most artists useing 0 as default,I mean why restricting a function its allready there?
The manual has been updated now with the new parameters.
https://docs.blender.org/manual/en/4.0/render/shader_nodes/shader/principled.html
It also includes this explanation for Random Walk (Skin):
Random walk method optimized for skin rendering. The radius is automatically adjusted based on the color texture, and the subsurface entry direction uses a mix of diffuse and specular transmission with custom IOR. This tends to retain greater surface detail and color and matches measured skin more closely.
Node sockets don’t support hard limits currently, unlike other types of properties. This should get implemented at some point.
Because I don’t think the color is representative of what it’s doing. High values will show white, low values black, regardless of the color tint.
But, we should really add Red/Green/Blue labels to those buttons. We just haven’t gotten to it yet.
There is a lot of discussion about this earlier in this topic. For me the main reason to stick with panels is to have a single consistent mechanism for organizing properties throughout the user interface.
I’ve added it as a to do item in the Principled v2 issue to look at this again.
For the reason explained here:
Yes! This is exactly what I’m asking for, not a color picker field, so all good then 
The input should also by a color input and not a vector input, but this is not that important IMO and more like nitpicking.
Just as an fyi personally I really don’t use radius values higher than 1 here anyways, because if I want larger radius I just up the scale instead
Looks good. This is probably nit-picky of me, but I can’t help but notice the subsurface example images don’t apply the material to the base of the model the way it is in the other examples. I mostly mention it because I think the base might actually be the best part of the mesh to really demonstrate the subsurface scattering effect.
There needs to be some kind of connection indicator there. Otherwise - exactly, yes - it looks like you have a wire connected to perhaps another node that is inadvertently hidden under the BSDF. More than once I’ve started dragging the BSDF node around trying to rearrange things, looking for what the heck … oh, right… it’s actually that one.
Something is going on with conversion of 3.6 principled bsdf’s into the 4.0 version. If a 3.6 principled BSDF has an image texture going into Base Color, when you open into 4.0, a new Mix Color node is there with this same bitmap that then goes into Specular Tint. I can’t figure out why it would do that, but it’s necessary to delete these for the material to match 3.6.
If you save this file in 4.0, then open in 3,6, save again in 3.6, and reopen in 4.0, it begins adding a chain of these mix nodes, one going into Fac of the next.
Specular tint is an input to adjust the tint of the specular component of the “base” material.
Back in 3.6 and many older versions, it was a simple slider from [0…1]. 0 means leave the Specular Tint white. 1 means make the Specular Tint the same colour as the Base Color input. And inbetween values were mixes between the two.
In 4.0 with the new Principled BSDF, the Specular Tint input is a color input, meaning that you specify the tint color directly rather than mixing between white and the base color. This allows for more artistic control. However, to convert 3.6 files to 4.0 and have them look roughly the same, extra nodes need to be added to simulate that “mix between white and base colour” behaviour of previous versions of Blender. So a mix node is added that mixes between white and the base colour based on the Specular Tint value in the old file.
Based on my testing, everything is working as expected. But you have an issue when you open a 3.6 file in 4.0, save it, open it in 3.6 again, save it, then open it in 4.0 again.
Here’s what’s happening:
Agree with this, in all my tests I’ve had to delete that extra Mix node too because it changes how the original shader looks.
Maybe it should be fixed so this Mix node is only added if the specular tint was originally set to a value other than 0. Otherwise is messing up the original material
I think this mix node going into Spec Tint should only show up with the spec tint value of the incoming file is above 0. It’s just going to add confusion. Right now the Mix node Factor just sets itself to zero, which is the functional equivalent of not having a node there.
Additionally, all incoming materials aren’t treated the same, only materials with a node going into Base Color do this. As long as Spec Tint is zero, setting the Spec Tint to white seems sufficient. If it’s above zero, then yes the mix node is needed.
@JulianPerez and @Christopher_Tyler
Both of you have talked about how you need to delete the mix node to make the material look right. Just confirming, which mix node do you need to delete?
The single mix node? In 3.6 and/or 4.0?
Or the double mix node? (In both 3.6 and 4.0)
Double mix node is where I seem to have seen a problem. I’ve done some more tests with the single node with factor set to 0 and that seems ok.
But if the tint is unused in the old file (it’s white, with no connection) - why does 4.0 need to add a White Mix node, and connect it to a node earlier in the chain, which produces exactly the same result if i just delete this newly added mix node connection?
Like, in this case it’s literally adding complexity to a shader and doing nothing.
Thanks. This is expected. In the double mix node situation, you will need to delete at least one mix node to get the “correct” results.
This is simply because when you open a 3.6 file in 4.0, save it, then open it in 3.6 again, the reverse versioning isn’t applied (As explained earlier, reverse versioning may not exist due to the complexity of knowing if the reverse versioning should even be applied or not), resulting in the render now being different, and when you open the file back in 4.0, versioning is applied again, resulting in incorrect results.
The versioning to add mix nodes was setup by Weizhen Huang, all I can do is speculate on why they may of made certain decisions.
In the case that the Specular Tint is 0 in 3.6, and you have an input connected to the Base Color, then a mix node will be added when you open it in 4.0. This is the behaviour we see, and this is how the versioning code is setup, there are no bugs.
Should Blender be doing this? As in, should it be adding a mix node in the Specular Tint = 0 in 3.6 case? That’s up for debate. But I can speculate on why Weizhen may of done it this way:
Specular Tint = 0 in 3.6 is a simpler piece of code to write.Obviously the versioning code can be adjusted to achieve the result various people seem to want. (Don’t add a mix node if the specular tint is 0 in 3.6)
For materials without nodes connected to the Base Color (or Specular Tint) input, a mix node isn’t added. I assume this is because it makes things more complex than they need to be (E.G. In an ideal situation, it would add a RGB and a Mix node). Although it does introduce it’s own issues (E.G. If a person had a orange material, with a high specular tint, opened it in 4.0, then changed the base color to blue, they may not be able to figure out why the reflections are still orange).
I can understand the reasoning. But yes, if I have materials that made no use of specular or tint at all (which means a lot of my materials), then adding mix nodes to all of these - which does nothing - i don’t think necessarily “lets people know that the Specular tint now behaves differently because extra nodes were added”.
In my case, I saw this and wondered what was going on. Then I rendered a material from 3.6, pulled into photoshop. Opened that scene in 4.0, and rendered (with the extra nodes). Then deleted those nodes, and rendered.
Finally, had all 3 of those layers in Photoshop and started flipping between them, trying to see what the difference was - which, there was no difference. TLDR: my impression as a user wasn’t just “spec tint is different now”, but also “why is this even here?” Given that BSDF2 does require tweaks to maintain the old look, one might already be gun shy without having the extra mix nodes.
Due to people having semi-strong opinions about this matter, I’ve made a pull request to try and rectify the issue. It can be found here: #113893 - Versioning: Don't add unnecessary mix nodes to Specular Tint - blender - Blender Projects
The final decision on whether or not a special case should be added for when Specular Tint = 0 goes to the Blender/Cycles developers.
The versioning code to add the mix node is simple and “generic”. It adds a mix node if an input is connected to the Base Color, and/or the Specular Tint input. It doesn’t check what the actual values are.
Generic code like this is done for the sake of simplicity, reducing bugs, issues, and the possibility for uncaught edge cases.
If it ends up doing nothing useful in some situations, then that’s just how it is.
This was just speculation on one of the reasons Weizhen may of written the versioning code the way they did. It’s likely they didn’t even think about this.