Spawning

Used by: Rate, Lifetime, EmitCount, EmitDelay, and EmitDuration apply to nearly every type (Trail has no Rate). The spatial spawning properties — SpreadAngle, Direction, Position, Pos. Mode, Orientation, Z-Offset — only apply to Part, Attachment, Model. Other types use simpler spawning surfaces covered in their per-type chapters.

Every emitter has to answer four questions about each particle it produces:

1. When does this particle appear?
2. Where does it appear, in space?
3. Which way is it heading?
4. How long does it live?

The properties on this page answer those four questions. Everything in this chapter applies to a Part emitter, an Attachment emitter, and a Model emitter the same way. Read it once; the per-type chapters reference back.

Properties at a glance

Panel label	Data attribute	Type	Default	What it does
Rate	Rate	number	10	Particles emitted per second when Enabled
Lifetime	Lifetime	NumberRange	1	Seconds each particle lives, with random variation
SpreadAngle	SpreadAngle	Vector2	(0, 0)	Cone of random deviation in degrees, X and Y
Direction	EmissionDirection	enum	Top	Which face of the part particles fly out of
Position	PosX, PosY, PosZ	three NumberRange	0	Random offset from the emitter’s centre at spawn
Pos. Mode	PosMode	enum	Local	Which frame the position offsets roll in
Orientation	Orientation	enum	None	How particles face the camera or their own velocity
Z-Offset	ZOffset	number	0	Constant render-depth bias for layering effects
EmitCount	EmitCount	number	0	One-shot burst count, separate from the continuous rate
EmitDelay	EmitDelay	number	0	Seconds to wait after Enabled before the first particle
EmitDuration	EmitDuration	number	0	Seconds of continuous loop after the initial bursts. 0 skips the loop

Rate

The simplest of the bunch. Rate is the number of particles your emitter spawns per second when Enabled is true.

A Rate of 10 is one particle every tenth of a second. A Rate of 100 is a thick stream — ten times denser. A Rate of 0.5 is one particle every two seconds: a slow, deliberate drip.

The plugin doesn’t enforce a maximum. The cost is what it is — each particle goes through the five-step birth from chapter 6, and at high rates, you’ll feel it. A single large explosion built on a Rate of 2000 is dramatic but expensive. A field of magical motes at Rate 5 per emitter, spread across twenty emitters, often looks better and runs cheaper.

When Enabled flips off, emission stops. Particles already in flight aren’t affected — they live out their remaining Lifetime and disappear.

Lifetime

How long, in seconds, each particle is alive.

This is a NumberRange rather than a single number, which means each particle picks a random lifetime within the range at the moment it emits. A Lifetime of 0.5,1.5 means each particle lives somewhere between half a second and a second-and-a-half. Two particles spawned at the same instant may die at different moments.

The variation matters more than it sounds like. A field of particles all dying at exactly the same time looks mechanical; the same field with random lifetimes feels organic. Setting Lifetime to a single number (1.0) collapses the range — every particle gets exactly that lifetime — which is occasionally what you want (a precisely-timed flash) but usually too uniform.

The plugin’s input format accepts a single value ("1.5") as a range with both ends equal, or min,max pairs ("0.5,1.5").

Trail is different. On Trail emitters, Lifetime is a single number (no range), default 2. Trail emits a streak rather than discrete particles, so the random-per-particle variation a range provides doesn’t apply. The Trail chapter covers this when we get there.

SpreadAngle

How wide a cone particles fly out of, in degrees.

A SpreadAngle of (0, 0) means every particle launches in exactly the emission direction — a tight beam. A SpreadAngle of (45, 45) gives each particle a random deviation of up to 45° from centre, on both the X and Y axes — a wide cone, like a flashlight beam.

The two components are independent. (45, 0) makes a fan: spread on X, no spread on Y. Useful for ribbon-like effects that should sweep horizontally but stay tight vertically. (180, 180) is fully omnidirectional — particles fly out in every direction, like a pollen burst.

Direction

UI label: Direction. Data attribute: EmissionDirection.

Which face of the emitter particles spawn through. An enum value drawn from Roblox’s NormalId: Top, Bottom, Front, Back, Left, Right.

