Motion

Used by: Part, Attachment, Model.

Spawning covered when, where, and which way each particle launches. This chapter is about everything that happens to it after launch.

The plugin gives you four levers on motion:

1. Speed — how fast a particle is moving at any moment of its life.
2. Direction modifiers — what slows it down (drag), what pushes on it (acceleration), and which way “forward” actually means (DirMode).
3. Rotation — how it spins around its own axes during flight.
4. Reversal — whether motion plays forward or backward (InvertMotion).

Properties at a glance

Panel label	Data attribute	Type	Default	What it does
Speed	Speed	NumberSequence	0	Velocity magnitude over the particle’s life, in studs/sec
Acceleration	Acceleration	Vector3	(0, 0, 0)	Constant force vector applied each frame, in studs/sec²
Drag	Drag	number	0	Exponential decay applied to velocity each frame
Dir. Mode	DirMode	enum	RigidLocal	Which frame the particle’s direction is interpreted in
Reverse Motion	InvertMotion	boolean	false	Plays the trajectory in reverse
Rotation	RotX, RotY, RotZ	three NumberRange	0	Random initial rotation around each axis at spawn
Rotation Mode	RotMode	enum	OverLife	Whether RotSpeed is per-life or per-second
Rotation Speed	RotSpeedX, Y, Z	three NumberSequence	0	Rotation speed graphs, one per axis

Speed

A graph of velocity magnitude over each particle’s lifetime, in studs per second.

Speed is a NumberSequence, which means it varies with the particle’s age. A flat graph at value 5 keeps every particle moving at five studs per second through its whole life. A graph that ramps from 20 down to 0 makes each particle launch fast and decelerate to a halt by the time it dies — useful for slow-fading sparks.

The direction of Speed is set by the launch direction (covered in Spawning — EmissionDirection, SpreadAngle, position offsets). Speed only sets the magnitude; the direction is whatever was rolled at spawn time, modified by DirMode and InvertMotion.

A graph with negative values reverses direction. A particle launched forward at speed +5 and then transitioning to speed -5 will reverse mid-flight. This is unusual but supported — some effects use it for pulsing motion.

A typical Speed graph: launch fast, decelerate, fade to a halt.

Acceleration

A constant Vector3 applied every frame, in studs per second squared.

This is gravity, wind, magnetism, anything pushing on every particle in a fixed direction.

Vector3.new(0, -50, 0) is gravity — every particle is pulled downward by 50 studs/sec² each frame. The fall accelerates over time, exactly like real gravity. Vector3.new(0, -196.2, 0) matches Roblox’s default gravity in studs.

Vector3.new(5, 0, 0) is a sideways breeze. Combined with Drag, this gives you wind-blown smoke or pollen drifting in a current.

Acceleration composes with Speed in the natural way — each frame, the engine computes the particle’s new velocity by adding Acceleration * dt to the velocity from Speed’s graph, then moves the particle. Two effects layered: the graph drives the initial trajectory, the acceleration drives the deflection over time.

The default is (0, 0, 0) — no acceleration. Particles travel along whatever the Speed graph says, in a straight line.

Drag

An exponential decay applied to velocity each frame. Each frame, the particle’s speed multiplies by a factor slightly less than 1. Over many frames, this compounds into a curve that’s fast at first and gradually flattens.

A Drag of 0 means no decay; the particle keeps whatever velocity it has indefinitely (subject to Speed’s graph and Acceleration). A Drag of 1 cuts speed to about 37% per second. A Drag of 5 cuts it to near-zero in under a second.

Without drag, the particle continues at constant velocity. With drag, speed decays exponentially — fast initial slowdown, then gradually flattening.

When would you reach for Drag instead of just authoring a falling Speed graph?

• You don’t know how long the particle will live. A Speed graph that ramps to zero over 1.5 seconds doesn’t help if the particle’s Lifetime is 0.5,2.0 — short-lived particles will die mid-decel and look fast, long-lived ones will sit at zero. Drag produces consistent deceleration regardless of lifetime.
• You want particles in different directions to all slow equally. Drag affects velocity magnitude, not direction. A spark launched up, sideways, or back all decelerate at the same rate. Speed’s graph would only affect the initial direction’s component.

Drag and Acceleration both apply each frame. If Drag = 1 and Acceleration = (0, -50, 0), particles slow on their initial direction and fall under gravity. The two effects compose.

