Non-Photorealistic Pipeline Tools Without the Template Voice

You've got your toon shader looking right: clean banding, that hand-painted edge, maybe a crosshatch pass that sits just on the right side of noisy. Then you hit play in 4K and the frame rate drops like a stone. It's not the shading math—it's the cache.

Shader cache hotspots in NPR stylization aren't the same as the ones in PBR pipelines. They hide in texture fetches, in the way you blend outline passes, in the sheer number of permutations your materials spawn. This guide is a field manual for finding them, fixing them, and knowing when not to bother.

Where NPR Hits the Cache Wall in Real Production

The 4K pixel load: why NPR shaders feel distinct

Most groups treat shader caching as a one-size-fits-all problem. That assumption dies the moment you render a toon character at 3840×2160 with a fat outline pass stacked on top. Photorealistic pipelines often get away with lazy caching as their shaders lean on shared material logic. NPR shaders don't. Every stylized effect — the stepped lighting, the halftone dithering, the hand-drawn wobble — adds its own branch of ALU work and texture fetches.

I have watched a lone cel-shaded frame double its draw window simply since the ramp texture was sampled per-pixel instead of per-vertex. The GPU starts thrashing on L2 cache, and suddenly your 4K output is stuttering at 24 fps when the same scene at 1080p ran smooth. Resolution multiplies the pressure linearly, but cache misses compound it. flawed order.

“The most expensive line of code you write is the one that silently evicts a thousand neighboring pixels.”

— A sterile processing lead, surgical services, field notes

— common remark among render engineers who have debugged NPR stalls

Toon ramps and lookup textures: the hidden hotspot

Your 1D toon ramp looks innocent — a tiny gradient strip, maybe 256 texels. But every pixel on screen samples it, and if the shader fetches it with a non-uniform coordinate, the texture unit can't coalesce the reads. That kills cache efficiency in a way that never shows up in a 1080p preview.

We fixed this in one project by pre-baking the ramp into a tiny 3D LUT, then letting the GPU handle interpolation. The adjustment cut frame phase by 11% on a 4K pass, but it also made the banding worse near specular edges. Trade-off: you trade cache friendliness for visual precision. The catch is you need to profile before you pick a side, given some engines handle 3D textures far worse than 1D ones.

Outline passes and depth buffers: memory traffic spikes

Outline passes are the other silent killer. Most NPR pipelines draw a back-face extruded mesh primary, then the shaded surface on top. That double draw doubles the vertex load, but the real spike comes from depth buffer access. Each pass reads and writes the depth target, and at 4K that's 33MB of traffic per frame per ping-pong. Run three outline layers — thick, medium, hairline — and you have six depth touches before any shading even starts.

That hurts. The GPU stalls not on computation but on memory bandwidth. A common fix is to fold the outline into the same render pass using geometry shaders, but I have seen groups revert that after a week as the shader permutation count exploded. What usually breaks primary is the editor's hot-reload latency, not the rendering itself.

Profile initial: tools that show the real spend

Most groups skip this part. They tweak LUT sizes, rearrange pass order, and pray. Real profiling tools — RenderDoc, NSight, or even the GPU counters in Unreal and Unity — will show you exactly where cache misses happen. Look at L2 hit rate per pass and texture fetch stalls per shader stage, not just total frame window.

The odd part is that beginners often misread these metrics. A low L2 hit rate on the outline pass might indicate the depth buffer is the problem, not your shader code. Profile opening, then optimize. Otherwise you will spend two days rewriting a toon ramp that was never the bottleneck.

That said, profiling at 4K requires the same hardware you ship on. Testing on a 1440p monitor with a workstation GPU hides the exact stalls your end users will feel. Run the real resolution, even if it means slower iterations.

Cache Misses vs. Shader Permutations: What Beginners Get faulty

Shader cache vs. texture cache: two unlike animals

The primary thing I see units conflate is memory pressure. Texture cache problems show up as pop-in, blurry mipmaps, or that dreaded moment where a 4K albedo sheet eats VRAM at the worst possible slot. Shader cache misses are quieter—they stall the GPU pipeline for a few milliseconds while the driver compiles or swaps programs. unlike failure modes. distinct fixes. faulty diagnosis and you spend a week optimizing the off thing.

Shader cache is about execution state. Texture cache is about bandwidth and storage. One holds compiled machine code; the other holds pixels. When an NPR pipeline stutters mid-scene, beginners point at the 8K contour map and say "cache it." That helps, sometimes. But the real culprit is often a shader permutation that never made it into the warm-up pass.

