Cycles Disney Brdf

Cycles Disney Brdf by Pascal Schön
(Cycles Disney Bsdf?) :stuck_out_tongue:
Pascal had posted looking for testers. Thought I would start a thread for it. I was going to post on Cycles Disney Shader but, it looked like a different project.

Here is a test build = cycles_disney_brdf_Win7.x64-dbad91c
Jens has a linux build as well…

– PACKAGE-INFORMATION --Branch: cycles_disney_brdf
Revision: dbad91c
Submodules: locale 4c06104 addons 2155eb5 addons_contrib 98f1144
OS: GNU/Linux, Architecture: x86_64, GLIBC: 2.19
Builddate: Mi 20. Jul 11:46:49 UTC 2016
Filesize: 72398292 byte
Shasum: 5d535d7b5b6f12a6bf86c021fc530233586a1b0d
URL: http://www.jensverwiebe.de/Blender/blender_cycles_disney_brdf_linux64_latest.tar.xz

Cheers,
~Tung

Was about to open the same thread :smiley:

I tested quickly but i’m not super comfortable with ubershaders still.

Said that, couple of doubts popped out when playing:

  • SSS, there is only a float slider, no chance to tint the SSS differently from the surface, is that how is supposed to be used?
  • Glossy still has not its own IOR, just refraction, i can’t seem to create an arch glass-like with this. (i would need full transparency, refraction IOR at 1 and glossy IOR higher, to get reflections but not distortions from refractions…)

Anyways, many kudos to Pascal for his great job on it

downloaded it but i dont see a BRDF cycles node ?.
may i also sugest to have maybe a single brdf node with a pulldown for its type (as there are so many)


It’s actually called Disney Bsdf
When you add your nodes pick the disney shader


Definitely will try this! Cycles Disney Shader is a different project using some different PBR techniques to achieve the same result. If this solves Blender’s fresnel problem, i’ll definitely be using it.

Btw: the crashing mentioned in bf_cycles ml is scenedependent. I was able to use SSS just fine with a sphere etc., but for example not on the bmw27 chassis. Odd.

Jens

I am testing the Disney BSDF against the ONELVXE Principled Shader to see how they compare, and how a workstation handles both setups.
The scene is the same scene I used to render out the Material Previews for the ONELVXE Material Pipeline
I am using a Studio lighting setup with a Key, Fill, and Backlight, combined with Image Based Lighting to play up reflections and provide ambient lighting. Lastly, I’m using some basic film emulation, with a slight curve adjustment to increase contrast and shadows.

I believe in the efficacy of this method, as my purpose for testing these two shaders against each other is to see how the Disney BSDF holds up in a production environment. I have essentially run the ONELVXE Principled Shader through the ringer at this point, so I understand how it should behave in various lighting situations.

Preliminary results so far:

Disney BSDF is intuitive and easy to use sure. First thing though, is Subsurface is broken. I’m running a GTX 970 for my display, and the viewport ran right out of memory after 2 seconds of rendering.
I am still actively testing this to see if there is anything else I can do to alleviate this problem on my end. Not really sure.

Now for some comparison shots: Look at the stamps to identify the shader used
Global Values:

  • 256 Samples
  • 1024x1024
  • GPU (2x Nvidia GTX 970s)
  • Filter Glossy & Clamp Indirect = 1.00
  1. Dielectric Shading (0.000 Roughness)


  1. Metallic (0.025 Roughness)


It looks like in this scenario the Disney Shader may not be responding to roughness properly. Could be cause for concern in user is planning on implementing Roughness Maps

  1. Glass



There was a 16 second increase in render time using the Disney BSDF with Transparency vs using the ONELVXE Principled Glass BSDF

Subsurface was completely unusable on my machine. At a very basic level, this shader is pretty awesome. The artistic control is great! It’s physically accurate etc. For now, I’d say what needs to be fixed is SSS, maybe an additional slider to control Anisotropic Rotation. Lastly, you’re going to need to include Microsurface roughness models when they get merged to trunk. The roughness value on this doesn’t behave 100% predictably.

The next round of testing will be completed using textures from the library included in the Material Pipeline.

The issue with SSS has todo with manifold geometry. Not yet looked into it deeply, but guess thats not a biggie.
Aniso angle is indeed a must.

this new BSDF do not fix the phong terminator issue, does it?


i found the disney shader, i like it, works out nice on skins.
However there one thing that i like to sugest if possible.
I’m kinda overwhelmed with options, perhaps an idea to include that disney image of all the options inside the node.
So you get some feeling of what you control, by the many sliders.

So thats my only ‘con’ about it, on the ‘pro’ this reduces a lot of complex node systems.

Another thing is perhaps to create a new math node.
One that compares if smaller then < use value A as output, else value B as output.
Like we have the color mix node.
As combined with disney BRDF, we then could use some image texture and then depending on RGB channel value (for Example R is <0.5) set clearcoat to 1 else set it to 0.5

This can be made with a group setup, but while thinking about it, thought it is strange that it doesn’t exist as math node, since we have color-mix node but it doesn’t have a math equivalent. Such a node would be great for combining with this disney node.

Use a math node in “greater than” or “less than” mode on the color mix node’s factor input, should give the result you want.

@lich the terminator problem is a shortcoming of normal smoothing, there isn’t a obvious/simple solution to it.

I tried to fix the SSS crashes/hang. In all my testcases it was fine now, pls check over new build:

– PACKAGE-INFORMATION –
Branch: cycles_disney_brdf
Revision: 32d3485
Submodules: locale 4c06104 addons 3c23caa addons_contrib 9a6cdee
OS: GNU/Linux, Architecture: x86_64, GLIBC: 2.19
Builddate: Mi 20. Jul 22:19:16 UTC 2016
Filesize: 72437332 byte
Shasum: adbef698e87e32c0c4813f3cf533e967c62f4227
URL: http://www.jensverwiebe.de/Blender/blender_cycles_disney_brdf_linux64_latest.tar.xz

Jens

And then the color mix node is a value input node… the thing is, why not simply create a such a math node
So that if some value is below X, use val input A else use val input B; if we got it with colors allready why not with math node, it be more general coresponding

( i did say i can make it in a node group but its cumbersome, same would be possible to do a color mix node withoud that specific node… but its just needles complex to do so )

Just barely tested it, and have some comments:

  1. SSS (I’m assuming this is their fake quick version?) crashes on Suzanne, but already mentioned. Edit: Apparently already fixed :slight_smile:
  2. Shader output seems to ignore bounces. Getting leaked color influencing a diffuse material.
  3. Specular (dielectric only) output seems extremely noisy. Fully metallic it looks just about right.
  4. Roughness on diffuse has quite a different response than builtin Oren-Nayar. Better due no darkening, but the edge is brightened. Is this as per their design? However, this also leads to some really interesting effects as diffuse roughness grows really big - almost satin like.
  5. I have no idea what the sheen is supposed to do, and I’ve never played with the original, so in my own Cycles node version I just went with Velvet. I have to use extremely high (or low negative) inputs to get any response in a simple plane light setup. Is this as intended? Would it work better for extremely bright lightsources (like the sun, scaled HDRI etc)?
  6. Use a default tangent of some kind if the node socket is not plugged in, as sometimes it seems to obtain garbage data. It doesn’t crash, but it seems like bad practice (although I’m not a coder).
  7. I have no idea how to control anisotropic rotation on the tangent level (if even possible), so a rotation input would seem natural.
  8. I have mixed feelings including energy transmissive controls. I think I would prefer a separate “uber shader” (I hate that word :)) governing all there is to transmissive materials (translucency, fogginess, separate controls for reflection and refraction color and roughness).
  9. Tooltips are missing. Since some controls override others (specular for dielectrics only, no metallic reflectance control other than input color etc), general tooltips would be nice. I.e. how metallic is usually a binary input, with only very close to the extremes being valid inputs (i.e. metallicness of 0.5 is just wrong). What the tint controls are actually used to “simulate”.
  10. I know Disney use it, but I’m still very uncomfortable using IOR rather than F-0 for facing reflectivity. F-0 is much more intuitive to make maps for and increase usability for existing specular maps. Is it possible to have a toggle that flips between IOR value or F-0 value next to it?
  11. Is it possible to have some additional outputs and passthroughs as well? With a shader output only you can’t do additional treatments when using this shader. What I have in mind (although there could be others) are the output colors fed to diffuse and specular components, fresnel output, and both normals. These outputs could now be used to make an additional shader with a mask mix to make the surface appear partially wet (darkened diffuse with increased saturation, blend and change the glossy component, smoothen the normals and so on). Like this effect (floor partially wet) where the additional node outputs can be seen “behind” in this node image, ref these papers, that I did in my own PBR setup.

When complete this will be an awesome shader that can handle 90% of most people’s requirements.

You should check out the version I’ve made. It basically covers everything that you’ve mentioned in the post. For example, I use F-0 instead of raw IOR from the broken Fresnel node. You can purchase the shader setup and 100 PBR Materials to go along with it here. Those PBR materials should work the exact same way with this new Shader Pascal has developed. Send an email to [email protected] and I’ll provide you with a discount code if you’re interested in testing it.

No need a quote all that, a simple @CarlG would do :slight_smile: Anyhow, I never buy stuff, I make my own, and I did make my own approach to the disney shader as material nodes/group long time ago. But it became too complex, and I’m now more into simpler PBR approaches with far less controls, and specialist groups when I need them. But I’m sure they would still be more time consuming than a builtin Disney, and I might exhange for that. The main thing missing from it now are the F-0 approach (personal preference) and the passthrough outputs of critical data to create wet surfaces. I have no idea how to setup a wetting system unless I get access to the data that goes into the enclosure - mixing parallel shaders with varying input data just didn’t work for me (additional geometry that could get complex is not an option). That didn’t look wet, just broken :slight_smile:

@CarlG I could work on that for you if you like. For the F-0 approach, look at CynicatPro’s tutorials on Fresnel, they’re really good and he solves the F-0 problem in one fell swoop. In terms of creating wet surfaces, all you really need is a wetness map to blend between a glossy, mirror like shader for a wet surface and whatever other shader type you’re using. You can get more complicated than that and take it a step further and use some fake glass shading (for rendering speed) methods with an F-Zero’d fresnel curve so that straight on it appears see through like water, and at a grazing angle it looks wet and reflective. For your wetness map you could honestly just do vertex painting. Or duplicate your roughness map and texture paint on top of it in the UV/Image Editor and use that. Another thing you could look into is an opacity map. So you’d take your roughness map, and whatever areas you have determined you want to be wet, you can give them an alpha value, and combine that alpha value with a Light Path (ray legnth) node or whatever to determine how see through you want the wet area to be.