A campfire spawning sparks should use Top. A jet exhaust should use Back. A floor vent letting steam drift up should use Top. The default is Top.

Direction only sets the initial direction. Spread and motion graphs take over from there. A particle launched out of Top with a Speed graph that includes negative values may end up coming back down through the part — the launch direction is the start, not a constraint.

Position

UI label: Position (one row with X/Y/Z axis inputs). Data attributes: PosX, PosY, PosZ.

Three NumberRange values that offset the spawn position from the emitter’s centre. Each particle picks a random value within each axis’s range and starts at that offset.

A PosX of 0,2 means each particle’s X position is 0 to 2 studs away from the emitter centre. Combined with PosY = 0,2 and PosZ = 0,2, you get particles spawning anywhere within a 2×2×2 cube relative to the emitter — a small region rather than a single point.

This is what makes a fountain look like a fountain rather than a laser. Particles can’t all leave from the exact same point if you want them to look natural. Even small offsets — 0,0.5 on each axis — break the uniform-source look and make emission feel real.

If you want a single-point source (a thin laser-like effect), set all three to 0,0. The default is exactly that.

Pos. Mode

UI label: Pos. Mode. Data attribute: PosMode.

PosMode is to Position what DirMode is to EmissionDirection — it tells the engine whose frame the position offsets are in. The offset values themselves (PosX, PosY, PosZ) only describe distances; PosMode decides which axes those distances are along.

An enum: Local, Global, or RigidLocal.

Local (the default)

Offsets are applied in the part’s local frame. The spawn region rotates and translates with the part as the part itself rotates and translates. A torch held by a character with PosX = 0,1 always offsets along the torch’s “right” — whichever way the character is facing — because the torch’s local-X rotates with the character.

Use cases:

• Spawn region attached to a moving emitter. Magic embers floating around a wand tip — the embers cluster around the wand wherever the wand is, in the wand’s coordinate frame.
• Per-face spawning that rotates with the source. Sparks coming off four faces of a cube — set PosX = (-1, 1), PosY = 0, PosZ = 0 on a Box-shape emitter, and the spawn band runs along the cube’s local X-axis, sweeping around as the cube rotates.
• Anything where the spawn shape “belongs to” the emitter. Most authoring lands here — Local is the right default.

Global

Offsets are applied in world space, ignoring the part’s rotation entirely. The spawn region stays aligned with the world’s X/Y/Z axes regardless of what the part is doing.

Use cases:

• Fountain on a moving boat. The boat tilts; the fountain’s spawn region (and therefore its visual shape) doesn’t tilt with it.
• Snowfall over a moving area. A wide flat spawn region that should always lie horizontally over the world even if the source emitter is rotated for non-related reasons (like animating with a tween).
• Procedurally-rotated emitters that shouldn’t drag their spawn region. Any case where you’ve got a script rotating the emitter for layout reasons but you want the actual particle positions to stay world-aligned.

RigidLocal

A hybrid. The offset is sampled in the part’s local frame at the moment of spawn, then locked into world space — subsequent rotations of the part don’t redirect already-emitted particles. The spawn cone follows the part’s rotation, but each individual particle, once spawned, stops tracking the part.

Use cases:

• “Shower” effects from a moving source. A character running through rain; raindrops spawn around the character (Local-style spawn region), but once spawned, drift on their own without re-orienting if the character pivots.
• One-shot bursts from a rotating object. A spinning pinwheel that fires a single burst — each spark’s spawn position freezes in world space at the moment of fire, so subsequent rotation of the pinwheel doesn’t drag the already-spawned sparks around.
• Anything where you want a tightly-controlled spawn shape but world-stable individual particle paths.

Composing with DirMode

PosMode and DirMode are independent — pick each on its own merits. The four most common combinations:

• PosMode = Local + DirMode = RigidLocal. Both spawn position and direction follow the emitter’s rotation. The default for most “attached to a moving thing” effects (torch, sword, vehicle).
• PosMode = Local + DirMode = Global. Spawn region rotates with the emitter, but particles always fly in world directions. A spinning sprinkler where droplets always fall down regardless of how the head is pointed.
• PosMode = Global + DirMode = RigidLocal. Spawn region is world-aligned (a flat plane), but particles fly in the emitter’s local direction. Useful for plane-of-emission effects on a tilted source.
• PosMode = Global + DirMode = Global. Everything is world-aligned. The emitter is just a position marker; its rotation is ignored entirely.

Orientation

How each particle is rotated relative to the camera or to its own velocity. The same enum Roblox’s ParticleEmitter.Orientation uses: None, FacingCamera, FacingCameraWorldUp, VelocityParallel, VelocityPerpendicular.

This is the property that decides whether a Part-particle reads as a 3D object tumbling through space, a 2D sprite always facing the viewer, or a streak of motion aligned with its trajectory. Picking the right mode is more about visual intent than about correctness — every mode is useful for some effect and confusing for others.

None

No automatic orientation. The particle uses whatever rotation it was emitted with — the random initial roll from RotX/Y/Z ranges, modified each frame by RotSpeedX/Y/Z graphs from Motion. The camera’s position and the particle’s velocity have no influence.

Use cases:

• 3D mesh particles that should tumble through space — a glass shard, a coin, a leaf. The whole point of these is that they read as 3D objects with their own rotation; you want them spinning on their own axes, indifferent to the camera.
• Screen-locked frozen orientations — a magic sigil drawn at a specific angle that should stay at that angle, never re-orienting based on viewer.

FacingCamera

Every frame, the particle re-rotates so its face points at the camera. The particle reads as a 2D sprite that always looks flat to the viewer — exactly how stock Roblox ParticleEmitter particles look by default.

Use cases:

• Sparks, glows, flares. Anything that’s conceptually a flat sprite — explosions, muzzle flashes, magic glints — should face the camera so the texture is always fully visible.
• UI-style indicators in 3D. Damage numbers, “+1” pickup popups, target reticles drawn as Part particles in world space but always camera-facing for legibility.
• Lens-flare-style highlights. Star-burst textures attached to bright objects that should always read as a flare regardless of camera angle.

FacingCameraWorldUp

Like FacingCamera, but the particle’s “up” axis is locked to the world’s up direction instead of the camera’s. The particle still faces the camera, but it doesn’t roll around the camera-axis when the camera tilts.

Use cases:

• Smoke columns / dust pillars. A smoke column should always stand vertical regardless of camera tilt; pure FacingCamera would let it spiral as the camera rolls. FacingCameraWorldUp keeps the column upright.
• Floating banners or labels. Text or icons in 3D space that should stay readable (right-way-up) even when the player tilts the camera.
• Anything where “up” has semantic meaning. Rain falling, snow drifting, energy beams pointing up — FacingCamera would let them spin around the camera axis. FacingCameraWorldUp keeps the up direction locked to world-up.

VelocityParallel

The particle aligns its forward axis with its current velocity direction — its “front” points where it’s heading, frame by frame. A spark emitted upward then deflected sideways by acceleration always points in its current motion direction.

Use cases:

• Streak-like effects. Tracer rounds, comet trails, shooting stars, lightning bolts — anything that should look like a thing moving fast with a stretched-along-motion shape.
• Speed-line effects. Anime-style motion blur lines radiating outward — each one aligned with its individual particle’s motion.
• Falling rain. Each raindrop oriented along its own velocity vector reads as falling, even when the wind redirects it sideways.
• Particles with a “front” texture. Arrows, fish, missiles — anything whose visual has an obvious direction. Combine with a Part shaped like an arrow or a thin streak.

VelocityPerpendicular

The particle aligns perpendicular to its motion direction. The flat side of the particle faces along its travel path.

Use cases:

• Ribbons sweeping through the air. A flat plane that follows along its path, showing its broadside as it moves. The shape stays edge-on to the velocity rather than face-on.
• Cinematic motion blur. Long thin rectangles oriented perpendicular to motion read as smear lines — useful for high-speed action visuals.
• Wing-like trails. A pair of Part emitters on either side of a moving object, oriented perpendicular to motion, produces wing-like ribbons sweeping out behind the source.
• Particles where the visual “spreads sideways” makes sense. A flag fluttering in the air, a piece of cloth caught in the wind — perpendicular orientation reads as the flat surface catching the apparent flow.