Dir. Mode

UI label: Dir. Mode. Data attribute: DirMode.

DirMode is the meta-setting that decides what EmissionDirection and Speed actually mean. The other two are nothing without it.

Recall: EmissionDirection picks a face (Top, Bottom, Front, Back, Left, Right) — that’s where particles head. Speed picks how fast they go in that direction. But neither of those two answers a basic question: whose Top? Is it the part’s own up-axis (which rotates with the part)? Or world up (which never moves)? DirMode is the answer to that question.

An enum: RigidLocal, Local, Global.

The same emitter, rotated 45° in two scenarios. World-mode particles ignore the rotation; RigidLocal-mode particles rotate with the part.

RigidLocal (the default)

EmissionDirection is read in the part’s local frame, as the part is currently oriented at spawn. Tilt the part 90° and the spawn cone tilts with it. This is the most physically intuitive mode for emitters that belong to a moving object — the particles read as part of the object.

Use cases:

• Torch held by a character. EmissionDirection = Top plus RigidLocal means flames always come out of the torch’s “up,” whichever way the character is facing.
• Sword swing sparks. Direction = Left (or whichever face is the cutting edge) plus RigidLocal plus a movement-tracking link makes sparks fly off the right edge of the blade through every frame of the swing.
• Vehicle exhaust. Direction = Back plus RigidLocal means smoke trails behind the vehicle no matter which way it’s pointed.

Local

Like RigidLocal, but the velocity direction is re-read from each particle’s current rotated frame on every simulation step — not just at spawn. So if a particle has any per-particle rotation (initial Rotation range, or a RotSpeed graph driving rotation over life), its velocity vector turns with it as it lives, and the trajectory bends.

How that produces a curving particle path

Three ingredients:

1. Set a Speed so particles actually move.
2. Set an EmissionDirection (e.g. Top) — the vector each particle launches along.
3. Set a RotSpeed graph on one or more axes (RotSpeedX / Y / Z in the Movement section). Each particle rotates during its own lifetime according to that graph.

Under DirMode = Local, every simulation step re-reads the velocity direction from each particle’s current rotated frame. So as a particle rotates, its velocity rotates with it — and its trajectory bends. A steady RotSpeed gives you a circular arc; a RotSpeed graph that varies over life gives you a custom curve. The particle traces the path its own rotation would draw, scaled by Speed.

Adjust the RotSpeed magnitude (or graph shape) to control the curve’s tightness; adjust Speed to control how fast the particle traverses that curve; pair with a child Trail (or Beam) to render a continuous ribbon along the path rather than discrete dots.

Other use cases

• Anime-style impact bursts. A fan of motion-blur lines radiating from a point. Local plus the initial Rotation range (e.g. RotZ = (-90, 90)) gives each particle a different launch angle from the same spawn point — without needing the emitter itself to rotate. The wide range is what produces the fan; the per-particle rotation roll is applied to the direction vector under Local mode (the same rotation roll that doesn’t affect direction under RigidLocal).
• Per-particle direction variance. Each particle “owns” its own initial direction, which composes naturally with the rest of motion (Speed, Acceleration, Drag). Combined with a wide Rotation range, you get a controllable scatter that’s separate from SpreadAngle and gives you finer control over the cone shape.

Global

The part’s rotation is ignored entirely. EmissionDirection = Top always means world up, regardless of how the part itself is rotated. The emitter could be tumbling end-over-end and the particles would still fire straight up.

Use cases:

• Fountain on a moving boat. The boat rocks; the fountain still sprays straight up.
• Snowfall / rainfall emitters. The emitter is just a Part somewhere in the air; particles always head down regardless of how that Part is oriented.
• Procedurally-rotated emitters that shouldn’t visually rotate. When a script tweens an emitter’s rotation for some other reason but the particles should stay world-aligned.
• Debug / placement-checking emitters. A Part you’re moving around in Studio that should visually mark world axes regardless of its own orientation.

Picking between the three

A short rule:

• Should the emitter’s particles “belong to” the emitter and follow its rotation? → RigidLocal. (default; the right choice ~80% of the time)
• Want a fan of trails varying per-particle, or anime-impact lines radiating from a point? → Local plus a non-zero RotX/Y/Z initial range.
• Should particles ignore the emitter’s rotation entirely? → Global.

