Okay, that makes sense.
The subsurface anisotropy seems to be isotropic in some cases, specifically when the light direction, rather than the camera direction would cause the most noticeable effect of anisotropy.
This was the test I’ve used where it’s clearly visible (small beam of light with a large incidence angle focused on a spot), the right image is how I’d expect it to look like:
Any relation to this?
There may be, but I don’t think that’s it and don’t know how to test it either apart from building it from source. At least in my simulation the result is still highly anisotropic when switching to isotropic after 9 bounces, though the appearance does change. In blender it’s completely isotropic for this test case, so I don’t think turning off this optimization should change much.
Also worth checking, but I’d noticed that the randmwalk scale is off by a factor of 10.
I had to set a value of 1 cm for a correct result of 10 cm.
This problem is not present in the skin variant.
Edit
I did a test with a keyhole and an infinite light.
RandomWalk, aniso 0
RandomWalk, aniso 0.9
Try putting the camera at normal incidence to the surface and the light spot at a grazing angle (like in my example). My guess is that the SSS is assumed as separable after the ray exits the surface (or some other simplifications not accounting for the light direction), this would explain why it looks like this in my setup.
There is an effect, but it’s very small, so it’s not impossible that this is a limitation of the method. I’ll try to compare with other renders if I have time.
For those who have deep knowledge of Cycles, am I correct that for dialectrics, Cycles doesn’t calculate relative IOR values at interface boundaries between two refractive objects? Meaning nested dialectrics? This seems to be the case in my testing, but I’m wanting to verify this if possible.
That’s correct it doesn’t, yet
Lukas Stockner had started a pul request to add Nested dialectric support in #118478 - WIP: Cycles: Implement volume stack priority and nested IOR support - blender - Blender Projects
However it isn’t in main yet.
4 Likes
Hello!
For people with knowledge of how Cycles work under the hood, am i wrong to think that currently, the Oren Nayar diffuse model being used in the Principled BSDF is based on this model by Yasuhiro Fujii?
If so are there any plans to implement this newer version of the Oren Nayar model based on this paper(proposed by some of the core authors of the OpenPBR standard)?
Thank you very much!
2 Likes
#123345 - Cycles: Switch to energy-preserving multiscattering Oren-Nayar BSDF - blender - Blender Projects
/* NOTE: This implements the improved Oren-Nayar model by Yasuhiro Fujii
* (https://mimosa-pudica.net/improved-oren-nayar.html), plus an
* energy-preserving multiscattering term based on the OpenPBR specification
* (https://academysoftwarefoundation.github.io/OpenPBR). */
2 Likes
Is there any timeline for when this nested dielectrics feature is planned to be released or integrated into a particular release?
Sorry, there’s no timeline for this.
Any timeline / concrete plans for thin (single surface) subsurface / glass?
This would be for surfaces like paper, leaves, or window panes.
4 Likes
Yes, exactly! What happened to the plan to add Thin Translucency to Principled? It’s been over 3 years 
It’s very frustrating, because 90% of Cycles materials can simply look like this:
But then there’s the remaining 10%, like Tree leaves, grass, paper, curtains, lamp shades, etc… that have to look like this (if they are supposed to be at least remotely correct and look right):
It’s such a PITA having to set up so many nodes for such frequent types of materials
8 Likes
Nothing happened to the plan. You have to remember different users want priority on different features, and you can only please one at a time. Current focus is on OSL Cameras which are seemingly very close to landing, and next is likely temporal denoising or nested IOR, since work has already gone into them. Features like this take time to implement, and what should be prioritized is subjective and different users will give you different answers.
7 Likes
- Lukas mentioned Thin translucency being the part of original Principled V2 design
- Having as niche feature as OSL camera before having Thin Translucency support in your main BSDF shader is like having operating system that has some cloud AI chatbot integration added before it even has UI file browser or application multitasking.
What should be prioritized being subjective is true only to some degree. Thin Translucency BSDF support and camera lens scripting are on very different levels of feature essentiality. It’s obvious that the amount of times Cycles users need to set up basic materials like foliage, paper, thing cloth, etc… is much, much larger than the amount of times they needed to script some custom obscure camera lens deformation.
8 Likes