Textures and Flipbooks

A particle has to look like something. The default duplicate inherits its visual from whatever you transformed — a brick is a brick, a sphere is a sphere, a MeshPart with a SpecialMesh and a Decal is all of that. But often you want more: a fire that cycles through six flame stages, smoke that morphs through twenty turbulence frames, a magic effect that animates a 64-frame spritesheet.

That’s what flipbooks are for. And when the texture you want exists as a Roblox asset but you only have the asset id (no source spritesheet on disk), the Dissect tool slices it into a usable flipbook at full resolution through the plugin’s server-side bridge.

Two flipbook systems, three folders

The plugin supports flipbooks on three emitter types, each with its own folder convention:

Type	Folder name	Frame instance
Part	MeshFlipbooks	Decal
Beam	BeamFlipbooks	Decal (the engine reads each child’s Texture field)
ImageLabel	ImageFlipbooks	Decal (or single Spritesheet image)

Each folder is a child of the source emitter. Frames are named numerically — 1, 2, 3, etc. — and the engine sorts them by name and cycles through. Drop ten Decals named 1 through 10 into a Part’s MeshFlipbooks folder, set the Part’s flipbook Mode to Loop, and you have a ten-frame looping animation.

The three folder names exist because each emitter type has its own runtime path: Part / Beam read sorted asset-id strings from numbered child Decals and rewrite the visual’s TextureID / Texture field per frame; ImageLabel either reads numbered Decals the same way or, when Source = Spritesheet, slices a single image by GridCols × GridRows and computes per-frame Rects.

For more on the per-property flipbook controls (Mode, Framerate, StartRandom, Reverse), see the shared chapter Mesh Flipbooks and the ImageLabel chapter for its dual-source variant.

The Inventory

Most users don’t author flipbook decals from scratch. They pick from a library — both the cloud-curated set bundled with the plugin, and their own local Studio assets. That’s the Inventory — chapter 11 covers it in full. The relevant bit here: when you click a flipbook entry in the Inventory, the plugin populates the appropriate folder on your selected emitter automatically.

Dissect — slicing an asset into a flipbook

A common authoring pattern: you find a spritesheet on the Roblox asset library — a 4×4 grid of fire frames, say — and you want each frame as its own Decal so the engine can cycle through them.

The plugin’s Dissect tool produces that for you. Plugin-side server infrastructure handles the actual dissection; from your end it’s a one-click flow.

Result: Decals land in MeshFlipbooks (or wherever you target) at full source resolution. No re-uploading. No fidelity loss.

The Dissect dialog

The Dissect dialog opens two ways: click the Dissect button on the inventory’s local-flipbooks toolbar, or shift-select multiple plain-texture entries and click Dissect on the selection toolbar that appears.

The dialog has:

• Cols and Rows inputs — the grid dimensions of each spritesheet you’ll dissect.
• Asset IDs — a multi-line text box. One id per line, or comma-separated. Each id becomes a flipbook named Spritesheet_<id>.
• From Selection — auto-fills the id box from the .Texture field of every selected Decal / Texture / Beam in your Studio workspace.
• Upload & Dissect — opens the file picker; uploads each file as a single texture, then dissects each one.
• Dissect — runs the dissection on the asset ids in the text box.

There’s no preview-of-the-grid in the dialog. You set the Cols × Rows you know are correct for the sheet (4×4 is the default; for an 8-frame strip, set 8×1; for a 16-frame square, 4×4). The plugin doesn’t validate the grid against the asset’s actual layout — set it wrong and you’ll get a flipbook of misaligned cells.

For sheets with non-standard layouts (variable frame sizes, non-grid arrangements), you can dissect into one large grid then manually delete or reorder the resulting Decals before emitting.

Texture pinning

Even with a flipbook in place, the very first emission can stutter as Roblox streams the texture asset for the first time. The plugin offers a PreloadTexture toggle in the Advanced section of Part / Beam / ImageLabel / Model emitters that force-loads the texture before emit begins. (For Model, the toggle walks every texture id reachable through the Model’s subtree.)

The full mechanism is covered in Texture Pinning under Hidden Depths.

Worth knowing

The dissect bridge is server-side infrastructure. The plugin authenticates with it via your Roblox UserId; the heavy lifting happens server-side, not in the Studio runtime.

Decals are sorted numerically by name, not by creation time. Names like 1, 2, …, 10, 11 come out in the order you’d expect. Zero-padding works too but isn’t required. Non-numeric names get treated as 0 and lump together at the front.

ImageLabel’s Spritesheet source mode skips the dissect step. When ImageLabel’s Source is set to Spritesheet, the engine reads the image once and computes per-frame Rects from the GridCols × GridRows count — no Decal folder needed. Faster on large flipbooks.

What’s next

Authoring with textures usually means iterating: tweak a property, watch the new particles fly out, tweak again. The next chapter — Motion Preview — gives you a way to see the trajectory variants of an emitter without firing it, so the iteration loop tightens. Then comes The Inventory, the library that powers texture and flipbook selection.