Two Modes: Emit and Animate

So far, every particle you’ve seen in this codex has been a short-lived duplicate. The engine duplicates the RenderTemplate, gives the duplicate its own age and its own randomly-rolled values, animates it for a fraction of a second, and destroys it. Many duplicates, each independent. We call this Emit mode.

There’s a second way an emitter can behave. Instead of making duplicates at all, the plugin animates the original instance in place, on a loop. One source, no duplicates, just the graphs you authored playing repeatedly while the emitter is enabled. We call this Animate mode.

Both modes use the same property panel, the same graphs, the same everything you’ve authored. The difference is whether the engine duplicates and animates many particles, or animates the source itself.

Emit mode, in detail

You set the Rate to 30 and turn on Enabled. Every 1/30th of a second, the engine emits.

But what does an “emission” actually do? When you ask for thirty particles a second, the plugin can’t just hand you thirty identical copies — that would look mass-produced. Each particle wants a small bit of variation: a slightly different lifetime, a slightly different direction, a slightly different graph sample. Here’s how each emission produces that:

1. Duplicate the RenderTemplate. This is the new particle. It looks like your authoring instance, stripped of bookkeeping (chapter 3 explained why).
2. Pick a random Lifetime within your range. If you set 0.5,1.5, the engine picks somewhere in between.
3. Pick a random direction within your spread cone. Two particles emitted at the same instant point slightly differently.
4. Give it a unique seed. This drives envelope variation on every graph — so two particles at the same age sample slightly different colours, sizes, transparencies.
5. Hand it to the simulation. From this point on, the engine updates this duplicate’s properties every frame: looking up where the particle is in its lifetime, evaluating each graph at that point, writing the result back. When the lifetime runs out, the engine destroys the duplicate.

Many emissions per second, each independent, each running this five-step birth.

At any moment there might be 30, 100, 500 active duplicates — depending on Rate and Lifetime. Each at a different age, each playing the same graphs but offset in time.

This is the classic particle-system look. Confetti bursts. Sparks. Smoke trails. Anything where you want many small things, each independent.

Animate mode, in detail

You change the EmissionMode attribute on your item to Animate. You turn on Enabled. The engine doesn’t duplicate anything.

Instead:

1. The original instance plays the graphs in place.
2. At time 0, the graphs produce their starting values; the engine writes them to the instance.
3. At time 0.5, halfway through the cycle, the graphs produce their mid values; the engine writes those.
4. At time 1, the cycle completes; the graphs loop back to time 0 and start again.

If you set AnimateLoop = false on the item, the engine plays one cycle and stops, leaving the instance at its final state for a moment before restoring the starting state. (We mention this for completeness; most uses want AnimateLoop = true.)

For 3D types (Part, Attachment, Beam, Model) the description above is literal — there are no duplicates, no active list, just the source instance animating. Re-calling Animate while a cycle is running cancels the current cycle, snaps the source back to its starting CFrame, and starts fresh.

For the screen-space types (Blur, Bloom, ColorCorrection, Atmosphere) and ImageLabel, Animate works slightly differently under the hood: the plugin creates one singleton clone of the source, animates that, and destroys it when the cycle ends. The source itself doesn’t render during the cycle. This is a plugin-level protection so that two effects emitting the same screen-space emitter can’t stack into a runaway — re-calling Animate while a cycle is alive is a silent no-op (the existing cycle keeps running). The user-facing experience is the same — one steady source-equivalent visual that loops while enabled — but the mechanics under the hood differ.

This is useful for ambient effects:

• A glowing orb whose colour pulses on a loop.
• A beam whose texture scrolls forever along its length.
• A skybox aura that shifts hue as the day wears on.
• A UI element whose Transparency rises and falls to draw the eye.

You wouldn’t use Animate for confetti. You wouldn’t use Emit for a slowly-pulsing aura. The choice is about whether the effect benefits from many independent particles, or from one steady source.

How to switch

There’s an EmissionMode attribute on your transformed item. Two values: Emit (default) or Animate. The property panel shows it as a dropdown labelled Mode in the Spawning section. The data attribute name (EmissionMode) is what scripts use via item:GetAttribute("EmissionMode") and :SetAttribute("EmissionMode", "Animate").

The mode is read once at the moment emission starts — the running :Enable loop or in-flight :EmitAnimate cycle won’t notice if you flip the dropdown afterward. Switching the dropdown on a paused emitter is fine; the next time Enabled is flipped on, the new mode takes effect. Switching it on an actively-emitting one: existing duplicates finish their lifetimes naturally, but you have to cycle Enabled off and on to pick up the new mode. The runtime API equivalent is calling :Disable then :Enable (or :EnableEmit) again.

The companion attribute is AnimateLoop (panel label: Loop, also in the Spawning section). It controls whether Animate mode loops the cycle continuously or plays one cycle and stops. Transform stamps AnimateLoop = false by default, meaning the source plays one cycle and stops. For continuous Animate behaviour (the typical use), flip the panel toggle on; the cycle then repeats as long as Enabled is on.

A type that defaults to Animate

One type defaults differently from the rest: Atmosphere. Roblox renders only one Atmosphere per Lighting at a time, so multiple cloned Atmospheres would compete for the single rendering slot and produce flicker. The plugin’s Transform sets EmissionMode = "Animate" on Atmospheres specifically, instead of "Emit" like every other type — so the default behaviour is the one Roblox can render correctly.

The plugin doesn’t enforce this at runtime. The dropdown is editable; switching Atmosphere to Emit afterward is mechanically valid but produces the flicker problem. The default is the protection; treat the dropdown as something not to touch on Atmosphere specifically.

We’ll see Atmosphere and the other ten types in chapter 8 (the Particiliary).

What’s next

So far, every emitter we’ve talked about has stayed where you placed it. But what if your emitter should follow something? Sparks at the tip of a swinging sword. Smoke trailing a moving rocket. A glow that hovers around a character’s hand as they cast. The plugin has a way to bind an emitter’s output to another instance, so it travels with that instance through space. That’s linking, and it’s the next chapter.