Material: a shader plus data

A material is not a picture, and it is not a coat of paint. It is a pair: a shader program, and the data plugged into it (numbers, colors, textures). Every engine works this way, and so does Blender. This lesson explains why code is kept apart from data, how instances inherit settings, and why a color changes instantly while one checkbox starts a compile. It also shows how the way materials are built affects the speed of a frame.

Why this matters

The last two lessons covered the shader, a function that runs for every pixel, and the surface properties that the function produces. In the editor, though, you mostly work with materials, not shaders. You assign a material to a mesh, tweak the color in an instance, duplicate a material for a new rock. The material is where a shader meets a particular asset.

Once you know how a material is built, a lot makes sense. You see why an asset pack ships one master material and seventy instances of it. You see why one checkbox can freeze the editor, and why “too many materials” slows a game down. And you can build a material library that a team will not drown in.

Further in the article

1. Code and data kept apart
2. What counts as data
3. Instances: inheriting from a parent
4. When the code changes: shader variants
5. What materials cost: draw calls
6. How to organize a material library
7. Where it breaks
8. Connections: the same idea in other fields
9. Key points
10. Test yourself