#Material to bright when using property blocks?

1 messages · Page 1 of 1 (latest)

unique venture
#

👋 Hey everyone, I’ve got a pro-level question 😄

I'm working with a material that has the following settings:

Emission color: `RGB(191, 191, 191)` → so about 0.75 in 0–1 space
Intensity: 2

It looks perfectly fine in-game with these settings. (nice, emission and bloom)

Now here’s the problem:

We’re animating the emission color by writing to a MaterialPropertyBlock, lerping the color towards black (0) when the Lantern is turned off.
But for some reason, Unity seems to be changing the color to something like RGB(3, 3, 3) 🤔 This causes a very bright material at the start of the animation.

That makes no sense to me, I’d expect something like RGB(1.5, 1.5, 1.5) based on the initial values and intensity. (colors * intensity)

The result is that the material becomes way too bright, and I can’t figure out why.

✅ This version works fine (correct brightness/emission):
public void SetEmissionColor(Color color) { if (targetRenderer != null && targetRenderer.materials.Length > MaterialID) { Debug.Log($"SetEmissionColor {color}"); targetRenderer.materials[MaterialID].SetColor(EmissionColorID, color); } }

❌ But this version gives the unexpected bright result:
public void SetEmissionColor(Color color) { targetRenderer.GetPropertyBlock(_block, MaterialID); Debug.Log($"SetEmissionColor {color}"); _block.SetColor(EmissionColorID, color); targetRenderer.SetPropertyBlock(_block, MaterialID); }

My question:
Is Unity somehow not applying the emission intensity properly when using MaterialPropertyBlock?
Or am I missing something obvious?

Any help or ideas would be appreciated! 🙏

wary turtle
#

The docs for MaterialPropertyBlock.SetColor seem to mention it doesn't support setting HDR colors and to use SetVector instead.

Since you're using URP it might be better to stick to material instances anyway, since MPBs aren't supported by the SRP Batcher. Though might not make much difference given there's only a few lanterns.

unique venture
#

We are using Property Blocks also for the enemies (about 30 per wave) to change their transparency, color etc on shader basis. Would you say that’s better with instances too? We thought Proberty Blocks are better for performance reasons as instances.

wary turtle
unique venture
#

Good to know :/ I thought MPBs are always a good choice 😖

elfin crane
#

(I"m the one that gave you that advice -- it's good advice for BIRP as far as I know but I don't know about URP, BIRP has a lot of performance quirks.)

#

But in any case it's still an unusual bug, like, if the bug was "propblocks don't work in URP" we woulda known a long time ago; this is a very specific thing that's happening for (presumably) a very specific reason, and we can find out why.

unique venture
#

We decided to use material instacne for those lanterns now

#

And another problem was
Material.GetColor(EmissionColorID).linear

elfin crane
#

oh is it fixed then? Sorry I'm gettin to this a bit late

unique venture
#

that seemed to apply the intensity twice

#

dont worry ^^ UnityChanThumbsUp

elfin crane
#

If it's still happening, I think I should just pull your repo and look at the shader and code. Am I on it?

#

It's been a long time

unique venture
unique venture
wary turtle
#

yes, MPBs aren't compatible with the SRP Batcher, which is used by URP

unique venture
#

i always learned, that MPBs are the most performant, because they dont create an instance and all use the same drawcall

#

Is this incorrect?

unique venture
wary turtle
# unique venture i always learned, that MPBs are the most performant, because they dont create an...

MPBs on their own can still create multiple drawcalls afaik. (Though I don't remember if it's just if they don't share the same values or whether it needs to be the same MPB object). I think it's only when used in combination with GPU Instancing that it can combine the drawcalls (which the shader needs to support). But instancing also requires the same mesh so is somewhat limited.

With scriptable pipelines such as URP, they use the SRP Batcher which doesn't combine drawcalls but optimises the setup between them. It can work with any mesh and material provided it shares the same shader. But it doesn't support MPBs.

unique venture
wary turtle
quick zealot
unique venture
quick zealot
#

The main thing to focus on is to minimize having many different shaders and shader variants, but even if you do have them I believe it's still performs better than than multiple shaders without SRP batching

#

SRP batching does a lot of the work for you out of the box like that, so trying to optimize on top of it using the wrong methods will just be a hindrance

unique venture
#

No lighting + problocks

#

No lighting + no propblocks

#

But still 2023 batches?
Or is "set pass calls" the value i have to look at mostly?