PDA

View Full Version : SSS "oddity" in pBSDF material?



jwiede
07-05-2018, 04:56 PM
I'm having some odd difficulties generating a material that transmits light "through" itself using principled BSDF material. I have a 1m cube with camera less than a meter away, and distant light directly opposed (again, less than a meter away, non-normalized, set for 10lx). Even if I set SSS to 100%, and SSS distance to 5m, I see very little pink light penetrating the cube (it's a gray cube with fairly bright pink SSS color). Also, despite the light source being dead center, the light that does penetrate is actually stronger at the edges of the cube (?!) and less in the center of the cube -- another unexpected result, the center should be the shortest path from the light.

I'm attaching the scene, just turn on VPR in camera view. I've attached the resultant render as well. I'd like someone to try same thing on Win LW2018.0.5 so I can determine whether this is a Mac-specific or cross-plaform behavior.

142101

142100

jwiede
07-05-2018, 06:28 PM
BTW, just to eliminate a potential argument (w.r.t. how SSS distance affects sampling), with the scene above set the SSS distance to 0.1m and with VPR on slowly slide distance value out to and past 1.4m and you'll see the distribution remains similar regardless of SSS distance setting. Despite the shortest distance to the light being in the center of the cube, the edges remain brighter.

If the overall lack of brightness is just a characteristic of pBSDF limitations, so be it, but it still seems odd to me that brightness is edge-focused as opposed to center-focused in this case.

OFF
07-05-2018, 09:20 PM
Try to increase the Subsurface to 1000% etc. Or use Sigma material - more advanced SSS (imo) tool.

madno
07-05-2018, 10:41 PM
Try with area light?

142105

Distant light looks same like yours here on Win10.

jwiede
07-05-2018, 10:58 PM
Try to increase the Subsurface to 1000% etc. Or use Sigma material - more advanced SSS (imo) tool.

You know, it's interesting you mention Sigma. I'm playing with it, and getting odd results there too. I'll bring that to the table shortly, after I can confirm its oddity.

- - - Updated - - -


Try with area light?

142105

Fair enough, but still suggests there's a problem, at least with distant light & SSS.


Distant light looks same like yours here on Win10.

Okay, so then that indicates the behavior is cross-plaform. I expected as much, but thanks for the confirmation.

Tobian
07-06-2018, 05:38 AM
Sigma, PBSDF and Skin all use the same underlying code for SSS, just used in different ways, so the 'bug' would be expressed exactly the same in each. Sigma allows 1 sss shader per colour, with different aobsorption depths, multiplied by the colour, as opposed to 1 sss shader multiplied by the colour. Skin is 3 layered sss shaders, each with different absorption depths, multiplied by their respective colours.

I haven't had a chance to check this, but the SSS also has absorption, so increasing the scale much bigger than it needs to be will also increase that too. I find it slightly unintuitive, but that's how it 'works' - try setting the scale to be just 1m?

My experience of the new lights is they need to be much brighter than you think they should be. 10LX is not terribly bright, given the range and inverse squared falloff, and absorption. If you turn camera round to see the front of that object, what does it look like? is it dimly or brightly lit? I'd expect it to be nuclear lit to be shining all the way through a 1m thick object. If you want a weak and watery type of sss then sigma 2 is much more what you need, but that is *very* tricky to get working.

jwiede
07-06-2018, 05:59 PM
Sigma, PBSDF and Skin all use the same underlying code for SSS, just used in different ways, so the 'bug' would be expressed exactly the same in each. Sigma allows 1 sss shader per colour, with different aobsorption depths, multiplied by the colour, as opposed to 1 sss shader multiplied by the colour. Skin is 3 layered sss shaders, each with different absorption depths, multiplied by their respective colours.

Yep, Sigma shows similar (mis)behavior. Haven't tried Skin, but presume it shows similar.


I haven't had a chance to check this, but the SSS also has absorption, so increasing the scale much bigger than it needs to be will also increase that too. I find it slightly unintuitive, but that's how it 'works' - try setting the scale to be just 1m?

Actually, as noted, I tried sliding distance from 0.1m to >5m with VPR running, and the light level stayed fairly consistent, only the "width" of the edge highlighting significantly changed (from quite narrow at 0.1m to as shown from ~1m->5m).

