UE4 VFX Optimization Guide
2015-08-12 12:31
891 查看
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.
Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. In
its simplest form, overdraw can be described as:
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.
Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.
Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
Appropriately setting the LOD Method can be vital to performance and visuals.
Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effect
necessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.
Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
+1 for
+2 for
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your meshes
low.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.
Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitations
when using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles your
system is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.
There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.
Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. In
its simplest form, overdraw can be described as:
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.
Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.
Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
Appropriately setting the LOD Method can be vital to performance and visuals.
Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effect
necessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.
Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
+1 for
+2 for
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your meshes
low.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.
Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitations
when using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles your
system is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.
There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
VFX
Optimization Guide
On this page:
Detail Mode Overview
Commands
Unreal Engine 4 currently supports switching between 3 detail modes: Low, Medium, and High. In cases involving effects, detail modes are set for Medium, and High detail. This is used primarily for the case of split screen where draw calls can reach performance
lowering levels. The primary objective being to reduce draw calls in Medium detail mode by culling or reducing emission rates.
Changing the value in the Medium Detail Spawn Rate Scale field on an emitter in Cascade, will reduce its emission rate when the game is running in Medium Detail Mode. These settings can be used to reduce overdraw and draw calls depending upon requirements.
In the case of split screen, draw call reduction is key.
How do I determine Draw Calls?
The detail mode can be set in Cascade using the View Menu -> Detail Mode setting, or for the entire Unreal Editor by changing the Quick Settings -> Engine Scalability Settings -> Effects quality
level. Change to Medium to see Medium Detail Spawn Rate Scale and you should see red text displaying the detail mode currently active. It is critical to work in Medium Detail Mode only when adjusting effects for this mode. Changes will not be visible in game
by default, unless your project defaults to Medium Detail Mode.
Medium Detail Spawn Rate Scale is a multiplier, sticking to a 0-1 range will set the appropriate value. Essentially setting to .5 will halve particle emission counts, a value of 1 will use the current emission rate. The values are clamped and will not go above
1.
It is good practice to consider split screen when in the process of placing ambient effects. If the effect is non-essential to split screen and has a high number of draw calls, it might be a good place to start reducing emission counts especially if the effect
consists only of mesh emitters.
It is important to remember draw calls for particles are determined by material, and are a fixed cost regardless of emission count. For example, a 1 pass material on an emitter with an emission rate of 30 is only 1 draw call.
There are several commands which are useful in determining draw call costs.
To switch to Split Screen Mode in Play in Editor or the game, use the console command
If you only have one controller, use the command
View draw calls for a given area using the command
is more of a visual reference.
Viewing the stats in the spreadsheet is straight forward. It should look something like this:
In this case, the fix is pretty straight forward. We have one effect that must call a bunch of meshes and they loop spawn most likely. This can be tricky however, because if one effect is the primary culprit, and you wish to keep the effect's current visuals
there is only one option, convert the meshes to sprites.
If however the emitter is not necessary for split screen, set the
Spreadsheet stat columns are named with appropriate descriptions:
RenderTime ms
How many milliseconds it takes to render the effect.
NumComponents
How many instances of the particle system are in view and active.
NumPasses
How many passes are in the material being called by the emitter.
NumEmitters
How many emitters are in the particle system.
NumDraws
The accumulated number of draw calls for all instances of the particle system.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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.
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.
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)
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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give you
the following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughout
your project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.
Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. In
its simplest form, overdraw can be described as:
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.
Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.
Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
Appropriately setting the LOD Method can be vital to performance and visuals.
Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effect
necessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.
Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
+1 for
+2 for
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your meshes
low.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.
Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitations
when using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles your
system is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.
There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
VFX
Optimization Guide
On this page:
Detail Mode Overview
Commands
Unreal Engine 4 currently supports switching between 3 detail modes: Low, Medium, and High. In cases involving effects, detail modes are set for Medium, and High detail. This is used primarily for the case of split screen where draw calls can reach performance
lowering levels. The primary objective being to reduce draw calls in Medium detail mode by culling or reducing emission rates.
Changing the value in the Medium Detail Spawn Rate Scale field on an emitter in Cascade, will reduce its emission rate when the game is running in Medium Detail Mode. These settings can be used to reduce overdraw and draw calls depending upon requirements.
In the case of split screen, draw call reduction is key.
How do I determine Draw Calls?
The detail mode can be set in Cascade using the View Menu -> Detail Mode setting, or for the entire Unreal Editor by changing the Quick Settings -> Engine Scalability Settings -> Effects quality
level. Change to Medium to see Medium Detail Spawn Rate Scale and you should see red text displaying the detail mode currently active. It is critical to work in Medium Detail Mode only when adjusting effects for this mode. Changes will not be visible in game
by default, unless your project defaults to Medium Detail Mode.
Medium Detail Spawn Rate Scale is a multiplier, sticking to a 0-1 range will set the appropriate value. Essentially setting to .5 will halve particle emission counts, a value of 1 will use the current emission rate. The values are clamped and will not go above
1.
It is good practice to consider split screen when in the process of placing ambient effects. If the effect is non-essential to split screen and has a high number of draw calls, it might be a good place to start reducing emission counts especially if the effect
consists only of mesh emitters.
It is important to remember draw calls for particles are determined by material, and are a fixed cost regardless of emission count. For example, a 1 pass material on an emitter with an emission rate of 30 is only 1 draw call.
There are several commands which are useful in determining draw call costs.
To switch to Split Screen Mode in Play in Editor or the game, use the console command
If you only have one controller, use the command
View draw calls for a given area using the command
is more of a visual reference.
Viewing the stats in the spreadsheet is straight forward. It should look something like this:
In this case, the fix is pretty straight forward. We have one effect that must call a bunch of meshes and they loop spawn most likely. This can be tricky however, because if one effect is the primary culprit, and you wish to keep the effect's current visuals
there is only one option, convert the meshes to sprites.
If however the emitter is not necessary for split screen, set the
Spreadsheet stat columns are named with appropriate descriptions:
RenderTime ms
How many milliseconds it takes to render the effect.
NumComponents
How many instances of the particle system are in view and active.
NumPasses
How many passes are in the material being called by the emitter.
NumEmitters
How many emitters are in the particle system.
NumDraws
The accumulated number of draw calls for all instances of the particle system.
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Core Systems in Cascade - GPU/Game Thread/Render Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
Overdraw - GPU
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. Inits simplest form, overdraw can be described as:
[code]Overdraw = Pixel shader cost = Number of layers * avg number of pixels affected by a layer * avg number of instructions for a layer
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs - Level of Detail - GPU/Game Thread
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
LOD Distance Check Time
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
LOD Method - Game Thread
Appropriately setting the LOD Method can be vital to performance and visuals.Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Fixed vs. Non Fixed Bounds - Game Thread
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effectnecessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw Calls - Render Thread
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
bUseLitTranslucencyDepthPass
+1 for
bUseLitTranslucencyPostRenderDepthPass
+2 for
bUsedWithFogVolumes
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
DumpParticleFrameRenderingStats. This command outputs a spreadsheet which lists draw call costs in detail.
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh Emission - Game Thread/Render Thread
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your mesheslow.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
CPU Collisions - Game Thread
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit - GPU/Game Thread
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitationswhen using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Memory Costs
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles yoursystem is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time - Game Thread
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Core Systems in Cascade - GPU/Game Thread/Render Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
Overdraw - GPU
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. Inits simplest form, overdraw can be described as:
[code]Overdraw = Pixel shader cost = Number of layers * avg number of pixels affected by a layer * avg number of instructions for a layer
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs - Level of Detail - GPU/Game Thread
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
LOD Distance Check Time
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
LOD Method - Game Thread
Appropriately setting the LOD Method can be vital to performance and visuals.Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Fixed vs. Non Fixed Bounds - Game Thread
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effectnecessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw Calls - Render Thread
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
bUseLitTranslucencyDepthPass
+1 for
bUseLitTranslucencyPostRenderDepthPass
+2 for
bUsedWithFogVolumes
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
DumpParticleFrameRenderingStats. This command outputs a spreadsheet which lists draw call costs in detail.
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh Emission - Game Thread/Render Thread
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your mesheslow.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
CPU Collisions - Game Thread
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit - GPU/Game Thread
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitationswhen using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Memory Costs
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles yoursystem is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time - Game Thread
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
VFX
Optimization Guide
On this page:
Detail Mode Overview
Commands
Detail Mode Overview
Unreal Engine 4 currently supports switching between 3 detail modes: Low, Medium, and High. In cases involving effects, detail modes are set for Medium, and High detail. This is used primarily for the case of split screen where draw calls can reach performancelowering levels. The primary objective being to reduce draw calls in Medium detail mode by culling or reducing emission rates.
Changing the value in the Medium Detail Spawn Rate Scale field on an emitter in Cascade, will reduce its emission rate when the game is running in Medium Detail Mode. These settings can be used to reduce overdraw and draw calls depending upon requirements.
In the case of split screen, draw call reduction is key.
How do I determine Draw Calls?
The detail mode can be set in Cascade using the View Menu -> Detail Mode setting, or for the entire Unreal Editor by changing the Quick Settings -> Engine Scalability Settings -> Effects quality
level. Change to Medium to see Medium Detail Spawn Rate Scale and you should see red text displaying the detail mode currently active. It is critical to work in Medium Detail Mode only when adjusting effects for this mode. Changes will not be visible in game
by default, unless your project defaults to Medium Detail Mode.
Medium Detail Spawn Rate Scale is a multiplier, sticking to a 0-1 range will set the appropriate value. Essentially setting to .5 will halve particle emission counts, a value of 1 will use the current emission rate. The values are clamped and will not go above
1.
It is good practice to consider split screen when in the process of placing ambient effects. If the effect is non-essential to split screen and has a high number of draw calls, it might be a good place to start reducing emission counts especially if the effect
consists only of mesh emitters.
It is important to remember draw calls for particles are determined by material, and are a fixed cost regardless of emission count. For example, a 1 pass material on an emitter with an emission rate of 30 is only 1 draw call.
Commands
There are several commands which are useful in determining draw call costs.To switch to Split Screen Mode in Play in Editor or the game, use the console command
debugCreatePlayer 1.
If you only have one controller, use the command
ssswapControllersto jump between players.
View draw calls for a given area using the command
DumpParticleFrameRenderingStats. This command dumps a spreadsheet and a screenshot of where the action took place. This screenshot is an estimation since it is taken after the data is dumped and
is more of a visual reference.
Viewing the stats in the spreadsheet is straight forward. It should look something like this:
In this case, the fix is pretty straight forward. We have one effect that must call a bunch of meshes and they loop spawn most likely. This can be tricky however, because if one effect is the primary culprit, and you wish to keep the effect's current visuals
there is only one option, convert the meshes to sprites.
If however the emitter is not necessary for split screen, set the
mediumDetailSpawnrate to 0.00.
Spreadsheet stat columns are named with appropriate descriptions:
RenderTime ms
How many milliseconds it takes to render the effect.
NumComponents
How many instances of the particle system are in view and active.
NumPasses
How many passes are in the material being called by the emitter.
NumEmitters
How many emitters are in the particle system.
NumDraws
The accumulated number of draw calls for all instances of the particle system.
Particle Systems
On this page:
Common
Offenders For Poor Effects Performance
Core Systems
For Effect Performance
Performance Considerations
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
OverdrawThe 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
GPUThe 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 expenseof 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.
Troubleshooting Links
I am having trouble on the GPU.
I am having trouble on the Game Thread.
I am having trouble on the Render Thread.
Particle System General Topics
VFX Optimization: Balancing Visual Effects with
Performance
VFX Optimization: Core Optimization Concepts
VFX Optimization: Getting Results
VFX Optimization: Split Screen
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Considering
Costs Up Front
Alternative
Means of Creating Effects
Considering Costs Up Front
Often times, creating the effects you need may come down to solid reference footage or images which best showcase key elements. Using reference to break effects down into these key elements can prove to be a huge time saver later on in production and give youthe following information.
What are my key components, and where am I going to spend my performance budget?
What materials, textures, and assets will be required to execute these key elements?
How many particles will I need to execute this effect?
How can I create this effect using the fewest number of material instructions, draw calls, emitters possible?
How will this effect be utilized? Is it key to communicating critical information to the player, or is this icing on the cake that might be the first item to be cut when the scene is not running fast enough?
What else is going on in this scene? What is the view distance? What sort of translucency exists currently? How well is the scene running? How much action (such as combat) is going on?
For each of these questions, a tool exists to get the information. Sometimes good performance can come down to using this information to your benefit.
Alternative Means of Creating Effects
Sometimes, an effect you are tasked with creating might not be a particle effect at all. There are many cases in which it might make more sense to create your effect using a mesh instead of a particle system. For instance, there might be several cases throughoutyour project where you have large columns of smoke and fire off in the distance. To render these columns using particles, we would run into several issues.
The Game Thread cost of updating the particle systems associated with keeping the emitters around ticking.
The GPU cost of rendering large groups of particles, drawing over each other to create a volume.
This can also be the case for instances where you might need to create flowing water or any dense volume which might require large amounts of particles. The cost associated with placing a Static Mesh is significantly lower than the cost of placing and updating
a particle system. In some cases, mixing a Static Mesh with particle systems may yield the most dynamic result. Experiment and find the solution which fulfills your scenario the best.
An effective Effects Artist finds ways of using multiple systems within UE4 to balance visuals with performance.
VFX
Optimization Guide
On this page:
Core
Systems in Cascade - GPU/Game Thread/Render Thread
Overdraw - GPU
LODs
- Level of Detail - GPU/Game Thread
LOD Distance Check
Time
LOD Method - Game
Thread
Fixed
vs. Non Fixed Bounds - Game Thread
Draw Calls -
Render Thread
Mesh
Emission - Game Thread/Render Thread
CPU Collisions
- Game Thread
Spawn Per
Unit - GPU/Game Thread
Memory Costs
Tick Time - Game
Thread
Core Systems in Cascade - GPU/Game Thread/Render Thread
Cascade creates robust particle systems which have dynamic costs spread across three core engine systems in UE4. Game Thread, Render Thread, and GPU.Particle simulation times (Tick) are calculated on the Game Thread.
Particle data finalization (Packing Geometry, Draw calls) are calculated on the Render Thread.
Particle visuals (Shader complexity, overdraw) are calculated on the GPU.
All of these systems calculate parallel to each other, so a slow down on any single system can mean bottlenecks in the rendering process, which equates to low framerate. It is important to consider all 3 processes when creating particle systems in Cascade.
It is also important to note that Cascade runs Particle evaluation on the Game Thread, which is the same location gameplay calculations are done.
Overdraw - GPU
When you add a Material to the surface of a sprite, that Material has a cost in instruction count. For translucent objects, this instruction cost adds up as translucency stacks up, creating overdraw. The more layers of translucency, the higher the cost. Inits simplest form, overdraw can be described as:
[code]Overdraw = Pixel shader cost = Number of layers * avg number of pixels affected by a layer * avg number of instructions for a layer
You can easily see this cost in the Shader Complexity Mode. Bright Red = 300 instructions, pink = 600 instructions, and white >= 900 instructions. Press Alt+8 to view shader complexity on PC.
The instruction count for a Material can be seen in the Material editor.
Shader complexity outputs an approximation of what the cost of a system will be; however, it is also dependent upon the scene since translucency is calculated against opaque objects which also have a cost.
Checking the usage of your effects is critical. An effect which may be called in any given scenario (weapon impact) will generally need to be lighter than an effect you can custom build to match a specific scenario, since it will be drawn in fluctuating cost
scenarios.
Some steps that can be taken to get overdraw impact under control are:
Reduce emission rates.
Reduce Material instruction count.
Reduce particle scale (fill less of the screen).
Create LODs for near/far particle emissions to reduce cost at different view distances.
Check for emitters placed in a line stacking against each other (static placed effects).
LODs - Level of Detail - GPU/Game Thread
LODs in Cascade provide users the ability to control modules and behavior based upon the distance from the player to the emitter. Any attribute in a particle system can be modified to make use of the LOD system.Refer to the Particle System Level of Detail
(LOD) section of the Cascade Reference Guide for more
technical information on setting up LODs.
It is important to keep in mind when creating LODs, there are memory costs associated with unshared modules. Sharing as many modules across LODs as possible reduces memory footprint. Only create unique module settings for the attributes you wish to modify.
The preview modes in Cascade and the editors perspective view behave in different ways. In order to get proper viewing in Cascade, make certain to set the View -> Detail Mode to High.
Cascade allows for a switch between LODs and displays the LOD specified. Be certain to disable the Editor LOD view mode in order to see Cascade update correctly.
Enabling the editor preview grants the ability to fly through the scene and see the particle systems switch between LODs as you move around.
It is important to measure the scene and get a realistic idea of just how many units are needed to see effects in the proper state. In the case of ambient particle systems, it is possible to emit 0.00 particles and reduce tick time when the particle systems
might not be visible. Measuring distance can be done by holding down the middle mouse button and dragging in any orthographic view (front, side, top.)
LOD Distance Check Time
The LOD Distance Check Time feature dictates how often the game checks the distance of the player to the emitter placed in the scene to determine which LOD to use. LOD Distance Check Time works when the LOD Method is set to automatic.Automatic essentially lets the game determine the LOD as you play. If you increase the LOD Distance Check Time, the amount of time between checks will increase. LOD DistanceCheckTime is calculated in seconds, so consider your player's max movement speed when
setting this. If you set LOD Distance Check Time to a value of 0.00 the distance is checked every frame, which may equate to lower performance.
LOD Method - Game Thread
Appropriately setting the LOD Method can be vital to performance and visuals.Automatic - the game will set the LOD based on the distance parameters defined in the effect, using the LOD Distance Check Time settings. Typically used on ambient effects which loop and are not called by game code.
Direct Set - the LOD is determined (typically by game code) when the effect is spawned and stays at the LOD defined. Typically used in burst effects like explosions or impacts.
Activate Automatic - The LOD is defined when the effect is spawned, based upon the distance parameters defined in the LOD. Typically used on burst effects called by Blueprints etc. which require LODs to never shift once spawned.
Fixed vs. Non Fixed Bounds - Game Thread
Bounds are one of the ways in which the engine determines visibility of an effect. These invisible coordinates tell the engine if an effect is in view or out of view. If a corner of your bounds is visible, the engine will calculate any components of the effectnecessary.
Bounds are costly the check and update each frame, therefore it is a good idea to set your bounds to be fixed and determine how large bounds need to be. In some cases, you might want your bounds to be rather large if you need to see every piece of debris flying
out of an explosion. If you wish to keep costs low, tightening bounds to core components can increase performance, at the risk of effects popping off when the bounds go out of view.
There are some considerations for fixed vs. non-fixed bounds to keep in mind.
Fast moving effects such as rocket trails, tracers, or anything attached to a projectile etc. should not have fixed bounds set nor have the fixed bounds set so large that the emitter cannot fly outside of the bounds.
When setting bounds, be aware of local vs. world space coordinates defined in your system. If an emitter is rotated the opposite direction of your bounds orientation, it is possible for elements of the effect to fly out of your bounds and elements popping out
of view can occur.
Draw Calls - Render Thread
Draw calls within particle systems can be tricky to track at times. There are several combined factors to keep in mind when determining draw call costs.Sprite particle emission is 1 draw call per emitter, regardless of screen orientation.
Mesh emission is 1 draw call per mesh emitter, regardless of the number of meshes emitted. However, on mobile devices the cost is 1 draw call per mesh emitted. So, on a mobile device, if you have 2 emitters in your effect, each emitting 10 meshes,
you have a total cost of 20 draw calls associated with that particle system.
Material passes also determine draw call costs. The more passes in your Material, the more draw calls in your effect.
For Instance:
Particle System A consists of: 1 emitter, spawning 12 sprites, using a Material with 1 Pass, the entire system costs 1 draw.
Particle System B consists of: 1 emitter, spawning 12 sprites, using a Material with 2 Passes, the entire system costs 2 draws.
Particle System C consists of: 1 emitter spawning 12 meshes, using a Material with 2 Passes
On mobile platforms: the entire system costs 24 draws. (2 passes per call X 12 meshes since each mesh is a single draw call = 24 draws.)
On all other platforms: the entire system costs 2 draws.
Particle System D consists of: 1 emitter spawning 6 meshes, using a Material with 2 Passes, and 1 emitter spawning 10 sprites with 1 pass the entire system costs 13 draws. ( 2 passes per call X 6 meshes since each mesh is a single draw call = 12 draws, 1 pass
X 10 sprites = 1 draw call.)
Material Attributes which contribute passes include:
Translucent Material = 1 pass base
+2 for distortion
+1 for
bUseLitTranslucencyDepthPass
+1 for
bUseLitTranslucencyPostRenderDepthPass
+2 for
bUsedWithFogVolumes
Opaque / masked Material = 2 passes base
Draw calls for a particular scene can be viewed using the command
DumpParticleFrameRenderingStats. This command outputs a spreadsheet which lists draw call costs in detail.
Impact from draw calls increases proportionally to the number of views being rendered. This means that in split-screen, the effects are multiplied. See the VFX
Optimization: SplitScreen page for more detailed information on optimizing effects for split screen.
It is important to keep these costs in mind when constructing your effects, and when optimizing effects. If your render thread is high due to draw calls, and the environment is within budget, this is the place to start looking.
Mesh Emission - Game Thread/Render Thread
Mesh emission is one of the more powerful features of Cascade. It is a feature which can be accidentally abused on mobile devices as the emission rate equates to the number of draw calls. Further, it is also a good idea to keep the vertex count on your mesheslow.
In some cases, a single mesh emission can be used to fake a large volume of objects without the cost of calculating the positions all of the sprites which would be needed to create a volume of debris for instance.
CPU Collisions - Game Thread
Typically there is a high cost associated with doing CPU particle collision in Unreal Engine 4, so they should be used only when needed.Several settings can be used to minimize collision costs these include:
MaxCollisions: keep this value as low as possible.
Collision Completion Option: set this to HaltCollisions/Freeze to stop doing collision checks against the scene once MaxCollisions is reached.
The Damping Factor determines the bounce of objects following collision, lower values may result in objects coming to rest faster (lower Max Collisions value).
Spawn Per Unit - GPU/Game Thread
Spawn Per Unit is a feature in Cascade which is helpful for filling in gaps when particle systems are moving. While this feature is handy for creating great looking trails of particles, it is important to balance visuals with performance limitationswhen using Spawn Per Unit.
There are a few tricks to controlling emission:
Keep the Unit Scalar to a value as high as possible, and balance it with the emission rate to get the fill you need, without making the effect too heavy.
Try and use lower instruction count Materials if you know you are going to have high emission rates using Spawn Per Unit.
Adjust the Max Frame Distance to limit how many particles can be emitted. If the emitter goes above this, Max Frame Distance Spawn Per Unit will cease emission until it returns below the distance. This prevents the emitter from dumping large amounts of sprites
into the scene.
Memory Costs
Cascade offers the ability to display large amounts of valuable information relative to particle system creation. It is often helpful to turn these displays on to get a good idea of just how many particles your system is allocating, and how many particles yoursystem is emitting.
Particle Allocation determines how many particles it is possible for the emitter to place in the world at any given time, this plays a large part in determining how much memory your particle system will consume. You can see a memory estimation by enabling the
particle memory overlay in the View drop down menu in Cascade.
By adjusting settings, it is possible to see memory cost increase and decrease.
Several ways to reduce memory footprint include:
Reduce the number of modules in a system to the essential modules required for a given behavior.
For looping effects reduce Loop Time/Duration (allocates fewer particles per loop).
Reduce Lifetime (fewer particles overall).
Share as many modules as possible.
Cascade features the ability to share modules from one emitter to the next. Using this feature has two benefits. First, if you wish to edit values across multiple emitters it is possible to edit one module and update all other settings. Second, sharing modules
reduces memory footprint since the cooked version sees the module cost as one instance of the module.
A more recent addition to the Cooker evaluates all modules in a particle system and determines identical modules, then shares modules to automatically reduce memory footprint at cook time.
Tick Time - Game Thread
Tick Time represents the amount of time spent updating particle systems in the scene. Tick Time can be viewed with the stat particles command which lists out all relative information required to assess particle evaluation costs.There are many methods which can be used to reduce Tick costs.
Tick Time is directly influenced by the number of active EmitterActors in your scene. The more active emitters in the scene, the higher Tick Time will be. Emitters should only be set to autoActivate if they are required to loop when the level starts.
If large amounts of sprites/explosions/burst effects are visible on level load in the editor, these effects are automatically evaluated at run time and can cause visible hitching when a level is loaded.
A Particle Parameter can be used in an effect to allow for position offsets once the effect is placed in the world. By using a particle parameter, it is possible to reduce emitter counts, which reduces tick cost overall. Particle Parameters can be setup by
selecting particleParameter from the distribution list in the module for the individual setting.
It is possible to stream out and disable EmitterActors when they are not in view, or if they are associated with an area of a level which is no longer in memory. Streaming EmitterActors with level geometry is a good practice to reduce tick overhead. In some
cases where atmospheric effects are heavy, Blueprint actions can be used to toggle atmosphere off and on during combat sequences to lower tick time and overdraw.
Particle Systems loaded into memory, but out of view (say on the floor above you) can also be toggled with Blueprint actions and streaming volumes to reduce evaluation costs.
In some cases, a mesh effect can be a good replacement for a particle system. A placed Static Mesh does not have an evaluation cost on the Game Thread. In many cases it is more beneficial to place a Static Mesh as a replacement for a particle system. This includes
vista effects, fog effects etc.
Particle counts play directly into evaluation cost. The more particles in a scene, and the longer they live, the more evaluation is required. Limiting lifespan to the duration required for the effect is good practice all around.
Enabling LODs in particle systems allows for lower particle emissions when a system is not within optimal viewing range. It may help to think of your effect in terms of a hero state, and an acceptable level of lower quality for longer viewing distances. Tightening
LODs to required distances can go a long way to lowering evaluation costs in a scene without dramatically losing visual quality.
Check your effects for expensive evaluation costs which can be lowered such as collisions, non-fixed bounds, and spawn per unit counts which are too high. Setting bounds to a fixed state can increase performance significantly and should be used whenever possible.
VFX
Optimization Guide
On this page:
Detail Mode Overview
Commands
Detail Mode Overview
Unreal Engine 4 currently supports switching between 3 detail modes: Low, Medium, and High. In cases involving effects, detail modes are set for Medium, and High detail. This is used primarily for the case of split screen where draw calls can reach performancelowering levels. The primary objective being to reduce draw calls in Medium detail mode by culling or reducing emission rates.
Changing the value in the Medium Detail Spawn Rate Scale field on an emitter in Cascade, will reduce its emission rate when the game is running in Medium Detail Mode. These settings can be used to reduce overdraw and draw calls depending upon requirements.
In the case of split screen, draw call reduction is key.
How do I determine Draw Calls?
The detail mode can be set in Cascade using the View Menu -> Detail Mode setting, or for the entire Unreal Editor by changing the Quick Settings -> Engine Scalability Settings -> Effects quality
level. Change to Medium to see Medium Detail Spawn Rate Scale and you should see red text displaying the detail mode currently active. It is critical to work in Medium Detail Mode only when adjusting effects for this mode. Changes will not be visible in game
by default, unless your project defaults to Medium Detail Mode.
Medium Detail Spawn Rate Scale is a multiplier, sticking to a 0-1 range will set the appropriate value. Essentially setting to .5 will halve particle emission counts, a value of 1 will use the current emission rate. The values are clamped and will not go above
1.
It is good practice to consider split screen when in the process of placing ambient effects. If the effect is non-essential to split screen and has a high number of draw calls, it might be a good place to start reducing emission counts especially if the effect
consists only of mesh emitters.
It is important to remember draw calls for particles are determined by material, and are a fixed cost regardless of emission count. For example, a 1 pass material on an emitter with an emission rate of 30 is only 1 draw call.
Commands
There are several commands which are useful in determining draw call costs.To switch to Split Screen Mode in Play in Editor or the game, use the console command
debugCreatePlayer 1.
If you only have one controller, use the command
ssswapControllersto jump between players.
View draw calls for a given area using the command
DumpParticleFrameRenderingStats. This command dumps a spreadsheet and a screenshot of where the action took place. This screenshot is an estimation since it is taken after the data is dumped and
is more of a visual reference.
Viewing the stats in the spreadsheet is straight forward. It should look something like this:
In this case, the fix is pretty straight forward. We have one effect that must call a bunch of meshes and they loop spawn most likely. This can be tricky however, because if one effect is the primary culprit, and you wish to keep the effect's current visuals
there is only one option, convert the meshes to sprites.
If however the emitter is not necessary for split screen, set the
mediumDetailSpawnrate to 0.00.
Spreadsheet stat columns are named with appropriate descriptions:
RenderTime ms
How many milliseconds it takes to render the effect.
NumComponents
How many instances of the particle system are in view and active.
NumPasses
How many passes are in the material being called by the emitter.
NumEmitters
How many emitters are in the particle system.
NumDraws
The accumulated number of draw calls for all instances of the particle system.
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- NGUI Widget
- UE4 Editor Viewport Options
- UE4 Editor Viewport Show Flags
- Android应用开发多线程基础之Handler，Looper，Message，MessageQueue，Runnable之间的关系
- Android xUtils 的@Unique说明
- String,StringBuffer与StringBuilder的区别。
- 浅谈Atlassian产品搭建的敏捷管理体系（二）——Confluence使用
- Deep Analysis UIImageJPEGRepresentation&UIImagePNGRepresentation
- RequiredFieldValidator控件验证不能为空时报错多种解决方法以及问题分析
- 关于代码手写UI，xib和StoryBoard
- HDU 1896 【留个使用priority_queue容器的样例】
- DedeCMS Error: (PHP 5.3 and above) Please set 'request_order' ini value to i报错解决方法
- UITableViewCell的选中时的颜色设置
- easyui 窗口的onBeforeClose 使用
- 【Mui】后台框架之表格控件
- UVa 10190 - Divide, But Not Quite Conquer!
- UVa 12167 & HDU 2767 强连通分量 Proving Equivalences
- 使用 spice-guest-tools 让虚拟机支持spicec 双屏显示
- iOS中的NSValue
- KMP算法的next、next value数组代码实现及POJ3461