Yeah, the way you’re testing it is basically what I landed on too. Cold cache, treat the first render and the first interaction as two separate things, and watch if anything new compiles when you poke it. That warm initial scene is exactly what fools you.

The thing that unlocked it for me was realizing I was thinking about it wrong. I was trying to cover configurations and there are thousands of those. But the GPU doesn’t care about configurations, it cares about programs, and there’s only a handful. Twenty wood finishes that are all the same MeshStandardMaterial with a different texture are one program, not twenty. So I stopped enumerating configs and started enumerating the stuff that actually changes the shader: the material types I switch between, the lighting presets that change light count or the env map, and whether the post stack with bloom and tone mapping is on or off.

That list is short. During the loading screen I just step through it, set each combo, call compileAsync. The one that bit me was the EffectComposer passes. renderer.compile doesn’t touch them, you have to actually render a frame through the composer with the passes enabled, otherwise they compile on the first interaction and you get exactly the hitch you’re describing.

And to your real question, how do you know you covered them without brute forcing every config, I just watch renderer.info.programs.length. Warm up, then click around like an annoying user, switch finishes, flip lighting. If that number goes up, you missed one, add it. When it stops moving no matter what you click, you’re done. Never had to render the whole matrix.

One more that caught me once, if you use onBeforeCompile or a custom cache key anywhere those are their own programs too, so they need to be in the warm-up or they’ll surprise you on first interaction.