DEV Community: rivskiy skulitom

How to make a pixel art waterfall animation (free, in your browser or from the command line)

rivskiy skulitom — Tue, 03 Nov 2026 17:23:19 +0000

Written with AI help (Claude), checked against the project's docs. Pixelbolt is made by our small lab, so we're not neutral; every number below comes from a run on 3 November 2026 with Pixelbolt 0.11.0 from npm.

This is a looping pixel art waterfall for a 2D game: water leaves a mossy stone ledge in an arc, lands in a basin and spills over its lip. It's made with Pixelbolt, an MIT-licensed tool that simulates the water as particles on a pixel grid and bakes each frame into palette pixels.

What you get

The waterfall preset, unchanged, rendered by pixelbolt gif at 6× on a dark background.

48 × 64 pixels, 24 frames of 60 ms (a 1.44 s loop at 16.67 fps)
9 palette colours on a transparent background (the GIF above is blended onto a dark colour and enlarged 6×)
a 384 × 192 sprite sheet (8 × 3 cells), a TexturePacker-style atlas JSON with each frame's rectangle and duration, a GIF, an animated PNG and single frames

The browser way

The guide gives four steps:

Open the waterfall in the playground from the guide's waterfall section (link at the end). The link carries the whole recipe, with nothing to install and no account.
Change a value in the Recipe JSON box. The preview renders again after each edit.
Choose a scale from 1× to 16× for the frame PNG and the GIF. The sheet and atlas stay at the art's own size.
Download the sheet, the atlas PNG and JSON, the GIF, a frame PNG or the recipe. Copy link makes a link to your edited version.

A note on versions: the guide's link and commands name Pixelbolt 0.9.1. The commands below use 0.11.0, the newest release. The recipe, size and timing are the same, but 0.11.0's liquid changes alter about 150 to 220 of each frame's 3,072 pixels. Its changelog says the waterfall's foot "splits into strands a little more".

The command-line way

You need Node.js 20 or newer. The waterfall ships as a preset:

npx -y pixelbolt@0.11.0 compile --preset waterfall --out waterfall.json
npx -y pixelbolt@0.11.0 gif waterfall.json --scale 6 --background "#17191d" --out waterfall.gif
npx -y pixelbolt@0.11.0 render waterfall.json --out waterfall

compile runs the simulation and writes an ordinary recipe of frames. gif enlarges it by a whole number and blends it onto one colour. render writes a folder holding the sheet, the atlas JSON, the frames, an animated PNG, CSS, a canvas player and a preview page. It also writes waterfall.tres, which the folder's README.txt calls a Godot 4 SpriteFrames file; we haven't tested that file. For engines in general, the guide says to slice the sheet as a grid of equal cells. Nothing is overwritten unless you add --force.

One knob, changed

The guide names the settings under effects → waterfall:

velocity on the source emitter ([1.1, 0]), which sets how far out the arc reaches
pulse, which surges the flow four times a loop
whitewater for spray and foam
flip, livelier toward 1 and calmer toward 0
the depth colour layer

To edit the recipe, save it as waterfall.fluid.json with the playground's Recipe JSON button, or download the same file from the npm package (in Windows PowerShell, type curl.exe):

curl -O https://cdn.jsdelivr.net/npm/pixelbolt@0.11.0/examples/waterfall.fluid.json

Compiling that file gives byte-for-byte the same result as the preset. We changed velocity from [1.1, 0] to [1.6, 0] and nothing else:

npx -y pixelbolt@0.11.0 compile waterfall.fluid.json --out waterfall-fast.json
npx -y pixelbolt@0.11.0 gif waterfall-fast.json --scale 6 --background "#17191d" --out waterfall-fast.gif

The same recipe with velocity at [1.6, 0].

The arc now lands near the basin's right lip instead of mid-basin. Halfway down (row 30), the stream's centre moved from x 24–27 to x 29.5–30. More water reaches the basin: the pool's surface rose from rows 43–45 to row 39, more spills over the lip, and the drawn water went from 619–640 to 708–739 pixels a frame. Size, timing and loop didn't change.

