Cycles Roughness & the Principled BSDF are incompatible #51895

New Issue

Andy Davies · 2017-06-25T21:21:43+02:00

Andy Davies commented

2017-06-25 21:21:43 +02:00

Hey all,

I'm concerned with the naming convention of the "Roughness" parameter in the new principled BSDF as it is incompatible with the "Roughness" parameter in the default (current) Cycles shader.

Cycles currently uses academic surface roughness ([Rdq ]]) in the default shader, whereas the Principled BSDF from the [ https:*disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf | Disney paper uses "Perceptual Roughness", that is a re-parametrization of Rdq (roughness^2) for a more perceptually linear distribution of blur strength in order to make it easier to work with for artists.

This essentially means that a user will have to manually convert the values between the two standards if they wish to get identical results (assuming they know the conversion formula). A roughness value of 0.5 in Rdq is equivalent to 0.7071 in the Principled BSDF.

In the images below you can see the differences between the two standards in practice.

In the image above I have used decreasing roughness values of 1.0, 0.8, 0.6, 0.4, 0.2 & 0.0. True Surface Roughness (Rdq) (top) shows a perceptually non-linear decrease in roughness from left to right when using the same values per sphere as the perceptual roughness (bottom), which shows a more artist friendly perceptually linear distribution.

I suggest that the Roughness parameter in the new Principled BSDF is renamed to "Smoothness", which is simply perceptual roughness inverted (1-). Giving the parameter a new name removes the potential for diluting the two standards together, allows them to live side by side & also avoids the confusion and incompatibility between them. A roughness value of 0.5 in Rdq is equivalent to 0.7071 in the Principled BSDF & 0.2929 in Smoothness.

Frostbite engine (DICE), Unity, CryEngine & Knald use the Smoothness convention so it already has support within the industry. While Unreal Engine 4 uses the term "Roughness" for "Perceptual Roughness", it should be noted that they only have to support one roughness standard so the issue with diluting the two terms or confusing users is non-existent within the UE4 ecosystem.

Hey all, I'm concerned with the naming convention of the "Roughness" parameter in the new principled BSDF as it is incompatible with the "Roughness" parameter in the default (current) Cycles shader. Cycles currently uses academic surface roughness ([Rdq ]]) in the default shader, whereas the Principled BSDF from the [[ https:*disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf | Disney paper ](https:*en.wikipedia.org/wiki/Surface_roughness) uses "Perceptual Roughness", that is a re-parametrization of Rdq (roughness^2) for a more perceptually linear distribution of blur strength in order to make it easier to work with for artists. This essentially means that a user will have to manually convert the values between the two standards if they wish to get identical results (assuming they know the conversion formula). A roughness value of 0.5 in Rdq is equivalent to 0.7071 in the Principled BSDF. In the images below you can see the differences between the two standards in practice. ![perceptual_vs_rdq_plot.png](https://archive.blender.org/developer/F642591/perceptual_vs_rdq_plot.png) ![roughness_vs_roughness_squared.jpg](https://archive.blender.org/developer/F642593/roughness_vs_roughness_squared.jpg) In the image above I have used decreasing roughness values of 1.0, 0.8, 0.6, 0.4, 0.2 & 0.0. True Surface Roughness (Rdq) (top) shows a perceptually non-linear decrease in roughness from left to right when using the same values per sphere as the perceptual roughness (bottom), which shows a more artist friendly perceptually linear distribution. I suggest that the Roughness parameter in the new Principled BSDF is renamed to "Smoothness", which is simply perceptual roughness inverted (1-). Giving the parameter a new name removes the potential for diluting the two standards together, allows them to live side by side & also avoids the confusion and incompatibility between them. A roughness value of 0.5 in Rdq is equivalent to 0.7071 in the Principled BSDF & 0.2929 in Smoothness. Frostbite engine (DICE), Unity, CryEngine & Knald use the Smoothness convention so it already has support within the industry. While Unreal Engine 4 uses the term "Roughness" for "Perceptual Roughness", it should be noted that they only have to support one roughness standard so the issue with diluting the two terms or confusing users is non-existent within the UE4 ecosystem.

Andy Davies commented

2017-06-25 21:21:43 +02:00

Changed status to: 'Open'

Andy Davies commented

2017-06-25 21:21:43 +02:00

Added subscriber: @AndyDavies-3

Andy Davies changed title from ~~Cycles Roughness & the Prinicpled BSDF are incompatible~~ to Cycles Roughness & the Principled BSDF are incompatible

2017-06-25 21:22:08 +02:00

Brecht Van Lommel commented

2017-06-26 05:04:14 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2017-06-26 05:04:14 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2017-06-26 05:04:14 +02:00

Brecht Van Lommel self-assigned this 2017-06-26 05:04:14 +02:00

Brecht Van Lommel commented

2017-06-26 05:04:14 +02:00

My plan is to convert all the other nodes to squared roughness in Blender 2.8 (automatically inserting an extra conversion node if the parameter is linked). For Blender 2.79 there will be some inconsistency, but I don't think it's that big a deal.

If we introduce Smoothness users will have to find the conversion formula as well, there will be new terminology to learn, and it's not a naming typically used in physically based raytracers. So I think that would be the more disruptive change.

My plan is to convert all the other nodes to squared roughness in Blender 2.8 (automatically inserting an extra conversion node if the parameter is linked). For Blender 2.79 there will be some inconsistency, but I don't think it's that big a deal. If we introduce Smoothness users will have to find the conversion formula as well, there will be new terminology to learn, and it's not a naming typically used in physically based raytracers. So I think that would be the more disruptive change.

Brecht Van Lommel was unassigned by Andy Davies

2017-06-26 05:08:30 +02:00

Andy Davies commented

2017-06-26 05:08:30 +02:00

Changed status from 'Archived' to: 'Open'

Andy Davies reopened this issue

2017-06-26 05:08:30 +02:00

Aaron Carlisle commented

2017-06-26 05:31:31 +02:00

Changed status from 'Open' to: 'Archived'

Aaron Carlisle closed this issue

2017-06-26 05:31:31 +02:00

Aaron Carlisle self-assigned this 2017-06-26 05:31:31 +02:00

Andy Davies commented

2017-06-26 05:33:43 +02:00

Thanks for the reply, Brecht.

I think it would be a great shame to remove the Rdq if I'm honest. It's the defacto academic standard and shouldn't be changed simply for a shader that is principled only. Disney made a mistake using the term "Roughness" in the first place when there was a current standard already in place and should have been more mindful when naming it.

I also have disagree that changing the name to smoothness with force users to find a conversion formula, as for all intents and purposes it would be an entirely new parameter for which users would expect a difference. As such a conversion would be expected, but not forced as the issue was that we had 2 parameters with identical names but different results. Users would naturally assume that these parameters would be identical and there is where the problem arises.

Also by changing the current shader to squared roughness we have a problem with regression where all shaders using the current roughness will break. It's got to be much less disruptive to just change the name to smoothness and circumvent the issue entirely. There would be zero regression as current files would continue to work and the new shader would function independently.

Thanks for the reply, Brecht. I think it would be a great shame to remove the Rdq if I'm honest. It's the defacto academic standard and shouldn't be changed simply for a shader that is principled only. Disney made a mistake using the term "Roughness" in the first place when there was a current standard already in place and should have been more mindful when naming it. I also have disagree that changing the name to smoothness with force users to find a conversion formula, as for all intents and purposes it would be an entirely new parameter for which users would expect a difference. As such a conversion would be expected, but not forced as the issue was that we had 2 parameters with identical names but different results. Users would naturally assume that these parameters would be identical and there is where the problem arises. Also by changing the current shader to squared roughness we have a problem with regression where all shaders using the current roughness will break. It's got to be much less disruptive to just change the name to smoothness and circumvent the issue entirely. There would be zero regression as current files would continue to work and the new shader would function independently.

Andy Davies commented

2017-06-26 15:58:33 +02:00

@brecht

Is it possible to at least get a checkbox to use Rdq so users can pick their choice of roughness standard? I use Rdq on a regular basis in situations where roughness squared is not usable without conversion.
Thanks :)