Z-Offset

UI label: Z-Offset. Data attribute: ZOffset.

A constant bias added to the particle’s render-depth — its distance from the camera as far as the renderer is concerned, not its physical distance.

Positive values pull particles “forward” (rendered closer to the camera, on top of other things). Negative values push them back.

ZOffset is for fixing layering disputes between effects. A flash effect that should always render in front of a smoke effect can use a positive ZOffset while the smoke uses zero. The two effects can occupy the same physical space and still respect a clear layer order.

The default is 0. Most emitters never need to change it.

EmitCount, EmitDelay, EmitDuration — three attribute-only fields

A note before the next three sections: these three properties are stored as item-level attributes, not editable rows in the property panel. The plugin’s emission pipeline reads them from the source instance via instance:GetAttribute("EmitCount") (and the others), but doesn’t expose them as panel inputs. To edit them, open Studio’s built-in Properties window, scroll to the Attributes section near the bottom, and edit the values there.

Transform sets default values when you transform an item (so the attributes are present from the start), and the plugin’s clipboard tool groups them under an “Emission” section for copy-pasting. But authoring them happens in Studio’s Attributes panel, not in the plugin’s property panel.

EmitCount

How many particles fire as the initial bursts of a fire event — Studio’s Emit button, :EnableEmit from a script, or :AbsoluteEmit on a transformed item. Each burst is one call to the per-type emit (one particle for Part / Attachment / Beam, one clone for the screen / image / light types), and EmitCount of them go out before the optional continuous loop (driven by EmitDuration) kicks in.

EmitCount does not affect the Rate-driven continuous emission you get from flipping the Enabled toggle on. That path uses Rate exclusively.

Most authoring uses Rate while Enabled is on and ignores EmitCount. Reach for it when authoring a triggered, one-shot effect — a sword swing, a spell cast — where the timing is event-driven rather than ambient.

EmitDelay

Seconds to wait at the start of a fire event, before the first burst goes out. Like EmitCount and EmitDuration, this applies only to the fire path (Emit button / :EnableEmit / :AbsoluteEmit) — not to the Enabled-toggle continuous flow.

Useful for staggering emitters that should fire in sequence. A wand effect with three emitters chained — head, mid, tail — can each have a different EmitDelay so the visual reads as a wave rather than a simultaneous flash.

EmitDelay only affects the start of the fire event. Once the bursts are out and the continuous loop (if EmitDuration > 0) is running, Rate takes over.

EmitDuration

Seconds of continuous emission after the EmitCount initial bursts have fired. Once those seconds elapse, emission stops on its own.

This applies to the “fire” path — Studio’s Emit button, the runtime :EnableEmit call, and :AbsoluteEmit on a transformed item. The plugin reads EmitDuration at the moment of firing, runs the continuous loop for that many seconds, then stops. Particles already in flight finish their lifetimes; no new ones spawn.

A value of 0 (the default) means no continuous loop — only the EmitCount initial bursts fire, then the emitter is silent until you fire again. A value of 2 means: fire the bursts, then loop continuously for two seconds, then stop.

EmitDuration is for declaring the run time of a one-shot effect. A casting animation that should run for exactly 1.5 seconds sets EmitDuration = 1.5 and trusts the plugin to stop on its own.

The other emission path — flipping the Enabled toggle in the property panel (or config:SetAttribute("Enabled", true) via script) — is not bounded by EmitDuration. That path runs the continuous loop until you flip Enabled back to false. Use Enabled for fountains and ambient effects that should run as long as the emitter exists; use EmitDuration (with the Emit button or :EnableEmit) for scripted effects with a specific run length.

Trail is different. On Trail emitters, EmitDuration is a string — either a single number ("2") or a comma-separated min/max range ("5,2") from which the plugin picks a random duration per emit. The Trail chapter covers the string format when we get there.

What’s next

The when, where, and which-way of spawning are covered. The next question is how the particle moves once it’s launched: how fast, in what direction, with what acceleration or drag. That’s the Motion chapter.