"Principled v2" feedback/discussion thread

[brecht]

There are multiple valid ways to use the subsurface radius and scale.

One is that you can use the float to set the scale at which you are working, and then treat the RGB values as a color, that you can texture if needed. Another is that you can set the RGB values to absolute distances, and then have a texture map for the float to vary the distance.

We could easily change the absolute unit to be on the RGB values instead of the float. It’s unclear to me which is more common or useful in practice.

[FreeMind]

I think the way it currently is as it should be (distance is set on one value, and RBG are scale values of that distance). It’s perfectly practical.
I just disagree with the labels.

[Christopher_Tyler]

I really like how SSS is now functioning. The only thing for me is that the ‘Scale’ and ‘Radius’ LABELS seem like they should be swapped. The 3 RGB ‘Radius’ values are scalar to what the ‘Scale’ value is, which is the absolute real world unit serving as the basis for the sss operation. Unless I am not understanding that correctly, but it’s how the function seems to behave.

[Alaska]

There was something I missed. Random Walk (Skin) will also automatically adjust the scattering radius based on the IOR and Albedo of the material. Random Walk doesn’t do this.

This is basically the same difference between Random Walk (Fixed Radius) and Random Walk. Where Random Walk (Fixed Radius) is similar to the new Random Walk, and the old Random Walk is similar to Random Walk (Skin) in this aspect.

[kram1032]

Since the scale is in actual units, if you change the scene scale, renders will appear different accordingly, yes.

Intuitively, it makes sense that, if your scene is supposed to represent a km² of land, you might want to work in a different scene scale than if it represents a single small room or even a slide under a microscope.

Diffuse and reflective materials, of course, behave precisely the same, as these are mere surface effects. But anything to do with volumes (including SSS) is gonna change quite drastically if you look at a tiny bit of it or something huge.

[FreeMind]

@kram1032

Since the scale is in actual units, if you change the scene scale, renders will appear different accordingly, yes.

The SSS Radius (Currently called “Scale”) scales proportionally with the scene scale, so the SSS appears the same.
I assume everything else that has to do with size, does so too.
Scene scale is just a multiplier for blender units, it does not, or should not affect renders at all.

[thinsoldier]

@FreeMind

Scene scale is just a multiplier for blender units, it does not, or should not affect renders at all.

vs

@kram1032

Since the scale is in actual units, if you change the scene scale, renders will appear different accordingly, yes.

So, who is correct?

---

90% of Blender scenes I’ve downloaded from Blendswap.com had, for example, chairs that were 15 feet tall. Ceilings that were 70 feet tall. I always dreamed there was a way to just change the scene units setting somehow and fix everything but I could never figure it out. I always had to meticulously scale every object down to real world size.

[SteffenD]

I was wondering about the same.
Just to confirm, we’re not talking about the Scene Units (or the Unit Scale), right?

This currently does nothing to shading or camera optics.

[brecht]

The units are purely a display option, that affects how values are shown in the interface.

But let’s please stay on topic.

[SteffenD]

Excuse me, I didn’t try to derail this thread.

[NRGSille]

Here is a little idea after testing the import behavior, it would be nice to have control over the socket group tab collapsing status via python API or if it would be implemented in node_shader_utils.py
The Idea is if a socket is connected, it tab will uncollapse automatically

[lsscpp]

I’d prefer to have the choice to keep tabs closed.
I think a solution could be to have a specific socket icon standing for “inside here something is connected”.
And just before the Off Topic Bell rings, I’ll leave here a quick mockup:

[slowk1d]

Yes!
Also Julien Kaspar on blender.chat said wires on collapsed panels currently look like there’s another node hidden behind it. Super nice mockup!

[NRGSille]

That is a good idea, but I meant the possibility to open/close the tab via Python script. My intention was to add a property to bpy.types.ShaderNodeBsdfPrincipled like bpy.types.ShaderNodeBsdfPrincipled.specular_collapsed=True

[Jvry]

