Material Attribute Node in Linear Space #72161

New Issue

Julien Kaspar · 2019-12-04T12:43:32+01:00

Julien Kaspar commented

2019-12-04 12:43:32 +01:00

System Information
Operating system: Linux-4.15.0-70-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: Quadro GP100/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.50

Blender Version
Broken: version: 2.82 (sub 3), branch: master, commit date: 2019-12-03 17:56, hash: blender/blender@fda791ab12

Short description of error
When loading materials in Eevee and using vertex color inputs via Attribute nodes, they load in linear color space until you click on certain parts of the interface Then they switch to sRGB and are displayed correctly.

Exact steps for others to reproduce the error
In this file I have a couple eyelashes & eyebrow objects. I couldn't relliably reproduce the bug with a newly created file.
The vertex colors are plugged into the base color of a Principled BSDF via an Attribute node
bug.blend

Open the file
Switch to Material Preview Mode
To fix the color, click on the vertex color layer "Col"in the properties editor

I haven't encountered this bug when using vertex color nodes in the materials. It only occurred when using vertex colors via attribute nodes.

**System Information** Operating system: Linux-4.15.0-70-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: Quadro GP100/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.50 **Blender Version** Broken: version: 2.82 (sub 3), branch: master, commit date: 2019-12-03 17:56, hash: `blender/blender@fda791ab12` **Short description of error** When loading materials in Eevee and using vertex color inputs via Attribute nodes, they load in linear color space until you click on certain parts of the interface Then they switch to sRGB and are displayed correctly. **Exact steps for others to reproduce the error** In this file I have a couple eyelashes & eyebrow objects. I couldn't relliably reproduce the bug with a newly created file. The vertex colors are plugged into the base color of a Principled BSDF via an Attribute node [bug.blend](https://archive.blender.org/developer/F8189273/bug.blend) - Open the file - Switch to Material Preview Mode - To fix the color, click on the vertex color layer "Col"in the properties editor ![bug.png](https://archive.blender.org/developer/F8189276/bug.png) I haven't encountered this bug when using vertex color nodes in the materials. It only occurred when using vertex colors via attribute nodes.

Julien Kaspar commented

2019-12-04 12:43:32 +01:00

Added subscriber: @JulienKaspar

Jeroen Bakker was assigned by Julien Kaspar

2019-12-04 12:45:55 +01:00

Jeroen Bakker commented

2019-12-04 13:53:24 +01:00

It seems that the GPU shader is not different. and just reads from the in variable.

The material has a var0 containing the data, and a boolean var0_is_srgb indicating of the color needs to be converted or not.

The later is set to 0 the first time and only set to 1 after it is updated.

The autonames are updated when the requested mesh data differs from the current one.

 if (!mesh_cd_layers_type_overlap(cache->cd_used, cd_needed)) {
    mesh_cd_extract_auto_layers_names_and_srgb(me,
                                               cache->cd_needed,
                                               &cache->auto_layer_names,
                                               &cache->auto_layer_is_srgb,
                                               &cache->auto_layer_len);
  }

fails as in this specific case the cd_used and cd_needed are the same.
I will add a drity flag in cd_used. this flag will be set when the surface batch is requested.

It seems that the GPU shader is not different. and just reads from the in variable. The material has a `var0` containing the data, and a boolean `var0_is_srgb` indicating of the color needs to be converted or not. The later is set to 0 the first time and only set to 1 after it is updated. The autonames are updated when the requested mesh data differs from the current one. ``` if (!mesh_cd_layers_type_overlap(cache->cd_used, cd_needed)) { mesh_cd_extract_auto_layers_names_and_srgb(me, cache->cd_needed, &cache->auto_layer_names, &cache->auto_layer_is_srgb, &cache->auto_layer_len); } ``` fails as in this specific case the `cd_used` and `cd_needed` are the same. I will add a drity flag in cd_used. this flag will be set when the surface batch is requested.

Jeroen Bakker was unassigned by Dalai Felinto

2019-12-23 13:41:21 +01:00

Dalai Felinto commented

2019-12-23 13:41:21 +01:00

Added subscriber: @Jeroen-Bakker