Legacy VelocityVectored attribute: if you’ve inherited or migrated an emitter from an older plugin version, you may see a VelocityVectored = true boolean on it. The plugin reads it for backwards compatibility — it’s equivalent to DirMode = "Local". New emitters use DirMode directly; the old attribute lingers only on legacy data.

Reverse Motion

UI label: Reverse Motion. Data attribute: InvertMotion.

A boolean. If true, the particle’s motion plays in reverse — backward through the trajectory it would have taken.

The plugin pre-simulates each particle’s path forward (this is what powers Motion Preview). With InvertMotion, the engine indexes that pre-simulated path backwards: the particle starts at where it would have ended, and moves backward along the curve toward the spawn point.

The default is false. Most uses don’t need it. But the ones that do are some of the most striking effects in the plugin’s vocabulary.

Use cases

• Charging up a spell or weapon. Particles converge inward toward the emitter rather than flying out, reading as the effect gathering energy before release. A glowing-orb cast where motes drift in from the surrounding air, then release outward when the spell fires (toggle InvertMotion = false at the cast moment).
• Time-rewind / time-stop spells. Smoke or sparks appear to play backward, suggesting the moment is being undone. Combine with a ColorCorrection emitter desaturating the screen for the duration.
• Tractor-beam / suction effect. Debris being pulled toward a vortex, a black hole, a vacuum cleaner, the open mouth of a creature. Linked-target tracking means the suction follows whatever you point the link at — the player gets pulled toward a moving enemy, the debris pulls toward a moving black hole.
• Healing / absorption visuals. Light motes converging on a wounded character. Set the emission radius outward (large PosX/Y/Z ranges around the character), enable InvertMotion, and particles read as the world’s light being drawn in to heal them.
• Reversed-trail “writing” effect. A Beam or Trail whose path looks like it’s being drawn backward into existence. Useful for rune-inscribing cinematics, ghost-writing reveals, or a magic wand “drawing” a sigil in mid-air.
• Combining with a paused rotating emitter. Spin the emitter on the spot (so the spawn cone sweeps), enable InvertMotion, and the convergence point traces a circular path — you get particles spiraling into a moving focus, which reads as a tracking lock-on or charging beam.

Combining with linking

Reverse Motion composes with Linking. A linked RigidLocal emitter with InvertMotion = true has particles arriving at the link target rather than leaving it. So:

• Sword tip linked, InvertMotion = true → sparks fly into the sword’s tip from the surrounding air during a charge-up animation.
• Player-character linked, InvertMotion = true → energy motes converge on the character, reading as power gathering.
• Camera-linked emitter (LinkSource = Camera) with InvertMotion = true → particles drift toward the player’s viewpoint, useful for dream-sequence inwards-drift atmospheres.

Combining with Animate mode

In Animate mode (covered in chapter 6), a single particle plays its trajectory in place on the source. With AnimateLoop = true and InvertMotion = true, the source plays the trajectory in reverse on a loop — the visual repeatedly sucks in toward the source rather than expanding outward. Combined with a graph-driven Color and Transparency, you can author “perpetual charging” loops that hold a steady-state visual without ever firing a discrete particle.

Rotation (initial)

UI label: Rotation. Data attributes: RotX, RotY, RotZ.

Three NumberRange values that set each particle’s initial rotation around each axis at spawn. The property panel shows them as a single row labelled “Rotation” with three axis inputs (X, Y, Z) below it.

Where Rotation Speed controls how a particle rotates over time during its life, these control where it starts.

A RotZ of 0,360 gives each particle a random initial rotation around its Z axis between 0° and 360°. Two coin-shaped particles spawned at the same moment will face different directions on launch. Combined with RotSpeedZ, they’ll then spin away from those independent starting orientations.

The variation matters mostly for visual texture. Particles that all spawn with the same orientation look uniform — fine for some effects, sterile for most. A small random initial rotation breaks the uniformity.

The default for all three is 0,0 (a single value of zero, treated as a range with both ends equal) — no random initial rotation.

Composes with DirMode = Local. Under DirMode = Local (covered above), the per-particle initial rotation is also applied to the launch direction vector. So a non-zero Rotation range under Local mode produces a fan of launch directions even with SpreadAngle = 0. Under RigidLocal (the default), Rotation only affects the rendered visual orientation, not the velocity vector.