@brecht Is it possible to at least get a checkbox to use Rdq so users can pick their choice of roughness standard? I use Rdq on a regular basis in situations where roughness squared is not usable without conversion. Thanks :)

Brecht Van Lommel commented

2017-06-26 22:37:30 +02:00

There isn't really one academic defined unit named roughness, it's all just convention in renderers. For example Arnold has used squared roughness for a long time, before Cycles even existed, and calls it roughness. We chose to make the Principled BSDF compatible with the Disney BRDF / UE4 / Substance Painter, and that comes with a specific naming and squaring.

In 2.8 we can convert old files in a backwards compatible way, I rather not add options since those kinds of legacy things accumulate.

There isn't really one academic defined unit named roughness, it's all just convention in renderers. For example Arnold has used squared roughness for a long time, before Cycles even existed, and calls it roughness. We chose to make the Principled BSDF compatible with the Disney BRDF / UE4 / Substance Painter, and that comes with a specific naming and squaring. In 2.8 we can convert old files in a backwards compatible way, I rather not add options since those kinds of legacy things accumulate.

Andy Davies commented

2017-06-27 03:13:11 +02:00

Thanks for the reply @brecht

I'm not sure that statement is entirely correct. Disney are using perceptual roughness, which is the square root of academic roughness. The whole reason [Beckmann ]] was introduced in the [ http:*inst.cs.berkeley.edu/~cs294-13/fa09/lectures/cookpaper.pdf | Cook-Torrance BRDF (page 6) , was to finally get a parameter that was based on something from physics/academics.

