Spritix takes one full-body character image and generates Idle, Walk, Run, Jump and Attack animations. At the end you can export a sprite sheet PNG, an animated GIF, an Atlas JSON or a ZIP of individual frames. Those four exist because different engines and workflows want different things, and it's worth knowing why before you pick one. Most of this applies no matter where your sprites come from.

The plain sprite sheet (PNG)

One image, frames laid out in a grid, every cell the same size.

Good when your engine can slice by grid, which most can. It's also the easiest thing to hand to someone else or drop into a level editor like Tiled.

The catch is the uniform cell size. If one action has a wide attack pose, every cell grows to fit it, and you get a lot of empty space. For a handful of characters that doesn't matter. For a lot of them, texture memory starts to.

Loading it in Phaser 3:

// preload
this.load.spritesheet('hero', 'hero_walk.png', {
  frameWidth: 128,
  frameHeight: 128,
});

// create
this.anims.create({
  key: 'walk',
  frames: this.anims.generateFrameNumbers('hero', { start: 0, end: 7 }),
  frameRate: 10,
  repeat: -1,
});
this.add.sprite(200, 300, 'hero').play('walk');

You have to know the frame size and frame count yourself. Get the size wrong by a few pixels and the character slowly drifts across its own cell.

Atlas JSON

A PNG plus a JSON file describing where each frame lives and what it's called. The engine reads names and rectangles from the JSON instead of guessing from a grid.

This is what I'd pick for anything going beyond a prototype in Phaser or PixiJS. Frame names survive, so code reads walk_03 instead of "frame 19", and you stop hard-coding sizes.

Phaser 3:

// preload
this.load.atlas('hero', 'hero.png', 'hero.json');

// create
this.anims.create({
  key: 'run',
  frames: this.anims.generateFrameNames('hero', { prefix: 'run_', start: 0, end: 7, zeroPad: 2 }),
  frameRate: 12,
  repeat: -1,
});

Check the actual frame names in the JSON before writing the prefix. That one line is where most "animation shows nothing" bugs come from.

PixiJS (v7/v8):

import { Assets, AnimatedSprite } from 'pixi.js';

const sheet = await Assets.load('hero.json');
const hero = new AnimatedSprite(sheet.animations['idle'] ?? Object.values(sheet.textures));
hero.animationSpeed = 0.15;
hero.play();
app.stage.addChild(hero);

If the JSON has no animations block, you can build the texture array yourself by filtering sheet.textures by name.

Frames ZIP

Every frame as its own image. Least efficient at runtime, most flexible before it.

Use it when you plan to edit frames by hand in Aseprite, when you want to repack everything with your own texture packer alongside other assets, or when a tool simply wants a folder of images.

Animated GIF

Not for the game. It's for checking that a loop actually loops, and for posting progress somewhere. I use it more than I thought I would, because a GIF shows a bad loop seam faster than scrubbing frames in an editor.

Things that bite regardless of format

• Pixel art blur. In Phaser set pixelArt: true in the game config. In PixiJS set the texture's scale mode to nearest. Otherwise everything looks smeared when scaled.
• Anchor/origin. Characters with different poses per action should share a consistent foot position. If idle and jump have different origins, the character hops when switching states.
• Frame rate per action. One global frame rate rarely works. Idle usually wants slower, run faster.

Spritix also has a loop editor for trimming frames, changing speed (0.5x to 2x) and setting frame count and size before export, which handles some of this up front. But even if you use something else, decide frame size and timing before export, not after. Fixing timing inside engine code across five actions is slower than doing it once at the source.

What I'd pick

• Quick prototype, any engine: PNG sheet.
• Phaser or PixiJS project you'll keep working on: Atlas JSON.
• Hand editing or your own packing pipeline: frames ZIP.
• Sharing or checking a loop: GIF.

That's it. If you're using a different packer or engine setup for web games, I'm curious what format you settled on and why.

For a long time that meant printing other people's files. Every time I wanted something of my own, a small figure from a drawing or a desk object from a photo, the path went through Blender, and Blender has a way of turning a "quick" idea into a weekend of tutorials.

So I built Image to STL. You give it an image, or a text description, and it generates a full 3D mesh you can download as STL, OBJ or GLB.

One clarification up front, because people ask: this isn't a lithophane or heightmap tool. Those take a photo and turn brightness into depth on a flat plate. This produces a whole object, front and back.

How it works from your side

The homepage is the tool. There are two tabs: image to STL and text to STL.

For images, upload a JPG, PNG or WebP between 128 and 5000 px, up to 5 MB. A single image is the default. If you have several angles of the same object, there's a multi-view mode (on Pro and Max) that gives the model more to go on.

Then you pick a quality level:

Standard is a fast draft, around 80K triangles. Pro goes up to about 1.5M triangles. Max is the highest fidelity. My suggestion is to run Standard first to see whether the overall shape is right, and only spend credits on a higher tier once it is. There are also material options, including PBR, which matter more if you're taking the GLB into a game engine or a web viewer than for printing.

Text to STL is for when you don't have a picture at all. Describe the thing, get a mesh.

Downloads: STL for slicers, OBJ if you want to edit in another tool, GLB for engines and the web.

The free tier gives 15 credits a month. Paid plans are $19.9 and $32.9 per month if you need more.

Picking a good input

Most of the result is decided before you click generate. What helps:

A clear subject that fills a decent part of the frame. A plain background. Even lighting without hard shadows that could be mistaken for shape. The whole object in view, not cropped.

What hurts: cluttered scenes, overlapping objects, and photos where half the subject is hidden. The model has to invent whatever it can't see, and invented geometry is where things get strange.

For sketches, clean line art with some shading tends to work better than a loose doodle, because shading hints at depth.

Before you hit print

A generated mesh has no idea how big it's supposed to be. So the first stop is the slicer.

Scale. Set the real size you want. Then look again at the thin parts, because shrinking a model is the fastest way to make a sword blade or a finger thinner than your nozzle can print.

Wall thickness. As a rough rule, anything thinner than about two extrusion widths on FDM is risky. Either print larger, or accept that tiny details will disappear.

Supports. Figures and organic shapes are full of overhangs. Tree supports are usually easier to remove from this kind of model than grid supports. Try a few orientations; sometimes laying a model back slightly cuts support material a lot.

Bed contact. If the base isn't flat, add a brim, or flatten the bottom with a cut in the slicer.

Resin. Hollow it, add drain holes, and think about where the supports touch visible surfaces.

Most slicers will also flag or auto-repair non-manifold edges. Let them, and check the layer preview before committing to a long print.

Honest limits

It works best on single, reasonably simple objects with a clear photo. Results depend heavily on the input image. Complex mechanical parts, thin interlocking pieces, or anything that needs exact dimensions are not a great fit; for functional parts you still want CAD.

Some outputs need cleanup before they print well, like a stray blob where the background confused things, or a thin area that needs thickening. Exporting OBJ and doing a quick fix in another editor is sometimes the right move. That's still a lot less work than modeling from nothing, which was the whole point.

If you try it, I'm interested in what kinds of images worked and which didn't. That feedback shapes what I work on next: imagetostl.io.