[Bf-cycles] Roughness of the glossy shader

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Dec 5 22:50:05 CET 2016

There's no particular reason the value is not squared, I just wasn't
aware other applications squared it. We can do this compatibility
breaking change in Blender 2.8.

On Mon, Dec 5, 2016 at 9:20 PM, Matthew Heimlich
<matt.heimlich at gmail.com> wrote:
> This is definitely a change to consider for some point in the future where
> we're planning on breaking BC for Cycles in an update. Roughness should,
> indeed, be squared based on most popular texturing apps and online sources.
> The notable exception here being Quixel Suite, as I was lucky enough to have
> a hand in their Cycles exporter and made sure this was taken care of
> automatically on export.
> On Mon, Dec 5, 2016 at 3:14 PM, Lukas Stockner <lukas.stockner at freenet.de>
> wrote:
>> Yes, this isn't related to color at all.
>> Most Microfacet models (at least Beckmann and GGX) have a roughness
>> parameter called alpha. In Cycles, the Roughness input of the Shader is used
>> directly as alpha. However, alpha^2 is perceptually more uniform, so many
>> render engines use that. I'm not exactly sure what the motivation for
>> Cycles' unsquared value was, but now that's how it works and we can't just
>> change it.
>> So, if your roughness is behaving funky, try plugging it twice into a
>> multiply node and you should be fine :)
>> Am 05.12.2016 um 17:29 schrieb Guillaume Soucis:
>> > I've come across what seems to be an issue with the roughness of the
>> > gloss shader and before submitting a bug report (or updating the manual,
>> > depending on what the intent was). I'm not sure if this is the best place,
>> > but I wanted to check with you guys to see if you could shed some light on
>> > what is going on before I report a bug or make a request to edit the manual.
>> >
>> > You can get an idea of the problem by reading this short exchange
>> > between RealPudding and JtheNinja on this Reddit thread:
>> > https://www.reddit.com/r/blender/comments/4n92r5/recently_discovered_how_to_make_cycles_more/d420ptu/
>> >
>> > After chatting for a while with troy_s on #blendercoders and doing
>> > numerous tests with different image formats and colour spaces, we came to
>> > the conclusion that this was not a gamma/colour space issue. He believes
>> > it's what JtheNinja suspected, namely that Cycles is interpreting roughness
>> > unsquared. Whether the correction factor is 2.0 or 2.2, however, doesn't
>> > change the fact that most roughness maps must be passed through a math node
>> > to render how artists expected them to, and this is not discussed anywhere
>> > in the manual.
>> >
>> > So my questions are as follows:
>> >
>> > 1 - Can someone confirm that this is indeed not a colour space problem
>> > but simply the fact that the value is read unsquared?
>> >
>> > 2 - What was the reason behind this implementation, if this is not a
>> > bug? There seems to be very few sources online saying  that roughness map
>> > should be squared when making them, but most roughness maps don't seem to
>> > be. Is it because Cycles is expecting a squared map? If so, shouldn't this
>> > be documented in the manual, given how much of an impact it has on the
>> > roughness, especially when using Cycles procedural textures as an input or
>> > simply when dragging the slider for a uniform value. There is very little
>> > difference in the 0.3-1.0 range, but an extreme jump in perceptual roughness
>> > in the 0-0.1 range.
>> >
>> > There seems to be a lot of confusion about the issue, which seems to be
>> > more visible recently with these tutorials coming out about how to use
>> > Cycles in a similar fashion to real-time PBR renderers (i.e. how to plug the
>> > maps of spec/rough or gloss/metal workflows). Since many artists come from
>> > these backgrounds and wonder why their roughness map is showing too rough,
>> > I'm sure many would appreciate if you could explain what does cycles expect
>> > and why. I'm not very knowledgeable about this myself so I might have
>> > confused things in my explanations, but with your help I could submit an
>> > update to the glossy shader node in the manual, letting people know of the
>> > behaviour of the input and how to correct unexpected values.
>> >
>> > Thanks!
>> >
>> > _______________________________________________
>> > Bf-cycles mailing list
>> > Bf-cycles at blender.org
>> > https://lists.blender.org/mailman/listinfo/bf-cycles
>> >
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles

More information about the Bf-cycles mailing list