There's something definitely "off" about how the SSS mechanism is interacting with distant lights. I'm putting it all together into a bug report, and letting Newtek sort it out, there's little further I can do there.


My experience of the new lights is they need to be much brighter than you think they should be. 10LX is not terribly bright, given the range and inverse squared falloff, and absorption. If you turn camera round to see the front of that object, what does it look like? is it dimly or brightly lit? I'd expect it to be nuclear lit to be shining all the way through a 1m thick object. If you want a weak and watery type of sss then sigma 2 is much more what you need, but that is *very* tricky to get working.

I'm decently familiar with "real-world-calibrated" lighting expectations, as I've been using other physically-calibrated engines' lights for years. And that said, I do see some indication that LW's "calibration" of light output might have greater than realistic falloff in general, at least in certain light types. The docs say the lights are calibrated in lumen-meters, but I'm seeing greater than expected falloff at a meter from some lights (distant being one) than I'd expect. I definitely need to do more testing there. Whether that's also impacting what's going on with SSS is anyone's guess, but I consider that a separate issue (and will file on it separately).

SSS having automatic & fixed absorption seems like a significant problem, IMO. If they're going to do that, then the absorption needs to be adjustable in all cases, otherwise getting realistic material behaviors will be difficult to impossible for SSS. Just giving distance control isn't enough if they're also computing absorption, for obvious reasons. However, absorption may explain the low light level penetrating the object, but it doesn't explain the highlighting at the edges versus the center, and that's the more serious problem I'm having now.

BTW, according to the docs, a 10lx LW2018 distant light should equate to a ~320% light using "old LW light values", so I'd expect it to be fairly bright at that distance. Though what I'm seeing is bright, it doesn't seem "320% bright" -- however, that also brings us back to potential than greater-than-real light falloff is impacting results there. There are just too many "open" variables in play here to conclusively determine whether the light's output is correct. I'm going to do some more controlled testing of the light output accuracy, but as a separate issue.

Until the odd edge-light/center-dark effect of the SSS effect is fixed for distant lights, the intensity issue is kind of moot for this case. The SSS-transmitted light clearly isn't being path-sampled in a realistic/appropriate manner, which also invalidates any expectations regarding the amount of transmitted light passing through.

Tobian
07-09-2018, 03:06 AM
Observationally (and perhaps not scientifically, this is just from use) if you have a light which was 100% it's automatically converted to ~pi (3.14) for an area light (different values for different types of lights too), this is because of the difference between the way the lights now work, where the light value is that of the 'surface' of the light, as opposed to a nominal range from the light, in terms of the falloff radius. So 100% is roughly 1lx, but that's the amount of light at the nominal range versus the surface of the light.

I tried to explain this as best i could in this video, if it's helpful https://www.youtube.com/watch?v=qeLLGPwiYOs

Normalise makes a big factor, and it's on by default. Because the system is based on lx (lux) it's luminous flux per m2, if it's not normalised, if you increase the area of the light by 2, then you will get 4x light in the scene. If you normalize the light, then as it increases in area, the lx is lowered commensurately (so to 0.25lx) so the net lx is still 1, this makes the lights work as they did before, where they have a fixed intensity regardless of area. Without normalization ticked then they work like standard luminaires, so a very small or very distant light needs to have an incredibly bright lx value to work. An example of this is if you use the distant light with an area over 0 (and this is handled as a special case), and untick normalise, you'll see the lighting drops to almost 0, that's because it now reflects the angular size of the light, if you increased the size to 90 degrees, then it will act like a dome light, but for a realistic sun, with an angular size of 0.52 degrees, you need over 10,000lx .

With regards to the SSS it's not multiscatter sampled, which is a shame, because it ignores internal objects, and secondary bounces, and it's not bi-directional path traced, as the render engine is not a path traced engine currently. You may well be right that there's not enough scattering, but it may just be the lack of secondary bounce which kills it a bit. to be fair to the system, you shouldn't objectively compare it to LW2015 and below as lights and shaders are quite wrong in a lot of cases. a better comparison would be another physically based diffusion based sss renderer, with similar lighting inputs. I suspect it's also generally a limitation of diffusion based scattering, where you will rarely get oberblown/white/glow through thin areas, in a realistic way. This is where newer volumetric scattering, such as random walk (available in Arnold and blender) gives much more real world simulation, and hopefully Antti can integrate them, when he gets a chance.