Is plugging another node into the radius socket meant to be able to work in Eevee, or just Cycles? At the moment it seems you can only input the RGB values directly into the radius fields in Eevee, and I don’t know if it’s not currently implemented or if it’s a bug.

@brecht

One is that you can use the float to set the scale at which you are working, and then treat the RGB values as a color, that you can texture if needed. Another is that you can set the RGB values to absolute distances, and then have a texture map for the float to vary the distance.

So if you plug a vector scale node into the radius socket and a texture map into the scale float, you have the best of both methods? I’d say that’s a point in the current setup’s favour in terms of versatility.

[Christopher_Tyler]

I’ve been trying to find a proper definition of SSS Anisotropy. The Blender manual simply says, “Controls the directionality of subsurface scattering.”

I understand that it biases how the scattering occurs, in a ‘forward’ or ‘backward’ way, but I’m unsatisfied with this description and feel the need for something more precise.

Does the anisotropy cause the scattering to bias in the direction of the viewer? or toward (or away from) the point of the surface that the light strikes? Or toward or away from the light direction?

Does 0 = uniform unbiased scattering? Or does 0 means full forward scattering and 1 fully back scattering, and where 0.5 means unbiased scattering?

Clearly in these tests 0 creates a forward appearance in the scattering, I just am hoping for a more precise definition of what the algorithm is doing.

I’ve tried negative values because some systems use negative values to indicate a bias direction. The input in 4.0 allows for a negative value but it doesn’t seem to do anything which makes me think it should be clamped to avoid confusion.

[MC-Blender]

PROBLEM/IMPROVEMENT 1: METALLIC

SOLUTION METALIIC OPTION 1: Isnt it also better to add metallic as a new section because metallic override transmission and subsurface like a upper layer, and also Metal rim color F0 will be added in future of principled bsdf, so isnt it better to add a new collapsable panel named metallic after subsuface and after specular because specular can be used for diffuse for all previous base layers and metallic can be like a weighted coat on all of them to create half metal materials , it gives more logical sequence when we do it. it can be called as metallic specularity

Specularity Section
-0. IOR
-1. Specular IOR LEVEL
2. specular tint

Metallic Specularity Section

1. Metallic RIM F0 Tint
2. Anisotrphy
3. Anisotrophic Rotation
4. Tangent

SOLUTION ALTERNATİVE METALLIC OPTION 2: specular section can have extra options about metallic under specular parameters, and next option can be metallic amount and the other parameter will be F0 metallic Rim color , because anisotropy is already found in specular section and its related to metallic anisotropy so metallic slider will be also put there as this: and we can add IOR to here as well maybe

0. IOR
1. specular ior level
2. specular tint
   3.metallic weight
3. metallic rim color
4. metallic anisotrophy
5. metallic anisotrophic rotation
6. Tangent

So I think we should merge metallic fully into specular section and put specular below the COAT section because it override all the other things as a FRESNEL on bases such as diffuse base, refractive base and subsurface base or trasnlucent base

PROBLEM/IMPROVEMENT 2 : LOCATION OF TRANSMISSION SECTION: Also transmision should be put after subsurface because specular layer affect the transmision and u can still change the specular tint of glass materials, so specular contains all those bases below as we know from manually making a pbr materials
Refractive base + specular (glossy with fresnel) = transmission material/glass
Diffuse base + specular = dialectric material
general base overridden by metallic specular = metal
subsurface base = subsurface material
Translucent base = translucent dialectric material
So actually transmission should be treated as base type and , specular should be treated as coat on different surface types for more logical material formation

PROBLEM 3: ALPHA SECTION. I think we should seperate ALPHA into 2 , first alpha should be a alpha mask that effects the alpha of base, for example if a base color texture has transparent/alpha parts we should add alpha mask
so that alpha should be renamed to Alpha mask and then there should be another alpha slider to artistically tweak opacity of all material , similar to how we have 2 parameter for EMİSSION section

