"Chunked mesh generation is math-bound, not draw-call-bound"

Your chunked runtime-mesh generator (voxel terrain, marching cubes, greedy-meshed blocks) hits a wall as world size grows. You assume it's draw calls or scene-object count causing the slowdown, so you increase chunk size to reduce the number of GameObjects — but regen time doesn't change at all.

Regen (the CPU time to generate mesh geometry) is generation-math-bound, not scene-object-bound. The cost scales with the total cell count (WorldSize squared), not the number of chunks or draw calls.

Measured evidence: bumping chunk cells from 32 to 64 quartered the GameObject and ModelCollider count (1024 down to 256 chunks at the same world size) with zero regen change (2286 ms vs 2257 ms). The generation passes iterate every cell regardless of how those cells are grouped into chunks.

Regen grows roughly linearly with cell count:

• 384² cells: ~0.4 s
• 1024² cells: ~2.3 s
• 1280² cells: ~3.6 s
• 1536² cells: ~5.4 s (the wall — busts a 5 s budget)

Thread the pure generation passes using GameTask.RunInThreadAsync. The per-cell math (noise sampling, greedy meshing, vertex emission) is stateless and embarrassingly parallel — split it across worker threads by chunk or by cell-row.

Don't raise chunk cell count for draw-call reasons — draw calls typically never bind fps for runtime-meshed terrain. Smaller chunks also preserve finer dirty-remesh granularity, which matters if you have a brush editor or localized terrain modifications.

Corollary: keep chunks small for editing responsiveness. A 32-cell chunk that needs remeshing after a brush stroke is a fraction of the cost of a 64-cell chunk, and the draw-call difference is invisible.

This is a counterintuitive result: the "obvious" optimization (fewer, bigger chunks = fewer draw calls) changes the wrong variable entirely. If your regen is the bottleneck, the only lever is parallelism — not scene-graph simplification. Measure regen time separately from frame time before committing to a chunk-size change.