1. Identifying Unexpected Transient Buffer Growth
The first step in any memory-related regression is isolating the specific resource types ballooning in your RHI dump. We used the console command rhi.DumpResourceMemory to compare our 5.4 baseline against 5.6.
We observed clear spikes in Nanite.RasterBinData, Nanite.VisibleClustersSWHW, and Nanite.MainAndPostCandidateClustersBuffer. While some of this is tied to engine features like Lumen or Virtual Shadow Maps, the overhead was disproportionate to our scene complexity.
- Run rhi.DumpResourceMemory in the console to capture memory stats.
- Compare heap allocations between your stable version and the new engine build.
- Categorize buffers to determine if growth is systematic or feature-dependent.
2. Deciphering r.Nanite.RasterIndirectionMultiplier
During our investigation, we uncovered the CVar r.Nanite.RasterIndirectionMultiplier. In newer engine versions, this multiplier often defaults to a value that provides a wider safety buffer for material sections per cluster than previous iterations required.
This multiplier effectively determines the size of the RasterBinData buffer, which handles lists of visible triangle ranges. If your project has a low density of multiple materials per cluster, the default value can lead to significant, unnecessary memory allocation.
- The buffer size is calculated as: Multiplier * MaxVisibleClusters.
- High values reserve more memory to prevent geometry popping.
- Reducing this value is a primary lever for clawing back VRAM on memory-constrained hardware.
3. Evaluating Material Sections Per Cluster
Before blindly lowering the multiplier, use the Nanite visualization tools to check your actual material distribution. If your meshes are heavily optimized with low material complexity, the overhead of the default buffer size is likely wasted.
We checked the 'Material Count' visualization mode. Seeing very few clusters with more than two materials confirmed that we were over-allocating memory for a scenario our project rarely encountered.
- Enable the 'Material Count' Nanite visualization mode.
- Inspect complex assets to see how many material sections fall within a single cluster.
- Identify if your project uses Fast Path or Slow Path (WPO-heavy) materials.
4. Applying and Validating Your Optimization
To optimize, adjust the CVar incrementally. A value of 1 often mirrors the behavior of older engine versions, but you should verify this against your specific hardware profile to ensure you aren't sacrificing rendering stability.
Always monitor for geometry popping or log warnings regarding buffer overflows. If the system warns that the buffer is too small, you have found your hard limit.
- Set the CVar to a lower value and observe the console for warnings.
- Perform stress tests with high-density Nanite scenes to check for geometry flickering.
- Profile your memory usage again to confirm the reduction in buffer overhead.
FAQ
What happens if I set r.Nanite.RasterIndirectionMultiplier too low?
If the buffer is too small to contain the required triangle range batches for the current frame, you will encounter geometry disappearing or flickering. The engine usually logs a warning when the buffer limit is hit.
Does World Position Offset affect this buffer size?
Yes, WPO-heavy materials complicate the rasterization path significantly. These materials often bypass the fast path, forcing the renderer to allocate more entries in the buffer regardless of your multiplier setting.