What’s so taxing about the Noise variable in particle system?

In short, the noise module uses a *lot* of maths.

There are 2 main things you can do to make it cheaper, aside from the obvious (fewer particles) ;-)

1. Reduce the Octaves. This is the number of times the noise algorithm runs. Each octave is a layer of noise. If you can make your effect look as good with fewer octaves, you will reduce the time it takes significantly.

2. Use lower quality settings. This also reduces the amount of times the noise maths is executed, but can also make the movement look more repetitive.

Hope it helps!

 

It’s Curl Noise, which is implemented as a “few” Perlin Noise passes. The exact number depends on the quality and octave count.

It can be done with cheaper “value” noise, in exchange for a compromise of visual quality, but I think I opted to only use Perlin. (I’d have to check the code to remind myself 100% though)

EDIT: I checked - we always use Perlin.

 

Ok, to be precise about the numbers:

Quality Low/Medium/High chooses whether to use 1D, 2D or 3D Perlin noise. Each level involves more maths than the previous, but I wouldn't like to try and be more precise about how much more, without really studying it.

To get 1 final noise sample, we call the noise function once per octave.
Then, to get a Curl Noise sample, we repeat the process 3 times, with different inputs. (These results get combined later to get a final "direction of movement" value)

So, for example, for High Quality noise, with 2 octaves, that would be:
(3D Perlin) * 2 * 3 = 6 passes of 3D Perlin Noise.

And for Low Quality noise with 4 octaves:
(1D Perlin) * 4 * 3 = 12 passes of 1D Perlin Noise.

Hope that helps

 

1D Perlin noise needs to evaluate values at two closest grid points, apply a polynomial to the fractional part of the input coordinate and do a single linear interpolation.
3D Perlin noise needs to do the same on a cube = evaluate 8 closest grid points, apply a polynomial 3 times (x,y and z) and do 7 lerps (4 on X, 2 on Y and one on Z dimensions).

N-dimensional Perlin noise does 2^N grid value evaluations, computes N polynomials and does 2^N-1 linear interpolations. Per pass

 

If you need numbers for artist budgets then I think the best way will be to make some example systems with eg 10K particles in each, with various settings (1 system per test scene) and look at the timeline profiler on your target platform to see how long the update job takes in milliseconds for each.

The cost will more-or-less scale linearly with particle count, so you can then start to say things like "if using high quality, 1000 particles will cost you 1ms of update job time". and "if using 2 octaves on that same system, you're up to 2ms".

The main gotcha is, that the particle update is multi-threaded, so if you have 4 worker threads, then simulating 1 particle effect costs the same as 4 (slight over-simplification!).

We also have this, which gives some indication of module costs relative to one-another, but it's very high level, and only uses one (unknown) config for the Noise Module:

Another option is to write a script that called ParticleSystem.Simulate, wrapped with some timing info. Then you could change a setting, re-run, and quickly get an idea of the relative difference each quality/octave count made to a system.

 

PS. Evaluating the polynomials is more expensive than the lerps.