Snapshots for GenTerraPostProcess

[tehtelev]

Summary

We've added a thread-safe snapshot system to GenTerraPostProcess, which caches subchunk data in local arrays once before scanning. This dramatically speeds up world generation: millions of slow GetBlockIdUnsafe calls with palette unpacking are replaced with instant index reads. We've also implemented strict array bounds checking and NullReferenceException protection, completely eliminating rare but critical generator crashes caused by non-standard column heights or missing data in chunks.

Type

• Bug fix
• Performance
• New feature
• Refactor or cleanup
• Docs or build

Checklist

• .\scripts\extract-patches.ps1 ran clean.
• dotnet build VintageStory.slnx -c Release is green.
• Every vanilla edit has a // Stratum marker.
• No vanilla source committed.
• Tested on a real server start, not just compilation.

Performance numbers

Tested on the generation of 31417 chunk columns (6 threads) by /stratum pregen start radius 100 16000 16000
Seed - seed 1027995113.
World setting - default.
AVX instructions: enabled

Three runs were performed before and after the changes using the Jetbrains dotTrace program.

Before

• OnChunkColumnGen method execution time: 5387 ms; 5529 ms; 5561 ms.
• Average: 5492.3 ms
• Standard deviation: 92.6 ms

After

• OnChunkColumnGen method execution time: 3402 ms; 3271 ms; 3681 ms
• Average: 3451.3 ms
• Standard deviation: 209.4 ms

Summary: The snapshot optimization resulted in an average speedup of ~37.2% (dropping execution time from ~5.5 seconds down to ~3.45 seconds). However, the standard deviation increased from 92.6 ms to 209.4 ms, indicating that the new version shows less stable chunk generation performance compared to the baseline.

[trevorftp]

I don't think missing chunk data should become air here. That changes the worldgen result and can feed fake air into the floating-block cleanup. Better to skip/fail this column than guess.

[trevorftp]

Can we recheck the seed live before calling this? As far as I can tell the snapshot can be stale after earlier cleanup and deletePotentialFloatingBlocks assumes the starting block is still solid

[trevorftp]

CopyBlocksToUnsafe is explicitly the no-lock path we need a synchronized bulk-copy path here

[tehtelev]

Thanks for the review, these are all good catches. Addressed all three points below. Summary of the key trade-off: the hot flood-fill loop works entirely over int[] snapshots and performs zero per-cell accessor lookups, so adding a single live re-check before cleanup costs nothing performance-wise.

1 - Missing chunk data becomes air
Agreed this shouldn't alter generation results. I kept the Array.Clear (fill with air = 0) strictly as a crash-protection fallback and documented it as such: at this late stage of column generation a null subchunk should not occur in practice, so we do not try to fabricate terrain — we just avoid an NRE on a missing provider. See BuildColumnSnapshot.

2 - Recheck the seed live before cleanup
Done with a single GetBlockId call at the call site (IsSeedBlockStillSolid) right before entering BFS. This is one accessor lookup, not a per-block loop, so it does not reintroduce the O(volume) accessor cost and preserves the speedup. I chose to keep the guard at the call site rather than moving it inside deletePotentialFloatingBlocks, since the latter would pay that check on every invocation. If you'd prefer the same protection inside the method, I can move it — happy to do whichever reads better for the codebase.

3 - CopyBlocksToUnsafe has no lock
Wrapped the CopyBlocksToUnsafe fast path in TakeBulkReadLock() / ReleaseBulkReadLock(), released in a finally. Reads are guarded against concurrent chunk-data reloads; the read lock is uncontended per column. See BuildColumnSnapshot.