Rotation Mode

UI label: Rotation Mode. Data attribute: RotMode.

How the Rotation Speed graphs are interpreted. An enum: OverLife or Speed. The same graph can produce a steady spin or an accelerating tumble depending on which mode you pick — the difference is in how the engine reads the graph values.

OverLife (the default)

The graph value at age t is the absolute angle (in degrees) the particle is rotated to at that moment. A graph that ramps from 0 at age 0 to 360 at age 1 spins the particle exactly once over its lifetime, regardless of whether the lifetime is 0.5 seconds or 5 seconds.

This is the right pick when you want the visual to land on a specific final orientation by the time the particle dies — the rotation is choreographed to the lifetime, not to wall-clock time.

A constant graph value here doesn’t spin the particle; it locks it to a fixed rotation. Spinning needs a ramping graph.

Use cases:

• A coin landing flat. Graph from 0° to 360° over life means every coin completes exactly one flip whether it lives 0.5s or 3s. The end state is reliable.
• An animation-locked tumble. A glass shard that should rotate exactly twice as it falls — graph from 0 to 720, regardless of how the lifetime varies between particles.
• A “settling” rotation. Graph from a chaotic high value (random initial spin, sampled via the initial Rotation range) decaying to 0 by death — the particle thrashes early then comes to rest at a known angle.

Speed

The graph value at age t is the rotation rate in degrees per second. The engine accumulates value × dt each frame. A graph at constant 360 spins the particle once per second; a short-lived particle gets fewer rotations, a long-lived one gets more.

This is the right pick when you want physically-continuous spinning — same rate per second regardless of lifetime, like a real-world rotating object.

Use cases:

• A tumbling shard with realistic angular velocity. Graph at constant 180 (half-rotation per second). A particle that lives 0.5s gets a quarter-turn; one that lives 4s gets two full rotations. The motion feels physical.
• An accelerating spin. Graph that ramps from 0 to 720 over life — the particle starts still and accelerates into a fast spin, like a thrown gyroscope picking up speed.
• A decaying spin. Graph that decays from 720 down to 0 — fast initial spin slowing to a halt, like a top wobbling and settling.
• Mixed-axis chaos. Different graph shapes per axis (RotSpeedX, RotSpeedY, RotSpeedZ) under Speed mode produce particles that tumble unpredictably — shrapnel, magical debris, anything that should feel like it’s caught in a gust.

Picking between the two

• Visual end-state matters more than physics? → OverLife. Coins always land flat; magic sigils always end aligned; any animation choreographed to lifetime.
• Physics consistency matters more than end-state? → Speed. Tumbling debris, anything that should feel like it has its own mass and angular momentum.
• Mixed across axes? → Pick per-effect. The mode is global to the emitter (you can’t have RotSpeedX in OverLife mode and RotSpeedY in Speed mode on the same particle).

Rotation Speed

UI label: Rotation Speed. Data attributes: RotSpeedX, RotSpeedY, RotSpeedZ.

Three independent NumberSequence graphs for rotation, one per axis. The property panel shows them as a single row labelled “Rotation Speed” with X/Y/Z graph selectors. Combined with Rotation Mode, they control how each particle spins during its life.

A RotSpeedY graph that ramps from 0 to 90 over its life rotates the particle by 90° around its own Y axis from spawn to death (with RotMode = OverLife). The same graph in RotMode = Speed accumulates 90 degrees-per-second at the end of life, giving an accelerating spin.

The three axes are independent. A coin-shaped particle that should flip end-over-end uses RotSpeedX only. A tumbling shard that should spin chaotically uses all three with different graphs. A windblown leaf might use RotSpeedY heavily and the others lightly.

The graphs are evaluated each frame at the particle’s current age, just like Speed. A graph that starts high and decays produces a particle that spins fast on emission and slows by the time it dies. A graph that ramps from 0 upward produces a particle that starts still and accelerates into a spin.

The default for all three is 0 — no rotation.

What’s next

You now know how a particle moves: the speed graph that drives it, the acceleration that pushes on it, the drag that slows it, the frame of reference that interprets its direction, and the rotation that spins it. The Advanced chapter covers a smaller set of properties that fine-tune particle simulation — total keyframes, post-life persistence, initial rotation ranges, velocity-vectoring.