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.

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 most property panels — neither for transformed items (except Trail, where EmitDuration is exposed as the Duration row in the Emission section) nor for native PEs. To set them on the rest, 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.

Native PE inside a transformed parent

If you put a native ParticleEmitter inside a transformed Part’s RenderTemplate, what happens at emit time?

Per Nesting, the engine walks descendants of the parent’s cloned visual looking for Transformed = true markers. A native PE has no such marker, so it isn’t picked up by the nesting discovery walk.

But there’s a separate code path that handles native emitters inside transformed parents. When a transformed Part emits, the plugin first walks every descendant of the cloned RenderTemplate and forces Enabled = false on any ParticleEmitter it finds (convention: PEs inside an RT are treated as visual-reference, not real emitters). It then walks the direct children of the cloned RT — any ParticleEmitter or Trail direct child gets fired via EnableEmitSingle, which respects its EmitCount / EmitDelay / EmitDuration attributes if set. Attachments at the top level recurse, so PEs nested inside Attachment-only paths also fire. The transformed-nested-emitter walk runs separately afterward.

Concretely: when a transformed Part emits, any native PE child inside its RenderTemplate gets its Enabled flag toggled and any EmitCount burst triggered. If the native PE has no such attributes set, it just becomes part of the cloned hierarchy without the plugin actively emitting from it (it’ll emit on its own based on its own Enabled state, like any normal Roblox PE).

This is how you compose native and transformed emitters: a fireball Model with a transformed Part-particle as the visible orb plus a native ParticleEmitter inside it for sparks works fine. The transformed part emits through the plugin’s emit pipeline, and the native PE either rides along (its native Enabled toggling controlling its emission) or pulses on each parent emit if you’ve set its attributes.

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.