> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livlive.ai/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> This is livlive's documentation. An agent reaches livlive from outside through the `livlive` CLI or the livlive MCP server (see /developers/install, /developers/cli and /developers/mcp). The person links it to livlive once, in the browser: `livlive login`, the local MCP's `livlive_login` tool, or the remote MCP at https://backstage.livlive.ai/api/mcp signing in by OAuth; a personal token made in livlive's settings is for CI. Pages marked 準備中 describe parts not decided yet: do not guess their behaviour.

# stage-art

> How an agent makes a stage's reference pictures (gpt-image) and models (Tripo) with the person's own keys, and fits each model to the stage in Blender — `livlive picture make`, `livlive model make`, the room kit's fit_generated and render_views. Read before using either command; when to offer them and what to ask the person first is `stage-lead`.

> [!NOTE]
>
> このページは、エージェントが読む skill「stage-art」の本文です。

> [!WARNING]
>
> いまは招待制βの準備中です。CLI と MCP は npm から入れられますが、使うには livlive のアカウント(招待制)が要ります。スキル(`npx skills add`)は、livlive-kit の公開とともに使えるようになります。

Two services can make parts of a stage with the person's own keys: gpt-image (OpenAI) draws reference pictures, and Tripo makes a model
from a picture. The room kit then fits each model to the stage in Blender. This skill is how. When to offer it and what to ask the person
first is `stage-lead`; how a stage is built, checked and handed in is `stage-package`; every number is the engine reference's
(`livlive reference`). None of them is repeated here.

What the two commands make lands in the stage folder's `art/`, which stays on the PC: a push sends only the package's files.

## The keys stay the person's

**The purpose:** a key goes nowhere but to its own service, and nothing is paid that the person has not agreed to.

`livlive picture make` and `livlive model make` read `OPENAI_API_KEY` and `TRIPO_API_KEY` from the stage folder's `.env` (then from the
environment) and send each only to its own service; livlive never sees them. The person writes them there once `livlive stage new` has
made the folder (it takes only a new or empty one), which leaves an `.env.example` naming both and a `.gitignore` that keeps `.env` out of
git. Never open, print or copy `.env`, never ask for a key in the conversation, and never put one on a command line.

