Choose your operating system:
Windows
macOS
Linux
This document assumes prior knowledge of Cascade, the Material Editor, Blueprints, and Matinee along with common effects related performance issues. There are multiple avenues to a performance issue solution. This document attempts to outline how Epic's effects team goes about solving these issues with the tools available.
Common Offenders For Poor Effects Performance
- Overdraw
-
The amount of screen space the particles cover, and the number of instructions on those particles. Overdraw = Number of layers * number of pixels affected. (GPU)
- Tick Time
-
The amount of time it takes the Game Thread to update all particle systems. (Game Thread)
- Draw Calls
-
The state setups to prepare for GPU. (Render Thread)
- Bounds Calculation
-
The amount of time it takes to update the bounds of an effect, which are used to determine visibility based on camera frustum. (Are the effects bounds in view?)
There are many subsets to these primary issues, which generally contribute to the creation of the issue, and for each subset there is usually a tool we use to manage performance issues.
Core Systems For Effect Performance
- GPU
-
The amount of time it takes to draw the pixels on the screen. (Overdraw)
- Game Thread
-
The amount of time it takes to update the particle systems behavior. (Tick Time)
- Render Thread
-
The amount of time it takes to pack particle geometry and associated draw calls. (Draw Calls)
Performance Considerations
Particle counts really play a negligible part in the grand scheme of things when it comes to performance. Regardless of split screen or not, Material complexity and screen coverage (overdraw) are your clear enemies when it comes down to the overall expense of a given system. A simple emissive spark with nothing but a texture multiplied against vertex colors and wired into the emissive input in an unlit Material clocks in at only a handful of instructions. You can pretty much spawn these all day long in droves and your overall performance impact is likely to be very small. The sprites are small which means that screen coverage is low, and the Material complexity makes them cheap and fast to render. The vertex count is not really something you need to care about in the long run unless you are getting up into really extreme numbers (hundreds or thousands or more).
Far more impactful on general performance is going to be the instruction count on your Materials. For Materials like fire and smoke, you basically have two avenues here. The first avenue is to create a more complex Material for your effect. Using fire as an example, you would spawn fewer sprites and let an enhanced Material's randomness and complexity do the work for you in regards to making the emitter come to life. The other option is to use a cheaper Material and spawn more sprites, keeping the overall cost similar but letting the higher particle count do your work in achieving randomness as opposed to the more complex Material. Keep in mind that Material cost is reduced exponentially by decreasing in distance (a quad drawn on the screen twice as far away from the camera costs 4x less due to the total pixel area dropping exponentially with distance, reducing the number of pixels that are being overdrawn).
In your case, you should analyze how expensive your Materials are, how many sprites you are spawning, and how close to the screen you will be getting to these effects. Those three properties are your main decision makers in terms of emitter complexity and they all need to be in balance. Also make judicious use of LOD systems which will adjust sprite count, Material complexity, and other factors as you move near or away from a particle system.
In general, focus on reducing the complexity of your Materials as a way to increase performance, and keep potential overdraw always in your mind as you work on emitters in general. Do not dwell on particle count unless you are spawning extreme numbers of particles, or you are spawning meshes using mesh emitters that have extreme vertex counts.
Once you establish where your issue(s) lie, you can use the following to begin optimizing.