Not every value is accepted. A pulse period of 5 is refused: "a looping effect repeats every 24 frames, so the period must divide 24".

Numbers from our run

Node 24.19.0, Windows 11, a 16-core desktop CPU:

compile took 3.02, 3.32 and 3.27 s through npx, which needs about 2.3 s just to start. Run with node on the same package, it took 1.03–1.07 s, about 0.3 s of that Node's start-up.
gif and render each took about 0.35 s with node.
Every run gave byte-identical files.
The GIF is 288 × 384 pixels and 41,809 bytes, the sheet 6,519 bytes and the atlas 9,599 bytes.

How it works

Pixelbolt's physics notes describe one grid per effect, one cell per pixel, with the liquid carried by particles, four to a full cell. Each step moves the particles' motion onto the grid, applies gravity and cohesion, and solves for pressure. It then hands the velocities back to the particles and moves them, never into a solid. The maths uses only basic arithmetic, square roots, the project's own trigonometry and seeded hashing, with fixed step counts, so a recipe gives the same pixels on every run. The stated aim is the picture: "When accuracy and looks disagree, looks win."

Limits

A fluid canvas is at most 128 × 128 pixels, with up to 16 emitters and 32 obstacles per effect.
One liquid per effect: mixing several is "out of scope for now".
Frames are at most 256 × 256 pixels, and a project holds at most 256 frames.
It imports PNG only, doesn't edit GIF or Aseprite files, uses no image model and isn't meant for painted or photographic art.
Spray and foam are still drawn as single pixels and dashes.
It's tuned for looks, not engineering accuracy.

How to make a pixel art fire animation for Godot 4 (free, in your browser)

rivskiy skulitom — Tue, 27 Oct 2026 17:19:40 +0000

Written with AI help (Claude), checked against the project's docs. Pixelbolt is made by our small lab, so we're not neutral; the measurements below come from a run on 27 October 2026 with Pixelbolt 0.9.1 (from npm) and Godot 4.6.3.

You want a looping campfire in your Godot game, you'd rather not hand-animate two dozen frames, and you'd like to change how it burns. Here's one way that's free and runs in a browser: open a ready fire recipe in Pixelbolt's playground, tweak a couple of numbers, export a sprite sheet, and slice it in Godot as a plain grid.

The campfire recipe, unchanged, rendered by pixelbolt gif at 8× on a dark background.

What you get

From the campfire recipe, unchanged:

The animation: 32 × 48 pixels, 24 frames of 70 ms each (1.68 s), looping, 9 colours on a transparent background.
The sprite sheet: 256 × 144 pixels, 8 columns × 3 rows of 32 × 48 cells with no padding. The PNG is 3,375 bytes.
The atlas JSON: a TexturePacker-style hash with every frame's rectangle and its 70 ms duration, plus the animation's name, order and loop flag.

The flames come from a small simulation of heat and smoke, not from hand-drawn frames, and a recipe renders to the same pixels every time.

Step 1: open the campfire recipe

Open the campfire in the Pixelbolt playground. It's the same button as on the fire guide. The link carries the whole recipe and names Pixelbolt 0.9.1; the playground renders it in your browser, with nothing to install and no account.

Step 2: change how it burns

The recipe is JSON. The fire's settings sit under effects → campfire, and the preview renders again after each edit. If the JSON breaks, the playground says what's wrong, usually with the line number. The guide's suggestions:

Setting	Default	What it does
`buoyancy`	0.45	How hard the heat rises. Higher lifts the flames higher and faster.
`cooling`	0.24	The share of heat lost each frame. Raise it for a lower fire, lower it for taller flames.
`vorticity`	0.45	Keeps small swirls alive, so the flames and smoke curl.
`flicker` (on the fire emitter)	0.6	Variation from cell to cell and frame to frame that breaks the base into tongues.
`count` (in the embers emitter's sparks)	0.5	Embers per frame. Fractions mean some frames get one and some don't.

What one change did in our run: the guide says to lower cooling for taller flames. Pixelbolt's compile report gives the fire's bounding box for every frame. Averaged over the 24 frames, it was 23.8 px tall at the default 0.24, 24.9 px at 0.16 (hardly a change) and 28.6 px at 0.08 (clearly taller). At 0.08 the gas stays hot as it rises, so the grey smoke turns into red wisps. Change it in bigger steps than you'd expect, and watch the smoke.

The torch recipe works the same way. For a blue torch, change the hex values of r, o, y and W in its palette (coolest to hottest). We used #1d3f8f, #2f7de1, #7cc8ff and #e8f8ff, and it rendered as a blue flame.

Step 3: export a sheet Godot can slice

Download Atlas PNG + JSON (or just Sheet PNG). Sheets come at the art's own size, one pixel per pixel, whatever scale you pick for the GIF and frame PNG. For a bigger sheet, add "sheet": { "scale": 4 } at the top level of the recipe (whole numbers from 1 to 16), or keep it small and scale it in Godot with nearest-neighbour filtering.

For Godot's grid slicing, Pixelbolt's game integration notes say: keep the default untrimmed layout and set sheet.padding to 0. The campfire's sheet already has no padding: 256 = 8 × 32 and 144 = 3 × 48.

The same from the command line

With Node.js 20 or newer, save the recipe (the playground's Recipe JSON button saves campfire.fluid.json, or take the one in the 0.9.1 package) and run:

npx -y pixelbolt@0.9.1 compile campfire.fluid.json --out campfire.json
npx -y pixelbolt@0.9.1 gif campfire.json --scale 4 --out campfire.gif
npx -y pixelbolt@0.9.1 render campfire.json --out campfire

compile runs the simulation and writes an ordinary recipe of frames. gif writes the animation. render writes a folder with the sheet (campfire.png), its atlas (campfire.atlas.json), every frame as its own PNG, an animated PNG, CSS classes, a small canvas player, a preview page and the recipe. Pixelbolt won't overwrite existing files unless you add --force.

In our run (Windows 11, Node 24), each npx command took 2.0 to 2.6 seconds, mostly npx starting up; the compile itself took about a third of a second. render wrote 32 files. The 4× GIF is 128 × 192 pixels and 22,385 bytes. The playground's GIF and atlas JSON came out byte-identical to the command line's, and its sheet PNG has the same pixels (it's a little bigger because the playground embeds the recipe in every PNG it exports, so you can drop the file back on the page and keep editing).

Step 4: play it in Godot 4

Copy campfire.png into your project.
For crisp pixels, set Project Settings → Rendering → Textures → Canvas Textures → Default Texture Filter to Nearest (or set Texture → Filter to Nearest on the node).
Add an AnimatedSprite2D. In the Inspector, set Sprite Frames to a New SpriteFrames and open it.
Click Add frames from sprite sheet, pick campfire.png, set Horizontal to 8 and Vertical to 3, select all 24 cells and add them.
Set the animation's speed to 14.29 FPS (1000 ÷ 70 ms), turn Loop on, and turn on Autoplay on load.

What we checked: in Godot 4.6.3 we imported the sheet headless and built the same SpriteFrames from a short script that reads the atlas JSON: 24 frames at 14.2857 FPS, loop on. Every rectangle in the atlas matched the 8 × 3 grid, and an AnimatedSprite2D played frames 0 to 23, then looped back to 0 (28 frame changes in 2 seconds). We didn't click through the editor steps above or take a screenshot in Godot; they're Godot's standard SpriteFrames steps for the same grid.

Limits

No Godot export. Pixelbolt writes PNGs and a TexturePacker-style JSON. Godot doesn't read that JSON, so you enter the grid, the speed and the loop yourself. The files never state an FPS: divide 1000 by the frame time in milliseconds.
Uneven frame times and padding. The guide's hand-drawn flame plays its 4 frames for 80 to 120 ms each, and its sheet has 1 px of padding. Set the recipe's sheet padding to 0 before you export, then use each frame's duration from the JSON (in Godot, a frame's duration is a multiplier of the animation speed), or import the separate frame PNGs instead.
Size. A recipe is capped at 256 × 256 pixels and 256 frames.
GIFs. Pixels under 50% opacity become fully transparent, and frame delays are rounded to 10 ms. The PNG sheet keeps full alpha, so use the sheet in the game and the GIF for devlogs.
The playground needs a recent browser (JavaScript, module workers and CompressionStream) and loads the engine from jsDelivr. The Atlas PNG + JSON button downloads two files; if your browser keeps only one, the page shows links to both for two minutes.
What we tested: Godot 4.6.3, headless, with the campfire. Not Godot 3, not the editor's clicks, and not the torch in Godot. Pixelbolt's own notes say engine integration "should be checked in your target engine", and that's fair advice.

If you'd rather not make your own

Our Elemental FX pack has 27 effects made with Pixelbolt (elemental powers, impacts, fire, smoke, goo, lava and magic), each with its sheet, atlas JSON and a Godot 4 SpriteFrames file you set on an AnimatedSprite2D. It's $4.99 or more, or $3.49 in itch.io's Halloween Sale until 4 November, 18:00 UTC.

How to nest laser-cut parts for free in your browser

rivskiy skulitom — Tue, 20 Oct 2026 13:13:59 +0000

Written with AI help (Claude), checked against the project's docs. Disclosure: this account belongs to the small project that makes Nestbolt.

Nesting means arranging the parts of a drawing on your sheet before you cut, so they use less material. Nestbolt is a free, MIT-licensed nesting tool for fixed sheets (laser, CNC, plasma, waterjet, fabric). Its browser app runs the nesting engine on your own computer in WebAssembly, and the page says it plainly: "Everything runs in this browser; files are never uploaded."

Below is one real run, step by step, with the numbers the app showed. I ran it on 20 October 2026 in desktop Chrome on the hosted app.

1. Open the app

Go to skulitom.github.io/Nestbolt. There is nothing to install and no account. If you just want to see how it behaves, it has five one-click examples: finger-jointed boxes, letters inside letters, a mechanical kit, a sewing pattern and interlocking gears.

2. Import your parts

Click Import SVG, DXF or LightBurn (or drop files on it). The importer treats each closed outline as a part and any outline inside it as a hole, so small parts can later sit inside larger ones.

My file was a 420 x 70 mm SVG with six outlines: a cat ornament, a star, a coaster, a gear, a heart keyring and a name tag. The app listed them as six parts with their areas (26.1, 8.4, 17.8, 14.1, 14.1 and 16.9 cm²) and showed what its cleanup did:

laser-parts.svg: cleanup removed 0 exact duplicate segment(s), 1 zero-length segment(s); merged 0 overlapping collinear segment(s)

Gaps up to 0.005 mm are joined automatically; larger repairs are listed with their positions. The import panel also shows which layers and colours it picked as cut lines, which is worth a look if your drawing has engraving or guide layers.

3. Set quantities, rotations and mirroring

Each part gets a Qty box, a Rotation choice and a Mirror tick box. Rotation options are 0/90/180/270° (the default), 0/180° (grain), Fixed 0°, Every 15° and Free. Use 0/180° when the grain or pattern direction matters.

I typed 12 cats, 20 stars, 8 coasters, 16 gears, 20 hearts and 15 tags: 91 parts, default rotations, no mirroring.

4. Describe the sheet

The default sheet is 600 x 400 mm with a 5 mm margin, and the preset list has Diode laser 300×200, CO2 bed 600×400, Plywood 1220×2440, two sheet-metal sizes and a 1500 mm fabric roll. You can add more sheet sizes, a count limit per size, a remnant outline (an odd-shaped leftover piece) and defects to avoid.

Under Settings: part spacing and edge spacing (1 mm each by default), the goal (Place every part, Fill the sheets (most area) or Fill by priority) and the time budget (Time, 30 s by default). I left all of these at their defaults.

5. Press Nest

The best layout found so far is drawn while the search runs. After the 30 seconds, my result read:

Sheets	Utilisation	Placed	Check
1	64.6%	91/91	valid

All 91 parts fit on one sheet, and the unused material was left as one clear strip, labelled offcut 600 × 49 mm, along the top. The project's README says the last sheet is compressed towards one end so that the offcut stays usable.

Check: valid comes from an independent validator (Clipper2) that tests overlap, spacing, containment, rotations and quantities. According to the README, invalid layouts are never returned.

The search is time-based, so results vary a little between runs: the same file and quantities gave 65.0% on 17 October, on an older build of the app.

6. Download the sheets

Each sheet has SVG and DXF buttons, and Download all sheets (ZIP) gets them all at once. My sheet-0.svg was 600 mm x 400 mm with all 91 parts as paths in one CUT group. The name tags' rounded corners were still SVG arcs (A 6 6 ...), not chains of short lines: the README says export is "transformed from the original curves rather than re-polygonised".

Open the file in your laser or CAM software and check it there before cutting. Save keeps the project in the browser, and Project ZIP saves it as a file.

Limits worth knowing

The hosted app runs a preview build from the project's main branch. The stable release (v0.1.0) is a download.
LightBurn project nesting (.lbrn2 and .lbrn) and lead-in allowances are preview features.
Common-line cutting is optional and still under development. It can increase material use, and its export needs CAM preparation so shared sections aren't cut twice.
Nestbolt gives no machine-safety or fit certification. Review every sheet in your own cutting software.
My numbers come from one run on one PC. A bigger job, or a slower computer, may need a longer time budget.

Other ways to run it

The same engine also comes as command-line tools for Windows, Linux and macOS (Apple silicon), and as an MCP server, so an AI agent can import, nest, validate and export a job (agent interface). The engine builds on jagua-rs and sparrow by Jeroen Gardeyn and collaborators.

More guides on the project site: free nesting for laser cutting, nesting SVG and DXF in the browser, the five examples and the benchmark results.

How to put crisp, animated pixel art in a GitHub profile README

rivskiy skulitom — Sat, 17 Oct 2026 22:58:20 +0000

Written with AI help (Claude), checked against the project's docs.

The header, tool cards, link buttons and footer of the GitHub profile at github.com/skulitom are now pixel art that moves: a night workbench where a flask boils and steam rolls up past a window, and a small scene for each tool. AI agents made all of it with Pixelbolt, a pixel-art tool that agents drive with JSON recipes. The liquid, mist and steam are real fluid simulations, shaded as pixel art. And it stays sharp at every width GitHub shows it at.

This post covers the README trick that keeps the pixels crisp, the simulations behind the steam, and how one command rebuilds every pixel to the same bytes.

The problem: GitHub scales your GIF and blurs it

A profile README is Markdown plus a little HTML. No JavaScript, no <style>, no style="". You get images.

Pixel art needs whole pixels. The usual move is a GIF with width="100%", so it fills the column. But the browser scales that image with smoothing, and GitHub's column is almost never a whole multiple of your art. These are the widths we measured:

Viewport	README column	Cell of a two-column table
1440 px	846 px	395.5 px
1280 px	831 px	388 px
1012 px	563 px	254 px
768 px	383 px	164 px
390 px phone (2x screen)	308 px	126.5 px

Here is one frame of a 192x100 card at 846 px wide, rendered by Chrome at 1x on a page that sizes images the way GitHub does. Left, as a plain image. Right, the same frame through the SVG wrapper described below.

The trick: an SVG that plays a sprite sheet

An SVG file is an image as far as the README is concerned, but inside it you can write CSS. Two properties do the work:

image-rendering: pixelated on the embedded sprite sheet, so it scales without smoothing.
A @keyframes animation with step-end timing that moves the sheet one frame at a time behind a clip.

This is the Inkbolt card's wrapper, trimmed (one keyframe stop per frame, 72 in all):

<svg xmlns="http://www.w3.org/2000/svg" width="384" height="200" viewBox="0 0 192 100"
     shape-rendering="crispEdges">
<style>
image{image-rendering:pixelated;image-rendering:crisp-edges;image-rendering:pixelated}
.a{animation-timing-function:step-end;animation-iteration-count:infinite}
@keyframes k0{0.0000%{transform:translate(-192px,0px)}1.3889%{transform:translate(-384px,0px)} /* ... */}
.l0{animation-name:k0;animation-duration:5040ms;transform:translate(-192px,0px)}
</style>
<defs><clipPath id="c0"><rect x="0" y="0" width="192" height="100"/></clipPath></defs>
<g clip-path="url(#c0)">
  <image class="a l0" width="1536" height="1000" href="data:image/png;base64,..."/>
</g>
</svg>

The sheet is 1536x1000: eight columns and ten rows of 192x100 frames. 72 frames at 70 ms each is 5,040 ms, so each frame owns 100/72 = 1.3889% of the animation. The viewBox is in art pixels, so the README can scale the whole SVG to any width and every art pixel stays a hard-edged block.

In the README it is an ordinary image:

<picture>
  <source media="(prefers-reduced-motion: reduce)" srcset="assets/v4/inkbolt-still.svg">
  <img src="assets/v4/inkbolt.svg" width="100%" alt="An ink drop falls into water and blooms into a vortex ring">
</picture>

We tested this in Chrome 155, Firefox 157 and WebKit 26.6 at 1x and 2x, and on github.com itself, before drawing any real art. It is cheap: a 96-frame, 208x162 stress sheet came to about 530 KB, and the finished profile's 40 SVGs (the header, phone header, four cards, footer and seven link buttons with their phone-width versions, each with a motionless twin) total 531,619 bytes.

Things that caught us out:

Everything must be inline. An SVG shown as an image can't load other files, so the PNG sheet goes in as a data: URI.
Reduced motion doesn't reach inside. The SVG can carry a prefers-reduced-motion query, but no engine we tested applied it to an SVG shown through <img>. The motionless twin goes in a <picture> source instead.
The animation starts at frame 0 on every page load. If frame 0 is a quiet hold, that's what visitors stare at. Order the sheet so it opens on a moment worth seeing; the loop is the same.
Two halves leave a hairline. Pixelbolt caps a frame at 256x256, so the 416x162 header is two 208x162 halves side by side. At fractional widths (831 and 563 px) Chrome and Firefox drew a 1 px seam between them. Making the left background one column wider (209 px), so the right half covers an identical column, removed it.
Text belongs in the SVG, not the pixels. Labels are SVG <text> drawn over the art, so they stay sharp at any size. Screen readers read the <img>'s alt, so describe the scene there.

The steam is a simulation

Pixelbolt compiles a fluid source into an ordinary recipe of palette pixels. Gases use stable fluids (advection, a pressure solve, vorticity confinement, buoyancy from temperature); liquids are FLIP particles, four per cell, on the same grid. "Look" layers then map fields such as density, speed, depth, light and shadow onto palette colours with ordered dither, so no colour outside the palette can appear, and looping effects blend their last frames into the first.

The header's steam is a 128x60 gas grid over 96 frames, fed by eight billows a loop at uneven intervals. One billow and the look, trimmed from the real source:

{
  "format": "pixelforge-fluid",
  "width": 128, "height": 60,
  "effects": { "steam": {
    "frames": 96, "duration": 70, "loop": true, "seed": 5,
    "buoyancy": 0.2, "vorticity": 0.35, "dissipation": 0.04, "drag": 0.09,
    "emitters": [
      { "name": "billow-1", "at": [86, 53], "radius": 3, "rate": 1, "start": 0, "end": 3,
        "density": 3.6, "temperature": 0.9, "velocity": [-0.3, -1.4], "expand": 2.0, "vortex": 0.3 }
    ],
    "look": [
      { "field": "density", "colors": ["u", "v"], "thresholds": [0.16, 0.34], "dither": 0.85 },
      { "field": "shadow",  "colors": ["v", "t"], "thresholds": [0.25, 0.55], "dither": 0 },
      { "field": "light",   "colors": ["x", "F", "G"], "thresholds": [0.22, 0.5, 0.82], "dither": 0 }
    ]
  } }
}

(pixelforge-fluid is the format's name from before the tool was renamed Pixelbolt.) The boiling liquid under the steam is a separate 44x50 FLIP simulation. Every piece shares one palette of 70 colours in 12 ramps; the header loop uses 44 of them.

The agents didn't get there first time. Three things they found:

At one cell per pixel, gas is too damped to roll a vortex ring by itself. A heavy blob, a starting jet and a burst vortex pair all stayed small and slow, across 14 parameter sweeps (the first is below: one setting per row, sampled over time). What worked was a velocity-only emitter riding a quarter turn of an orbit, so the push eases out as the ink sinks, with two spinning emitters on either side to spread the ring. The curls themselves are the simulation's. Unequal spins keep it lopsided: a symmetric ring reads as a face.
Too much swirl makes eyes. At vortex 3 and above, the flask's liquid hollowed into round voids that looked like eyes. Vortex 2.2 gives a clean swirl and slosh up one wall.
A rising column drags thin smoke down beside it. A gentle updraft, "wind": [0, -0.08], removed the downward tails without changing the look.

One command rebuilds every pixel

The recipes live in the profile repo's art/ folder. Small Python generators write the JSON recipes and fluid sources, Pixelbolt runs the simulations and draws every pixel, and a short wrapper script packs the sheets into the SVGs:

bash art/build.sh

It fetches Pixelbolt at the pinned commit (8c5f662), needs Node 20+ and Python 3.11+ with Pillow, and takes about 45 seconds. From a clean copy it rebuilt all 40 SVGs byte for byte. That works because Pixelbolt's simulation is deterministic by design: a fixed timestep, fixed iteration counts, seeded noise, and only arithmetic, square roots and polynomial trigonometry, so a source gives the same recipe on every machine and in the browser. (The one caveat in the notes: the Python generators use Python's math module, so another platform's maths library could in principle move a pixel.)

The site re-simulates it in your browser

The portfolio at skulitom.github.io uses the same art, played on a canvas. Under the workbench there are three buttons. "Add heat" and "Stir the flask" don't switch to a pre-made clip: Pixelbolt's fluid compiler runs in a Web Worker in the page, re-simulates the steam or the liquid with your change, and plays the new loop.

On the live site, on a desktop Ryzen 9 7950X3D, "Add heat" took 932 ms in Chrome, 795 ms in Firefox and 793 ms in WebKit. (The recording above, of the same page just before it went live, shows 957 ms.) To get under a second, the live version simulates a 48-frame loop with 12 pressure iterations; the pre-rendered art uses longer settings. One limit showed up: an emitter's start/end window can't wrap around the loop, so a click near the end of the loop is moved to frame 0.

Try it

Pixelbolt has no npm dependencies. From a clone:

node bin/pixelbolt.js compile examples/steam-vent.fluid.json --out output/steam.json
node bin/pixelbolt.js gif output/steam.json --scale 4 --out output/steam.gif

The repo has ten fluid presets (campfire, torch, steam, magic, explosion, smoke puff, waterfall, drip, potion, splash), and its fluid guide covers emitters, looks and loops. Limits worth knowing: a fluid canvas is at most 128x128, a frame at most 256x256, gravity and obstacles are static, and emitters move only on circles and ellipses (or by chaining time windows along a path). It runs on the CPU, with no GPU and no model calls.

To see how the wrapper is built, read art/tools/wrap.py in the profile repo: it turns a Pixelbolt sheet and atlas into a self-contained animated SVG and its still twin.

Profile: github.com/skulitom, recipes in art/
Live re-simulation: skulitom.github.io
Pixelbolt: github.com/skulitom/Pixelbolt

DEV Community: rivskiy skulitom

How to make a pixel art waterfall animation (free, in your browser or from the command line)

What you get

The browser way

The command-line way

One knob, changed

Numbers from our run

How it works

Limits

Links

How to make a pixel art fire animation for Godot 4 (free, in your browser)

What you get

Step 1: open the campfire recipe

Step 2: change how it burns

Step 3: export a sheet Godot can slice

The same from the command line

Step 4: play it in Godot 4

Limits

If you'd rather not make your own

Links

How to nest laser-cut parts for free in your browser

1. Open the app

2. Import your parts

3. Set quantities, rotations and mirroring

4. Describe the sheet

5. Press Nest

6. Download the sheets

Limits worth knowing

Other ways to run it

How to put crisp, animated pixel art in a GitHub profile README

The problem: GitHub scales your GIF and blurs it

The trick: an SVG that plays a sprite sheet

The steam is a simulation

One command rebuilds every pixel

The site re-simulates it in your browser

Try it