Skip to content

Type differences

Several properties have the same name across emitter types but different types or meanings depending on which emitter you’re looking at. This catches users who learn the property on one type and assume it works the same way on others.

This chapter is the lookup table.

TypeData typeMeaning
PartNumberSequence (graph)Glow multiplier over each particle’s life
BeamNumberSequence (graph, attribute BeamBrightness)Glow multiplier over each emission’s life
PointLightNumberSequence (graph, attribute PLBrightness)Light intensity multiplier over life
Trailnumber (single value)Glow multiplier (constant — Trail segments have their own per-segment age that Roblox already animates other properties along)
Native ParticleEmitternumber (single value)Glow multiplier (constant — Roblox-native API)

The split: types that duplicate per particle and animate per duplicate (Part, Beam, PointLight) get a graph. Types that have built-in Roblox per-segment animation (Trail) or a single billboard (native PE) get a single number.

You can’t paste a Brightness graph from a Part emitter onto a Trail or native PE — the clipboard tool detects the type mismatch and skips. To convert, sample the graph at a chosen point and paste that single value.

TypeData typeMeaning
Part, Attachment, ModelNumberSequence (graph)Velocity magnitude over each particle’s life, in studs/sec
Native ParticleEmitterNumberRange (range)Per-particle random velocity, picked at spawn, constant for the particle’s life
Beam, Trail(absent)These types don’t move spatially
PointLight(absent)PointLights don’t move; they pulse in place
Screen-space types (Blur, Bloom, etc.)(absent)No spatial motion
ImageLabelNumberSequence (graph, in pixels/sec)Velocity magnitude over each particle’s life, in screen pixels

The big gotcha is the graph vs range split between transformed Part and native PE. Don’t try to paste between them — the types don’t align. The transformed NumberSequence says “velocity over life”; the native NumberRange says “constant velocity per particle, randomly picked from a range.”

TypeData typeMeaning
Part, Attachment, Model, Beam, PointLightNumberRange (range)Per-particle random lifetime, picked at spawn
Trailnumber (single value)Per-segment lifetime, constant for all segments
Native ParticleEmitterNumberRange (range)Same as transformed types
Screen-space typesNumberRange (range)Per-emission random clone lifetime
ImageLabelNumberRange (range)Per-particle random lifetime

Trail’s Lifetime is unusual in two ways. First, it’s a single number, not a range — the same value applies to every segment. Second, the meaning is per-segment, not per-particle. A Trail with Lifetime = 5 has segments that each fade over 5 seconds, regardless of when they were created. There’s no “particle” with a lifetime in the per-Part sense.

TypeData typeMeaning
Part, Attachment, Model, PointLight, ImageLabelColorSequence / NumberSequence (graph)Per-particle, animated over the particle’s life
TrailColorSequence / NumberSequence (graph)Per-segment, animated over each segment’s life
Beam(via GraphBlender)Multi-state interpolation; no single Color or Transparency property
Native ParticleEmitterColorSequence / NumberSequence (graph)Per-particle, animated over life
AtmosphereColorSequence (graph)Per-emission, animated over the cycle. Atmosphere has two ColorSequence properties: Color and Decay.
ColorCorrectionNumberSequence for Brightness/Contrast/Saturation; ColorSequence for TintColorSigned graphs for the first three (negative values valid)

Beam’s GraphBlender mechanism is the structural outlier. There’s no single Color property on a Beam — instead, the GraphBlender folder holds multiple states, each with its own Color and Transparency graph and a Time value. The engine interpolates between adjacent states linearly. See the Beam chapter and GraphBlender Math for the full mechanism.

TypeData typeMeaning
Part, Attachment, Modelthree NumberRange (PosX, PosY, PosZ)Random per-axis offset from the source’s centre at spawn, in studs
ImageLabelUDim2 (single Position value)UI position with Scale + Offset components per axis. No per-axis range — particles spawn at the configured Position and move in pixel-Offset from there
Beam, Trail(absent)Position is fixed by the attachments
PointLight(absent)Position is the source’s parent’s position
Screen-space types(absent)Post-process effects have no position

