Question Material.SetColor is not being applied immediately.

I have a procedurally created game object, which contains a MesheRender and its materials, the object is displayed correctly, however, the script that creates the object also changes the material emission, like this:

Code (CSharp):

1. for(int i = 0;i<count;i++) {
2.    material[i].SetColor("_EmissionColor",Color.white*value);
3. }

The problem is that the emission is set on the material but not actually applied until I click on the material's expand button:



So, why is that?

 

have you found a solution for this?

 

Hi!
Do you try enable keyword at the same time?

Code (CSharp):

1. material.EnableKeyword("_EMISSION");

Please note that the game build must include the variant "_EMISSION" after it is built or it won't work.

 

Yes, but that doesn't help

 

This might not help, but will at least remove one nightmare... those bloody strings!

static readonly int Emission = Shader.PropertyToID( "_EmissionColor" );

Then the call to change colour looks like this:

materials[i].SetColor( Emission, myNewColor );

Note, I'm being a complete pedant here, pointing out that arrays should have an s at the end of the name so you don't go mad thinking "is this a variable, a name or an array?" when looking at it later.

But, more importantly, there's something wrong with how the Materials Editor is "working" in 2022 (and possibly earlier versions, I've leapfrogged from 2019.LTS to 2022.LTS, so don't know what happened in between)...

... and sorry, I haven't posted this yet, but there's definitely a bug in how Emission is handled in the Material Editor, especially the luminance of HDR. I'm seeing that if I don't drag within the colour gradient, any direct adjustments to the Luminance of HDR are wrong in the Scene and Game view until that Editor input within the colour editor. This is a Mac issue, for me. But I think this might be a much more general problem, creating and extending to this issue that you're experiencing.

EDIT: additionally...

there's two possible culprits for all sorts of issues with Materials and Shaders in the Editor, stemming from the introduction of Material Variants, which seems half baked, as the very best possible interpretation of how this has been done and described...

...and this move towards ever more Editor Inspectors being coded with the UIToolkit nonsense. You can think this stuff is good, if you like, and progress if you think so, but I use AudioSources, a lot, and they've lost the ability to show the level meters during this "upgrade" to UIToolkit rendering of the inspectors, and performance of them has gotten worse, despite this loss of a realtime rendering of level meters.

There's something way too deep about the call stack of the UIToolkit system, and other issues that mean its a performance quagmire without, so far as I can see, any redeeming qualities.