Native Editing

Not everything in your scene needs to be a Part-Icles emitter. Some particle effects are fine as plain Roblox ParticleEmitter instances — the simple ones, where each particle is a flat textured quad (2D, no thickness; the four Orientation modes change which way the quad faces, but the rendered shape is still a flat sprite), motion is a single direction with a Speed range, and you don’t need three-axis size, mesh particles, or graph-based animation per axis.

The plugin recognises this. When you select a stock ParticleEmitter or Trail that hasn’t been transformed, the property panel opens anyway — with a curated subset of the native properties wired to the same graph editor, color picker, and bulk tools as your transformed emitters. You get most of the plugin’s authoring conveniences without the structural changes Transform makes.

This chapter explains exactly what works, what doesn’t, and when reaching for native editing makes sense.

When to use native editing

The default question is “should I transform this or leave it native?” — and it usually has a clear answer.

Transform when you need:

• 3D mesh particles with custom geometry (Part-emitter rendering)
• Three-axis size graphs (SizeX, SizeY, SizeZ)
• Per-axis rotation graphs (RotSpeedX/Y/Z)
• Animate mode (in-place property animation, no clones)
• Linking (binding emission to a moving target)
• The RenderTemplate model (a stripped-down clone-template for emission)
• Three-axis position offsets, complex spawn shapes, or other plugin-specific behaviour

Leave native when:

• The emitter is a 2D-billboard sprite (Roblox’s classic ParticleEmitter look)
• You’re working with an existing scene’s stock effects and don’t want to restructure
• The simpler property surface is enough — Speed range, Lifetime, Color sequence, Transparency sequence, Size sequence — without graph-based motion
• You want trails with the standard Roblox per-segment behaviour

The plugin is just as capable an authoring environment for native PEs and Trails as it is for transformed items, but the property surface is narrower. You’re working within Roblox’s native API, which is more limited than what Transform makes available.

How the plugin recognises a native instance

Selection detection is attribute-based, not type-based. When you click on a ParticleEmitter or Trail, the plugin checks for the Transformed attribute:

• Has Transformed = true → it’s a transformed item (Part / Beam / Trail with Transform applied / etc.). The plugin renders the transformed property panel for that type.
• No Transformed attribute → it’s native. The plugin renders the native property panel — different rows, different inputs, but the same overall layout.

Internally, the panel checks for the Transformed attribute on every selected instance and routes to either the transformed or native panel based on what it finds. There’s no IsNative flag — just the absence of the Transformed marker.

This means you can mix transformed and native emitters in the same scene without any concern. The plugin handles each correctly based on what attributes are present.

Native ParticleEmitter — what the panel exposes

When you select a native ParticleEmitter, the panel sections are:

Spawning

• Direction — Roblox’s EmissionDirection enum (Top, Bottom, Front, Back, Left, Right).
• Enabled — toggle.
• Rate — particles per second.
• Lifetime — NumberRange for per-particle lifespan.
• SpreadAngle — Vector2 for cone spread.

Appearance

• Texture — asset id input.
• Brightness — single number (Roblox added this property recently; the panel exposes it as a numeric input).
• Size — NumberSequence graph. Edited with the plugin’s full graph editor — keypoints, bezier handles, presets, envelope mode.
• Transparency — NumberSequence graph. Same editor.
• Squash — NumberSequence graph. Same editor. (Squash is Roblox’s stretch-along-velocity property.)
• Color — ColorSequence graph. Edited with the plugin’s color sequence editor.
• LightEmission — single number.
• LightInfluence — single number.
• Z-Offset — single number.
• Orientation — Roblox’s enum (FacingCamera, FacingCameraWorldUp, VelocityParallel, VelocityPerpendicular).

Movement

• Speed — NumberRange (a range, not a graph). Roblox’s native ParticleEmitter.Speed is NumberRange; the panel respects that.
• Rotation — NumberRange for initial rotation in degrees.
• RotSpeed — NumberRange for spin rate in degrees per second.
• Acceleration — Vector3 for constant force vector.
• Drag — single number.
• VelocityInheritance — single number.
• TimeScale — single number.
• LockedToPart — toggle.
• WindAffectsDrag — toggle.

Shape, Flipbook, Advanced (collapsed by default)

• Shape — Roblox’s enum (Box, Sphere, etc.) for the spawn region.
• FlipbookMode / FlipbookFramerate — flipbook animation settings.
• PreloadTexture — a plugin-added attribute that hints to load the texture before emit.

The key terminology shift to understand: where transformed types use NumberSequence graphs for Speed, native PEs use NumberRange. Roblox’s native ParticleEmitter.Speed is a range (min/max picked at spawn), not a graph that varies over life. The plugin doesn’t try to fight this — it shows the right input for the right type.

Same for RotSpeed. Same for Rotation. They’re per-particle ranges on natives, graph-over-life on transformed types.

Native Trail — what the panel exposes

