Using renderer.SetPropertyBlock(), we can apply our new values to the renderer. The MaterialPropertyBlock class is nothing more than a plain C# class that holds keys and values – the keys being the shader property names, and values whatever you wish them to be. SetColor() to write a shader property to a MaterialPropertyBlock. Let’s start with the second line first: we use. it hides the property from the material inspector to signify that it will be different per renderer. If you like, you can add in front of the attribute. Just create a new “Standard Surface Shader” from the “Create” menu in the project tab. If you’re not yet familiar with writing shaders, don’t fret – you don’t need to be.

First of all, you need to create a custom shader. Now that you have seen the value of this technique, it’s time to get to its implementation. You’ll also be happy to know that the memory usage is back to what is when using a single, stationary material, since all spheres are in fact using that same material. See how that thick band of highlighted green has become naught but a sliver. If that’s not a win, I don’t know what is. See that? 0.01 millis for the same effect. Say hello to MaterialPropertyBlocks! This is the profiler for the exact same scene, but using the aforementioned technique instead of renderer.material. Take a look at the CPU profiler when animating the 2500 materials using renderer.material:ġ5.19 of your precious millis are gone! I’m sure you would like to have them back so you can put them to good use elsewhere. Time to get to the meat of the issue: there is also a significant CPU overhead to uploading material changes to the GPU. 6 MB might not seem like much in a world of many gigabytes of memory, but it’s still a very sizable increase! However, I can feel your judgmental stares – surely you haven’t been reading this far for just a few megabytes more memory. Now, this is what the memory profiler looks like when using renderer.material:Īs expected, we have created 2500 materials. Of those 40 materials only one is for our spheres, the others are stuff like the default material for the plane, the skybox, etc. Notice how there’s just 40 materials in the scene, requiring a manageable 47 kB. This is the memory profiler when all spheres are using a single, stationary material: This means that there are potentially a lot of material copies out there, all eating memory. This copy is henceforth used for that renderer 1. Because of this, Unity creates a copy of a material when you access renderer.material for the first time (unless that renderer is already the only one using that material). The problem with this is that in order to change the color in the shader, Unity needs to tell the GPU that this object is going to be rendered differently, and the only way it can do so is by changing the material instance. Įasy, right? Just grab that color and animate away.

Unity 5 palette swap single object