Unreal Engine 5 Documentation has been moved to the Epic Developer Community

ParticleSystems and Cascade , the Particle System editor, are extremely flexible and powerful. However, before you jump in and get your hands dirty, there are some important concepts that you will need to fully grasp. The purpose of this document is to introduce you to these key concepts, giving you a more solid feel for how these aspects of the particle system work, while avoiding the nuances of the user interface or the specifics of particle effect creation.

A Modular Approach to Particle Effects

The primary and overreaching concept of Cascade is that of modularly designed particle systems. In some 3D effects packages, such as Maya, a particle system is created with most of the necessary properties for behavior already in place. The user then alters those properties in order to achieve the desired result.

In Cascade, on the other hand, a particle system begins with only a few bare bones properties and a few behavioral modules.

Each module represents a specific aspect of particle behavior, and contains only the properties that control that behavior, such as color, position at birth, movement, scaling, and many others. The user may then add or remove modules as they see fit, thereby further defining particle behavior. Since only the modules for necessary behavior are added, there is no extraneous calculation of unnecessary properties.

Best of all, modules can be easily added, removed, copied, and even instanced from the emitters within a particle system, making intricate setups very easy to achieve once the user is familiarized with the modules available.

Default Modules

Some modules exist on a particle emitter by default. Whenever a new Sprite Emitter - the key component of any particle system - is added to a particle system, it is always created with the following default modules:

• Required - This contains a variety of properties that are absolutely necessary for a particle system, such as the material applied to the particles, how long the emitter should emit particles, and many others.

• Spawn - This module controls how quickly particles will spawn from the emitter, whether they will spawn in bursts, and any properties related to the timing of particle birth.

• Lifetime - This governs how long each particle will live once it is born. Without this module, the particles will live indefinitely.

• Initial Size - This controls the scale of a particle at the moment of its birth.

• Initial Velocity - This controls the movement of a particle at the moment of its birth.

• Color Over Life - This module controls how the color of each particle will shift throughout its lifespan.

Module Categories

There are many modules that can be added to your particle emitters. To help avoid confusion, these modules are broken up into various categories. These categories are:

For more information on individual particle modules, be sure to check out the Particle Module Reference .

Initial vs. Over Life

Two important concepts to keep in mind when working with particle modules are initial and over life or per life properties.

• Initial modules are used to control some aspect of particles the moment they are spawned into the world.

• Over Life or Per Life modules exist to allow some aspect of a particle to change throughout its life.

For example, an Initial Color module will allow you to set the color of a module at the moment a particle is born, while a Color Over Life property allows the particle color to gradually change between the moment of birth and the moment of death.

Module Time Calculation

If you change a property to a distribution type that changes over time, some modules use 'relative time' and some use 'absolute time' (more on distributions below).

• Absolute time is basically the containing emitter time. If you have an emitter set up for 3 loops of 2 seconds, Absolute time for modules in that emitter will run from 0 to 2 seconds three times.

• Relative time is between 0 and 1, indicating the lifetime of each particle.

Descriptions of the currently available modules can be found at ParticleSystemReference .

Emitters, Particle Systems, and Emitter Actors

As you work with Cascade to create your own particle effects, it is important to keep in mind how each one of the objects relates to one another. In this document, we have already discussed the concept of modules, but they only make up one component of a complete particle effect. All told, the components of a particle system are modules, emitters, particle systems, and emitter Actors. A solid way to remember how they relate is like so:

• Modules , which define particle behavior and are placed within...

• Emitters , which are used to emit a specific type of particle for an effect, and any number of which can be placed within a...

• Particle System , which is an asset available in the Content Browser , and which can then in turn be referenced by an...

• Emitter Actor , which is a placeable object that exists within your level, controlling where and how the particles are used in your scene.

Particle Calculation

It is important to be aware of calculation order when working with particle systems. Each column in the Cascade emitter list area represents another emitter, and each block in the column represents another module. Calculation order runs like so:

• Emitters are calculated from left to right in the emitter list.

• Modules are calculated from top to bottom in the stack.

Emitter Types

Just as there exists a wide variety of effect types that you will want to create with your particles, there is also a variety of emitter types available to help you create exactly what you need. Below is a list of the available emitter types:

It should be noted that all emitters, regardless of type, are sprite emitters at the start. Various emitter Type Data modules are then added to the emitter to change its type to something else.

