Cycles Disney Brdf

Any macos builds?

I have already setup a PBR approach similar to his. No problem doing it using nodes. But I suspect a complex node setup to be less efficient than a builtin shader that does the trick for me.

As for wetness, you seem to describe fully saturated wetness (not related to color saturation :)). That approach gave me a huge headache when simulating rising saturation from completely dry to fully saturated, then starting to form puddles. Similar to video in this wet surface approach. Masking is not the issue, the problem for me so far has been correctly tweaking the original materials output to make it appear different levels of wet on a single polygon:
Dry - original
Semi saturated - slightly darkened and more saturated, roughness pretty much unaffected.
Fully saturated - very darkened and more saturated, roughness starting to reduce.
Puddles forming - mix between fully saturated and water characteristics, but transition areas should be convincing.

Not sure what you mean with the ray length node. As this is supposed to work on a single flat polygon (with separate bumpmaps for the surface itself and fully saturated bumped puddles and everything in between), ray length wouldn’t give back anything useful afaik.

@CarlG if you’re referring to F-0, what’s interesting is that this Disney BSDF from Pascal actually solves for F-0 and is physically accurate. However, it’s slightly slower than the one I’ve built, as you can see from the test. In particular when rendering a glass, it was about 16 seconds slower, which is a significant difference.

@CarlG send me a quick mail at [email protected] and we can talk about your wetness problem :slight_smile:

New build is up after Jens commit to fix sss = cycles_disney_brdf_Win7.x64-32d3485

I think this is due to the remapping of the roughness value. In the Disney BRDF paper, they squared the roughness value for specular (and metallic) reflections.

Thanks for your testings and especially for Jens work on the SSS! I’ll have a look on the other stuff mentioned here. It may take some days (my master thesis is taking some time either :slight_smile: ), but I’ll work on it. :wink:

Downloaded it, but instead of (fake?) SSS crashes it just goes darker to full black for SSS=1. Am I missing something here?
For many parameters I don’t seem to get what the image in post #3 seem to reflect. Does that scene/HDRI (with settings) exist anywhere?

Edit: Roughness seem to be squared original. So Glossy Roughness of 0.09 seems to match Disney Roughness of 0.3. Does this translate correctly with Disneys own? Is there some code I can look at, as I’m getting curious as to how this is made (even if I probably can’t really read it :)).

Thats right. i only tried to fix the crasher. The functionality is in question. Thats only a scale factor i guess, so higher values goes darker to full black is expected. I must admit i did not look into the shadercode itself.

EDIT: turned out my “fix” was only working by disabling sss aspects, thus did not crash but also not computing sss.
I rolled it back and must find the true reason for the segfaulting.

Btw: SSS is not using the disney code but blender BSSRDF_BURLEY hardcoded, so when working, it should be pretty nice.



At the moment I don’t get where this segfault is caused because I only copied the code to prepare the BSSRDF_BURLEY closure. But I will look into it on monday. Currently my master thesis takes some extra time, so I can’t work on it every day. :wink:

Interesting that you find the node group faster than the hard coded shader.
That was my biggest curiosity.

I find node groups hard to teach to students when they don’t use it a lot which is why they often settle for simpler shaders networks or if the app offers it an uber shader.

Does anybody know if the fresnel code for this Disney shader is different and improves some of the cycles fresnel limitations?

@cekhuhnen 1 to 2 seconds faster isn’t really a big deal. However, 16 seconds improvement on my shader for glass is notable. If a 3rd party would like to test this because they believe my results may be biased, please go right ahead.

The uber shader is probably less intuitive to use than my shader because of the sliders. So for instance, you can basically break the laws of physics by making an object slightly diffuse, a little bit metallic, halfway transparent, with subsurface scattering. In my early experience with UberShader networks, this is what I ended up doing quite often. Sometimes it looked cool, but most of the time it looked bad, and was painfully slow to render.

With the shader I’ve created, actually shading something is as easy as determining which shading model you want to use beforehand. In most cases, the only reason you would have to mix shading models is for stuff like painted metal. With the built in uber shader, you have to plug in the right textures into the right slots and make sure that none of the other shaders are messing up the shading algorithm. In mine, you simply add a mix node and mix between dielectric and metallic, with the Surface metallic output node (greyscale socket) as factor input in the mix node.

Lastly, the uber shader does “seem” to solve the fresnel problem. However, I did not rigorously test this. Just based on analysis of the images, there was no noticeable physical difference in reflections and what not except for changing roughness values.

This shader has correct (per microfacet) fresnel?

First of, many thanks for the amount of work put into this, looks very interesting!

One question regarding SSS, in Pixar PxrDisney shader, you can assign a texture map for the base(surface) color, set the amount of subsurface, then a subsurface color for the underlying color, but I cant find it or the equivalent in Cycles Disney shader, can anyone help me figuring this out?

I think Pascal is a bit short with time cause of working on his master thesis, so some parts are not yet implemented. Sor far:

            /* subsurface */
            float3 albedo = baseColor;
            float3 subsurf_weight = baseColor * sc->weight * mix_weight * subsurface * diffuse_weight;
            float subsurf_sample_weight = fabsf(average(subsurf_weight));

            if (subsurf_sample_weight > CLOSURE_WEIGHT_CUTOFF && ccl_fetch(sd, num_closure) + 2 < MAX_CLOSURE) {
                /* radius * scale */
                float3 radius = make_float3(1.0f, 1.0f, 1.0f);
                /* sharpness */
                float sharpness = 0.0f;
                /* texture color blur */
                float texture_blur = 0.0f;

Which means:

  • SSS col is atm == base col
  • the radius is hardcoded atm. to 1 in each direction and cannot be scaled
  • sharpness and blur are not yet used and set to 0.0, can be introduced easily

As said the method is: bssrdf_setup(sc, (ClosureType)CLOSURE_BSSRDF_BURLEY_ID);
Thus you can expect the same features as Blender SSS following this route ( which again means
you can circumvent the missing SSS handling by just mixing with cycles SSS shader for now )


This branch has no special dependencies, just compile it like master.


Is Pascal Schön aware about this thread and testing that users are doing here?

Yes he knows, he’s been unable to post. Needs a moderator to allow posting. New account?

Got it, thanks for the info!