Optimization

Measure the Player

Use a Development Player at a fixed resolution, camera, quality level, density, lighting mode, and graphics API. Warm the renderer before sampling. Report CPU frame time, GPU frame time, grass-stage CPU markers, visible blades, visible chunks, indirect commands, GPU memory, and steady-state managed allocation separately.

Editor Game-view FPS is useful for interaction checks but is not a release benchmark. Record controlled Development Player results for the target hardware and keep internal evidence separate from the distributable package.

Select the quality budget

High, Medium, and Low reuse the same packed 24-byte blade allocation. Normal Off retains it for instant reactivation. Release Resources While Off is a separate delayed memory policy and can add a reload or regeneration cost later.

Tune the real bottleneck

• If GPU time rises with stable CPU time, reduce survivor density, maximum distance, shadows, procedural motion vectors, semantic field resolution, or overdraw-heavy far width.
• If CPU grass stages rise with species count, inspect visible commands. Species share one blade budget but require material and geometry command ranges.
• If memory is high, lower the total blade cap or author a smaller field. Do not create one blade allocation per runtime quality level.
• If dirty painting stalls, increase chunk size only after measuring the tradeoff between command count and patch granularity.
• If a distant field is open and automatic Hi-Z has no profitable occlusion, its backoff path is expected. Do not force Hi-Z merely because it exists.