[Bf-cycles] Roughness of the glossy shader

Guillaume Soucis guill at live.de
Tue Dec 6 17:52:12 CET 2016

Thank you all! I will request a change to the manual for 2.7x specifying that a math node squaring the value should yield better results in most circumstances for roughness.

-----Original Message-----
From: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org] On Behalf Of Brecht Van Lommel
Sent: December 5, 2016 4:50 PM
To: Discussion list to assist Cycles render engine developers <bf-cycles at blender.org>
Subject: Re: [Bf-cycles] Roughness of the glossy shader

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_discovere
>> > d_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
Bf-cycles mailing list
Bf-cycles at blender.org

More information about the Bf-cycles mailing list