Animate Object Support Lands in Pixelkiln

PixelLab’s Object Creator sat as an open line in the project’s own roadmap notes since the character generator shipped, until two releases this week modeled it end to end.

The agent skill’s roadmap notes have carried the same line since the character generator shipped last week. PixelLab’s Object Creator, demonstrated across three of PixelLab’s own tutorials, was modeled by nothing in pixelkiln. map covers one prop in one generation, no direction or state concept at all. 1dir covers exactly one direction. Neither one can pose an object differently, and neither can animate it. Two releases this week, 0.55.0 and 0.56.0, closed that line for good.

The last post covered a four-release bug chain plus a new tile generator. This is a different shape of gap, not a tile or a character but the family PixelLab built for props and creatures that have no skeleton to pose at all.

A second base, state, and animation family, minus the skeleton

0.55.0 (commit) adds objectPro, wrapping PixelLab’s /create-object-pro-flash endpoint, what PixelLab’s own tutorials call Object Creator. It reuses the exact base, state, and animation shapes character already has (see CHARACTERS.md), including the same asset.state and asset.animation fields and the same free mirror flip. Everything that assumes a rig is simply gone: no mode, template, proportions, isometric, concept, or styleCharacter. A floating rune or a treasure chest doesn’t have a skeleton, so none of those fields apply to it.

One real choice goes the other way. objectDirections can be 1 or 8; character’s pro-flash tier is always 8. A single south-facing prop is a legitimate thing to ask for here, and a one-direction object’s animation has to target south specifically, because that’s what /create-object-pro-flash itself rejects with a 400 if you don’t.

"chest": {
  "generator": "objectPro",
  "objectDirections": 1,
  "prompt": "a wooden treasure chest with brass fittings"
},
"chest.open": {
  "prompt": "lid open, gold spilling out",
  "state": { "of": "chest" }
},
"chest.shimmer": {
  "prompt": "a faint magical shimmer playing across the open lid",
  "animation": { "of": "chest", "frames": 8, "fps": 8 }
}

The gallery learns the same two buttons twice

0.56.0 (commit) adds “+ New state” and “+ New animation” to a character or objectPro base or state’s drawer in gallery --edit, the same manifest-only write “+ New revision” already does. Adding one costs nothing by itself: the new entry only writes to the manifest, and plan reports it as blocked until its parent downloads, same as one added by hand. What actually generates it is the gallery’s own budget-gated generate action, the same background job gen runs for any manifest entry, so once the new state or animation is unblocked, a second click on the same gallery page carries it the rest of the way to a downloaded asset, no CLI and no manifest edit required. Add and generate are still two separate clicks, not one: Object Creator doesn’t get a single button that does both at once yet. The animation form adapts to which family it’s editing: template mode and a subject override only show up for a character, since objectPro has no skeleton concept for either one to describe.

What’s still an assumption

PixelLab doesn’t publish a rate for /create-object-pro-flash directly. objectProCost() assumes it prices identically to character’s own measured pro-flash formula, since the two request bodies are near-identical minus one field, template_id. That was a working assumption, not a confirmed number, roughly the spot isometricTile‘s cost was in for about a day before a live test corrected it, and building a small example project this week gave it the same live test: a chest base and its open-lid state, both at 64px pro-flash, billed 6 and 20 generations against a real account. The base landed exactly on the borrowed formula, but the state came in at half of what it predicts, 20 instead of 40, the same shape of over-read this series keeps finding whenever a cost gets borrowed instead of measured. Only confirmed at this one size so far. Object Creator’s other real gap, batch generation, one prompt turning into several distinct objects in a single call, is still unmodeled. adopt hasn’t been extended for objectPro‘s own remote-id scheme either, though the generic object-matching path 1dir and map already share might already cover it; that part is untested.

I didn’t have a project yet where I’d needed to pose or animate a plain object instead of a full character, so I put together a small example one this week, partly to have real assets to point at in posts like this. It gave me exactly the objectPro use case I was missing: a chest base and its open-lid state, generated for real. The state’s cost came back lower than the borrowed formula predicted, corrected above. objectPro’s own animation cost is still unconfirmed, since that same example project ended up animating the chest through a different, newer mechanism instead of objectPro’s native one (the next post covers why). If you get a real number on objectPro’s own animation cost first, I’d like to know.