Emitters

Document Summary: A reference to properties-based emitter editing and creation. (non UDN build).

Document Changelog: Updated by Tom Lin for 2226 build and reorganization. Original Author: Lode Vandevenne.

Emitters are actors you can drop into your level that will spawn particles. Using a huge amount of properties, you can tell the emitter what kind of particles to make, how many, how the particles will move and more. Almost any effect you can think of is possible with particles, given the right parameters. You can make fire, rain, snow, waterfalls, smoke, fireworks, lightning and much more. This is the fun stuff!

To add a working Emitter in your map, first you have to select the Emitter in the Actor Class Browser, it's directly in the Actors list.

Add the Emitter in your map at the place where you want the effect. In the editor, the Emitter looks like 5 colored dots.

This Emitter will not do a lot on it's own, it's just a placeholder for one or more sub- emitters, called ParticleEmitters. This is slightly confusing. The "Emitter" itself is simply a convenient way to group one or more "ParticleEmitters" that do the actual work. Open the properties of the Emitter and expand the "Emitter" field. Click on Emitters (you can't expand this yet, because it's empty now) and press the Add button that appears. Now Emitter[0] (which is one of the aforementioned ParticleEmitters gets created in the list.

For example, this is an Emitter with 6 total emitter slots in it. 2 of the places are filled (one with a SparkEmitter and one with a MeshEmitter), and the other 4 are still empty.

There you can enter the amount of Acceleration you want along the X, Y and Z axis. You can enter negative values too. If you assume that the upper part of the Top View is the North, here's what the settings do:

If X > 0, the particle will go to the East If X < 0, it'll go to the West If Y > 0, it'll go to the South If Y < 0, it'll go to the North If Z > 0, it'll go to the ceiling or sky If Z < 0, it'll go to the ground The total acceleration is the sum of these 3 components, so if X = 425, Y = -950 and Z = -950, the particles will go to the North-East and down, and will go to the North with more acceleration than to the East. However, if you rotated the Emitter actor with the Rotation tool, this won't be correct anymore, the CoordinateSystem will be rotated then. The X-axis will then be the direction of the arrow if you set bDirectional to True in advanced. Once you gave it some acceleration, you'll see the particles move.

Collision can make the particles realistically bounce on walls, floors or ceilings. It looks for example like the animated gif:

If you have no Collision, the particles will just disappear in the wall:

But if you set UseCollision to True, the particles will bounce on the wall. If they hit the wall perpendicularly, they will bounce back to from where they came as on the first screenshot, in any other case they'll bounce like on the second screenshot. Note that collision doens't work if the coordinatesystem is PTCS_Relative.

On every screenshot, the Z value of the DampingFactor is modified to alter the "bounciness" of the particles. It's the Z value that's used, because in this case the particles are bouncing on the Z-axis, to the floor. If the DampingFactor is "1" they can keep and keep bouncing as long as they live, as shown on the first screenshot. If you make it lower than 1, for example 0.9, they'll bounce less high every time they hit the ground, as in the second screenshot.

If you make the DampingFactor higher than 1, for example 1.5, the particles will bounce higher and higher (1st screenshot). If you give a different Min and Max value, every particle will bounce randomly something between the Min and Max value (2nd screenshot).

First choose a color, for example red. Then you need to enter a RelativeTime. This time depends on the LifeTime of the particles (you can set this in Time), and on the ColorScaleRepetitions value. The RelativeTime does NOT depend on the MaxParticles, so if you have too few MaxParticles, it might be the LifeTime is too long. Then you'll have to make more MaxParticles, or reduce the LifeTime. If ColorScaleRepeats is at it's default value of 0, and RelativeTime = 1, the particles will be their own texture color (in this case blue) at the start of their Life, and will have finished fading to red at the end of their life.

If RelativeTime = 0.5, they will have Faded to red in the half of their LifeTime, and then get their original color back (first screen). If RelativeTime = 1.5, the particles will never get read (they die already at "1"), but you will see the fading process already (second screen)

You can also set more than one Color by adding more ColorScales. Then you can set as many Colors and RelativeTimes as there are ColorScales.

If you want the particle to be red at the beginning of it's life already, set the RelativeTime of the red color to 0.

Remark: the color the particle will get depends on the Color you entered in ColorScale, but also on the color of the texture from the particle itself. On a black particle, the ColorScale will not be visible at all, on a white texture it works at it's best. In the examples above, the texture was blue.

With these fields you can make your particles fade in or fade out. You can also make only a few of the colorchannels to Fade, so for example the red and green parts of the texture will be invisible while the blue parts are always visible.

On the screenshot, the particles have a LifeTime of 5 and a FadeInEndTime of 5, so they are 100% visible at the moment they die:

• W: corresponds to the alpha value.
• X: corresponds to "Red"
• Y: corresponds to "Green"
• Z: corresponds to "Blue"

If the values are 1, they Fade normally. If you make for example X = 0, the red channel will get changed 0%, so while the other colors are invisible (this is at the start of a FadeIn, or the end of a FadeOut), the red will still be visible (left part of the first screen). Or when Y = 0, the green will still be visible (right part of the first screen). If X and Y are 0, both will be visible, it looks somewhat yellowish here (left part of the second screen). If X, Y and Z are 5, the whole texture will get super-invisible so it Fades out much faster (right part of the second screen). If X, Y and Z would all be 0, the texture wouldn't get invisible at all.

• W: corresponds to the alpha value.
• X: corresponds to "Red"
• Y: corresponds to "Green"
• Z: corresponds to "Blue"

If you use a FadeIn AND a FadeOut, the effect will look like the first screen if FadeInEndTime is smaller than FadeOutStartTime (here 1 and 4), and it'll look like the second screen if FadeInEndTime is larger than FadeOutStartTime (here 4 and 1)

With this, it's possible to make the particles get affected by other objects that are flying around. For example to shoot a projectile through smoke and have the smoke smoothly and realistically dissipate. To make this work, you have to set UseActorForces to True, and the projectile or whatever other object going through it must have Forces enabled. I tried this with a Flappy (an animal) running through some particles. So in the properties of the Flappy, the projectile or whatever else go to Force, and set ForceType to FT_DragAlong. Also set a ForceScale (how big the Force is) and a ForceRadius (the radius of the Force).

If now the Flappy runs through the particles (because it fears my grenade launcher), some of them will fly away. Of course you can make this effect looking much better with nice smoke and projectiles.

Auto Destroy creates an actor that will delete itself when it no longer has particles. You will need to recompile the package the script was exported to in order for it to work or show up in the editor.

?? autoreset

With these settings you can make the particles start somewhere other than at the Emitter itself. There are several options here, but many of them are ignored depending on other settings. Read on for more information.

To give the particles a random StartLocation, you can use StartLocationRange or SphereRadiusRange. First you have to choose if you want this random StartLocation to be inside a sphere or a box: set StartLocationShape to PTLS_Sphere for a sphere, or PTLS_Box for a box.

If you use PTLS_Sphere, you have to set a minimum and maximum radius in SphereRadiusRange. The particles will then start somewhere between these 2 radii.

This is pretty complicated. The X, Y, and Z variables in StartLocationPolarRange are mapped to theta, phi, and r respectively in the standard polar equation. Basically, this makes a hollowed partial-sphere with radius r. It will sweep longitudally theta degrees and latitdually phi degrees.

If you use PTLS_Box, you can set 6 values to determinate the 6 sides of the box: X(Min), X(Max), Y(Min), Y(Max), Z(Min) and Z(Max). For example if you set X, Y and Z(Min) to -150 and X, Y and Z(Max) to +150, all the particles will start inside a 300*300*300 box.

• PTLS_Box
• PTLS_Sphere
• PTLS_Polar
• PTLS_All

Note that PTLS_Box and PTLS_Sphere work in combination with [[#StartLocationOffseT ][StartLocationOffset]], so the final StartLocation is the sum of those. Also note that you will never want to use the PTLS_All option.

More about the shapes and effects you can tweak with these settings is in the section Shapes.

Mesh Spawning uses the vertices of a static mesh to calculate the spawn location, and optionally the velocity and the color of the particles in this emitter. The static mesh does not have to exist in the world, nor do the faces of the spawning static mesh matter. This means that you can make arbitrary shapes for static meshes in a modeling program to make a framework for particle spawning. You can also use existing static meshes in the world and attach effects to them to produce results like a bush on fire.

This is the threshold for the Normal Direction. This will only work if Spawn Only In Normal Direction is true.

Mesh Scale is the scale of the Static Mesh. Given that this is a range, a random number in the range is chosen for every particles spawned.

Mesh Spawning Type	Description
PTMS_None	Off. The mesh spawning is not used at all.
PTMS_Linear	The particles will be spawned on each subsequent vertex based on numbering of the vertices.
PTMS_Random	The particles will spawned on a random vertex.

This is the static to use for the mesh spawning. Select a mesh in the mesh browser and click "Use".

(Note: Do not use with Respawn Dead Particles = true!)

This will only use the normals within Normal Direction Threshold of Normal Direction to spawn particles.

This will cause only the X component to be used to uniformly scale the mesh. With will prevent stretching and squashing and just change the size of the static mesh.

Uniform Velocity Scale will cause the only the X component of the Velocity Scale to be used to uniformly scale the velocity.

This will use the normal of each vertex to determine the initial velocity of each particle. This is a Boolean toggle, which tells the engine whether or not to use the values in VelocityScaleRange, below.

This scales the velocity from the mesh normal. For example if you have a mesh sphere with outward facing normals, you can set the Velocity Scale to negative values and the particles will move inwards towards the center of the sphere.

This are the same Object settings as any normal actor has (the Emitter itself has it too), but this time it's for the ParticleEmitter. The Group settings are missing here, and you can't change any of the values, you can just check the Class and Name of the ParticleEmitter here.

While "Rotation" rotates individual particles about their center, "Revolution"rotates particles about a fixed point in space. Using Revolution will cause the particles to change position.

These settings will allow your individual particles to spin during their lifetimes. Rotating particles is one of the biggest tools at your disposal for making particle systems that look convincing, as it helps to break up visual repetition a great deal. You'll be spending a lot of time with the following fields.

Here you can set your particle sizes. It's possible to set them in a fairly random manner, or to control the size more with SizeScale settings over the lifetime of the particle.

Below is an example of the RelativeSize and RelativeTime over two SizeScales.

If you enter a different X(Min) and X(Max) value, the particles will get a random size.

If you want to use the SizeScales, you have to set UseRegularSizeScale to False.

• PTSU_None : Off. Skeletal location is not used at all.
• PTSU_SpawnOffset: The particles will spawn at bone locations but once the particle is spawned, it will not be affected by the mesh. This is good for particle trails - imagine a streamer, or a ribbon.
• PTSU_Location : The particles will spawn at a bone location and will continue to be affected by the location of the bone but not the rotation. This is useful if you want to keep the particles tightly tied to the spawning mesh.

• Pitch: 1.0 is the default pitch.
• Probability: the chance that this sound will play if it is told to play. The sound will be told to play based on Spawning Sound Probability or Collision Sound Probability.
• Radius: The distance from the sound at which it will be audible. This is not given in Unreal units.
• Sound: To set a sound, select a sound in the sounds browser and click "Use."
• Volume: This takes only values between 0.0 and 1.0. 1.0 is the standard volume and it can only be made quieter.
• Weight: This field is obsolete. Ignore it.

For the example screenshots, the blue texture does not have an alphachannel. The second multicolored texture has an alphachannel that has 16 dark dots, like this:

PTDS_Regular makes the texture opaque, so it's a non-transparent square.

PTDS_AlphaBlend makes the darker parts of the A-channel of the RGBA texture more transparent than the bright parts. Black becomes 100% transparent (invisible) and white becomes 100% opaque. Grey becomes semi-transparent. This effect is not very visible on bright textures.

PTDS_Modulated makes the texture some sort of inverse translucent: it makes the brightest colors of the texture more transparent than the darkest colors, so black becomes opaque, white becomes 100% transparent (invisible). Grey, red, blue, etc... become semi-transparent.

PTDS_Translucent makes the darkest colors of the texture more transparent than the brightest colors, so white become opaque, while black become 100% transparent (invisible). Grey, red, blue, etc... become semi-transparent.

PTDS_AlphaModulate makes the actual RGB texture brighter on places where the alphachannel is darker. It looks somewhat the opposite of AlphaBlend. This effect isn't good to see on very bright textures.

PTDS_Darken makes the colors of the texture negative and translucent.

PTDS_Brighten makes the texture to brighten the background, so the texture becomes translucent and brighter than it's original version.

As you can see, the alphachannel of an RGBA8 texture is only used for the DrawStyles AlphaBlend and AlphaModulate.

Use the SubdivisionEnd and SubdivisionStart values if you want only a few Subdivisions of the texture to be used. Subdivision 0 is the Subdivision in the upper left corner of the texture, Subdivision 1 the one below that, and the last one is in the lower right corner of the texture. This picture shows the numbering:

If you want to make some of your subdivisions last longer than others, you can use the SubDivisionScale feature. We'll use the above image as an example.

First select SubDivisionScale in the properties and press the add button there 3 times, so there are 3 SubDivisionScales. This will make 4 of the 9 Subdivisions be active. If you want the 9 Subdivisions to be used, you have to make 8 SubDivisionScales. If you make less than 8 SubDivisionScales, the last Subdivisions will never appear. There's also nothing fatally wrong with making too many SubDivisionScales, the extra ones will just be ignored.

The SubDivisionScale looks pretty straightforward: it's a single number that is relative to the LifeTime of the particles, so a SubDivisionScale of 1.0 will last for the entire particle LifeTime.

Each SubDivisionScale represents a certain point in the LifeTime of the particle. For example if the LifeTimeRange is 4 seconds, a SubDivisionScale of 0.25 is the end of the first second of the LifeTime. A successive SubDivisionScale should always be larger than the previous one, otherwise you're going back in time and it will be ignored.

For example, if you make Subdivision [0] = 0.1, [1] = 0.3 and [2] = 0.6, and LifeTimeRange is 4 seconds:

• the particle will have Subdivision 1 for 0.4 seconds
• Subdivision 2 will last for 0.8 seconds (0.3 x 4 = 1.2, 1.2 / 0.4 = 0.8)
• Subdivision 3 will last for 1.2 seconds (0.6 x 4 = 2.4, 2.4 / 1.2 <Subdivision 2 lifetime. = 1.2)
• Subdivision 4 for the remaining 1.6 seconds. On the screenshot, the particles move from left to right.

If you make SubDivisionScale [0] = 0.4 and [1] = 1, only two of the Subdivisions will be used. Then it doesn't matter anymore what value you entered in [2].

To get this effect at it's best, you have to use the correct LifeTimeRange and also make sure the MaxParticles value is high enough. Read sections General and Time for this.

Setting these settings to 0 or 1 does exactly the same thing: it divides the texture into 1 Subdivision, meaning there are no Subdivisions at all (the Subdivision is the texture itself), so the particles will look like this:

If you set both TextureUSubdivisions and TextureVSubdivisions to 3, it looks like this:

If you set them to 2 or 4, some pictures of this texture will be cut into half, because it has 3 * 3 Subdivisions and isn't made for other values.

If you set respectively TextureUSubdivisions=1 and TextureVSubdivisions=3 or TextureUSubdivisions=3 and TextureVSubdivisions=1, it'll look like this:

If you set UseRandomSubdivision to False, the particles will change during their LifeTime. For example if you'd have 2 * 2 Subdivisions, then first they'll have the upper left Subdivision, then the bottom left, then the upper right and finally the bottom right. The time it takes to change from one Subdivision to another, depends on their LifeTime, more about this further in the section Time. On the screenshot, there are 9 Subdivisions.

and then rotate the camera 180 degrees, wait an hour and then look again at the Emitter, you'll still see exactly the same image (where the warmup is not finished yet). When you can't see the Emitter actor, but you should be able to see some particles, you'll not see these particles! Only when you can see the Emitter itself, you'll be able to see its particles. If you'd rather have it calculate particle movement offscreen, set SecondsBeforeInactive to 0.000000.

Triggering allows you to change the behavior of an emitter when it is triggered. You can trigger an emitter just like everything else in Unrealed by setting the Tag of the Particle System to be that of an Event of a trigger. It is important to note that the Tag is not specified per emitter but for the entire particle system. Each emitter can configure how it handles the trigger differently but they will all receive the same trigger event at the same time. Triggers are use mainly to turn emitters on and off in different ways. This trigger system provides good ways to turn emitters on but it unfortunately does not provide a very smooth way to turn emitters off.

In this image, there is a particle system with movement along the Z-axis. The first image shows the particles going straight up. The second image shows the same particle system with the AddRadial applied. The third image shows the AddRadial applied, with a higher overall value on the RadialRange. This causes the particles to reach the center and continue past, in the direction they were headed, until their lifetime ends.

If Min and Max are the same, you get what you would expect: the particle moves with the speed you entered to the direction you used. If the values are not the same, you'll get a random velocity between those two values. For example, if you set X-Min equal to X-Max and Y-Min equal to Y-Max and Z-Min equal to Z-Man (and make sure there is no acceleration), all the particles will move towards the same direction:

Note that velocity can be negative, which will make the particles travel in opposite directions, not just faster or slower. We'll set X(Min) to -500 and X(Max) to +500 (and keep the Y values), so that the particles will spread randomly in the X direction:

If you'd have made X(Min) = -150 and X(Max) = +150, there'd be less difference in the directions:

If there is a Velocity and a Acceleration along the same axis, but they have opposite (positive/negative) signs, the particle will first move in one direction, but at a certain point the absolute value of the speed caused but the Acceleration will be larger than the absolute value of the Velocity, so the particles will move back to the direction they came from. Put more simply, imagine shooting a cannonball straight up into the air. The high velocity will eventually be counteracted by a negative acceleration, and the ball will fall back to the earth.

If you use a Velocity and an Acceleration, both along different axes, the particles will make a parabola. A parabola is the realistic trajectory that a bullet or a thrown object will follow. For example if Acceleration has Z = -950 (close to the gravity on Earth), and StartVelocityRange has X(Min) = X(Max) = + 500, it'll look like this:

If you now set also the X of Acceleration to -1000, it'll do the following:

If you use this, the Acceleration will keep speeding up the particle until the MaxAbsVelocity speed is reached.

So basically, the longer the warmup of a certain ParticleEmitter, the higher you have to make the WarmupTicksPerSecond setting (and set RelativeWarmupTime to 1) if you want there to be no visible warmup.

Here is a flowchart that may help in thinking about how you want to design your future particle systems. (items in parentheses indicate what section relevant fields can be found in.)

• SpriteEmitters, BeamEmitters and SparkEmitters also work with animated or procedural textures
• If you place the Emitter Actor inside a solid brush, the emitter might not work. If this happens, but you want the StartLocation to be inside the brush, you can use the GlobalOffsetRange.
• The 4 ParticleEmitter classes are in the Actor Class Browser, in Object --> ParticleEmitter (after you turned off "Actor classes only")
• If you type "stat particle" in the console, you see the particle stats. pclrender and pcltick have to do with the rendering time for the particles, pcls is the total number of particles in the map and emitters is the number of emitters in the map.
• Thanks to Daniel Vogel (and any other people who worked on it) for making such a great particle system :)
• There's another Emitter tutorial with example maps and a description on how they were made.