[Bf-cycles] Some suggestions for nodes' interface revision in PBR times
matt.heimlich at gmail.com
Sun Dec 10 18:13:09 CET 2017
In practice, I have never in over a decade seen a texture map in production
that wasn't either linear or sRGB. And I don't think I've worked on or even
heard of a colleague that had worked on a production in five years or so
that hasn't adopted a completely linear workflow. Anecdotal, sure, but I
would be very interested in hearing of a pipeline that wasn't linear or
sRGB based in 2017.
On Dec 10, 2017 10:41 AM, "Troy Sobotka" <troy.sobotka at gmail.com> wrote:
> On Sun, Dec 10, 2017, 4:44 AM Adriano Oliveira <adriano.ufrb at gmail.com>
>> 1. COLOR SPACE. Today we need to open a drop down menu and pick color
>> (sRGB) / non-color (linear). In a PBR workflow, most of textures should be
>> linear (roughness, metallic, normal map, ambient occlusion etc) and only
>> albedo/base color is usually a sRGB bitmap. Therefore, we need to perform 2
>> clicks over the majority of textures we import... A better approach would
>> be to have just a check box for "[ ] sRGB", like in Unreal. If it is
>> checked (default), color space is gamma corrected, if it is not, it is
>> linear. Believe me, when you have a scene with dozens of PBR material, this
>> is a huge time saving.
> There are more colour spaces than sRGB, and many, many, many more transfer
> functions than the sRGB OETF.
> A check box cannot work. In the case of 2.8, if we manage to get a wide
> gamut reference space in, it becomes all the more necessary to have the
> group box.
> PS: Linear isn't a colour space.
> With respect,
> Bf-cycles mailing list
> Bf-cycles at blender.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-cycles