#Changing MaterialPropertyBlock has little to no effect

1 messages · Page 1 of 1 (latest)

candid jacinth
#

Hi, I'm just checking if somebody has any insight on this, because I'm almost ready to report this as a bug.

I'm trying to change the emission on a couple of renderers/material instances through property blocks. This exact same method works great in other scripts and for other renderers, but for some reason it doesn't work here.

On one renderer, the difference in emission intensity is minimal, and on the other, I see no noticeable change at all. It's possible that both renderers are changing in intensity, but the difference is just too small to see on one of them. The result is the same whether emissiveIntensityOn_LightRenderer is 100 or 10 000.

The first picture shows my renderers and how they should look (I manually changed the emission intensity in the material just to show).

I'm using this code to execute the change. (Same code as in the image) Through debugging I've verified that I've got the right renderers and materials.

void ChangeLightRenderer(bool on)
{
foreach (MeshRenderer renderer in renderers)
{
if (renderer == null) continue;
Debug.Log("RENDERER IS " + renderer.gameObject.name);
renderer.GetPropertyBlock(block_LightRenderer, materialIndex);

    if (renderer.materials.Length > 1) currentLightRendererColor = renderer.sharedMaterials[materialIndex].GetColor(emissiveColorID_LightRenderer);
    else currentLightRendererColor = renderer.sharedMaterial.GetColor(emissiveColorID_LightRenderer);

    if (on) hdr = currentLightRendererColor * emissiveIntensityOn_LightRenderer;
    else hdr = currentLightRendererColor * emissiveIntensityOff_LightRenderer;

    block_LightRenderer.SetVector(emissiveColorID_LightRenderer, new Vector4(hdr.r, hdr.g, hdr.b, hdr.a));

    renderer.SetPropertyBlock(block_LightRenderer, materialIndex);
}

}

I just don't understand. Does anybody have any insight, or are MaterialPropertyBlocks just broken or something?

image.png image.png image.png image.png
short oriole
candid jacinth
#

Okay, that's very useful information, thank you! So the reason other property block changes have worked may be because those materials don't have GPU Instancing enabled or something?

#

Although, looking at it now, the material of the lamp on the left doesn't have that enabled either.

#

Changing material property blocks works on a bunch of stuff I thought was SRP Batched, so maybe I've misunderstood how SRP batching works

short oriole
candid jacinth
#

All right, thank you. It seems very strange that it's worked so inconsistently so I'm not sure we're getting to the root of the problem here, but since my intention is to use SRP batching I'll just stick to switching out material instances instead. Thanks for the help!

short oriole
#

It's a potential issue that if you have a ridiculous number of meshes each with its uniquely changing material instance, keeping them in memory and updating them might get heavy

#

MPBs were lighter than material instances so they had kind of a competitive edge there
But now RSUVs are an SRP-native way to solve that problem

#

In my experience SRP batching and GPU instancing perform about the same with a huge number of identical meshes, but GPU instancing has overhead and only works for identical meshes so it's not that attractive in comparison

candid jacinth
#

Yeah, I wanted to avoid changing materials every time I turn the light on haha. But yeah, I'll have to learn RSUV's, can't believe I haven't heard of it until now. As far as I understand though, according to the docs, it's only slightly more performant than material instances? But maybe it's memory that's important here?

short oriole
# candid jacinth Yeah, I wanted to avoid changing materials every time I turn the light on haha. ...

I believe so
The amount of data in memory would be much smaller with RSUVs
But materials instances aren't that big, and plenty fast
You can and for convenience probably want to pool or otherwise manage them, rather than creating new ones
Though with the basic methods as soon as you modify a renderer's material properties it automatically makes it an instance and keeps that as the reference for further modification

#

So having a system to manage and smartly re-use them is just a bonus

candid jacinth
#

That makes sense. But wouldn't having pre-defined materials and switching renderer.sharedMaterial avoid creating a new instance alltogether?

floral topaz
#

That makes sense if you have a small number of colors

short oriole
#

Runtime instances can be shared and re-used by pooling

floral topaz
#

rather than 100 that are red, 100 that are blue, etc.

#

which is what happens if you just do renderer.material.color = Color.blue;

short oriole