Shader rebuild key ignores hasWarn and textures

[kmatzen]

SdfMesh.onStoreChange (src/engine/SdfMesh.ts:180) decides whether to rebuild the material from two fields only:

if (sdf.glsl !== this.lastGlsl || sdf.paramCount !== this.lastParamCount) {
  ...
  this.rebuild(sdf);
}

But rebuild() bakes two more inputs into the material:

• hasWarn — passed to buildFrag(sdf.glsl, sdf.paramCount, sdf.hasWarn) (:105-107), so it selects the fragment source.
• textures — each becomes a DataTexture uniform (:195-204).

So an evaluation that produces identical GLSL and the same param count, but a different hasWarn or different texture payload, never reaches the GPU. The thin-wall highlight shows the previous evaluation's state, and a texture-only change renders with stale texture data.

Fix

Include both in the cache key. hasWarn is a boolean, so it is free. Textures need a content key — hashing the payload on every evaluation may not be worth it, so a cheap structural key (count, plus each texture's name/width/height) would catch the common cases, with a comment noting that same-dimension content-only edits still need a full hash to detect.

Related

#53 (GPU resources leaked on every rebuild) touches the same function. Fixing the key here makes rebuilds more frequent for texture changes, which makes the leak worse — so #53 should land first or together.

[kmatzen]

Correction to my own report above — I checked the producer side before fixing, and the textures half of this issue is latent, not live.

codegen.ts declares textures (:6), resets it (:324), and returns a copy (:352), but nothing ever pushes to it:

$ grep -nE 'textures\s*(=|\.push|\.splice|\[)' src/worker/sdf/codegen.ts
324:  textures = [];

No other file in src/worker/sdf/ mentions textures at all, and the only GLSL use is the uniform sampler2D declaration line, which maps over an always-empty array. So sdf.textures is always [] at runtime and a texture-only change cannot currently produce a stale render — there are no textures to go stale.

What remains live is hasWarn. It is baked into the fragment source via buildFrag(sdf.glsl, sdf.paramCount, sdf.hasWarn) and genuinely absent from the rebuild key, so a thin-wall highlight can show the previous evaluation's state whenever GLSL and param count are unchanged.

Fixing both anyway — the texture key costs nothing while the array is empty, and having it in place means the cache key is already correct whenever textures do get wired up. But the severity here is lower than I first wrote: one real bug, one pre-emptive.