Why permutation count isn't the only metric

I have sat through reviews where someone presents a table: "We have 4,200 shader permutations, so we need a bigger cache." That number is meaningless lacking context. What matters is how many permutations in practice execute per frame, and how often they adjustment between frames. A scene with 40 distinct materials but stable draw calls will cache fine. A scene with 12 materials that each swap between three stylization variants per object—outline width, hatching density, color quantization thresholds—creates a permutation storm that no LRU cache can tame.

The catch is that NPR tools tend to generate variants at runtime. You tweak a threshold slider, and suddenly the shader key changes for every mesh using that material. The cache sees a new key, compiles, stalls. The fix isn't a bigger cache; it's batching draw calls by shader key or precompiling the variant space you in fact expose to artists.

Permutation count only matters when the working set exceeds the cache's capacity. Most production scenes don't. What kills you is churn—keys changing every frame given someone animated a stylization parameter that isn't binned.

Odd bit about animation: the dull step fails primary.

Odd bit about animation: the dull step fails primary.

The myth of the 'optimized' uber-shader

Uber-shaders sound like the answer: one program, all features, branch on uniforms. No permutation explosion. But here's the trade-off—you trade compile window for register pressure and divergent branches. The GPU executes both sides of a branch if the warp is split. Your gorgeous toon outline branch runs alongside the watercolor wash branch, and now every pixel costs double.

The odd part is, some groups revert to monolithic shaders as they read one talk about bound shader states and over-correct. The actual win is a tight set of specialized programs—maybe five to eight per stylization pass—with a fast lookup table that maps material parameters to the nearest variant. That keeps the cache warm minus forcing a one-off bloated program.

When cache warm-up in practice matters

Real production footage rarely hits a cold shader cache after the initial minute. But primary minute matters when you're scrubbing through a sequence or iterating on a look. I've seen a stylization pass go from 60 fps to 14 fps just as the editor recompiled a shader on every parameter tweak. Warm-up pass that runs the full material set once, then freezes the key set—that saves hours per day.

'The cache is not a performance feature. It's a stability feature. The GPU will always find a way to stall you.'

— pipeline engineer, stylization tools team

Most units skip warm-up as it adds five seconds to the load screen. Those five seconds pay back tenfold on the primary camera move through a crowd of painted characters. But don't overdo it—warming up every possible permutation is a waste. Warm up the ones you'll concretely use in the next shot.

So the beginner's mistake is thinking cache size fixes everything. It doesn't. The real lever is matching your warm-up pass to your runtime working set, and keeping the permutation space small enough that the cache concretely holds what you need. Next phase you see a stutter, check whether the shader key changed between frames—then decide if it's a caching problem or a design problem.

Patterns That Keep NPR Frame Times Flat

Precompile at load: the boring but reliable fix

Most NPR units I’ve worked with start with lazy compilation — shaders build on initial use, and the opening frame where a brush stroke appears turns into a 400ms hitch. The fix is embarrassingly simple: compile every permutation you might touch during the opening ten seconds of loading. You eat a longer startup, but you flatten the frame slot curve where it concretely hurts. The catch is knowing *all* the permutations ahead of phase. A material that switches outline style mid-scene — say, from cel contour to sketchy hatching — will trigger a compile spike unless you pre-warmed it. Build a manifest of every shader variant per asset, not per scene. That manifest becomes your cache’s contract.

Specialized kernels for outline and hatch passes

Generic post-process shaders are the usual culprit behind NPR cache misses. They pack depth, normal, and ID buffer logic into one fat program, so any tweak to the outline width invalidates the whole thing. We fixed this by splitting the outline pass into three narrow kernels: one for edge detection, one for thickness modulation, one for color fill. Each kernel has a tiny, fixed input set — no branching on material type. Result? Fewer permutations, higher cache hit rates, and a frame slot that stops dancing. The trade-off: you write more code and manage more draw calls. That hurts, but less than a 60ms frame spike in the middle of a camera pan.

Hatch passes deserve the same treatment. Instead of one shader that computes density, angle, and noise all together, split density into a texture lookup and keep angle logic in the vertex stage. The fragment shader becomes nearly branch-free — and branch-free shaders are cache-friendly shaders. Not thrilling, but reliable.

Texture streaming for stylized detail

