Texturing stalls indefinitely at ~48–52% on large projects — RAM pinned at 95%, CPU ~3%, Abort unresponsive (RS 2.1.1)

Version: RealityScan 2.1.1 Desktop
System: AMD Ryzen 9 9950X (16C/32T), 128 GB DDR5, NVIDIA RTX GPU (CUDA) + AMD iGPU, Windows 11, project and cache on NVMe SSDs (1.4 TB free), page file manually set to 256–512 GB on NVMe.

Project: 10,285 registered images, single reconstruction region. The original reconstruction, as a singleton, could not be unwrapped beyond 32 × 16K textures — attempts at 48 and 64 × 16K failed with out-of-memory. To work around that, the original mesh was simplified within RealityScan to ~43.6M triangles / 1,260 parts, after which unwrap succeeds at higher texture counts. Current unwrap: 128 × 8K textures, geometric method, fixed texel size. Unwrap is not the issue being reported — the problem is the Texturing step that follows.

Issue: Texturing consistently stalls partway through and never recovers:

128 × 8K textures → texturing stalled at 48%: RAM at 119/126 GB (95%), CPU 3–4%, all disks 0% active, no progress for hours. The “time remaining” estimate keeps counting but the completed percentage never advances.

During the stall, Task Manager shows Committed at only ~142 GB out of a 376 GB commit limit — the process is not paging (disks fully idle), it simply stops progressing once physical RAM is exhausted. No error and no out-of-memory message is ever raised.

Abort is also non-functional during the stall. Clicking Abort does nothing — the job never terminates, and the only way out is End Task on RealityScan.exe from Task Manager, losing any unsaved project state. This suggests the texturing worker is genuinely wedged (deadlocked or stuck in allocation retry), not merely slow.

The same texturing workflow (large image sets, high texture counts, spilling to the page file when RAM was exhausted) completed successfully on this hardware in older projects with previous versions. The documentation states texturing is out-of-core and should split jobs to fit available RAM; in 2.1.1 that no longer appears to happen — the job wedges at the RAM ceiling instead. This appears to have regressed somewhere in the 2.x line.