Optimizing the effects

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.