Export formats

Pixploder's whole export suite lives in one place: the EXPORT panel that fills the right rail of Step 8 · Preview & Export. It ships ten formats, and every one of them is assembled in your browser out of the scene Step 8 is previewing — same paint order, same placement, same baked shadows — so your Photoshop file, your engine package and your sprite sheet all describe the same picture. This page is the per-format reference: what each download contains, how your sprites are named and placed inside it, and the handful of rules that decide what makes the cut.

The Export panel

The panel is the whole of the Step 8 right rail — this step exists to hand the scene off, and nothing else shares the column. Its header carries a download mark and is a toggle: click EXPORT to collapse or expand everything under it, and while it is collapsed the header shows a 10 formats hint on the right.

The panel opens expanded, and so do all three of its sections, so every format is on screen at rest. Export PSD (layered Photoshop) comes first, on its own, followed by three collapsible sections with a count badge each:

• Game engines (5) — the Unity button plus Godot, GameMaker, RPG Maker and Spine.
• Pixel editors (1) — the Aseprite button.
• Universal formats (3) — Texture atlas, Cropped PNGs + JSON and Full-size layers.

Every button carries a one-line description under it, and the eight buttons inside the sections repeat that same line as a hover tooltip. Each section header is a toggle of its own, with a tooltip that flips between Expand Game engines and Collapse Game engines for the section it names. Fold the ones you never use and the panel comes down to the layered PSD button plus three folded headers, each still showing its count.

While an export builds, its own button shows a spinner reading Building… until the download fires. The layered PSD and the Unity package each run on their own lock, so neither blocks anything else — but the other eight formats (the four remaining engine targets, Aseprite and the three universal buttons) share a single lock, so starting any one of them dims the rest until it finishes. Export PSD (layered Photoshop) carries one extra condition: it stays disabled until the project actually has sprites. If a build finds no layers to write, nothing downloads and a notice says so — Nothing to export yet — reconstruct the scene first. from the eight that share the lock, Nothing to export to Unity yet — reconstruct the scene first. from Unity. A builder that breaks part-way through says so as well, in a notice that names the format and the error — PSD export failed: and Unity export failed: from those two, and the format's own name from the rest — and it releases its lock either way, so a failed run never leaves the panel stuck.

What every export shares

The eight packaged formats read one shared snapshot of your scene, so placement and stacking never differ between them. From back to front that snapshot is: the inpainted background as the farthest-back, full-document layer; a ground shadows plate that unions every sprite's contact shadow from Step 6 · Add Shadows; then each sprite as a cutout at its box position, with its own object shading already baked into the pixels. The Unity package and the layered PSD are built on their own paths from the same scene, so they line up too.

Layer order is paint order — the order you set on Step 5 · Finish Sprites — read back to front: the sprite that paints first is the back of the scene, so it lands at the bottom of the exported stack, just above the background and the shadow plate, and the one that paints last ends up in front of everything. Inside a group, members keep the order the element tree lists them in.

Ground shadows follow that same order rather than all sitting at the bottom. The plate is styled once, as one piece — so overlapping shadows never darken twice — and is then cut into disjoint slices: ink cast by a sprite stacked above others rides in its own layer directly beneath that sprite, named <sprite name> shadow, and inside that sprite's group. Ink that nothing can be stacked under stays in the one bottom ground shadows layer. A scene whose shadows only ever fall on the background exports exactly as it always did: one plate, one layer.

Shadow styling is baked into the ink, not left as a blend mode. The Blend onto the scene mode and the Strength you chose on Step 6 · Add Shadows are folded into the shadow pixels before any file is written, so every format ships its shadows as plain normal-blend layers and every tool shows the shadow the app previews with nothing left to set by hand.

Group membership travels with each sprite. The formats that understand folders — PSD, Unity, Godot, Aseprite — rebuild your group tree, and two groups that happen to share a name stay two folders there, because those exporters key on group identity and only take the display name from it. The two universal ZIPs that ship loose files nest them in real subfolders named after the group path. The rest keep the group path as a text field in their JSON, so a custom loader can still regroup. Spine is the one exception: its data model has no folders, and its README says so.

Three rules decide what makes the cut.