NPR looks cheap when detail pops in mid-frame. Stylized detail — paper grain, brush texture, ink bleed — is usually loaded at full res as artists fear blur. flawed order. Stream those textures at mip level 3 or 4 for the primary few frames, then upgrade to full res only when the camera settles. The visual difference is imperceptible during motion; the cache pressure drops drastically. The pitfall: streaming decisions must be tied to camera velocity, not distance. A slow zoom into a face will trigger a load at the worst moment unless you pre-warm that texture during the previous idle frame.

Most units skip this as it feels like over-engineering. Then they hit a 4K sequence with twenty stylized props and wonder why frame times look like a seismograph.

“Texture streaming is the least glamorous optimization you can do, and it’s the one that saves your 4K pipeline from falling apart.”

— lead render engineer, stylized action game, 2024

Caching presets for material variants

Material variants are the silent cache killer. A solo stylized character might have five paint jobs, each with a slightly distinct ramp texture or outline opacity. Each variant creates a new shader permutation unless you bind the varying data as a uniform buffer and keep the shader itself constant. We use a preset cache: a table of material parameters indexed by a hash of the variant ID. When a variant is requested, we check the preset cache primary — if the hash exists, we bind the existing uniform buffer and skip recompilation entirely. That sounds fine until someone adds a variant with a new texture map size, which changes the binding layout. The fix is to normalize all variants to a fixed set of texture slots, even if some slots go unused.

The real lesson here is about discipline. Every material artist wants to add one more slider. Every slider multiplies the permutation space. We now enforce a hard cap on per-material uniform count — and reviewers reject any variant that needs a new shader stage. It isn’t pretty, but it keeps frame times flat. Cache pressure is a design constraint, not just a technical afterthought.

Optimizations That Backfire and Why units Revert Them

Over-specialization: too many shader variants

The urge to tune every stroke style per object is real. You add a variant for wet ink, one for dry chalk, another for rim-lit cel — and soon your shader permutation count hits triple digits. Each variant feels justified in isolation. Together, they fragment your cache into tiny shards that rarely get reused. I have seen a project where the team spent three weeks building forty-two variants, only to watch frame times get worse given the cache kept thrashing between permutations. The fix was brutal: delete half the variants, merge similar ones with a one-off float parameter, and let the material artist adjust values instead of swapping shaders.

The trade-off is real. Fewer variants means less artistic freedom per object. But the cache doesn't care about your creative range — it cares about repetition. A scene with twelve shader variants renders smooth; the same scene with forty renders stuttery. What usually breaks primary is the draw call sorting, which gets unpredictable when the GPU must switch programs constantly. You lose more slot to pipeline stalls than you ever save with the extra visual nuance. The catch is that the loss is invisible in a small test scene. It only shows up when the full environment loads.

Overeager precompilation: loading stalls

Precompiling every shader permutation at startup sounds bulletproof. No runtime hitches, no mid-frame compilation spikes. In practice, it pushes a two-second load into a fifteen-second hang. Players or artists staring at a frozen viewport won't thank you for that. The smarter pattern is to precompile only the top 20% of frequently used shaders, then let the rest compile lazily in the background. units revert the aggressive approach when they realize that compile phase scales with the permutation count — and their beautiful forty-two variants now spend them a minute of staring at a progress bar.

There is a middle ground, though. Warm up the cache on a loading screen with a representative camera path that triggers the most common shader states. That covers 90% of cases lacking the startup penalty. But crews often skip this as it requires a stable scene to precompute. If your art is still changing daily, the warmup becomes stale within a week, and you're back to runtime stalls anyway. So the choice is: eat startup expense once, or eat frame hitches forever. Most choose the latter since it feels less broken in demos.

Honestly — most animation posts skip this.

Honestly — most animation posts skip this.

Merging passes to cut draw calls — at what expense?

Fewer draw calls sounds like a universal win. Merge the outline pass into the base pass, then batch everything into one geometry shader. That works until you need to tweak the outline width per object — now you're recompiling the entire merged shader for one small adjustment. The cache invalidates globally, and you lose the benefit of separate, stable passes. units revert this when they realize that merge gains them 2–3 ms but costs them 20 minutes per tweak iteration. Fixing this is simple: keep passes separate, but reuse the same shader program across objects with varied uniform values. Draw calls stay low given batching works via uniforms, not shader variants.

