-----Original Message----- From: bf-cycles-bounces@blender.org [mailto:bf-cycles-bounces@blender.org] On Behalf Of Lukas Stockner Sent: December 23, 2016 11:51 AM To: Discussion list to assist Cycles render engine developers Subject: Re: [Bf-cycles] Roughness of the glossy shader 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@blender.org > [mailto:bf-cycles-bounces@blender.org] On Behalf Of Guillaume Soucis > Sent: December 6, 2016 11:52 AM > To: Discussion list to assist Cycles render engine developers > > 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@blender.org > [mailto:bf-cycles-bounces@blender.org] On Behalf Of Brecht Van Lommel > Sent: December 5, 2016 4:50 PM > To: Discussion list to assist Cycles render engine developers > > 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 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 >> >> 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! >>>> >>>> _______________________________________________