[Bf-viewport] Unified Principled BSDF and Eevee PBR

[metalliandy]

Hi Clément,

Thanks for the reply. :)

On 27/06/2017 20:52, Clément FOUCAULT wrote:
> I also don't quite like the fact of removing the specular workflow. 
> But supporting it would add some usability issue (discussed previously 
> but maybe reopened for debate). Adding a Specular Node is just a 
> matter of usability / UI point of view. For now just supporting the 
> Principled BSDF should cover most of the use cases.
>
> About your statements on the Metallic workflow:
>
> >There are often texture interpolation issues where a dielectric and 
> metallic materials meet 
> (https://s3.amazonaws.com/docs.knaldtech.com/docuwiki/light_fringe_values_close.jpg 
> <https://s3.amazonaws.com/docs.knaldtech.com/docuwiki/light_fringe_values_close.jpg>)
> This will happen with both workflow. I understand that interpolation 
> of metallic values produces colored specular. In specular workflow it 
> won't.
> The real workaround on this is to use layered material that are 
> rendered separately, but this is too heavy for realtime games.
Sure, but with the specular workflow the interpolation outline you get 
is often close to black in colour so it's much less noticeable.
Yea, I agree that a linear blend between 2 materials is the ideal 
solution, but ofc, as you said, it's too heavy for games.
>
> >The metallic workflow is most often locked to 4% reflectivity for 
> dielectrics which gives less control to experienced artists.
> False, the metallic workflow (as per Unreal Implementation) is using 
> disney approach to give a specular input to tweak dielectrics specular 
> values. So you can go up to 8% with default range and beyond if you 
> want. Unfortunately it seems that Unity does not handle that. Still 
> Metallic material inputs can be exported as Specular inputs. The other 
> way in not easily doable.
>
> >Semi-conductors (Rust, Magnetite etc.) and crystalline objects (gem 
> stones etc.) cannot be rendered accurately as they require a 
> reflectivity of between 4-18%.
> Read previous point.

The default for most applications is 4% reflectivity because it's a good 
average value for most dielectric materials.
Yes, you can change the reflectivity from 4-8% too (though most people 
don't), but then you are still locked into that value. You cant one part 
of a mesh have a 4% value and the other having 8% if they are using the 
same texture/material.

Most engines that have the specular workflow as an option (i.e 
Unity/Toolbag ) allow you to specify the reflectivity within the texture 
itself so multiple values are possible within the same texture.

Unity also fully supports varying specular reflectivity. They even made 
separate charts to guide people :)
https://docs.unity3d.com/Manual/StandardShaderMaterialCharts.html

Also we can't just look at Unreal for a reference when looking at the 
broad game dev workflow. It's a very popular engine, but many studios 
use their own engines with their own "PBR" workflows and specifications.

> > It's much easier to use incorrect values within the metalness mask 
> when less experienced artists author content, which can break the 
> workflow.
> It's equally easy to put incorrect Specular values with specular 
> workflow ;) that's why they came up with the metallic one in the first 
> place.

Sure, I can see why people would think that to be true, but I have seen 
the opposite on many occasions. If artists don't correctly understand 
the workflow then it can be extremely problematic.
For the most part a the metalness map is binary and only allows grey 
values where a material transitions between a conductor & dielectric, 
but people often get confused and either add an incorrect grey value or 
don't compensate the albedo/base colour correctly.

Check out this thread for an example of what I mean. As game engines 
don't have a blend between 2 separate models the rules are much more 
ambiguous and the limitations more severe than offline rendering.

http://polycount.com/discussion/171689/pbr-the-problem-with-greyscale-metalness/p1

Also Specular is more often used by experienced artists who already 
understand the specific workflow requirements and thus make less mistakes.

>
> Regards.
>
> Clément
Cheers,

-Andy
>
> 2017-06-27 19:42 GMT+02:00 metalliandy <metalliandy666 at googlemail.com 
> <mailto:metalliandy666 at googlemail.com>>:
>
>     Hey all,
>
>     I wanted to pop in and mention that the Specular workflow is
>     absolutely not a legacy option within PBR game dev. It's a higher
>     quality alternative to the metalness workflow that is often used
>     when users are not constrained by memory limitations. This is why
>     it is supported in Unity & Toolbag etc.
>
>     https://docs.unity3d.com/Manual/StandardShaderMetallicVsSpecular.html
>     <https://docs.unity3d.com/Manual/StandardShaderMetallicVsSpecular.html>
>
>     The metalness workflow has some great positives ofc, but it also
>     has some serious limitations when it comes to accurately rendering
>     materials.
>
>     For example:
>
>       * There are often texture interpolation issues where a
>         dielectric and metallic materials meet
>         (https://s3.amazonaws.com/docs.knaldtech.com/docuwiki/light_fringe_values_close.jpg
>         <https://s3.amazonaws.com/docs.knaldtech.com/docuwiki/light_fringe_values_close.jpg>)
>       * The metallic workflow is most often locked to 4% reflectivity
>         for dielectrics which gives less control to experienced artists.
>       * Semi-conductors (Rust, Magnetite etc.) and crystalline objects
>         (gem stones etc.) cannot be rendered accurately as they
>         require a reflectivity of between 4-18%.
>       * It's much easier to use incorrect values within the metalness
>         mask when less experienced artists author content, which can
>         break the workflow.
>
>     As such I wouldn't recommend removing the specular workflow from
>     Blender as it would be severely limiting the usefulness of the
>     viewport for artists that do not use the metallic workflow.
>
>     Cheers,
>
>     -Andy
>
>
>     _______________________________________________
>     Bf-viewport mailing list
>     Bf-viewport at blender.org <mailto:Bf-viewport at blender.org>
>     https://lists.blender.org/mailman/listinfo/bf-viewport
>     <https://lists.blender.org/mailman/listinfo/bf-viewport>
>
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20170627/45a01656/attachment.htm