Native Trails use the same property panel as transformed Trails. Trails use a different storage path — properties read and write directly to the native Trail instance with no Configuration child or Render Template. There’s no real difference between transformed and native Trails at the engine level — Transform on a Trail is a no-op at the engine layer (the Trail is just marked as a Part-Icles emitter for inclusion in clipboard / retime / hue operations).

Cover for Trails is in the Trail chapter — read that for the full property surface. The native vs transformed distinction matters for emitters that have a real Transform path; for Trails it’s mostly cosmetic.

Since v38 there’s also TrailEmitter — a transformed Trail that produces clone-per-emission particles instead of the direct-access toggle. The Transform tool offers both options when you click Transform on a Trail. See TrailEmitter for the emitter variant; native Trails covered here stay direct-access.

Native Beam — BeamNative

Plain Roblox Beams are recognised as a distinct type called BeamNative. Same shape as native ParticleEmitter / Trail editing: the plugin’s panel exposes the Beam’s properties (Texture, Brightness, Width0/Width1, CurveSize0/CurveSize1, Segments, TextureLength, TextureSpeed, TextureMode, LightEmission, LightInfluence, ZOffset, FaceCamera, plus the Beam’s native Color and Transparency sequences) for direct editing, without creating a RenderTemplate / Configuration / GraphBlender. The same Beam renders continuously between its two attachments; toggling Enabled is the only emission control.

When to keep a Beam as BeamNative versus Transforming it to the Beam emitter type is covered in the Beam chapter’s Native variant section. Short version: BeamNative for static or attachment-driven streaks you want to edit with the plugin’s graph and bulk-edit tools; transformed Beam when you want clones, graphs over each clone’s life, GraphBlender multi-state animation, and emit timing.

What works on natives

Every plugin authoring convenience that doesn’t depend on the transformed model:

The graph editor. Native PE’s Size, Transparency, Squash, and Color/Transparency graphs all open the plugin’s full Graph Editor or Color Sequence Editor. Keypoints, bezier handles, presets, envelope mode, simplification — all there.

Bulk multi-selection editing. Select ten native ParticleEmitters at once, change Rate, all ten update. The plugin’s mixed-selection model works across native and transformed equally.

The clipboard. Copy property values from one native PE, paste to another. Properties match by name — Color to Color, Size to Size, etc. You can even paste from a transformed Part’s Color graph onto a native PE’s Color (same ColorSequence type).

Resize tool. Slider-driven scaling of Size (NumberSequence), Speed (NumberRange), and Acceleration (Vector3). Same tool, same UX.

Retime tool. Slider-driven scaling of timing-related properties (Lifetime, Rate, Speed, RotSpeed, FlipbookFramerate, Acceleration).

Hue tool. Hue/Saturation/Value shifting on Color graphs. Works the same way as for transformed types.

Shifter. Bulk per-axis offsets for properties that accept them.

Motion Preview. The trajectory-envelope visualisation that shows you where particles will go before they emit. Works for natives as well as transformed types.

Emit Code generation. The plugin’s emit-code tool generates a Particle:Emit() script snippet that works on both transformed and native instances. The runtime API handles the dispatch internally.

What doesn’t work on natives

Some plugin features require the transformed model and aren’t available on natives:

Linking. The Link / LinkMode / LinkSource attributes are stamped during Transform; native PEs don’t have them. If you need a native PE to follow a moving instance, parent it under that instance directly (which makes its emission position naturally follow) or use a script to update its CFrame.

Animate mode. EmissionMode = "Animate" only works on transformed types. Native PEs always use Roblox’s standard emit-and-destroy model.

Render Template. Doesn’t exist for natives. Native PEs render Roblox’s built-in flat textured quads (2D, oriented per Orientation, fed by the chosen Texture). There’s no clone-template to populate with custom geometry.

Three-axis size and rotation graphs. Roblox’s native ParticleEmitter.Size is a single-axis NumberSequence. You don’t get SizeX/Y/Z independence — only one Size graph that scales the billboard uniformly.

GraphBlender. Beam-only, transform-only feature.

Three-dimensional motion. Native PEs use 2D-billboard motion in 3D space — they don’t have the full Part-emitter motion model with DirMode, Pos. Mode, three-axis rotation graphs, etc. They have what Roblox’s API gives them and that’s it.

Emit timing — the EmitCount / EmitDelay / EmitDuration attributes

The plugin’s emission pipeline reads three timing attributes off the source instance: EmitCount (how many particles fire as initial bursts), EmitDelay (seconds to wait before the first burst), and EmitDuration (seconds of continuous loop after the bursts).

These are attributes, not panel inputs. The plugin doesn’t surface them as editable rows in any property panel — not for transformed items, not for native PEs, not for Trails. To set them, use Studio’s Properties window’s “Attributes” section:

1. Open Studio’s Properties window for the source instance.
2. Click the “Attributes” header (below the property list).
3. Click + and add a number attribute named EmitCount / EmitDelay / EmitDuration.
4. Set the value. The plugin’s emit pipeline picks it up the next time you trigger emission.

For transformed items, Transform stamps default values at Transform time (EmitCount = 0 for most types, 1 for Beam; EmitDelay = 0; EmitDuration = 0), so the attributes are present and editable in Studio’s Attributes panel right after Transform. For native PEs / Trails, you have to add the attributes manually if you want them.

The plugin’s clipboard tool groups these three under an “Emission” section so they can be copy-pasted between items, but the property panel itself stays out of the trio.

If you mutate any of these attributes from a script while the property panel is open on the same item, the panel’s input rows refresh automatically — you don’t have to click away and back to see the new value. The same goes for the Randomizer or any other external write path.

Native PE / Trail / Beam inside a transformed parent

A native ParticleEmitter, Trail, or Beam parented inside a transformed item’s RenderTemplate is now emit-aware. Two things happen:

At Transform time. Transform walks the source RenderTemplate once and sets Enabled = false on every ParticleEmitter, Trail, and Beam descendant it finds. This silences the source so it doesn’t bleed an extra particle stream into your scene from the (hidden) source RT — the native instance is purely a template. The disable is one-shot at Transform; if you later add a fresh native instance to the RT, you have to disable it yourself or re-Transform.

At emit time. When the transformed parent emits, every native ParticleEmitter, Trail, and Beam inside the cloned RenderTemplate fires alongside the parent’s emission. The fire follows whatever timing attributes are stamped on the native instance: EmitCount / EmitDelay / EmitDuration if present, otherwise a sensible default that emits one short pulse. Native Beams use EmitDuration as a single number (seconds the Enabled pulse stays on) — same shape as the native-Trail path. This behaviour is the same whether the native instance is a direct child of the RT, nested inside an Attachment, or buried deeper in the subtree.

The double-emit guard: if a transformed sub-emitter sits between the parent and the native instance, the parent’s walk doesn’t reach into the sub-emitter’s own subtree — the sub-emitter handles its own descendants when it fires. Same native PE never gets fired twice from the same parent burst.

This composes cleanly with the rest of the nesting model. A fireball Model with a transformed Part for the visible orb plus a native ParticleEmitter for sparks: every time the Model emits, the Part-particle clones itself, and every native PE inside any clone’s RT pulses according to its own emit attributes. No extra wiring.

Why the plugin is a better authoring tool than Studio’s panel even for natives

Studio’s property panel for native PE is functional but minimal:

• The graph editor for Size, Transparency, and Squash shows a list of keypoints with numeric inputs — no bezier handles, envelope mode, or presets.
• The color editor for Color is a stops-based gradient strip. Functional but minimal.
• No multi-selection editing — Studio’s panel updates one instance at a time.
• No clipboard for property values.
• No bulk-operation tools (Resize, Retime, Hue, Shifter).
• No motion preview.
• No way to add the plugin’s EmitCount / EmitDelay / EmitDuration attribute control inline (you have to switch to the Attributes section and add them manually).

Switching to the plugin’s panel for native PE editing gives you all of the above without changing the underlying instance. The instance stays a stock ParticleEmitter. Roblox’s runtime handles it natively. The plugin only intervenes when you actively edit, copy, or emit through it.

Worth knowing

A few native-specific quirks.

Native PE Speed is a range, not a graph. This catches users coming from transformed Parts. On a transformed Part, Speed is a NumberSequence that varies over each particle’s life. On a native PE, Speed is a NumberRange — each particle picks a random value at spawn and keeps it. The two aren’t interchangeable; you can’t paste a Speed graph from a Part onto a native PE.

Brightness was a recent Roblox addition. Native ParticleEmitter.Brightness is a relatively new property. The plugin exposes it as a numeric input. If you’re authoring against an older Roblox runtime, the property may not exist — Studio’s compatibility check will warn you.

The PreloadTexture attribute is plugin-specific. Roblox’s native ParticleEmitter doesn’t have a Preload mechanism. The plugin adds the PreloadTexture attribute and the runtime calls ContentProvider:PreloadAsync() for any native PE inside a transformed parent. For native PEs that emit on their own (no parent to trigger preload), the attribute has no effect — set up Roblox preloading manually if your effect needs guaranteed asset availability.

Don’t accidentally Transform a native you wanted to keep native. Transform on a ParticleEmitter doesn’t actually do anything — ParticleEmitter isn’t in the plugin’s transform-target list — but if you Transform an Attachment containing a ParticleEmitter, the Attachment gets transformed and the PE rides along as a native child. Pay attention to which instance is selected when you click Transform.

What’s next

Native Editing makes the plugin an authoring environment for the parts of your scene that don’t need transformation. Next: Texture Pinning — the PreloadTexture attribute and how the plugin keeps asset bytes resident so the first emission of a textured effect doesn’t render with a blank texture.