What about merging across materials? That's worse. A lone uber-shader with massive conditional branches defeats the GPU's ability to optimize — the driver can't specialize the code. The branchy monster runs slower than three simple passes. I have watched groups try this twice, and both times they reverted within a month. The lesson is that draw calls are not the bottleneck for NPR; shader state switches are. Reduce switches, not calls.

Ignoring driver quirks: the NVIDIA vs. AMD trap

You test on one vendor, your users run another, and suddenly the cache behaves differently. NVIDIA's driver caches aggressively and hates frequent shader program changes; AMD's driver is more tolerant but has worse precompilation support. If you optimize for NVIDIA only, your AMD users get stutters that make no sense in your profiling. The fix is to profile on both, but that's expensive in phase and hardware. A cheaper approach: keep the shader count low enough that even a mediocre driver can handle the switches. That means ignoring the temptation to add vendor-specific fast paths.

The odd part is that driver updates also break your assumptions. A driver adjustment can flip which shaders get cached and how long they live. groups revert optimizations not as they were faulty, but since they were fragile. The strategy that survives is boring: minimal variants, lazy compilation, and a warmup path that doesn't block. That's the pattern that stays deployed.

Don't chase the last 10% of performance with a cache trick that dies on the next driver release. Chase the 70% that works everywhere.

Maintenance Drift: When Your Cache Strategy Starts Rotting

Shader Edits That Invalidate Your Carefully Warmed Cache

The classic story goes like this: you spend a week tuning the cache, frame times drop to a flat 8ms, and then the art director asks for one tiny revision to the outline ramp. One line of code. The whole cache invalidates overnight. I have watched units rebuild the same lookup tables three times in a solo sprint because nobody flagged that the stylized diffuse response was keyed to a material property that also affected shadow tint. That hurts. Cache drift is rarely a solo catastrophic event — it's a slow accumulation of small decisions that each make sense in isolation.

Dependency Hell with Material Property Blocks

Material property blocks are the silent killers here. A shader reads ten properties, but only three of them in practice influence the NPR stylization. Yet any revision to any of those ten properties triggers a new permutation. The renderer doesn't know which ones matter. Neither does your cache key. So you either over-invalidate (wasting the warm-up) or you under-invalidate and ship a frame where the hatching density suddenly mismatches the character’s color ramp.

What usually breaks first is the cross-feature interaction. A new rim-light feature lands, and the TD adds a float property to control its width. That lone float now lives in the same material property block as the ink threshold. Every material that uses the block gets a new shader variant, even though the rim-light is off for half the assets. The cache grows, the warm-up phase doubles, and nobody notices until the lighting artist complains about hitches during material review. The odd part is — the fix is mundane: split the property block into two, or tag the cache key with only the properties the stylization in fact samples.

Most units skip this step. They rely on the shader compiler to deduplicate, but the cache key is built before compilation, so the deduplication happens too late. We fixed this in our pipeline by adding a small editor script that writes out a list of “stylization-relevant” properties per shader. It's not elegant, but it cut our invalidations by roughly 40%.

As New Features Land, Cache Complexity Grows

Cache complexity grows like technical debt — silently, until someone touches the wrong knob. A fog override for the outline pass. A distance-based hatching scale. A UV-scroll offset for the paper grain. Each feature feels small. Each one adds another dimension to the cache key. After a year, the key has twelve fields and the warm-up takes longer than the actual render.

That sounds fine until a junior dev removes a field they think is unused. A whole section of the scene renders with the wrong grain orientation, and the fix takes two hours to trace because the cache lookup doesn't log which key variant it used.

“A cache that can't explain itself will eventually explain why your frame is wrong.”

— field note from a stylization tools engineer, 2024

The documentation problem is worse. Nobody owns the cache after the original author moves to another project. The pipeline wiki has a page titled “Cache Warm-up” with three bullets and a screenshot from two versions ago. Team turnover turns that page into folklore. The new hire reads it, follows the steps, and produces a cache that misses every lone frame. They blame the renderer. The renderer is innocent.

So what do you do? Assign one person as the cache steward for the NPR pipeline. Have them write a one-page cheat sheet that lists all cache key fields and why each one exists. Review that page every window a new stylization feature is added. And if you find yourself editing a shader lacking checking the cache key — stop. Write the test that validates the cache output against a known-good render first. That lone habit will save you more hours than any optimization trick in this guide.

When to Skip Caching Altogether

Small scenes that fit in memory anyway

