转自 : http://thomasmountainborn.com/2016/05/25/materialpropertyblocks/

I’ve found MaterialProperyBlocks and their brother in arms, [PerRendererData], 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!

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

1GetComponent<Renderer>().material.color = ...

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:

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:

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:

15.19of 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 and [PerRendererData]! This is the profiler for the exact same scene, but using the aforementioned technique instead of renderer.material.

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. Then, just add [PerRendererData] in front of the _Color property. This attribute will tell Unity to compile the shader in such a way that the _Color property is to be set per renderer, instead of being shared for all renderers using the shader. This attribute can be added to all shader properties.

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.

Note that while it is possible to use renderer.SetPropertyBlock() on a shader property that does not have the [PerRendererData] keyword, Unity will simply create a new material instance behind your back.

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 and [PerRendererData], 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.