• The approval gate. Once you have ✓-picked any sprite in Step 5 · Finish Sprites, only approved sprites export: the ones you ticked, plus every sprite that sits in no generation call at all — nothing was generated for it, so there was never anything to review and it counts as approved. All ten formats read that one set — the layered PSD included — so no format ever comes out short of layers. A project with no picks at all exports everything; there is nothing to gate on yet.
• No hidden rows. There is no per-layer hide any more: the eye lived on Step 8's removed Layers list, so every approved sprite ships in every format. To keep a sprite out of the package, leave it un-approved on Step 5 · Finish Sprites — its ↺ corner puts an approved sprite back in the queue.
• Texture filtering is always crisp. Every format declares nearest filtering, and there is nothing to set: Pixploder works in pixel art on every project. ★ Repixelize on Step 7 · Final Polish changes the resolution your files ship at, never the filtering they declare.

Once a Step 8 bake is applied, a fuchsia baked · nearest chip appears in the preview header next to the zoom read-out, naming the filtering your files will ship with and, after it, the palette that was snapped when one was armed.

Sprite names become file names through one rule across the packaged formats: lowercased, every run of non-alphanumeric characters turned into _, leading and trailing underscores dropped, trimmed to 48 characters, and a _2, _3 suffix added if two layers would collide. The Unity package spells names the same way but does not trim them, and the layered PSD needs no file names at all — its layers keep the names you typed, spaces and punctuation included. If you reused one sprite's generated result on another sprite, the formats that can share a texture ship those identical pixels once and point both layers at the same file.

Palette snaps, and the two flattenings outside the promise

If you snapped the scene to a palette on Step 7 · Final Polish, every layer in every format carries only that palette's colors on its opaque pixels — background, sprites and shadow ink alike. That is a checked promise rather than an intention: an automated test snaps a scene, pushes it through the export builders, and fails if a single opaque pixel of any per-layer product comes out in a color the palette does not hold. It covers all three universal formats, the four engine bundles that ship PNGs, and the Aseprite file; the layered PSD and the Unity package sit outside that particular test.

Two products sit honestly outside the promise itself, and both are flattenings rather than layers: the composite.png inside Full-size layers (ZIP), and the PSD's merged preview together with its Original scene layer, which is a copy of your working source. Translucent shadow ink is snapped too, but what it composites to over the art beneath it is a blend of two palette colors, which is not itself one of them. Files stay full-color RGBA in every format — an indexed Aseprite mode and a PSD color table are a separate job, and the snap does not turn them on.

Sprites you kept in the background

A sprite you flagged Keep in background on Step 3 · Find & Cut still exports as its own layer, even though its pixels are also part of the backdrop image underneath it — a package you can pull apart is worth that overlap. It casts no ground shadow of its own. The Step 8 diorama preview drops those planes instead of drawing them twice, so this is the one place where the preview and the files deliberately differ.

What each format preserves

The ten downloads at a glance

Every ZIP unpacks into a single top-level folder named after the file, and every ZIP ships a README text file with the steps for that target — README.txt, or README_GAMEMAKER.txt and README_RPGMAKER.txt for those two.

Photoshop — the layered PSD

Export PSD (layered Photoshop) is the flagship, and the one button the panel shows without opening a section. Its line reads "Groups as folders, every sprite as an editable positioned layer (shadows baked in), plus the background tree. Auto-switches to .psb past 30,000 px."

It downloads pixploder-layers.psd: a fully layered document where your groups become real Photoshop folders (nested, collapsed when it opens), each sprite is an editable layer at its own position with its shading baked in, and a group's mask arrives as a Photoshop group mask with the members still individually editable inside it. A sprite whose rebuilt artwork reaches past the canvas keeps those pixels and hangs over the edge, exactly as the app draws it. A sprite whose folder is missing from the file — a stale parent link left behind by an edited element tree — is rescued to the top level rather than quietly dropped.

Beneath the sprites sit the raw materials, bottom-up:

1. Original scene — your untouched working image.
2. Background (scene minus elements) — a hidden layer of full scene pixels under a non-destructive mask that hides every cut-out element, written whenever at least one exported element carries a mask. Sprites you kept in the background are deliberately left showing in it, because their pixels belong to the backdrop. Paint the mask in Photoshop to bring other pixels back; nothing is baked out.
3. The Background folder — the editable patch tree you built in Step 4 · Rebuild Backplate, mirrored as nested folders with each patch's hole mask as an inverted layer mask. It is written only when the tree holds more than the bare base, and a patch you switched off with its Hide eye on Step 4 arrives as a hidden Photoshop layer rather than a missing one.
4. Ground shadows — the ink no sprite can be stacked under.

Any shadow that has to sit above a sprite is not in that bottom layer — it arrives as a <sprite name> shadow layer placed directly beneath its own sprite, inside the same folder, so dragging the folder keeps the two together. Shadow layers are plain Normal layers on purpose, because the blend and strength you set on Step 6 are already in the ink.

This is the only format that preserves the editable background patch tree and the raw scene-minus-elements layer — every other format flattens the backdrop to one image. It is also the only format written at your source resolution: after a ★ Repixelize bake the other nine ship the small baked document, while the PSD keeps the original canvas size and carries the repixelized art inside it as chunky pixels. For a canvas over 30,000 px on either side the export switches itself to the Large Document Format and downloads pixploder-layers.psb instead: same contents, in the container Photoshop needs to open a document that size.

Game engines

Five targets. Unity has its own prominent button at the top of the section; the other four sit below it.

Export to Unity (.unitypackage)

"Every layer as a point-filtered Sprite, placed in 3D as a diorama. Double-click the imported scene to open it."

Downloads pixploderdiorama.unitypackage, a Unity 6 package built as a gzipped tar in the browser. Import it into a project and double-click Assets/pixploderdiorama/pixploderdiorama.unity. Inside are a Sprites/ folder (the background, one PNG per layer and one per ground shadow), a Scripts/ folder holding the PixploderDiorama.cs component, and the ready scene.

Every layer becomes a Single Sprite on its own GameObject, placed in 3D by the same depth model the Step 8 diorama uses; groups become empty parent objects mirroring your tree; and sorting order follows paint order, so overlaps match. Each ground shadow is its own upright quad sorted one step below its caster and parented in the caster's group. Orbit the Scene view to see the depth, and drag Parallax Separation on the PixploderDiorama component in the Inspector to spread the layers apart or flatten them — the component holds explicit references to every layer and its depth, so re-parenting in the Hierarchy is safe.

Export to Godot 4 (.tscn + PNGs)

"Drop-in folder: a Sprite2D scene with paint-order z-index, nearest filtering, groups as Node2D and per-sprite parallax depth metadata."

Downloads pixploder_godot.zip — a pixploder_godot/ folder holding a text scene.tscn (format 3), a sprites/ folder of trimmed PNGs and a README. Copy the folder into your project root, let Godot import the PNGs, and double-click the scene.

Under a PixploderScene root, each layer is a Sprite2D with centered = false at its top-left position in document pixels, a nearest texture_filter, and an absolute z_index (z_as_relative = false) carrying the paint order, so re-parenting in the editor cannot change the stacking. Groups are Node2D parents. Shadow layers need no material of their own. Every sprite carries metadata/pixploder_depth (0 far … 1 near) for a parallax script — the README even suggests the one-liner. Godot may log UID notices the first time it opens a text scene authored elsewhere; saving once clears them.

Export to GameMaker (assets + GML)

"Included Files + a GML script that rebuilds the scene on version-proof asset layers at the right depths."

Downloads pixploder_gamemaker.zip: the images and a scene.json under datafiles/pixploder/ to drop into Included Files, plus scripts/scr_pixploder_build/scr_pixploder_build.gml. Paste the script into a script asset of that name, call pixploder_build_scene() from a room's creation code, and the scene rebuilds at runtime on asset layers — the background at depth 15000 and every sprite 10 depth-steps closer, so your own instances can slot between them. It deliberately never touches the fragile project format, which is what makes it work on every recent GameMaker version.

Export to RPG Maker MZ (plugin)

"Full-size stacked pictures plus a plugin with Show/Hide scene commands (manual MV path included)."