• Sprite Emitters - These are the most basic types of emitter and the most frequently used. Particles are emitted as polygonal sprites (2-polygon cards) which always face the camera. Useful for smoke, fire, and a wide variety of other effects.

• AnimTrail Data - Used to create trails from the sockets of animated skeletons.

• Beam Data - Used to create beams such as lasers, streaks of lightning, and similar effects.

• GPU Sprites - These are special types of particles in which the bulk of runtime calculation is passed off to the GPU. This boosts the number of possible particles from the several thousand possible with CPU particles to several hundred thousand , depending on the type of GPU in the target system.

• Mesh Data - Instead of emitting a series of sprites, this type of emitter will instead emit polygonal meshes. Great for rock slides, debris, and similar effects.

• Ribbon Data - This produces a string of particles that are attached end to end to form a ribbon which trails behind a moving emitter.

For more information on the different types of emitter available, please see the Emitter Types page .

Parameters

Not all aspects of a particle system can be defined in advance. Sometimes, certain parts of a particle system's behavior will need to be controlled or changed at runtime. For example, you may be creating a magic effect that changes color based on the amount of magical energy consumed when the spell is cast. In such cases, parameters will need to be added to the particle system.

A parameter is a type of property that can send or receive data to/from other systems such as Blueprints, Matinee, a material, or many other sources. In Cascade, just about any given property can be assigned to a parameter, which means that the property can then be controlled from outside the particle system.

For instance, setting up a parameter to control spawn rate for a fire effect could allow for the player to have the ability to increase or decrease the amount of flame being emitted at runtime.

Conversely, there are parameter modules which can be added to a particle system that can, in turn, drive other things in the level such as a color used in a given material.

In Cascade, parameters are generally established by way of Distributions, which are ways to handle data within a property. You can find a general overview of distributions below , or you may read more detailed information about them on the Distributions page .

Lit Particles

Particle systems can be set up to receive light, but require a special setting.

To set up lit particles:

1. Make sure the material is using a shading model other than unlit. Using DefaultLit will allow you access to normal mapping, specularity, etc.

2. In the LODSettings in Cascade (found under the LOD properties, which you can see when all modules and emitters are deselected), there is a flag for each separate LOD called bLit. Make sure that is selected. This flag can only be updated in Cascade.

Following those steps should allow your particles to show up in game as lit. They are lit from the emitter origin so be sure to move the origin around in the world to see the lighting update; or spawn dynamic lights nearby.

Levels of Detail (LODs)

Particle systems can easily become very expensive to calculate. Even when using GPU particles, which offload a great deal of the particle calculation to the GPU, it is important to consider the value of calculating particles from which the player is too far away to see or adequately appreciate.

For instance, consider a particle system of a camp fire. When viewed up close, one might see embers and sparks drifting up into the smoke. However, if viewed from several hundred meters away, those embers would be so small that a monitor or screen would not even be able to render them. So why calculate them?

This is where Levels of Detail (LODs) come into play. The LOD system allows you to set up custom distance ranges at which your particle system will automatically simplify. Each range constitutes another LOD. Simplification takes place in the form of lowered property values, deactivated modules, or possibly even deactivated emitters. For instance, in the campfire example given above, it would be ideal to completely deactivate the emitter that was adding sparks to the overall effect once the player was too far away to see them.

Your particle system can have as many LODs as you need, and you can manually control the ranges for each one.

Distributions

Distributions are a set of data types for handling data in specialized ways, such as using a range for a value, or interpolating a value along a curve. Any time your particle system requires randomization or the ability for some particle aspect to change over time, you will use a distribution to control that property.

Many of the properties found within modules in Cascade can have different distributions applied to them. The actual value for that property is then set within the distribution.

There are 5 primary distribution types:

• Constant - This designates a single static value that does not change in any way.

• Uniform - A uniform distribution provides a min and max value, outputting a random selection from between (and including) the two values.

• Constant Curve - A constant curve provides a single curve over which a value interpolates over time. In this case, time generally refers to the duration between birth and death of a particle, or the start and stop times for particle emission.

• Uniform Curve - A uniform curve distribution provides a min and max curve. The final value is chosen from the point along a graph that sits between these two curves.

• Parameter - This is a type of distribution that allows a property to be parameterized so that it can be manipulated externally via Blueprints, Matinee, or other means.

For more information on distributions and how they work, please see the Distributions page .