Why does my Shader Graph Time node animate in editor but freeze in build?

The shader variant using _Time may have been stripped during build. Add the shader to Always Included Shaders, mark the renderer's material as Animate when using a feature like Animated Materials, and verify the variant collection includes the time-driven keyword.

How do I prevent Unity from stripping shader variants?

Open Project Settings > Graphics > Always Included Shaders and add your shader. Create a Shader Variant Collection that uses your shader at runtime, mark it for preload. Avoid keyword combinations the build does not see; otherwise URP/HDRP shader stripping removes them.

Why does the Time node return 0 in some materials?

In SRP, the Time node maps to the global _Time variable updated by the renderer. If the camera using the material has been disabled or the material is rendered through a Custom Pass that does not set time, the value reads 0. Confirm the camera is active and the render path supports global shader variables.

Fix: Unity Shader Graph Time Node Not Animating in Build

Quick answer: Time-driven Shader Graphs animate in the editor because the inspector continually redraws. In a build, if the shader variant or its keywords are stripped, the time uniform never reaches the GPU. Add the shader to Always Included Shaders, ship a Shader Variant Collection, and verify any cameras rendering the material are active.

Here is how to fix Unity Shader Graphs that animate via the Time node in editor but freeze on a still frame the moment you build the project. Your water surface ripples in Play mode and the asset preview, but in the standalone player it sits still. The shader compiled fine. The material exists. The time variable is just stuck at zero, or the variant that uses it never made it into the build.

The Symptom

A shader that uses the Time node (sine wave UV scroll, animated noise, color pulses) animates correctly when you press Play in the editor. After running Build And Run, the shader renders but does not animate. The static appearance matches what the editor showed at _Time = 0.

What Causes This

Shader stripping in URP/HDRP. SRP build stripping removes variants that the build process believes are unused. If your time-driven path lives in a keyword that the build never enabled, that variant is gone.

Shader not in Always Included Shaders. Materials only used at runtime (instantiated, not present in any scene) can be excluded from the build entirely. The shader is missing, the engine falls back to the error shader, which is unanimated.

Camera not rendering global time. Some custom render passes do not set _Time. Materials in those passes see zero.

Animation Mode disabled on UI materials. UGUI materials assigned to a CanvasRenderer require the canvas to redraw to push new shader uniforms. If the canvas is static (no dirty flag), time updates may not reach the material.

The Fix

Step 1: Add the shader to Always Included Shaders. Open Project Settings → Graphics → Always Included Shaders. Click the + and drag your time-using shader. This guarantees it survives stripping regardless of scene references.

Step 2: Build a Shader Variant Collection and warm it.

using UnityEngine;

public class VariantWarmer : MonoBehaviour
{
    [SerializeField] private ShaderVariantCollection collection;

    void Awake()
    {
        if (!collection.isWarmedUp) collection.WarmUp();
    }
}

Capture variants by enabling Save to Asset in Project Settings → Graphics → Shader Loading, run through your scenes once, and the collection records what was used.

Step 3: Verify the time uniform with a debug overlay. Add a Float property named _DebugTime in the shader and bind it from a script:

void Update()
{
    material.SetFloat("_DebugTime", Time.time);
}

If the override animates but Time node does not, the shader variant is the issue. If neither animates, the camera or render path is the issue.

Step 4: Disable shader keyword stripping for time-related keywords. In URP, open the URP Asset and enable Strict Shader Variant Matching. In HDRP, edit the shader stripping settings via HDRPShaderStripping.cs or use the project’s shader stripping config.

Step 5: Confirm the Sky/Camera renders normally. If your custom Render Feature uses a CommandBuffer that does not include built-in globals, set the time uniform manually:

var cmd = CommandBufferPool.Get("AnimatedPass");
cmd.SetGlobalVector("_Time", new Vector4(Time.time / 20f, Time.time, Time.time * 2f, Time.time * 3f));
context.ExecuteCommandBuffer(cmd);
CommandBufferPool.Release(cmd);

Unity’s built-in time vector packs _Time = (t/20, t, 2t, 3t). Match that layout if you replicate it manually.

UI Materials

For UGUI Image components, set Maskable off if not needed and ensure the Canvas’s Render Mode is Screen Space - Camera (rather than Overlay) when using cameras that drive global time. Force a redraw each frame on stuck UI materials:

graphic.SetMaterialDirty();   // Forces canvas update

Mobile Quirks

On Adreno GPUs, very large time values eventually lose precision and visible animations slow down or freeze. If your game has long sessions, modulo time with a large period in the shader: frac(_Time.y / 1000.0) * 1000.0. This keeps numerical precision high indefinitely.

Understanding the issue

Shader bugs manifest visually but trace to invisible state. Triage requires understanding the runtime context as much as the source.

The specific bug described above is the kind that surfaces during integration rather than unit testing. It depends on a combination of factors: the asset configuration, the runtime state, the platform's specific behavior. In isolation, each piece looks correct; in combination, the bug emerges. This is why thorough integration testing - playing the actual game in realistic conditions - catches things that automated tests miss.

