[Bf-cycles] Roughness of the glossy shader

Fri Dec 23 17:50:55 CET 2016

It applies to the Glossy, Glass and Refractive Shader. The Diffuse Shader uses the Oren-Nayar model, not the Smith microfacet model, so it's a different concept of roughness.

Am 23.12.2016 um 16:50 schrieb Guillaume Soucis:
> Sorry to reawaken this older subject, but I was about to request a modification to the manual and I was wondering it this holds true for the roughness of all other shaders, e.g. glass and diffuse.
> 
> -----Original Message-----
> From: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org] On Behalf Of Guillaume Soucis
> Sent: December 6, 2016 11:52 AM
> To: Discussion list to assist Cycles render engine developers <bf-cycles at blender.org>
> Subject: Re: [Bf-cycles] Roughness of the glossy shader
> 
> 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
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
Url : http://lists.blender.org/pipermail/bf-cycles/attachments/20161223/24c9f305/attachment.pgp 