Isometric Tile Generation Lands in Pixelkiln

Terrain’s tiles turned out to be square, not isometric, and fixing that led to a new generator built for isometric content.

Four bug-fix releases landed in one evening this week, all on the terrain generator, all circling the same shape mismatch. I watched them stack up in the CHANGELOG, 0.53.1 through 0.53.4, without writing anything, because none of them made sense as their own post. Then the next morning, 0.54.0 shipped a new generator that explains what the whole chain was pointing at.

The last post covered terrain landing as a new generator. This is what happened to it a day later, and the live generator table on pixelkiln’s own site already reflects the end state.

Terrain’s tiles were never isometric

Terrain wraps PixelLab’s /create-tileset endpoint, and when it shipped, the Godot exporter had to decide which shape’s peering-bit names to write for it. It fell back to "isometric", because that’s tiles‘ own real API default and terrain had never set a shape of its own. Two releases, 0.53.1 and 0.53.3, patched around that fallback: normalizing terrain’s Wang corners for tileset export, then switching to Godot’s own isometric corner names for terrain’s peering bits. Both were real fixes for a real symptom. Neither was the actual bug.

0.53.4 (PR #196) found it: /create-tileset places tiles on a rectangular vertex grid, standard square Wang-tiling math, with no shape parameter at all. A downstream project’s actual generated tiles confirmed it independently. They came back fully opaque, with none of the diamond alpha mask an isometric tile would need. Terrain now sets its shape explicitly instead of falling through to a default that was never really its own.

A dedicated generator for isometric tiles

0.54.0 (PR #198) adds isometricTile, wrapping a third, separate PixelLab endpoint: /create-isometric-tile. It’s distinct from the two isometric-adjacent options already in pixelkiln: tiles‘ own tileType: "isometric" (a full connectable Wang and building set) and terrain’s now-confirmed-square /create-tileset. This one generates a single standalone tile, no candidates: the shape for one elevation piece, a raised mesa or a cliff block, rather than a connected ground set.

"cliff": {
  "generator": "isometricTile",
  "isometricTileShape": "block",
  "isometricTileSize": 32,
  "prompt": "grey stone cliff face"
}

"cliff": {
  "generator": "isometricTile",
  "isometricTileShape": "block",
  "isometricTileSize": 32,
  "prompt": "grey stone cliff face"
}

isometricTileShape controls vertical thickness (“thin tile,” “thick tile,” or “block,” the API’s own default), a more direct elevation control than anything terrain or tiles expose. isometricTileSize is the API’s own tile grid, 16 or 32, kept separate from the general size field the same way terrain already splits its own tile size from the overall canvas.

The cost model was wrong until it was tested

PixelLab’s own OpenAPI documentation gives { type: "usd", usd: 0.02 } as the example response for this endpoint, so the generator shipped billing in USD at first. One real, authorized generation against a live account showed the actual response was { type: "generations", generations: 1 }; the documented shape never appeared. The wrong assumption also broke a real safety check: gen‘s preflight budget comparison refuses to proceed when a plan’s cost unit doesn’t match the account balance’s unit, so a manifest using only isometricTile failed before it ever reached the API:

error: Provider pixellab estimate unit usd does not match balance unit generations.

Fixed the same day: isometricTile now bills 1 generation like every other PixelLab generator here, folded into the same cost branch as tiles and terrain instead of carrying its own USD-shaped exception. Only the one tested combination, 32px at “block,” is actually measured, documented as such, since the endpoint doesn’t publish a size-tiering formula the way 1dir or tiles does.

The live generator table on pixelkiln.griffen.codes already reflects both halves of this: isometricTile at a flat 1 generation, and terrain still marked unmeasured, honestly, right next to it. The tiles and engine exports guide and the generator selection reference both cover where each of the three isometric-adjacent options actually fits. The full version history, including the four-release patch chain, is on GitHub.

What stuck with me about this one isn’t the generator itself, it’s that the underlying bug only surfaced because someone was building something real on top of terrain and the tiles came back wrong. I don’t have a project yet where I’ve needed a standalone isometric elevation tile instead of a full terrain or tile set. If you do, I’d like to hear what you’re building.