Page MenuHome

Cycles: random walk subsurface scattering.
ClosedPublic

Authored by Brecht Van Lommel (brecht) on Feb 8 2018, 5:30 PM.
Tags
None
Tokens
"Love" token, awarded by robocyte."Love" token, awarded by rbx775."100" token, awarded by craig_jones."Love" token, awarded by dingto."Yellow Medal" token, awarded by charlie.

Details

Summary

It is basically brute force volume scattering within the mesh, but part
of the SSS code for faster performance. The main difference with actual
volume scattering is that we assume the boundaries are diffuse and that
all lighting is coming through this boundary from outside the volume.

This gives much more accurate results for thin features and low density.
Some challenges remain however:

  • Significantly more noisy than BSSRDF. Adding Dwivedi sampling may help here, but it's unclear still how much it helps in real world cases.
  • Due to this being a volumetric method, geometry like eyes or mouth can darken the skin on the outside. We may be able to reduce this effect, or users can compensate for it by reducing the scattering radius in such areas.
  • Sharp corners are quite bright. This matches actual volume rendering and results in some other renderers, but maybe not so much real world objects.

Diff Detail

Repository
rB Blender

Event Timeline

Principled BSDF support for random walk subsurface scattering.

Christensen-BurleyRandom Walk
43.35s28.73s
14.52s10.87s
155.75s197.98s

Remaining optimizations and quality improvements could be committed separately I think, the current code should be in a pretty good state.

Are the test files same-time or same-time or same-noise?

Code can only give minor feedback so far. However, does it make split kernel with SSS and Burley distribution slower (similar to how bevel shader caused slowdown) ?

intern/cycles/kernel/closure/bssrdf.h
377

Multiline conditions are forcing brace to be n the next line.

intern/cycles/kernel/geom/geom_motion_triangle_intersect.h
251–259

Probably missing indentation? Or maybe phabricator just doesn't show changes here?

intern/cycles/kernel/kernel_subsurface.h
82

Brace on the next line.

With NVIDIA Titan Xp performance impact is ok, a little faster on 3 scenes, a little slower on 2 scenes. Testing an SSS scene it's about the same render time as well. I didn't test AMD yet.

SceneRelative render time
bmw27-0.71%
classroom-1.56%
fishy_cat0.3%
koro0.87%
pabellon-0.83%
Brecht Van Lommel (brecht) marked 3 inline comments as done.Feb 8 2018, 6:08 PM
Brecht Van Lommel (brecht) added inline comments.
intern/cycles/kernel/geom/geom_motion_triangle_intersect.h
251–259

It's just phabricator not showing the changes.

Brecht Van Lommel (brecht) marked an inline comment as done.EditedFeb 8 2018, 6:27 PM

Are the test files same-time or same-time or same-noise?

Same number of samples, I've added render times to the table. The radius has a big impact, dense volumes like skin render slower and with more noise as rays take longer to exit. I'm not really concerned about render time and noise now though, better to evaluate that properly after more optimizations are done. The main thing this commit brings is the ability to render some types of materials that you couldn't before, with an acceptable render time.

A couple more renders for fun:

Radius 0.1Radius 0.2Radius 0.3Radius 0.6Radius 1.0
Burley
Random Walk

@Brecht Van Lommel (brecht), to me main stopper would be verifying AMD OpenCL performance (we shouldn't cause measurable slowdown of SSS scenes when random walk is not used). Can run some tests here if you didn't do it yet. Do you see other things to be done/checked before putting this to master?

AMD RX 480 on Windows 10, seems to be fine as well. The numbers here are basically measurement noise.

SceneRelative render time
classroom-1.08%
koro0.43%
pabellon-0.11%
agent327 face-0.45%
agent327 face (branched)0.29%

I think it's ok to go to master now.

Can it have anisotropy not hardcoded to zero? In arnold it can be changed.

We may add anisotropy later. It's more complicated than just exposing the parameter since the adjusted mapping from albedo to scattering coefficients needs to be done as well, and I couldn't find published numbers for that. "Path Traced Subsurface Scattering using Anisotropic Phase Functions and Non-Exponential Free Flights" describes how Pixar did the fit, but gives no numbers.

This revision was not accepted when it landed; it landed in state Needs Review.Feb 9 2018, 8:12 PM
This revision was automatically updated to reflect the committed changes.

We may add anisotropy later. It's more complicated than just exposing the parameter since the adjusted mapping from albedo to scattering coefficients needs to be done as well, and I couldn't find published numbers for that. "Path Traced Subsurface Scattering using Anisotropic Phase Functions and Non-Exponential Free Flights" describes how Pixar did the fit, but gives no numbers.

Could also the base uses Oren Nayar instead of normal diffuse?

Could also the base uses Oren Nayar instead of normal diffuse?

In the Principled BSDF the roughness does affects both diffuse and SSS, with higher values going to Oren-Nayar. It's not in the Subsurface Scattering node though.

Could also the base uses Oren Nayar instead of normal diffuse?

In the Principled BSDF the roughness does affects both diffuse and SSS, with higher values going to Oren-Nayar. It's not in the Subsurface Scattering node though.

For the ulimate realism this would be beneficial.
http://www.yafaray.org/documentation/userguide/material#diffuserefl
Here are some oren nayer values. for skin its about 0,57 thats much more different than zero for the standard diffuse.

For the ulimate realism this would be beneficial.
http://www.yafaray.org/documentation/userguide/material#diffuserefl
Here are some oren nayer values. for skin its about 0,57 thats much more different than zero for the standard diffuse.

I didn't look at those papers in detail, but I'm not so sure about that. If you render skin with only an Oren-Nayar BRDF without SSS (or even specular?), then 0.57 might be the best fit. But that's not at all what we are doing here and it wouldn't work very well. The extra control might help, but plugging that number into a different material model doesn't seem so meaningful.