Master materials and instances

A master material is a parent material built with parameters and switches, so that many surfaces can share it. Each surface then gets a lightweight material instance that only changes values: textures, colours, tiling, feature toggles. Epic's documentation says an instance "inherits all of its attributes from the parent (or master) Material", and lets you change its look "without incurring an expensive recompilation" (Unreal Engine documentation: Instanced Materials in Unreal Engine).

Most professional environment projects work this way. Artists spend their days in instances; the master materials are built once, carefully, and changed rarely.

#Why work with masters and instances

• Speed. Changing a parameter on an instance updates immediately. Changing a material graph recompiles shaders.
• Consistency. Every brick wall, metal panel and concrete floor behaves the same way under light, because they share the same logic.
• Shared fixes. Harry Gray notes that edits to the master carry through to its instances (80 Level: Technical Tips for Environment Artists: Part 2). Fix a bug in the master and every instance gets the fix.
• Control. Only parameters are exposed; values that should not change stay constant (Unreal Engine documentation: Instanced Materials in Unreal Engine).
• Performance. Epic notes that instances can "improve Material performance" (Unreal Engine documentation: Instanced Materials in Unreal Engine); Gray credits them with "decreasing draw calls and instructions" (80 Level: Technical Tips for Environment Artists: Part 2).

#Parameters, static switches and instances in Unreal

#Parameters

A parameter is a node with a name that instances can override: scalar (one number), vector (a colour or four numbers), and texture parameters. Changing them in an instance does not recompile the shader (Unreal Engine documentation: Instanced Materials in Unreal Engine).

#Static switches

A static switch parameter turns a whole branch of the graph on or off. It is "applied at compile-time" (Unreal Engine documentation: Instanced Materials in Unreal Engine), so a disabled branch costs nothing at runtime. Static switches can "remove an entire branch of a material with no runtime cost" (Epic Developer Community Forums: Knowledge Base: Understanding Shader…).

Static switches have a cost: "A new Material is compiled for every combination of static parameters" used by instances (Unreal Engine documentation: Instanced Materials in Unreal Engine). Two switches give up to four shaders, ten switches up to 1,024, and that is before the engine multiplies them again for different mesh and lighting types. Epic advises you to minimise static parameters and the combinations actually used (Unreal Engine documentation: Instanced Materials in Unreal Engine). On AnswerHub, an answer about one huge FX material summarised the problem as "Exponential growth" (Unreal Engine AnswerHub: Some artists have built massively deep…).

Static switches cannot be changed from scripts at runtime (Unreal Engine documentation: Instanced Materials in Unreal Engine). For that, use dynamic parameters.

#Constant and dynamic instances

• Material Instance Constant: "Only calculated prior to runtime." What you make in the Content Browser (Unreal Engine documentation: Instanced Materials in Unreal Engine).
• Material Instance Dynamic (MID): "Can be calculated (and edited) at runtime", for example from Blueprints with Create Dynamic Material Instance (Unreal Engine documentation: Instanced Materials in Unreal Engine). Use it for gameplay effects like a wall that gets wet when it rains or a light panel that flickers.

#Material functions

Material Functions are "snippets of Material that you can save in packages and reuse across multiple Materials" (Unreal Engine documentation: Material Functions in Unreal Engine). Edits to a function "propagate throughout all Material networks which use it" (Unreal Engine documentation: Material Functions in Unreal Engine). Build your height blend, detail normal or wetness logic once as a function and use it in several masters.

The same propagation that makes functions useful also makes them expensive to change. The AnswerHub answer notes that editing a shared function forces every material using it to recompile (Unreal Engine AnswerHub: Some artists have built massively deep…).

#Naming

Epic recommends prefixing parent materials with M_ and instances with MI_ (Unreal Engine documentation: Instanced Materials in Unreal Engine). Add MF_ for material functions and be consistent; see naming conventions.

#Unity: shaders, materials and material variants

In Unity a shader (from Shader Graph or code) plays the role of the master logic, and materials are like instances: they set the shader's properties.

Material Variants add a hierarchy on top. A variant is a material "that inherits the properties of a parent material" (Unity Manual: Material Variants). You can "change a parent material and automatically propagate those changes down to all the child materials", override values in children, and "lock properties so child materials can't override them" (Unity Manual: Material Variants). That gives you something close to Unreal's master → instance → child instance chains.

Unity's equivalent of static switches are shader keywords, which create shader variants. Unity warns about "combinatorial explosion": ten on/off keywords produce 1,024 variants, which increases build time, file size, memory and loading time (Unity Manual: Shader variants). Its advice is to strip variants you do not need and use variants only for branches that would be costly at runtime (Unity Manual: Shader variants).

#Godot: shaders, ShaderMaterial and uniforms

In Godot, a Shader resource holds the logic, written in Godot's shading language or built as a visual shader, and a ShaderMaterial uses it (Godot Engine documentation: Using VisualShaders). Uniforms in the shader become the parameters: they "will appear as editable parameters in the material's inspector" (Godot Engine documentation: Shading language). Many ShaderMaterials can share one Shader, each with its own uniform values, which is the same pattern as master and instances.

Godot has two extra levels:

• Per-instance uniforms "are set on each GeometryInstance3D, rather than on each Material instance", so one material can vary per object. They do not support textures or arrays, with a practical maximum of 16 per shader (Godot Engine documentation: Shading language).
• Global uniforms are "global to all shaders in the entire project", useful for things like a world-wide wetness or snow value (Godot Engine documentation: Shading language).

#Organising a project's materials

A practical structure for an environment project:

1. A small set of masters, each with a clear job. For example: opaque environment surfaces, foliage, glass, decals, water, terrain.
2. Shared material functions for logic used in several masters: height blending, detail normals, wetness, macro variation.
3. A library of base instances for each surface type (red brick, clean concrete, painted steel), tuned once and reused.
4. Child instances for local variations (dirtier brick for one area), so the base library stays clean.
5. Folders and names that make sense to the whole team, for example Materials/Masters, Materials/Functions, Materials/Instances/Brick.

Write down what each master supports, and which switches are expected to be on, in the art bibles and style guides or a team wiki page.

#Keeping shader counts under control

• Only add a switch when the feature is expensive and many instances will not use it (detail normals, parallax, emissive). Cheap features can stay as parameters set to zero.
• Avoid switches nobody uses. Every combination used by at least one instance gets compiled (Unreal Engine documentation: Instanced Materials in Unreal Engine).
• Prefer a few combinations. Ten instances with the same switch settings share one permutation; ten with different settings make ten.
• Consider project-wide reductions. In Unreal, settings under Engine > Rendering > Shader Permutation Reduction can reduce shader permutations by "up to 50%", according to Tom Looman, depending on which lighting features a project uses (tomlooman.com: Optimizing Shader Compilation Settings &…).

#In different tools

#Further reading and watching