So according the the problems I mentioned above, for better logical layering should be like this in my opinion for understanding materials:

A. BASE LAYERS & CHANGING TYPE OF BASE
0. Base Properties that affect all type of materials: (contains base color, roughness and IOR(?)

1. Subsurface Base Altering (it changes the default diffuse base to subsurtface base)
2. Transluceny Base Altering (not thin sheet but just like a mix shader of translucent bsdf with a weight property to make simple translucent concrete materials or artistic things, )
3. Transmission base altering (it turn s base into refractice base and benefit from specular to mix with glossy to be glass, so it should not be put after specular section it should be before, and we can add thin sheet and volumetric absorbtion tint to this place as its planned for future , we might )

B. SPECULAR AND METALLIC LAYER TO ALL BASES AS MAIN COAT

5. Specularity ( It will further effect tweak the ior by ior level and base that are done below, so when u change tint of specular it change the specular tint of a transmissive material so transmission section should be below specularity. I think we shuld add the IOR to this section as well to make things more logical.)
6. Metallic (this can be a new section or added under specularity section to turn specular behavior to metallic specular and we can add extra featuers like METALLIC RIM color as its planned

C. EXTRA COAT LAYERS
7. Coat
8. Sheen

D. ARTISTIC TWEAK / ADDITIONAL FEATURES
9. Emission
10. Alpha/Opacity - I think we can make a new section and put ALPHA hear because it override all the layers below so its more logical and we can add a image texture socket to use a image as transparancy and then another parameter to further tweak opacity like we do in emission, so it will be easier to use without adding a node between texture and opacityyy. So it will make principled shader more versatile
So it will have alpha mask and alpha opacity as 2 parameters

I ll make a visual image to explain soon too.

EDIT: TYPO IN THE SCREENSHOT, TRANSMISSION ‘‘BEFORE’’ SPECULAR*** NOT ‘‘BELOW’’**

If we make it like this, princpled BSDF will be so robust and also logical in terms of how materials are formed (NOTE: IOR can stay in its old location if desired, it doesnt matter much, but other things are really needed to make it fully logical organization and versatile instead of being more randomly sequenced)

[MC-Blender]

Thank you for clarification, so If princpled V1 is not possible, is there any chance we at least add the OLD SHEEN MODEL AS OPTION TO NEW PRINCPLED so when we open old files it will use the old SHEEN MODEL and visual appereance will not be affected that much? Is it also a decision to not allow users to choose old non-microfiber sheen model in princpled shader? because I think it deserves to have ENUM for old sheen model in principled shader.

[Alaska]

@Christopher_Tyler

I understand that it biases how the scattering occurs, in a ‘forward’ or ‘backward’ way, but I’m unsatisfied with this description and feel the need for something more precise.

Does 0 = uniform unbiased scattering? Or does 0 means full forward scattering and 1 fully back scattering, and where 0.5 means unbiased scattering?

For questions like these, I turn to the code. But the math behind how the anisotropy impacts the scattering is too hard to follow for me. So you will probably get a better answer from someone else.

It is supposed to be a slider that adjusts the “directionalality of scattering”, with 0.0 supposed to be isotropic scattering, while 1.0 is full forward scattering. But I don’t seem to observe this behavior, or I misunderstand it.

Note: Isotropic scattering means the ray can scatter any direction, it doesn’t matter what the last direction was. And the more “forward scattering” the material, the more likely the ray is to continue in directions similar to the direction it was previously going.

@Christopher_Tyler

I’ve tried negative values because some systems use negative values to indicate a bias direction. The input in 4.0 allows for a negative value but it doesn’t seem to do anything which makes me think it should be clamped to avoid confusion.

The Subsurface Anisotropy is clamped to the [0…0.9] range. Values outside that range tend to render incorrectly, probably due to Subsurface scattering being an approximation of a real world effect.

[baoyu]

BTW, please make the parameters that actually being clamped by the engine also a HARD CLAMP on the UI side. It’s helpful as a hint for the user to understand the logic behind.