Do Androids Dream of MaterialPropertyBlock?

Bob Levesh — Tue, 08 Sep 2026 06:31:17 +0000

I had been developing mobile games for over a decade and found myself adrift in the doldrums of game design. Every mechanic had been used to exhaustion and was no longer a differentiator in the marketplace; so for someone who came to mobile gaming on that magnificent wave of brutal, punishing gameplay exemplified by Flappy Bird, I was in a real jam. I had to look beyond game mechanics. Instead of focusing on those silly things every purist eschews, like retention, CPI, or even playtime, I decided it would probably be a good idea if I learned a bit more about graphics and use that knowledge to juice up my future games. I got the basics down then went looking for inspiration. I didn’t have to look for long. Led Zeppelin had Muddy Waters, Kant had Hume, and I had ‘Pistol Whip’. That VR game had me at the first shot. For those that have never seen it, you don’t need to play the game to appreciate the graphics, everything in the game changes color, and it does so multiple times, and certain objects shake, split apart, flash white, and turn back to ‘normal’. A very cool aesthetic in my opinion, and the kind of thing I wanted to ‘borrow’ for my new game idea.

I was making my game, as usual, using Unity game engine and I would be making it for mobile devices. The idea was that you would be in a aircraft chasing down and shooting at alien spaceships. The aliens would have a number displaying the number of hits needed to destroy them (nice of those aliens to give us that information) and it would be displayed on the ship (easy to keep track of the hit count without having to glance around the screen - this is the sort of thing we game developers think about). Whenever the alien was hit I wanted it to flash white and shake apart then reform and return back to it’s original color very similar to the behavior I saw in ‘Pistol Whip’. I also wanted the scenery to change color every time an alien spaceship was destroyed. There would be multiple alien ships per level. Well, I had a clear idea of the visuals and its dynamic behavior along with a great reference in ‘Pistol Whip’. It was time to get started.

My knowledge of graphics basics gave me the answer right away; I figured I’d have the graphics done before lunch. Here is a basic primer: anything that you can see in a game made with Unity is called a game object (let’s forget about scriptable objects for now) and they can be seen thanks to a property they all have called ‘material’. Materials also have properties, one of which is ‘color’. So in a script I would change every game object’s material’s color when it was time. All I needed was this code snippet: GetComponent<Renderer>().material.color = [my color of choice];. I was already thinking about lunch - maybe a double cheeseburger, I think I earned it. Sometimes game development can be a breeze. Unfortunately this wasn’t one of those times.

Unity’s Profiler is supposed to be every game developer’s friend. It’s the kind of friend that tells you what you need to hear and not what you want to hear. It was telling me my game’s frame rate was dropping below 20 frames per second (fps). Some friend. Of course, 60 fps is an easy standard to achieve and one I would always get with my other games. So why was it so low? And when would I be able to eat that double cheeseburger?

I found an answer to the former, and the answer to the latter would come once frame rate was fixed.

Looking at the Profiler I saw there were too many draw calls, too many instances of game object Materials. Batching was broken. It turned out using renderer.material (remember my awesome code snippet?) was forcing Unity to instantiate unique material copies on the heap. This forced the GPU to process every single mesh (the points in 3d space that define the object, like a skeleton) in its own separate draw call. I couldn’t be more inefficient if I tried. I had to find a solution. Think. Think.

If the problem was with the graphics then that’s where the solution would be, right? So I went in for a deep dive into game graphics and said bye-bye to that double cheeseburger - maybe some other day.

Ok, so I knew that using renderer.material was creating clones of each material, which broke batching and increased memory usage and slowed down the game’s fps. So I needed an alternative solution. Thankfully, the big brains at Unity HQ (wherever that is) had already thought of one. You guessed it. Enter MaterialPropertyBlock. The long and short of it is that the MaterialPropertyBlock (let’s call it MPB now that we’re on familiar terms) allows the developer to change properties, like color, on objects that share the same shader without creating clones and breaking batching. Caloo-Calay! Problem solved. Let’s use that MPB.

Documentation, once again, saved the day. Examples of code always clear up any confusions in implementation. For the MPB all I needed to do was create an MPB instance and then set the color, right? Well not so fast. Like the Trucker’s Hitch it looks easy but upon closer inspection your thoughts can’t follow the thread and you end up confusing yourself. Let’s make sure we don’t get tied up in any knots.

The renderer, remember we were directly changing its color earlier causing all this trouble in the first place, also has a method called ‘SetPropertyBlock’, and the method takes a MaterialPropertyBlock as an argument. Now we’re cooking!

MaterialPropertyBlock _mpb;

void Start()
{
    // ...setup and initializations 

    _mpb = new MaterialPropertyBlock();
}

void SetObjColor(Renderer targetRenderer, Color targetColor)
{
    // Renderers register with this script

    _mpb.SetColor("_Color", targetColor);
    targetRenderer.SetPropertyBlock(_mpb);
}

And like that, frame rate was back up to 60 fps!

Recap: I still use each game object’s renderer, remember I am giving game objects unique colors, but I no longer use renderer.material.color. Instead of that slow, cumbersome code I streamlined with the MaterialPropertyBlock. I create ONE instance of it and set its color, that’s something I can do continuously during gameplay - changing the color - and then apply that color to one object and NOT clone the material and NOT break batching. How simple. Sometimes game development really can be a breeze.

DEV Community: Bob Levesh

Do Androids Dream of MaterialPropertyBlock?