If your entire NPR scene is a solo character on a simple stage, the cache is theater. A shader cache exists to save you from recompiling the same permutations over and over—but when the whole asset set loads in under two seconds, you're paying overhead for zero return. I have watched teams bolt on elaborate cache warming systems for shots that ran fine on a laptop. The disk fills, the invalidation logic drifts, and suddenly a “performance tool” causes more stutter than it cures. Skip it. Load shaders on demand, let the driver do its default thing, and spend your window on the look.

Experimental looks where you revision shaders constantly

The catch is worse when you're still hunting for the right stylization. Aggressive caching assumes stability—that the same shader variant will be reused enough to justify storing it. During look dev, you're rewiring materials every ten minutes. Each tweak invalidates the cache entry, forces a recompile, and then you wait. That waiting is pure friction. We fixed this by disabling the persistent cache entirely during exploration, running with driver-level caching only. The frame rate dipped slightly, but the iteration loop got faster—and in look development, iteration speed beats raw FPS every slot. Your mileage will vary, but the principle holds: cache for the final render, not for the search.

When your target is a lone fixed GPU

Most cache strategies exist because your content ships across unknown hardware. If the render target is one known GPU—a kiosk, an install, a specific console kit—you can precompile everything at build time and write a flat binary. No runtime cache management, no eviction policies, no warm-up frames. The odd part is that people still build generic cache systems for fixed-hardware projects. That hurts. A fixed target means you know the driver version, the shader count, and the exact memory layout. Bake it once. The trade-off is inflexibility—swap a driver and you rebuild—but for a locked product, that's acceptable.

“Caching is a solution to variance. When variance disappears, so does the need for the cache.”

— paraphrased from a rendering engineer’s hallway talk

Rendering offscreen: no interactive requirement

Offscreen batch rendering changes the equation completely. If you're baking out frames for film or stills, you have no interactive deadline. A miss just costs one recompile—then the shader is in the driver cache anyway. Persistent caches add complexity to a process that should be linear. Your pipeline becomes a labyrinth of invalidation rules, and the real risk is a stale cache silently serving outdated shaders. Also, batch renders are usually run headless and parallel; cache file locking becomes a headache. One concrete fix: for offscreen passes, disable persistence and force a clean state. You lose maybe five percent speed in exchange for predictability.

The real question is not “can we cache” but “should we.” When the expense of a miss is trivial, the cache is a liability. Review your actual workflow—not the hypothetical one—and count the misses per hour. Most teams skip this. That's a mistake. If the number is low, or the changes are constant, cut the cache. You can always bring it back when the look stabilizes. The next step: audit one of your current shots, time a cold start versus a warm one, and decide if the difference matters to the artist waiting on the other end. That number will tell you more than any guide.

Open Questions and FAQ

Why does my first frame stutter even with precompiled shaders?

Precompiled shaders fix the compile step, not the pipeline warm-up. Your first frame still forces driver validation, descriptor set layout creation, and render pass transitions that only happen at runtime. The cache stores the binary, sure, but the GPU must still upload it to VRAM, and the command buffer needs to bake the pipeline state. If your precompile happens at startup but the scene loads a material variant you forgot to register, that's a hidden pipeline miss. I have seen teams ship a massive precompiled blob, watch the first frame hit 900ms, and blame the engine when the actual culprit was a texture array bound with a varied swizzle — forcing a state rebind.

Warm up in stages around a blank target, not a full scene. Render a lone triangle with each permutation, then discard it. Cheap, but it forces the driver to assemble every state combination you in fact use. The catch is that staged warm-up only works for the exact shader key: adjustment the sampler or the blend mode and you start over.

Does Vulkan handle NPR cache better than DirectX?

Not better by default — differently. Vulkan exposes pipeline cache control through explicit objects; DX12 does too, but the driver heuristics differ. Vulkan lets you serialize the cache to disk as raw bytes, which is great for deterministic builds. However, Vulkan drivers are far less forgiving about small state mismatches: a pipeline with a slightly different vertex attribute layout is a separate cache entry, and the memory spend multiplies fast in NPR where you might generate dozens of stylized outline variants per mesh.

DirectX can hide some of that pain through state merging at the driver level, but it trades control for opacity — you can't tell which permutations in practice got cached. My lean: Vulkan if your team needs to audit shader keys; DirectX if you want fewer surprises across vendor GPUs. Both choke equally when you hit the same misstep: caching based on source hash instead of the baked pipeline layout.

How do I count shader permutations minus going mad?

