# How to change 100 GameObjects' color without pushing RAM to hard?

I'm developing a mobile game and one of the gamemodes has 100 gameobjects(basic cubes). And they all have same material. I need to know how to change their color one by one with script.

I'm not very good at programing, so only idea that i have for this situation is declaring 100 objects to var, and then change their color one by one.

But like a said it's a mobile game so i need to do it with simplest code so performance would be perfect.

• You can create an empty game object, call it something like cubes, add all your 100 cubes as child of our created cubes game object, grab reference to that cubes object in script and loop through every child objects and change their materials. However it may not be that performance efficient Apr 6 '19 at 12:36
• Do you want all the cubes to change to the same new colour, or might each cube get a different colour? RAM or var are not your limiting factors here - that's more likely to come from draw call overhead from breaking batching. Apr 6 '19 at 12:44
• On side note, i want to know why you have to change color runtime, is it game requirement?, can't we just change them in the inspector?, can you elaborate more on this. Apr 6 '19 at 12:46

Having 100 game objects with 100 behaviours each one running an own update function isn't actually that much, even on mobile. There might be some performance to gain by using the rather new Entity - Component - System architecture, but intuitively I am not that sure that this will even be necessary.

What could, however, become a bottleneck is if you update the color of each cube with GetComponent<Renderer>.material.color = new Color(r, g, b). Whenever you modify the material of a renderer, you actually create a completely new material in memory and assign that new material to this one object. This also breaks certain optimizations the rendering engine can do when multiple objects share the same material.

When you end up with 100 cubes which each have their very own material, then you might indeed run into performance problems.

So what should you do instead? That depends on what you actually want to do.

• If the number of colors you want is limited, then you could create a different material for each color and exchange those material assets.
• If all the cubes are supposed to change their color at the same time, you can access the .sharedMaterial of one of them to also change all the other (which of course won't work if you already broke the material sharing as described above)
• If you want to assign arbitrary colors to each cube, use renderer.SetPropertyBlock. This very useful method allows you to override just a few settings of a material on a per-renderer base without breaking the draw call optimization you got from sharing materials.

Example code:

MaterialPropertyBlock properties = new MaterialPropertyBlock();
properties.AddColor("_Color", new Color(r, g, b));
GetComponent<Renderer>().SetPropertyBlock(properties);

• Thank you so much for your explanation <3 Apr 6 '19 at 16:12

It's really hard to give advice with so little information about the language and what exactly you are trying to do. But still, there's some ideas you could like:

A comment here mentioned that you can use an empty object (you can call it CubeMaterialManager for example), and you can store the reference array in it.

If the cubes are created dynamically, you can add them to the array while they are created. If they aren't, you can use something along "find all objects of class", but that's usually not recommended.

You can most probably add a tag to the object and search by that. And if you know that they are located in some proximity, you can even use some kind of collision to find them (in UE4 it would be MultiSphereTrace).

You didn't mention if all the cubes will change to the same color. If they will all have a different color, the CubeMaterialManager can store another array with the new materials. Then just go through the loop.