The Effect class manages all the particles and decals which are created in-game. Other actors reference an effect asset, a data only blueprint, and request its creation from the game state.
The Effect class manages all the particles and decals which are created in-game. Other actors reference an effect asset, a data only blueprint, and request its creation from the game state.
On the output side of the node is the reference to the created effect which is in this case discarded. It’s okay because the Effect class manages everything during its lifetime: creation of decals and particles, their decay, the change of the Amount parameter, cleanup of expired elements, etc. There are scenarios where it make sense to keep the effect reference: for example the smoke coming from the exhaust pipe would stay active forever but have its Amount value constantly adjusted in relation to engine torque.
Besides the create-and-forget property of the Effect class the other advantage is that effect editing is decoupled from effect use, they involve different assets, which makes collaboration easier.
Another important feature of this system is that it’s a collection of particle systems and decals: the same particle system or decal can be used in different effects. For example a dust puff particle system can be added to the bullet impact effect (along with a bullet hole decal) while also included in the effect for physics objects sliding on the ground. Reusing effect building blocks is especially handy with iterative development where the particle systems are refined more and more over a longer period of time while in use right from the start.
Now let’s see how an effect is actually set up:
The Elements property is a dynamic array of a struct which looks like this:
This class is not finished yet, the next feature I intend to implement is sound effect support. I almost added dynamic lights but particle systems can create point lights which were good enough so far.