Particle System Description

The X-Plane 11 particle system follows a fairly standard game-industry design:


Particle Types

Every particle in a particle system has a type, and the definition file defines the behavior of every particle type. Typically you will have a small number of types per definition file. For example, a definition file that contains “smoke and fire effects” might contain three types of particles: a flame particle, a white smoke particle, and a black smoke particle.

The particle type definition controls the appearance and behavior of the particle over time, including what textures it uses and how it grows/shrinks and fades over time.

Every particle that is created in a particle system has a finite lifetime (measured in seconds) before it disappears. The particle definition file defines how the particle type is drawn over that lifetime. For example, a typical behavior is to make the opacity of the particle fade from 100% to 0% over the lifetime of the particle, so that the particle slowly disappears.

All properties of the particle type that can be key-framed are key-framed over either the lifetime of that particle, or by data-refs. You can use more than one key-frame table; the results of each table are multiplied to get the final result.


Emitter Types

An emitter creates particles; every emitter has a type, and the emitter type definition defines how the emitter creates particles.

The emitter always creates the same type of particles, but it can control the particle’s initial properties, including its initial size, its initial opacity, and how long it lives for.

Emitters are used in the simulator by attaching them to objects or aircraft. The emitter would be attached at a particular location on an OBJect with a particular direction; if the object is on an airplane, the emitter moves with the airplane. For example, you might put an emitter of smoke puffs on the exhaust pipe of an aircraft.

For convenience, X-Plane lets you put one or more sub-emitter into each emitter. Each sub-emitter can emit its own type of particles with its own properties. The motivation here is to make it easy to attach a lot of emitters to a single point in an object.

For example, our gun-barrel emitter contains two sub-emitters: one for the muzzle flash (emitting a small number of fire particles) and one for the smoke (emitting a larger number of smoke particles). By wrapping both sub-emitters in a single emitter, it’s simple to attach the one “gun barrel” emitter to the tip of a gun barrel on a fighter.

The various properties of the emitter (number of particles created per second, initial velocity, etc.) are key-framed based on datarefs. So you can specify that an emitter makes more particles (or faster particles, or bigger particles) as the engine’s N1 spools up. In this way, an emitter can dynamically change its stream of created particles based on inputs from X-Plane.

Datarefs attached to emitters can use wild-cards for array indices. When you specify [] for a dataref index (e.g. sim/flightmodel2/engines/N1_percent[]) the * is replaced with an index number that comes from the OBJ file where the emitter is attached. This lets you use a single ‘generic’ emitter for all engines in your aircraft and specify the engine index number each time you use the emitter. (This mechanism works the same as wild card parameters in FMOD.)

Many parameters of the emitter type definition can be randomized. In this case the parameter ha a lower and upper bound that can be edited separately. Since the parameter is key-framed, the amount of randomization (the distance between the two parameters) can vary based on a dataref


Effect Types

Emitters are attached to parts of the X-Plane world (scenery objects, airplane objects, etc) and run continuously based on their volume. This is good for continuous sources of particles like a smoke stack, but it is not good for a finite event, like an explosion.

An effect is a collected sequence of key-framed emitter locations and values. An effect is something that happens over a time and start location. For example, an explosion effect might contain instructions to run a fire emitter for 10 seconds.

The properties of an effect are key-framed to the time of the effect; the effect has a finite total duration. Thus for an effect you can create a smoke emitter that creates a lot of smoke and then have the smoke level slowly die down.

Effects cannot be attached to objects; rather X-Plane uses effects directly at specific times, e.g. when a bomb hits the ground or when the airplane crashes.


Particle Editor GUI

As of X-Plane 11.30d2, the X-Plane B737 has been updated to use the particle system and can be used as a reference.

Pick “Show Particle System Browser” from the developer menu to access the in-sim particle system UI. You will see a list of all currently loaded particle system definition files (.pss files). You can edit any loaded particle system shown in the browser by double-clicking to open its editor. Note that these windows can be resized or popped out, and the width of the columns in the .pss window can be adjusted.

To create a new particle system, click the “New…” button and pick a particle system file on disk. The location of your particle system on disk matters because only textures in the same folder as the particle system (or in sub-folders) can be used.

To open and edit a particle system not currently in use by X-Plane, click the Open… button and browse to your .pss file.

The upper left column (named for whichever particle you double clicked to open from the browser) is a hierarchy list of all particles, emitters, effects etc. + preview and texture tab. This may be hidden if the Particle Budget column is expanded. Click an item to view its properties; icons under this section are: create, delete, duplicate, move up, move down. The eyeball icon next to the various emitters lets you disable emitters globally.

The lower left column is the particle budget. For the PREVIEW only, this shows how many particles of each type are being used, which lets you figure out if you have enough particles of each type budgeted in the system. Note that particle systems used in the sim and not in the editor preview are NOT shown, so sadly you cannot use this to debug budget problems in the live sim.

When “texture” is selected from the hierarchy, the texture preview appears on the right side.

The middle section is the property editor and is named for whatever is selected in the hierarchy. When an emitter is selected, the sub-emitters form multiple columns.

When a property that can be key-framed is selected in the middle view, the key frame editor appears on the right side. The add/delete buttons on the right let you add a second key frame table or delete the bottom one.

Each key frame table lets you pick a dataref or other key frame source, and then edit the key frame table either graphically by dragging nodes or by clicking. Option-click on a key-frame curve to add nodes graphically, or use the + (add) and ø (delete) icons on the right.

The key-frame interpolation mode popup changes the algorithm by which the key frame points are attached.

If the key frame property contains more than one value (E.g. two for a randomized value between two bounds or 3 for RGB colors) you can drag each line independently.

Top buttons provide access to: save/revert the .pss file, undo/redo edits, and preview/stop previewing the selected emitter or effect. (You cannot preview a particle type directly – you must preview an emitter that emits them.)


Particle Properties

These settings affect all particles of a given type. Some properties can be key-framed either by a dataref or by “particle lifetime”, which makes a property change over the life of each particle. When “particle lifetime” is used, the key frame table runs at different speeds for long-living and short-living particles.

Name: this is the name you see in the hierarchy – X-Plane ignores it.

Max particles: this is the maximum number of particles of this type you can have at once. The biggest you can set this is 16384. Set this large enough that the system does not run out of capacity, but smaller is better.


Physics Properties


Rendering Properties


Emitter Properties

Each emitter contains one or more sub-emitters – the idea is to allow several emitters at a single spot (e.g. smoke and fire for a rocket) by attaching only one emitter in an OBJ.


Sub-Emitter Properties


Offset Properties

These properties offset where the particle is created relative to the emitter on the object.