Why this happens

The triage path for this kind of bug is long. The symptom appears in gameplay, but the cause is in a different system. The reporter describes the gameplay effect; the engineer has to translate that into a hypothesis about the underlying cause. Misdirection is common.

At the engine level, the behavior comes from a deliberate design decision in Unity. The engine team chose a particular trade-off - usually performance versus convenience, or generality versus specificity - and that trade-off has consequences when you push against it. Understanding the trade-off is what turns 'this bug is mysterious' into 'this bug is the expected consequence of this design'.

Verifying the fix

For shipping games, the safest verification is a staged rollout. Apply the fix to 1% of players for 24 hours; watch the affected metric; expand if green. Skipping the staged rollout means the verification is the entire player base, which is too high a stakes for most fixes.

Reproducibility is the prerequisite for verification. If you can't reliably reproduce the bug pre-fix, you can't reliably verify it post-fix. Spend time getting a clean reproduction before you write any fix code. The fix is fast once you understand the reproduction; the reproduction is the slow part.

Variations to watch for

Related bug classes often share the same root cause. If you find yourself fixing this issue, look for cousins: similar symptoms in adjacent systems, the same data flow but a different value, or the same fix pattern in another module. The catalog of 'we've seen this before' becomes valuable institutional knowledge.

Adjacent bugs often share a root cause. After fixing the case you've found, spend an hour searching the codebase for similar patterns. What's the same call with different arguments? The same data flow with a different entity type? The same lifecycle issue in a sibling system? Each match is a candidate for the same fix, or a related fix that prevents future bugs of the same class.

In production

Live games surface this bug class at scale. What's a rare edge case in development becomes a daily occurrence once you have a few thousand concurrent players. The class isn't 'this player has a unique setup'; it's 'one in N thousand sessions will trigger this exact combination'.

When triaging a similar issue in production, prioritize gathering data over hypothesizing causes. A player report describes a symptom; what you need is a build SHA, a session timestamp, and ideally a screen recording or session replay. With those, the bug becomes tractable. Without them, you're guessing at hypothetical reproductions that may not match what the player actually hit.

Performance considerations

If this issue manifests under high load (many actors, many particles, many network connections), profile the post-fix code path with realistic counts. The original cost was a bug; the new cost is real work, and real work has a budget.

Diagnostic approach

Diagnosing this class of bug benefits from a structured approach: confirm the symptom, isolate the variables, hypothesize the cause, and verify the hypothesis before writing fix code. Skipping the isolation step is the most common mistake; without it, fixes often address symptoms while the underlying cause continues to produce other variations.

For Unity-specific diagnostics, the editor's profiler is the canonical starting point. Capture a representative frame with the symptom present; compare against a frame without the symptom; the diff often points directly at the cause. If the symptom is non-deterministic, capture multiple frames and look for the pattern - the cause is usually a state transition or a specific input value rather than a continuous effect.

Tooling and ecosystem

Third-party plugins often provide better diagnostics for their own behavior than the engine does. If the affected code is in a plugin, check the plugin's documentation for debug modes, verbose logging, or inspector tools - these can save hours of investigation when they exist.

Within Unity, the relevant diagnostic surfaces include the standard frame debugger, memory profiler, and engine-specific debug overlays. Each one shows a different facet of what's happening. The frame debugger reveals draw call ordering and state transitions; the memory profiler shows allocation patterns; the debug overlay reveals per-system state. Bugs that resist one tool usually surrender to another - the trick is knowing which tool to reach for first.

Edge cases and pitfalls

Boundary conditions deserve specific testing attention. What happens when the input is zero, maximum, negative, or NaN? What happens at the start of a session vs hours in? What happens at the boundary between two systems handling the same data? These are where bugs hide and where regression tests are most valuable.

When writing a regression test for this fix, focus on the boundary conditions that surfaced the original bug. Tests that exercise the happy path catch obvious regressions; tests that exercise the boundary catch the subtler regressions that look like new bugs but are really the original returning. The latter are the tests that earn their keep over the long life of the project.

Team communication

Document the fix and its rationale in the commit message or attached engineering doc. Future engineers will encounter related issues; the rationale tells them whether your fix is reusable or specific to the case at hand. Without rationale, the fix gets reverted or copied incorrectly.

If this fix touches a system several engineers work in, a short writeup in the team's engineering channel helps. Not a full design doc - a paragraph explaining what was wrong, what's fixed, and what to watch for. Future engineers encountering similar symptoms will search for the fix; making it findable is a small investment that pays back later.

“Time is a global. If the build strips it, mocks it, or never sets it, the shader sits still. Always Included Shaders + Variant Collection covers most cases.”

Related Issues

For other shader build issues, see Shader Variant Collection Missing. For URP-specific render issues, see URP Shader Not Rendering in Build.

Always Included Shaders. Variant Collection. Manual _Time in custom passes. The animation moves again.