In all of the facet Slope distribution functions, the spread of the specular component depends on the root mean square (rms) slope m.

The fact that it's an academic parameter is why it was used in the first place when the Cook-Torrance model was introduced was so you could use physical measuring instruments to tune the BRDF.

Roughness is also mentioned frequently in the Beckmann book (BECKMANN, P. AND SPIZZICHINO, A. The Scattering of Electromagnetic Waves from Rough
Surfaces. MacMillan, New York, 1963, pp. 1-33, 70-98).

In addition we also have Rdq too.

Unfortunately perceptual roughness is pretty useless for scientific use without conversion, and it would be a great shame to see it dropped. Using the two types of roughness interchangeably without prior knowledge of the re-parametrization can make large differences to expected results, with problems such as the same roughness values mapping to different Specular Powers because of the different scales used becoming very evident. Unless we have a clear way for the user to know which type of roughness we are using then it is likely to cause problems.

Another thing worth mentioning is that as Beckmann uses academic roughness, is it reasonable that people would expect Beckmann within Blender to use academic roughness as it's stated in the paper?

Thanks for the reply @brecht I'm not sure that statement is entirely correct. Disney are using perceptual roughness, which is the square root of academic roughness. The whole reason [Beckmann ]] was introduced in the [[ http:*inst.cs.berkeley.edu/~cs294-13/fa09/lectures/cookpaper.pdf | Cook-Torrance BRDF (page 6) ](https:*en.wikipedia.org/wiki/Specular_highlight#Beckmann_distribution), was to finally get a parameter that was based on something from physics/academics. > In all of the facet Slope distribution functions, the spread of the specular component depends on the root mean square (rms) slope m. The fact that it's an academic parameter is why it was used in the first place when the Cook-Torrance model was introduced was so you could use physical measuring instruments to tune the BRDF. Roughness is also mentioned frequently in the Beckmann book (BECKMANN, P. AND SPIZZICHINO, A. The Scattering of Electromagnetic Waves from Rough Surfaces. MacMillan, New York, 1963, pp. 1-33, 70-98). In addition we also have [Rdq ](https://en.wikipedia.org/wiki/Surface_roughness) too. Unfortunately perceptual roughness is pretty useless for scientific use without conversion, and it would be a great shame to see it dropped. Using the two types of roughness interchangeably without prior knowledge of the re-parametrization can make large differences to expected results, with problems such as the same roughness values mapping to different Specular Powers because of the different scales used becoming very evident. Unless we have a clear way for the user to know which type of roughness we are using then it is likely to cause problems. Another thing worth mentioning is that as Beckmann uses academic roughness, is it reasonable that people would expect Beckmann within Blender to use academic roughness as it's stated in the paper?

Brecht Van Lommel commented

2017-06-27 22:57:36 +02:00

For the Beckmann case, squaring the roughness is like using the standard deviation instead of variance, it's just as physically based and the choice is a matter of convention. We will document the precise meaning of the roughness parameter when we change it. The 1% of users that care about this kind of thing should be smart enough not to assume a parameter corresponds to their best guess, and read the docs or code.

Daniele De Luca commented

2020-06-18 12:48:53 +02:00

Added subscriber: @Sparazza

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles Roughness & the Principled BSDF are incompatible #51895