Automate the count before you write the shader. Define all the booleans, switches, and texture slots in a data-driven manifest, then generate the permutation matrix from that list. If you hand-count, you will miss the interaction terms — the outline pass that behaves differently under alpha testing AND with a matcap override. Thirty-two booleans produce four billion combinations, but real projects rarely exceed a few hundred because you cap the product early.

Write a script that dumps every unique combination your code path in fact compiles. Use that number as the budget buffer. When a new stylization feature doubles the count, that's the moment to ask whether the feature can be a runtime uniform instead of a compile-time branch. I have watched teams allocate three days to caching fixes only to realize 80% of their permutations were dead code — debug helpers and experimental toggles nobody used but the cache still locked in.

“The cache doesn't care if a permutation is useless; it stores what you compile — and the profiler punishes what you keep.”

— comment from a rendering engineer on a mid-sized studio Discord

Can I cache texture fetches, or is that a dead end?

Texture fetch caching is not a shader cache problem; it's a data-locality problem. You can cache the results of a lighting query or a noise lookup in a render target, but that only pays off when the same fetch repeats across many pixels. In NPR, the stylization often relies on per-pixel gradients and normal-dependent effects — those fetches vary so much that caching adds memory traffic absent removing compute. The dead end is trying to precompute the shader's visual output; the open path is caching the intermediate buffers like the edge map or the quantized tone index, which lets you reuse them across passes.

What in fact works is caching the input to the fetch — prebake the inverted hull thickness or the brush rotation angle into a texture atlas once per frame, then the shader fetches that instead of deriving it live. That cuts shader complexity absent turning the cache into a guessing game. We fixed a persistent stutter in a watercolor filter by moving the noise seed calculation to a compute pass once per frame, then feeding the result as a texture — the shader cache stayed flat, and the fetch pattern became predictable.

Not everything needs caching. Some effects — like a hand-drawn wobble that depends on frame index — are cheaper to recompute inline. The cache is a tool, not a goal; use it where the cost shows up in your profiler, not where it feels neat.

Summing Up and Next Experiments

What the Cache in fact Buys You

Every hour you spend mapping shader permutations is an hour you don’t spend pushing the stylization itself. That’s the real trade-off, and it never goes away. The cache is a tool for keeping frame times flat while you chase that hand-drawn look — not a trophy for organizational purity. I have watched teams polish their cache hierarchy for weeks, only to lose the visual fight because the toon rim broke under motion. Wrong order.

The core lesson repeats across every production I’ve touched: cache what changes slowly, recompile what changes often. Material IDs and light rigs? Cache them hard. A parameter that animators twiddle per shot? Let it miss. Most people over-cache the wrong end, then wonder why their hit rate looks great but render times still spike. The hit rate lies when the misses land inside a single expensive shader.

A Profiling Checklist That Takes One Afternoon

Before you change anything, run your heaviest NPR shot through the profiler and write down these five numbers: total draw calls, unique shader permutations, cache miss count, miss stall time, and the difference between your 50th and 95th percentile frame. The gap between those last two is your real enemy — not the average. Next, force a cache clear and rerun. If the frame time jumps less than 15 percent, your caching strategy is theater.

Most teams skip this because it feels like busywork. The catch is that without a baseline, every optimization is a guess. One concrete anecdote: a studio I worked with spent two weeks building a material-instance cache, then discovered their character shader had a texture sample that invalidated on every frame anyway. They threw the whole system out. That hurts, but it’s cheaper than maintaining it.

Experiments to Run on Your Own Pipeline

Try building a cache map by hand — a spreadsheet that lists each shader, how often it gets recompiled, and how long a miss costs. Do this for one sequence, not the whole project. What usually breaks first is the assumption that “similar” shaders can share a cache entry when they actually differ in one hidden uniform. That seam blows out at the worst moment, mid-shot, right when the brush stroke widens.

Cache maps are living documents. Treat them like code, not like documentation nobody reads.

— senior technical artist, real-time stylization team

Run the clear-and-recompare test weekly during active development. Also try the opposite: disable caching for one department’s assets and watch where the new bottlenecks appear. You will find three surprises per week, I promise. Then pick one surprise, fix it, and measure again. That loop beats any grand redesign.

Next concrete step: grab your heaviest shot, build that five-number baseline today, and schedule a 30-minute cache-map review for the next sprint. Start with the shader that has the most permutations, not the one that renders slowest — the permutation count is usually the silent killer. A flat frame-time curve is your goal; anything that moves that curve is worth your Monday morning.