Isn’t the SSS anisotropy using the Henyey Greenstein phase function?
HG uses -1 for backscatter to 0 for isotropic to 1 for forwardscattering.
In the code, calls to single_peaked_henyey_greenstein and henyey_greenstrein_sample are made either to get the PDF or new direction for scattering inside the subsurface_random_walk file.
So the answer is “almost certainly yes”
1 Like
Then values from -1 to 1 would make sence if someone want to use HG values from measurements.
Btw.I don’t know if the development of shader features is final.I have seen a video of a SSS shader with melanin absorption for a more realistic skin rendering.
I’m pretty sure the Henyey Greenstein functions support the full back to forward scattering range, because the same function is used for volumetric scattering and none of the math seems sign dependent . And the Henyey Greenstein functions seem to match those values. -1 is back scattering, 0 is isotropic scattering, and 1 being forward scattering.
And Subsurface Scattering Random Walk seems to follow this trend. -1 represents back scattering, 0 represents isotropic, 1 represents forward scattering.
However due to the use of Anisotropy in other equations inside the Subsurface Scattering Random Walk material, values outside the [0…0.9] range are not supported. So we can only use the Isotropic to mostly Forward scattering range.
1 Like
Not sure how usefull backscatter is with SSS.However with volume scattering it is.Example is simple ocean water.You need volume absorption for the water color,but volumetric backscatter for the tiny particles too.
Even in the tests with smaller radius (E.G. Scale 0.1m), as the Anisotropy is turned up, there seems to be an increase in uniform or back scattering which doesn’t make sense to me.
This seems to be the main cause for issues. Disabling this optimizations gives me results closer to what I would expect.
Note: This is basically the same scene as before. 2mx2mx2m cube with the same material setup as before. In this test I tested the 0.1m scale option. Removed the red and green lights, and increased the brightness of the white light to 1000 compared to 10 in the original test.
Ok, so that answers my question about the value ranges. 0 is isotropic. I’m assuming then that Random Walk (Skin) is the same?
Currently the UI allows a value of -1 and I tend to think that it shouldn’t allow that if the functionality isn’t there.
Yes, it seems to be the same.
There are soft limits to the UI. You can only drag the anisotropy between [0…1]. The only way to get -1 is to type it in. And for a long time, this approach seems to have been considered “enough” by the UI team.
To fix that, there would need to be hard limits in the UI (E.G. You type in -1, and it resets to 0). I might be missing something, but I don’t believe Blender supports this at the moment.
Ok, understood. Thanks.
Well you can set RGB values to higher than 1 as well, so don’t see why not just use that? 
To set a value to higher than 1 with a RGB picker, you need to manually type it in. With a Vector picker, values higher than one can be accessed by simply dragging the slider to the right until you get above 1.
This difference in user accessibility to values higher than 1.0 may be what Brecht was referring too.
He also said it could be used as absolute distances for each channel (presumably scatter depth), and then a texture map could be used in the scale to vary it. This sounds like a more flexible system than the RGB picker could easily allow for.
I don’t mean that it should be just an RGB picker like the base color, but instead Red, Green and Blue like in the RGB tab in the RGB color picker (but not as a factor clamped between 0 and 1). Like this:
To me this makes way more sense since it’s literally the radius of red, green and blue. The purple/blue input is a vector input which is about X, Y and Z and has nothing to do with color so I don’t see at all why that is even an option? Sure you can plug in whatever you want in those three channels, but for people not knowing this having a vector radius is not intuitive at all.
Also as a bonus this also looks better than having those three X, Y and Z floats in the middle of those input fields, so it matches the rest of all the fields and sliders in the Principle shader
6 Likes
I tend to agree with this. I don’t see a downside to labeling things clearly. For the longest time (years ago) I didn’t realize that’s what these 3 channels did.
5 Likes
I agree with this too, even if internally the input is still a vector, the labels should be Red, Green and Blue.
It is not enough. If any particular parameter in the application by default accepts a negative value, the slider needs to be able to be dragged to a negative value.
But with the Subsurface Anisotropy setting, although you can type in a negative number, it does nothing because Subsurface Anisotropy is clamped to [0…0.9]. So although the UI supports negative values, it’s a waste of space and will cause confusion to expose negative values to users by default because it does nothing.
A lot of other sliders on the Principled BSDF can also support values below their minimum and above their maximum, and it actually has an impact on the material (at least until a few weeks ago). But the Blender foundation does not expose the ability to drag values into these ranges by default because they are uncommon, unsupported, and/or physically incorrect. Exposing the full range of supported values by default for many of the Principled BSDF inputs will cause confusion, frustration, bug reports, and slow down peoples work flow that want to just experiment with material properties without having to worry about making sure everything they slider they drag is still a physically correct value.
1 Like
Not every artist’s goal is a physically correct result.
1 Like
Then those artists can type in physically incorrect values.
Note: I know I made a change recently which clamped a lot of values, reducing the ability to create many physically incorrect materials. I’m working on reverting some of this and only clamping what’s necessary.
2 Likes
I don’t want to derail the thread, but I’d like to give feedback about the Principled node UI. And in case also for other nodes UI enhancements, like nodegroups.
Is there any open thread about it?
