Drop an animated model, get a pixel-art spritesheet. The palette, the dither and the direction set are already chosen — fine-tuning lives in the editor.
Hand-pixelling a character in eight directions with eight frames each means drawing sixty-four images and keeping them consistent with one another. The hard part is not any single sprite; it is that the character has to be recognisably the same object in all of them, lit the same way, at the same proportions. That consistency is the thing a 3D model gives you for free.
Rendering is where the pixel-art look is applied, not painting. The frame is quantized to a coarse grid, every colour is snapped to a fixed palette, and an ordered dither fakes the shades the palette does not contain. Because that runs identically on every frame, the whole sheet is coherent by construction — and if you change the palette, all sixty-four sprites change together.
This page fixes the settings that need a viewport to judge. The pixel grid is derived from the cell size rather than exposed as its own number, because the ratio between them is what actually matters and getting it wrong produces a downscaled render rather than pixel art. Toon shading is on at four bands, which is what makes palette snapping read as deliberate rather than as banding. The pass order is fixed.
What is left are the five choices you can make correctly without seeing the result: how many directions, which palette, how big a sprite, how many frames, dither on or off.
That is a real trade. A palette is exactly the kind of decision you should make by looking, and this page cannot show you the alternative. It picks a good default and puts the editor one click from the result, which is a more honest arrangement than twelve sliders above a drop zone.
Smaller than you think. 32 px suits an item or a top-down roguelike character. 64 px is the classic sidescroller sprite. 128 px is a large character or a boss and is the default here. 256 px is already past the point where the pixel-art look survives — at that size the grid stops being visible as a grid and you are looking at a stylised render.
The cell is a budget, not a resolution: a 64 px sprite has about four thousand pixels to say everything with. Detail finer than one of those pixels is discarded, which is why the mesh density of the source model is nearly irrelevant here and why a heavily decimated model produces the same sheet as the original.
Sidescroller — four directions, for platformers and beat-em-ups. Isometric — eight, for RTS, ARPG and city-builder sprites. Top-down — a single overhead view, for shooters and roguelikes.
Each direction is a full re-render of every frame, so an eight-direction sheet is eight times the work of a single view. That is wall-clock time in your tab, not a limit — but it is the reason to pick the set your game actually reads rather than the largest one.
A model with no animation clips produces one pose per direction: a turnaround rather than a cycle. That is often exactly what you want for props and items.
One PNG: the beauty sheet, cells laid out by direction and frame. Drop it into an engine and slice it on the grid.
It does not include the cell metadata JSON, the normal, depth and emissive passes that drive 2D dynamic lighting, or the ready-to-import Unity and Godot packages. Those exist — they are editor exports, and the link under your result goes straight there. The split is deliberate: a page whose whole contract is "drop a file, get a file" should hand back a file, not a zip you have to unpack to find out what is in it.
For the same reason there is no custom palette import here. Lospec URLs, .gpl and .hex files all work in the editor's pixel-art pipeline, against a live preview.
Render it rather than redraw it. Apply the pixel-art look as a render effect — quantize the frame to a coarse pixel grid, snap every colour to a fixed palette, and dither between palette steps — then bake the result to a spritesheet. Because the effect runs per frame on the same model, every sprite in the sheet is consistent with every other one, which is the part that makes hand-pixelling a multi-direction character slow. Drop a file above and you get exactly that.
No. The rendering runs on your GPU through WebGL in this tab, and the PNG is assembled in the page. The file never leaves your machine.
DawnBringer 16, PICO-8, NES, Game Boy and CGA on this page. Custom palettes — a Lospec URL, a GIMP .gpl file, a plain .hex list — are supported in the editor, where you can see the model change as you switch between them.
32 px for items and top-down characters, 64 px for a classic sidescroller sprite, 128 px for a large character or boss. Above about 128 the pixel grid stops reading as pixel art. Pick the size your game actually renders at rather than a larger one you plan to scale down — downscaling a sprite sheet destroys the crisp pixel edges that were the point.
No. With animation clips you get frames sampled across the first clip; without them you get a single pose per direction, which is the right output for props, items and scenery. Either way the direction set still applies.
Almost always the cell size is too large for the look you want — at 256 px the grid is too fine to read as pixels. Drop to 64 or 128. The other cause is downstream: an engine that filters the sheet bilinearly will smear every edge, so set the texture filter to nearest/point in Unity, Godot or wherever it lands.
Not for quality — a 64 px sprite cannot show the difference between a 300,000-triangle mesh and an 8,000-triangle one. It does help speed, since every frame in every direction is a full render. If a bake feels slow, run the model through the polygon reducer first; the sheet comes out the same.
Not from this page — it hands back the colour sheet only. The normal, depth and emissive passes bake cell-aligned to the colour sheet so one set of coordinates reads them all, and they are editor exports along with the Unity Sprite-Lit and Godot Light2D packages that wire them up.
Same renderer, different amount of control. This page is a preset: five palettes, dither on or off, a fixed pass order, and one PNG out. The editor exposes the whole pipeline — custom and Lospec palettes, colour-level control, toon band count, outlines, drag-to-reorder post passes, and every export format — against a live viewport. Use this page when you want a sheet; use the editor when you want a specific look.