Downloads pixploder_rpgmaker.zip: every layer as a full-canvas picture named in paint order under img/pictures/ (px_001_…, px_002_…), a js/plugins/PixploderScene.js plugin with Show Pixploder scene and Hide Pixploder scene commands (both take a First picture ID), and a scene.json for reference. The layer list is baked into the plugin at export time, so it is self-contained. Every picture is shown at (0,0) with normal blending. Because every picture goes at the same place, the README also documents a manual Show-Picture path that works in MV.

Export to Spine 2D (JSON + atlas)

"skeleton.json for the Spine editor + packed .atlas/.png for runtimes; slots follow the paint order."

Downloads pixploder_spine.zip, which serves both Spine paths at once: a skeleton.json with a loose images/ folder for the editor's Import Data route, plus a packed skeleton.png and libGDX-format skeleton.atlas that a runtime can load without opening the editor. One root bone sits at the document's bottom-center, and each layer is a slot plus a region attachment on the default skin, in paint order — first slot drawn behind. The data is written as Spine 4.1, which any 4.1-or-newer editor imports. Group names are not part of Spine's data model, so the slot list is flat.

Pixel editors

One native-file export, written straight from the file-format spec — no ZIP, no README, just the file.

Export to Aseprite (.aseprite)

"One native file: every layer editable, Pixploder groups preserved, ground shadows as multiply layers stacked in your layer order."

Downloads a single pixploder.aseprite with every layer editable and every Pixploder group preserved as a real Aseprite group layer, in bottom-to-top order. Each non-empty layer becomes one zlib-compressed cel trimmed to its visible pixels, in sRGB RGBA. Ground shadows are stacked in your layer order exactly as the panel's line says — each in its own layer, directly under the sprite that casts it — but they ship with Aseprite's Normal blend rather than Multiply, because the blend and strength you set on Step 6 are already baked into the ink; a multiply on top of that would darken the scene twice. The document is clamped to 65,535 px per side, the hard ceiling the format allows.

Universal formats

Three engine-agnostic hand-offs for custom pipelines — MonoGame, Raylib, Phaser, PixiJS or a loader you wrote yourself. Each ZIP ships a README that spells out the reconstruction, and the atlas one adds copy-paste loader snippets.

Texture atlas + JSON/XML

"One packed sheet + TexturePacker-hash JSON and Starling XML with full scene placement — Phaser/Pixi load it directly."

Downloads pixploder_atlas.zip: one packed atlas.png, plus atlas.json (TexturePacker "JSON hash", which Phaser 3 and PixiJS load directly) and atlas.xml (Starling/Sparrow, the same data). Frames are shelf-packed on a power-of-two sheet with a 2-pixel gap and no rotation; nearest sampling never reaches across a frame border, so there is no edge extrusion to pay for. Every frame's source size is the whole document and its trim offset is its position in it, so drawing each frame at (0,0) with a top-left origin rebuilds the scene with no math. The full background stays off the sheet as its own background.png — packing it would roughly double the sheet — and is listed in the metadata with its position. That metadata, under meta.layers, also carries every layer's paint order, depth, blend and group for a hand-rolled loader.

Cropped PNGs + JSON

"Every sprite at its minimum box + scene.json with offsets, z-order, depth and groups — the standard hand-off."

Downloads pixploder_sprites_json.zip: every sprite trimmed to its minimum bounding box under sprites/ (element groups become subfolders under it — a project with no groups stays flat), the backdrop as background.png, and a scene.json that spells out each sprite's top-left x/y, its center offset, size, z-order, depth, blend and group. Coordinates are whole pixels except the center offsets, which can end in .5 for odd-sized sprites. The README carries reconstruction pseudocode for both the top-left and the center anchoring convention.

Full-size layers (ZIP)

"Every layer as a full-canvas transparent PNG — stack them at (0,0) in absolutely any software."

Downloads pixploder_layers.zip: every layer as a full-canvas transparent PNG in a layers/ folder, numbered in paint order (00_, 01_, 02_ …) — element groups become subfolders under layers/, and the numbering stays global across them so it still spells out the whole stack — plus a flattened composite.png to check the result against and a layers.json listing names, z-order, depth, blend and group. Stack the PNGs at (0,0) in ascending order, in any software at all, and the scene rebuilds itself.