The "Noise" module, which adds irregular "fluctuations" to the movement of particles, is extremely useful for expressing the irregular rise of sparks of flame, dust flying in the air, blizzard, etc. However, if you casually mass-produce particles while this function is turned on, it will cause the entire game to freeze at a serious level. In this article, we will explain the internal mechanism of this CPU load explosion bug in an easy-to-understand manner using the analogy of ``assigning staff to fold origami'', and present optimization steps and a system migration approach.

1. Understand with an analogy: ``A large amount of origami crafts that the store manager has to do.''

To intuitively understand this CPU bottleneck issue, let's consider ``Division of duties in store operations'' as an example.

You are the manager of a store (game engine). We have an ``excellent store manager (main thread of the CPU)'' who is in charge of the most important main tasks (physical calculations for games and execution of C# scripts) to keep the store running smoothly, such as supervising the store, operating the cash register, and processing paperwork. However, in order to decorate the event, the store manager was given the additional task of folding ``5,000 sheets of complicated origami per second (complicated 3D noise vector calculations for each particle)'', all by hand.

The store manager tries to fold at superhuman speed, but he gets so caught up in the folding work (floating point calculations on the CPU) that he is completely paralyzed from his primary duties of cash register processing (update processing) and customer service (issuing drawing commands), resulting in a huge queue (decreased frame rate) in front of the store. This is the CPU main thread occupation bug caused by Shuriken particles with the Noise module turned on.

Originally, the correct business design for such a "simple but huge amount of work (parallel calculation for each particle)" is to evenly distribute the work to 1000 specialized part-time workers who are good at origami (parallel GPU cores) and have them fold all at once (computation using Compute Shader on the GPU). Trying to have the store manager (CPU) do the work by himself is the root cause of this high load.

2. Solution A: Shuriken's noise quality and octave limit.

If it is not possible to migrate from the Shuriken system to another effect system due to game specifications, first make adjustments to reduce the work of the store manager (CPU) to the absolute minimum (lower noise calculation accuracy).

Configuration optimization steps:

  1. Select the GameObject to which you want to attach the target Particle System and open the "Noise" module in the Inspector.
  2. Check the 'Quality' drop-down settings. If it is set to ``High (3D Noise)'' by default, change it to ``Low (1D)'' or ``Medium (2D)''. This simplifies complex noise calculations in 3D space to 1D and 2D, reducing the calculation load by approximately one-third.
  3. Adjust the “Octaves” value. Octave is a setting that superimposes noise to make details finer, but when the value is ``2'' or ``3'', the CPU will perform twice or triple the calculation steps for one particle. Be sure to set this to ``1'' to minimize repeated noise calculations.
  4. Lower the Frequency to slow down the noise recalculation span and reduce calculation overhead.

3. Solution B: GPU-operated “VFX Graph (recommended)

If you want to apply a noise-based fluctuation effect to gorgeous effects where the total number of scattered particles exceeds 1,000 (such as large explosion sparks, violent storms, sandstorms, etc.), completely abolish Shuriken, which requires calculations on the CPU, and replace it with ``VFX Graph'', which performs parallel noise calculations using the GPU Compute Shader.

VFX Graph comes with ultra-high-quality 3D noise modules such as "Turbulence" and "Vector Field" as standard. All of this is processed in parallel by thousands of GPU cores, so even if the number of particles increases to 100,000, the processing load on the CPU's main thread (manager) remains completely **zero**, making it possible to draw smooth random fluctuation effects at 60FPS/90FPS that look cool even on actual mobile devices.