- Home /
Share material on Instantiate()
I have a script that Instantiate
s a number of objects. When I look them up in the inspector their materials are called "MaterialName (Instance)" and these seem indeed separate instances of the material - if I tweak the parameters of the original material none of the instantiated objects' appearances change. Is it possible to make the Instantiated objects keep the original material instead?
I tried to set .sharedMaterial
after instantiate, like:
var clone : GameObject = Instantiate(proto);
clone.renderer.sharedMaterial = proto.renderer.material;
but it doesn't help. I guess I lack understanding of how .material
and .sharedMaterial
work.
May be the problem is due to my cloning logic (clouds[ ]
is an array of clones):
// clone the gameObject this script is connected to... var proto = Instantiate(gameObject); // make sure this script won't be called on clones proto.active = false; // make clones of the proto-clone for(var i=0; i<clouds.length; ++i) { clouds[i] = Instantiate(proto, transform.position, transform.rotation); clouds[i].transform.parent = transform; clouds[i].name = "Cloud LOD"+i; clouds[i].active = false;
// remove this script from the clones
Destroy(clouds[i].GetComponent(CloudController));
// [... further cloud setup ...]
}
// destroy the proto-clone
Destory(proto);
The reason it's like this is that I want the artists to be able to place and manipulate the prototypes in the editor, then have them spawn their clones at run-time. Among other things they may change the material used for this particular prototype (but also other things, like particle system parameters).
May be that's what I'm doing wrong and there is a better way?
here are screen shots of the inspector:
http://www.flickr.com/photos/artm/5299848182/ http://www.flickr.com/photos/artm/5299247737/
You can see that the second one (with clone selected) has a private instance of the material
Answer by Mike 3 · Dec 28, 2010 at 09:40 AM
The issue is that when you read .material from proto, it'll create an instance. I don't think the second line is necessary at all though - it should use the same sharedMateral as the original prefab. What you need to do is make sure that you're using .sharedMaterial to manipulate any colour or texture changes
Yes, the second line was there to try to understand what .shared$$anonymous$$aterial
means. I still don't get it though.
Is the editor using .shared$$anonymous$$aterial? Because that's what I want to do - to spawn a number of clones then tweak the material in game mode. But what happens is that each of the clones seems to have its own private instance of the material (at least from editor's point of view), while objects that I create manually all share a material (and change accordingly when I tweak a material in the editor in game mode)
The editor only manipulates .shared$$anonymous$$aterial - in your case, calling .material at all will cause a new instance to be created, which you don't want
I added a larger snippet of my cloning logic to the original question with the offending line removed. This still creates new instances of materials.
$$anonymous$$y bad. I was indeed using .material
elsewhere in the script, which is why they all got disconnected. Thanks for pointing me in the right direction.