Since your mod most likely has a
lot of stuff happening simultaneously, it is a good idea to optimize all
the particle effects to minimize their CPU usage. We don’t want the
frame rate to drop drastically every time you start a cool particle effect
now do we? This section gives some pointers for advanced users on how to
extract the best performance from their particle effects.
The number of particles:
This is the most rudimentary way to reduce the effect’s CPU usage.
In general, try to create your effect using as few particles as possible.
Also make sure to set the number limit to roughly the same number as the
effect uses. This way, no extra memory is wasted on particles that never
occur. Watch the frame rate counter when adjusting the amount of
particles. As a guideline, small, frequently triggered effects such as
bullet impacts should be done with 10-40 particles, explosions should be
around 150-200 particles and large snowstorms some 400-600 particles.
Particle size: It
is a known fact that huge screen-filling particles cause fill rate
overhead. Use them wisely, only a few at a time.
Emission Rate: If
your cycle lasts 0.1 seconds and the effect is set to use 20 particles
maximum, there is no point in using a massive emission rate that emits and
replaces 20 000 particles during the cycle, out of which only 20 remain
alive. Lower the emission rate so that it is in par with the maximum
particle limit.
Rapid Cycle Looping:
If your emission cycle is very short and set to loop, the frequent
re-starting of the effect causes some CPU overload. Use only in special
cases. For steady looping effects found in levels, such as steam coming
out of sewers or a fire in a fireplace, the optimum effect length is 5 to
10 seconds, and the looping of the effect set on from the script, not from
the editor.
Particle Lifetime:
The particles continue to live even when they’ve fallen out of the
level – they do not collide. For falling debris, set the lifetime of
the particles just long enough for them to reach the edges of the room.
Graph Samplerate:
If you use the graph only for a constant value (horizontal line) or a
linear ramp, there is no point in having the sample rate at 16. Lowering
it to 2 does the job just as well. If you don’t use some values at
all (for example, when using the particle effect only as a light), make
sure to reduce the sample rates of them minimum. The editor sets 16 as the
default rate for all graphs, used or not.
Effect Overall Radius:
The further the particles travel from the emission center, the larger the
overall radius of the effect. Very large effects or very long smoke trails
will need to be drawn inside every room that is inside the effect radius,
causing overhead. Try to ensure that the radius of the effect
doesn’t grow too large.
Use the lights wisely:
If your muzzle flash effect has several separate flames coming from here
and there, it’s still enough to use only one light. Using 4 lights
in one particle effect is a bad, bad idea in terms of overhead. A good
idea can be to handle the lighting with a separate dummy emitter (with
everything else but the light set to minimum/disabled) and a dummy particle.
Rarely use the Light Falloff Graph:
Whenever the light radius changes, the level geometry is re-tessellated to
accommodate the light. Changing the light radius a lot causes CPU
overhead. Only use it in special cases.
Combine the bitmaps: Once
you’ve built a set of particle effects for the game, include all the
particles it uses into the _All_Particles.pse file. All the bitmaps will
be combined into one large bitmap, so several different effects can share
the same bitmaps. This helps to save texture memory, especially if your
effect has several different particle types that all share the same
bitmaps.