Fr0zka
9591088d34
STAGE C group 1. No operator added: nineteen ops before, nineteen after. What changed is what ELEVEN of them READ. THE MECHANISM, AND WHY §2's "NO CLEAN HOME" PROBLEM DISSOLVED FRoomGraphSource gains LocalParams(): the strate params with the nearest room's hash-rolled UVoxelTerrainOpDefinition applied on top, exactly as the original's `FStrateGenerationParams LocalTerrainParams = Params; ... NR.RoomOp->ApplyTo(...)` shadow does. Every detail op that read the shadowed copy now reads that. OPSTACK-DECOMPOSITION §2 called this the piece with no clean home and proposed giving each modifier an "only inside room N" predicate. The difficulty came entirely from assuming each modifier must OWN its params. One op owns the shared state, the rest read it -- and that pattern was already established here twice (FOverhangShelfMod <- FSurfaceColumnSource, FShaftLedgeMod <- FShaftFieldSource). No scoping predicate was invented. Same shape as the pit/chimney resolution. ELEVEN, NOT TWELVE, AND THAT IS READ FROM THE CODE Surface roughness (4b) does NOT read the per-room copy: the original's `const FStrateGenerationParams& Params = LocalTerrainParams;` is declared INSIDE the `if (bNearCaveSurface)` block, which begins after step 4b. Ported that way and flagged in the op so it does not get "uniformised" later. MEMOISED PER VOXEL, AND WHY THAT IS FIDELITY RATHER THAN OPTIMISATION The original builds the copy ONCE per voxel inside the gate. Eleven ops calling LocalParams() would build it eleven times. So FState carries a valid-flag that FRoomGraphSource::Eval clears at the top of every voxel (before any early-out, so nothing can read the previous voxel's room), and the first modifier that asks pays for it. Deep rock pays nothing, exactly as before. The ~74-field copy itself is TRANSCRIBED AS-IS. It is a real per-voxel cost; recorded in OPSTACK-PROGRESS as a perf item, not "improved" here. ONE THING THIS EXPOSES, WRITTEN DOWN BEFORE IT BITES EffectOverBox still answers from the STRATE params, because a box spans many rooms and a per-voxel copy has no meaning there. Since ApplyTo writes the op's value even where the strate's was 0, a room op can ENABLE a modifier the strate had off -- so a box verdict can now be too optimistic on a strate that has a terrain-op pool. Harmless today (nothing consumes ClassifyBox in production) and it MUST be fixed before ClassifyTile does. Noted at FLayerLineMod::EffectOverBox and in OPSTACK-PROGRESS. TEST (same commit) -- this is the acceptance stage B could not make - The pool gains a Terrace op with values (3.0 / 0.95 / 1.4) deliberately far from the strate's (6.0 / 0.6 / 0.5). A stack that ignored the override now CANNOT be bit-identical. - New check 3c asks the structure, not the density, because there is still no params probe for a pool (the pool is not in the SDF cache key): how many baked rooms carry a Terrace op, and how many samples fall inside one of those rooms' influence radius. Both must be non-zero, or check 1's green means only that two paths agree where the override never applies -- which is what stage B already proved. Fourth application of the pit lesson. IF THIS GROUP IS WRONG: check 1 fails with diffs clustered inside a subset of rooms (those that drew Terrace) and terrace-shaped Z banding, while check 3c still reports non-zero coverage. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>