ImageLabel’s polar emission model means it doesn’t have PosX/Y/Z ranges — instead, it has EmissionAngle (a central direction) and SpreadAngle (random spread around it). Particles spawn at a single base Position and fly out in directions picked from the polar range.

TypeData typeMeaning
Part, Attachmentthree NumberSequence (SizeX, SizeY, SizeZ)Per-axis multiplier on source’s Size, animated over life
ModelNumberSequence (Scale)Uniform scale via Model:ScaleTo(), animated over life. Cascades through every descendant.
Beam(via Width0, Width1)Per-endpoint width graphs; not a unified Size
TrailNumberSequence (WidthScale)Multiplier on Trail’s native Width, varies per segment
PointLight(via Range)The light’s radius graph — no equivalent of Size
Native ParticleEmitterNumberSequence (single graph)Uniform 2D billboard size, animated per particle
ImageLabelUDim2 for base + SizeScaleX/SizeScaleY graphs for per-axis multipliersCombination of UDim2 base and animated multiplier graphs

Three completely different size models depending on the type:

  • Three-axis graphs for Part / Attachment (you can stretch independently per axis)
  • One uniform graph for Model (everything scales together via :ScaleTo)
  • One uniform graph for native PE (single 2D-billboard size)

If you’re authoring an effect across multiple types and want consistent sizing behaviour, you’ll need to set up the right size properties per type — there’s no universal “size” graph that maps cleanly across all of them.

TypeData typeFormat
Part, Attachment, Model, Beam, PointLight, ImageLabel, screen-spacenumberSeconds of continuous loop after the initial EmitCount bursts. 0 skips the loop.
TrailstringEither a single number ("2") or a comma-separated min/max range ("5,2"). The plugin parses and picks a random duration per emit
Native ParticleEmitternumber (attribute)Seconds (read by the plugin’s runtime, not Roblox’s native API)

The Trail’s string format is the unusual one. "5,2" doesn’t mean “5 seconds emit then 2 seconds tail” (a common misreading) — it means “random duration between 2 and 5 seconds, picked per emit.” See the Trail chapter for the full Trail emission timing model.

TypeData typeMeaning
Part, Attachment, Modelenum (NormalId)Which face of the source’s frame particles fly out of (Top, Bottom, etc.)
Native ParticleEmitterenum (NormalId)Same as above
ImageLabelEmissionAngle (number, degrees) + SpreadAngle (number)Polar direction in 2D screen space
Beam, Trail(absent)No direction; positions are fixed by attachments
PointLight(absent)No direction; lights are omnidirectional
Screen-space types(absent)No direction; effects are global

The 3D types use a face-of-the-source enum. The 2D type (ImageLabel) uses a polar angle in degrees. The post-process and fixed-geometry types don’t have a direction concept at all.

TypeData typeMeaning
Part, Attachment, Modelthree NumberSequence graphs (RotSpeedX/Y/Z)Per-axis rotation speed
RotMode enumOverLife (graph value = absolute angle at age t) or Speed (graph value = rate in degrees/sec, integrated each frame)Same enum on these three types
Native ParticleEmitterNumberRange for both initial Rotation and RotSpeedPer-particle random initial rotation; per-particle random rotation rate
ImageLabelNumberRange for RotRange (initial), NumberSequence for RotSpeed, enum for RotModeSingle 2D rotation axis; same OverLife/Speed enum
Beam, Trail(absent)These types’ geometry is fixed
PointLight(absent)No rotation
Screen-space types(absent)No rotation

The 3D types get three independent rotation axes. The 2D type gets one. The fixed-geometry types get none.

Quick reference: what every emitter type has in common

Section titled “Quick reference: what every emitter type has in common”

Two emit-timing properties are universal across every type that emits anything:

  • Enabled — boolean toggle, on every transformable type
  • Lifetime — present on every transformable type (with the type variations noted above)

Beyond those two, almost every property has some type that doesn’t share it. When in doubt, check the type’s specific Particiliary chapter and look at the Properties at a glance table.

That’s the same-name-different-shape (polymorphism) quick-reference. For deeper coverage of any specific type, the Particiliary chapters are the canonical source. The remaining FAQ topics — and the foundation chapter folds for Enabled, EmissionMode, and LinkMode — come in upcoming docs releases.