Hiya.
I have several GO objects in scene some contain multiple materials and others contain a single material. I am taking one of the GOs that has a single material and changing it’s main color. In doing this, I was expecting that all other GOs that share this same material would also change their color but that is not happening.
Is the behavior I am expecting correct?
Here is what the code looks like:
private var skinColorOptions : Color[] = [Color.red, Color.green, Color.black, Color.cyan, Color.magenta, Color.white, Color.yellow, Color.blue];
function setSkinColor ( dir : int ) {
var mat : Material = transform.Find("c_default").renderer.material;
if (dir == 1){
// Increment HairColor Counter
if (currentSkinColor + 1 <= skinColorOptions.length - 1){
currentSkinColor ++;
} else {
currentSkinColor = 0;
}
// Set Material Color
mat.color = skinColorOptions[currentSkinColor];
} else {
// Increment Shoe Counter
if (currentSkinColor - 1 >= 0){
currentSkinColor --;
} else {
currentSkinColor = skinColorOptions.length - 1;
}
// Set Shoe Mesh
mat.color = skinColorOptions[currentSkinColor];
}
}
Thanks in advance for the help!
– Clint
If you want change the material of all objects with the material I believe what you want is:
var mat : Material = transform.Find("c_default").renderer.sharedMaterial;
Changing the render.material only changes the material for that object.
HHHMMM,
I tried sharedMaterial and it is giving me the same result as material did.
Something I just tried in the editor which seems whacky but worked, is this. While my scene was running, I selected the “c_default” GO and in the Mesh Renderer I accessed the Material pulldown. From the pulldown, I selected the same material that was already there then hit my button to change color and “viola” it worked as I thought it would. Is this a bug or am I doing something wrong?
Thanks,
– Clint
Using sharedMaterial should work. Are you sure the objects share that particular materials? Just click one on the Renderer materials property to see the line connecting to where the material is in the project view and make sure this is actually the same as the other material.
Hiya Jo,
There is only 1 material with the name I am working with so I am positive. I also checked based on your suggestion, just in case. 
Whether I use sharedMaterial or material, the results are the same.
Any ideas?
Thanks,
– Clint
What does it say in the inspector. Run the simulation, after your operation was applied. Pause. Then view the different objects. What does the material color of the inspector show?
Maybe some other script instantiated the material by using renderer.material, thus it is not being shared anymore when your script tries to modify the sharedMaterial.
(renderer.material automatically unshares the material, so you can modify it per instance.)
Hey Jo,
Attached are some screenshots, hope they prove useful.
Thanks,
– Clint

Since they have a different color, it’s safe to assume they are different materials.
So now while you have paused the game after it has done it’s operation. Select the material in the renderer again to reveal where it is coming from.
If it cant reveal a reference, that means it isn’t in the project folder which means it got instantiated. Which is probably caused by some other script calling renderer.material, somewhere else in your code.
Ah, so the material attached to “c_default” when selected is not revealing anything in the editor, as usual, just like you suspected. 
I was accessing the color, just to store it higher up in the script that looked like it was causing the problem. I changed that reference and the accessor further down to sharedMaterials and it worked perfectly.
I am surprised that grabbing a reference to the color of the material would cause it to shift like that but great to know!
Thanks as always!
– Clint
Yeah. When purely reading the material properties you should always use sharedMaterial.
Optimally we would only instantiate the material when using renderer.material when the user actually modifies the data. But as you can imagine that is actually quite hard to do in a robust way - in some generic way tracking from where the material got grabbed and then instantiating the material on that renderer only.
Yup, I can totally see where that would be pretty difficult. Understanding the methodology, the implementation seems like a fair compromise and does make good sense. 
Thanks for the time and explanation!
– Clint