Thomas Mountainborn
Unity material animation using MaterialPropertyBlocks

The magic of Material Property Blocks

I’ve found MaterialProperyBlocks to be very useful, but there doesn’t seem to be a whole lot of information on them out there. I’ve decided to compile a quick post on what they do, and how best to use them – they’ll definitely become a new go-to tool in your Unity skill set, if you haven’t yet had the pleasure of becoming acquainted.

Let’s start with what they are used for. Say you have an object whose color you wish to animate. Scratch that – say you have 2500 objects whose color you wish to animate! More is always better!

animated spheres

The first thing that will most likely jump into your mind is the following:

Easy, right? Just grab that color and animate away. 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. 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). This copy is henceforth used for that renderer1.

This means that there are potentially a lot of material copies out there, all eating memory. This is the memory profiler when all spheres are using a single, stationary material:

Mem profiler

Notice how there’s just 40 materials in the scene, requiring a manageable 47 kB. Of those 40 materials only one is for our spheres, the others are stuff like the default material for the plane, the skybox, etc. Now, this is what the memory profiler looks like when using renderer.material:

Mem profiler leak

As expected, we have created 2500 materials. 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. Time to get to the meat of the issue: there is also a significant CPU overhead to uploading material changes to the GPU. Take a look at the CPU profiler when animating the 2500 materials using renderer.material:

set pass performance

15.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. Like, reaching 90 FPS, for instance. Say hello to MaterialPropertyBlocks! This is the profiler for the exact same scene, but using the aforementioned technique instead of renderer.material.

set passper renderer

See that? 0.01 millis for the same effect. If that’s not a win, I don’t know what is. See how that thick band of highlighted green has become naught but a sliver. 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.

Now that you have seen the value of this technique, it’s time to get to its implementation. First of all, you need to create a custom shader. If you’re not yet familiar with writing shaders, don’t fret – you don’t need to be. Just create a new “Standard Surface Shader” from the “Create” menu in the project tab. If you like, you can add [PerRendererData] in front of the attribute. This does the same as [HideInInspector], i.e. it hides the property from the material inspector to signify that it will be different per renderer.

Create a material using this shader in the editor, and apply it to a mesh. Notice how the Color property isn’t visible anymore in the material editor – per renderer properties can only be changed by script. Nothing is stopping you from creating scripts that execute in the editor and change per renderer material data, however. So, how do you change per renderer data in a script?

The important bit resides in Update() . Let’s start with the second line first: we use .SetColor() to write a shader property to a MaterialPropertyBlock. 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.

Using renderer.SetPropertyBlock(), we can apply our new values to the renderer. Job done! However, it is important to note that setting a property block on a renderer overwrites any other data set by property blocks on that renderer. If your new property block doesn’t hold a value that was present before, that value will be reset. This means that if there are multiple scripts affecting the renderer through material property blocks, they will be interfering with each other. Therefore, you should always get the current property values first, before making any new changes. That is exactly what the first line in Update() does. Don’t worry, this isn’t something that needs to be retrieved from the GPU, it’s just data residing in regular memory.

The final best practice is keeping a field reference to the MaterialPropertyBlock instance. This isn’t because we have to destroy it later as with an actual material (remember, MaterialPropertyBlock is a plain C# class), but just so we don’t create a new object on the heap every frame that needs to be garbage collected.

There you have it! MaterialPropertyBlocks, everybody. 15.19 milliseconds to 0.01. I hope you will find a good use for them! There is but one disappointing element to an otherwise great tool: even though all objects share the same material, MaterialPropertyBlocks break dynamic batching.

1 Be aware that this copy will not be destroyed automatically! You will have to do so yourself, lest your create a memory leak. 

Leave a Reply

7 Comment threads
4 Thread replies
Most reacted comment
Hottest comment thread
8 Comment authors
Russ MenapaceThomasAutumnAnilin ReddyNamaeMoNai Recent comment authors
newest oldest most voted
Notify of

Short and too the point. Thanks.



Thanks a lot for the explanation!

Pretty handy!


Amazing article!

Is it possible to set shader KeywordEnum by this way?


Since this page shows up when you google “unity MaterialPropertyBlock” I thought I’d mention that you can use .sharedMaterial instead of .material on the Renderer component to not make a new copy of the Material. GetComponent().sharedMaterial.color = Color.yellow; MaterialPropertyBlock is very useful but using it just to change the color of the shared Material is a bit overkill, at least if you call GetPropertyBlock() every Update. Also regarding footnote (1) about memory leaks, I’d be very surprised if Renderer doesn’t clean up its own instance of the copied Material upon its own destruction, so no you don’t have to worry… Read more »

Anilin Reddy

This is great, thanks!


Thank you!

It’s amazing how you can read one explanation (Unity Docs) and it seems like the most confusing, esoteric concept, and then you can read another explanation (yours) and it seems like the simplest thing in the world.

This is exactly what I needed for animating my car’s brake light materials.

Russ Menapace
Russ Menapace

Very helpful and well made. Thank you.