Page MenuHome

Material Attribute Node in Linear Space
Closed, ResolvedPublicBUG


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: rBfda791ab1241

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

  • 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.

Revisions and Commits

Event Timeline

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)) {

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 (jbakker) lowered the priority of this task from 90 to 50.Dec 5 2019, 8:30 AM
Clément Foucault (fclem) closed this task as Resolved.Jan 17 2020, 4:31 PM
Clément Foucault (fclem) claimed this task.
Clément Foucault (fclem) changed the subtype of this task from "Report" to "Bug".

This was resolved by 6eaf51ef3e5b.
Now we have to decide if we include this in 2.82.