Each picture and each model is billed to the person's own account with that service, at the service's prices: say so, never a price of
yours. Before the first paid call, say what you will make (which pictures, the whole stage's picture among them, and which models) and make
only what they said yes to; ask again before more.

A missing key stops the command before anything is asked of a service, with the line to add. Tell the person which key it is, what it is
for and where it goes, or build that part with Blender alone if they would rather not, and say what that changes.

**It is met when** no key has appeared in anything you wrote or ran, and before each paid step the person knew what it would make and whose
account would pay for it.

## Reference pictures

**The purpose:** the person and you agree on how the whole stage, and then each part, should look before anything is made from it.

```
livlive picture make <folder> --prompt "<words>" [--from <picture>]… [--name <name>] [--size <size>]
```

It draws one picture into `art/pictures/<name>.png` in seconds (`livlive --help` names the sizes). Write the words from what the person said
and the atmosphere they chose for the look. `--from` draws from pictures, the person's own or one you made: to follow a picture they
brought, or to keep one look across several pictures. Each `--from` is a path as your shell reads it, like `<folder>` itself, not from inside
the folder.

The first picture is the whole stage, in the atmosphere agreed: the one scene among the pictures, for the person to agree the look on, and
never a picture a model is made from. Draw it again, on the person's yes, until they agree the look, and first again when the look changes.
The single things are then drawn from it with `--from`, so that they keep its look. A picture a model will be made from shows that one thing
whole and alone, on a plain background, seen from the front or three quarters: a model is made of one thing, never of a scene, and so never
from the whole stage's picture.

Show each picture as itself, a file the person opens, and ask what you are unsure of before going on.

**It is met when** the person agreed the whole stage's picture before any single thing's was drawn, and has seen every picture a model will
be made from and said it is what they meant.

## Models

**The purpose:** a model of each part that matters, made from that part's agreed picture and paid for once.

```
livlive model make <folder> --from <folder>/art/pictures/<name>.png [--name <name>] [--faces <n>]
```

It uploads the picture to Tripo, starts a task, waits for it and downloads the model into `art/models/<name>.glb` the moment it is done
(Tripo's address for it lasts only minutes). It takes minutes, so run it in the background (a foreground shell's time limit is often
shorter than the wait it states), or else with a time limit longer than that wait. Run each paid command on its own, one command a model or a
picture — never in a loop, a fan-out or a script — so each is one the person agreed to.

`art/made.json` keeps every picture and model the folder has made, and each Tripo task from the moment it starts (the command says the task
started, with its id). A command cut off, a wait that ran out or a download that failed leaves a task whose model is not here: fetch it with
`livlive model make <folder> --task <id>` (the line the command printed when it could, or the id from `art/made.json`): no new task, nothing
more billed. Never make it again from the picture to get it back.

* One `model make` per picture at a time: another for the same picture only once the first has said its task started.
* A second model of the same picture is a new paid task, so ask the person first. While a task's model is not fetched, the command refuses
  one and prints the `--task` line instead; `--again` overrides that, and it is the person's agreement to pay again. Never copy or rename a
  picture to make its model again.
* `--faces` asks Tripo for fewer faces from the start; the fit below brings any model within its budget either way.

**It is met when** each model the person agreed to was paid for once, and every task in `art/made.json` has its model in `art/models/`, or
the person knows why not.

## Fit each model to the stage

**The purpose:** each model within the stage's limits, drawn in the agreed look and facing the way it serves, before it is placed.

The room kit (`livlive room-kit` prints its folder; `blender_kit.py`) fits a generated model in one call:

```
fit_generated(col, path, name, center, size, faces, turn=…)
```

It brings the model to at most `faces` triangles, fits it inside `size` keeping its shape with the middle of its bottom at `center` (the
room's frame), caps its pictures and finishes it flat; its docstring says what each argument means. It takes seconds and needs a recent
Blender (it says which when the one it runs in is older). A budget it cannot reach is an error, never a model over it.

* **The budget is yours, read from the reference.** The whole space, the room with everything placed in it, stays within
  `limits.SPACE_LIMITS` (triangles, images, bytes). Read the numbers fresh and give each model a share that leaves room for the rest of the
  build: more where the cameras come close, less for what stands far off. The limit is the ceiling of the whole space, never the target of
  one model. `tex_cap`, the size the fit caps a model's pictures at, is the kit's choice and no engine limit: raise it for a part seen
  close, within the space's images and bytes.
* **The front first.** A generated model often faces another way than the room's front (+z); Tripo's has come facing +x. Draw its views
  (below) and look at the front one before anything else. Turn it by quarter turns (`turn`, radians about +y) and look again, or, for a
  seat, let `face_away` turn it until its back stands away from where its sitter faces.
* **A height that must be exact.** For a seat, `fit_seat` brings its seat's top to the height its seat declares. For a top at a set
  height, `fit_generated(…, height=True)` fits it by its footprint and gives it the height of `size`, finished as any other.
* **The look is the stage's.** The anime look is the stage's own `look.ink`, which you declare in its world.json for the atmosphere agreed (a
  new stage declares none): outlines and light in steps that the engine draws over the whole room, within the ranges the reference gives
  (`limits.INK_RANGE`, and `look` in world.json's schema). Models are finished flat (`flat`, on by default) so that the ink draws them as
  it draws the room. Never bake outlines or light bands into a model: they would be drawn twice.
* **The light is for the characters.** How the room is lit is `stage-lead`'s (Show it early): light it by that.
* **One model, many places.** A thing brought as its own file is fitted at `center` (0, 0, 0), so that its origin is the middle of its
  bottom, as thing.json's schema asks. Copies of one model are placements of that one thing (`stage-package`), never imports of the same
  file again: placements share the thing's pictures, while each import brings its own, and the space counts every one.

Then draw it, to show it:

```
render_views([model], out_dir, name)
```

It writes `<name>-front.png` and `<name>-three-quarter.png`, the model alone on a transparent background, in seconds. Show both to the person
with what you are unsure of. They show the model without the stage's lines; the dev page shows those once it is placed and `look.ink` is
declared, and you say so.

**It is met when** each placed model is within its share of the limits, faces the way it serves and carries no lines of its own, and the
person saw it and agreed before it took its stand-in's place.

## When a service refuses

**The purpose:** the person knows what happened, what it cost and what comes next, in their own words.

The commands end with exit 2 when nothing was asked of a service (a missing key, a command that cannot be used as given), and with exit 1
when a service refused, could not be reached, or what it made could not be kept. Their words say which service and why, and never a key.

Tell the person which service refused and why (a balance run out, too many requests, a picture refused, a task that ended without a
model), and what was billed, as far as the command says it and no further. A balance or a key is theirs to settle with the service; after
too many requests or no answer, try again later; for a refused picture, change the words or the picture with them; a task that ended
without a model is made again only on their yes. Never try again blind when the command says a task may have started: then no new task
until the person has looked at their Tripo tasks and found none, and a task they find there is fetched with
`livlive model make <folder> --task <id> --name <name>`, nothing more billed. A model made but not fetched is fetched with its `--task`
line. Never work around a refusal by sending a key yourself or by reading `.env`.

**It is met when** after each refusal the person could say which service refused, why, and what happens next.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.