[Bf-cycles] Roughness of the glossy shader

Lukas Stockner lukas.stockner at freenet.de
Mon Dec 5 21:14:05 CET 2016


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
> 

-------------- 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/20161205/d24767f1/attachment.pgp 


More information about the Bf-cycles mailing list