[Bf-cycles] Roughness of the glossy shader

Matthew Heimlich matt.heimlich at gmail.com
Mon Dec 5 21:20:57 CET 2016


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20161205/3f795c63/attachment.htm 


More information about the Bf-cycles mailing list