Why don't my Material Function changes show in Material Instances?

Material Instances cache the compiled shader from their parent Material. When you edit a Material Function used by the parent, the parent does not always auto-recompile. Open the parent Material, make a trivial change (disconnect and reconnect a wire), and save. All instances will pick up the new function code on the next compile.

What happens if I rename a parameter in a Material Function?

Material Instances reference parameters by name. If you rename a parameter in a function, existing instances lose the link to the old name and revert to the default value. The parameter appears as a new entry in the instance with a default value, and the old override silently disappears.

What is the difference between MIC and MID in Unreal materials?

A Material Instance Constant (MIC) is an asset saved to disk. Its parameters are fixed at cook time and efficient at runtime. A Material Instance Dynamic (MID) is created at runtime in code or Blueprints, and its parameters can change every frame. MIDs do not persist across sessions. Changes to a Material Function affect MICs after recompile; MIDs pick them up on the next CreateDynamicMaterialInstance call.

Fix: Unreal Material Function Not Updating Instances

Quick answer: Open the parent Material, make a trivial edit (move a node), and save to force a recompile. Material Instances cache the parent’s compiled shader and do not auto-update when a Material Function used by the parent changes. Never rename exposed parameters — instances reference them by name.

You edit a Material Function to change how your water shader blends. Save. Check the Material Instance on the lake mesh. Nothing changed. The old blend is still there. You open the parent Material and the preview shows the new function working correctly. Close it, check the instance again — still old. The compiled shader is cached and nobody told the instances to recompile.

How Material Compilation Propagates

Unreal’s material system has three layers: Material Functions, parent Materials, and Material Instances. Changes propagate upward at compile time:

You edit a Material Function.
The parent Material that uses the function must recompile to incorporate the change.
Material Instances inherit the parent’s compiled shader. They recompile when the parent recompiles.

Step 2 does not always happen automatically. The editor marks the parent as dirty but may not recompile it until you open it, modify it, or explicitly trigger a recompile. Until then, instances use the stale cached shader.

The Fix

Option 1: Trivial edit on the parent.

Open the parent Material. Disconnect any wire and reconnect it (or move a node slightly). Save. The editor recompiles the material graph including all referenced functions. Every child instance picks up the new shader on the next render.

Option 2: Right-click Recompile.

In the Content Browser, right-click the parent Material and select Asset Actions → Recompile Material. This triggers a full recompile without opening the editor. Faster for bulk changes.

Option 3: Console command.

// Recompile all materials that reference a specific function
// Run in the editor console
recompileshaders changed

This recompiles every shader that the editor considers “changed” since the last compile. Heavier than a single-material recompile but catches everything.

The Parameter Rename Trap

Material Instances store parameter overrides by name. If the parent Material has a parameter called BaseColor_Tint and an instance overrides it to red, renaming the parameter in the function to Tint_Color breaks the link. The instance now has an orphaned override for BaseColor_Tint (which no longer exists) and a new default for Tint_Color.

The fix is to never rename parameters that have shipped to instances. If you must rename, add the new parameter alongside the old one, update all instances to use the new name, verify, and then remove the old one.

MIC vs. MID

Material Instance Constants (MICs) are assets on disk. They compile once and are efficient at runtime. Material Instance Dynamics (MIDs) are created at runtime via CreateDynamicMaterialInstance. MIDs inherit from their parent at creation time and do not need explicit recompilation — they pick up the current compiled state of the parent whenever they are created.

If your MID is showing stale function behavior, the bug is that you created it before the parent recompiled. Destroy and recreate the MID after the recompile, or ensure the recompile happens before any MID creation at game startup.

Verifying the Fix

Open a Material Instance that uses the function. Check the preview sphere. If the preview shows the new behavior, the instance is updated. If the preview is correct but the in-viewport mesh is wrong, the mesh component is caching a stale MID — trigger a material reassignment on the component.

“Material Functions are libraries. Materials are programs. Instances are compiled binaries. When you change the library, you have to relink the program and rebuild the binary. Unreal does not do this automatically in every case.”

Related Issues

For Material Instance parameter issues, see Unreal Material Instance not updating. For shader preview problems, see shader graph preview black screen (same concept, different engine). For Nanite mesh rendering, see Unreal Nanite mesh not rendering.

After editing any Material Function, always right-click the parent Material and hit Recompile. It takes two seconds and prevents a class of bugs that otherwise take twenty minutes to diagnose.