Game guide · source of truth
Production

Tripo → Blender → Unity (3D pipeline)

How monsters, props and gear get from concept art to game-ready Unity assets — Tripo generates the raw mesh (by API, hands-free), Blender polishes it headless (clean, retopo, UV, rig, LOD), Unity imports it — what the two Tripo bridge add-ons actually do, the API/MCP options, credit and licence guardrails, and the roadmap tasks.

Decision (owner, round 7, closes OPEN-2): the owner bought a Tripo plan. Tripo makes the raw 3D mesh, Blender polishes it, Unity imports it. The goal is that an agent can run the whole chain without the owner's intervention after the owner provides an API key once.

◆Current mode: by hand from the model request log (ADR-033)

ADR-033: agents do not call the Tripo API (the owner's plan is a web subscription). The API sections below stay for a later decision. What the owner does for each model on the Model requests wiki page:

  1. Open the request. It names the model id (MDL-<KIND>-<name>, e.g. MDL-MON-duneplate_beetle), its use, the reference views in art/3d/requests/<id>/ (front.png, side.png, back.png cut from the accepted turnaround by python3 tools/model-views.py; the monster sheet ART-MON-053 has top.png instead of a back view), plus prompt.txt, and its polygon budget. The list is packages/game-data/data/model-requests.json, generated by scripts/gen-model-requests.mjs in pnpm data:build and ordered by roadmap need (the Dune Beetle first). A request without views waits for its 2D turnaround (ART-3D-* in the art queue) and shows views-missing.
  2. In the Tripo website, use image-to-3D with the views (multi-view if your plan offers it, otherwise front.png) and the request's prompt. Texture on (PBR). Auto-rig off, no animation, no pose change. If the site offers a face limit or low-poly option, use the request's budget; otherwise export as is and the agents retopologise.
  3. Export GLB and save it as art/3d/inbox/<id>.glb (exact id, lower case after the prefix). Keep a second attempt as <id>.v2.glb; the highest version is used. The inbox GLBs are git-ignored (raw exports are 4–20 MB each): their provenance is the sha256 in model-delivered.json, and polished models live under art/source/3d/**.
  4. Nothing else: agents run node tools/model-inbox.mjs at the start of each art or content task. It reads the inbox (never changes it), checks the id, triangles against the budget, size, UVs (TEXCOORD_0), embedded textures and that there is no skeleton or animation, and writes delivered or rejected with what to change into model-delivered.json (merged into the request log). Over the budget a model is delivered with a needs retopo note; only above 25 × the budget (at least 250k triangles, proposed in model-requests.manual.json) is it rejected. Agents then polish and rig delivered models in Blender.

Player bodies, weapons and simple props are made in Blender and normally have no request. Requests cover monsters, elites, bosses, mounts, armour and clothing pieces and set-piece props.

◆What the two bridge add-ons are (checked in SRO/tripo ai/)

Add-onWhat it doesAutomation value
Tripo Blender Bridge 1.0.34 (Blender ≥ 4.1)A sidebar panel that starts a WebSocket server on 127.0.0.1:60600. The Tripo website, open in a browser, "sends" a finished model into Blender.Interactive only: a person generates in the browser and clicks send.
Tripo Unity Bridge 1.0.14 (Unity ≥ 2021.3)Same idea: Tools → Tripo3D Bridge → Start Server receives models from the Tripo website and imports them (FBX).Interactive only.

Both listen on loopback only (good) but neither one calls Tripo or generates anything. They are conveniences for hand work (e.g. you generate a prop in the browser and drop it into Blender). They are not the automation path. Adoption follows the toolchain gate: disposable project first, review the code, the Blender add-on installs from the zip you already have.

◆The hands-free path: Tripo API (+ optional MCP)

  • Tripo has a public REST API and an official Python SDK (tripo3d on PyPI). Supported tasks include text-to-3D, image-to-3D, multiview-to-3D, texturing, retopology/"smart low poly", rigging/animation retargeting, segmentation and format conversion (docs).
  • Keys: the owner creates an API key in the Tripo Console. It is never committed, pasted into chat or put in logs: it lives in the owner's shell environment (TRIPO_API_KEY) or ~/.config/zoen/tripo.env. Agents never create keys or accounts.
  • Billing: the public docs do not say whether a web subscription includes API credits. API access is billed per credit (about US$1 per 100 credits at the time of checking, roughly 40–50 credits for a textured model). Owner action: open the Tripo Console → API/billing and confirm which credits the API draws from. Until confirmed, agents do not call the API.
  • MCP: VAST-AI-Research/tripo-mcp (MIT, alpha) lets an assistant ask Tripo for a model and import it into Blender through the Tripo Blender add-on. It targets Blender only and is early. Plan: use the Python SDK in our own script for batch generation (reproducible, loggable, cost-capped) and treat the MCP server as an optional extra after a disposable smoke test.

◆The pipeline (per asset)

  1. Input: the accepted concept art or turnaround sheet from the art queue (e.g. ART-MON-*, ART-CHR-050/051, mount and prop sheets). Images only; no text prompts for final assets, so the look follows the approved art.
  2. Generate (agent, headless): tools/tripo/generate.py (M3) reads a request list, calls the API (image-to-model, PBR texture, quad/low-poly option with a face limit from the budgets), downloads the GLB to art/source/3d/tripo/<id>.glb and appends logs/tripo-gen.jsonl (task id, credits used, seed, ok). A credit guard stops the run when the session cap (set by the owner, default 200 credits) is reached and counts toward the shared PHP 5,000 expense cap.
  3. Polish (Blender, headless): blender -b -P tools/blender/polish_tripo.py -- <id>: import, delete loose parts, fix normals and scale/origin, retopologise or decimate to the tri budget (monster ≤ 22k, prop 0.3–5k), re-unwrap UVs and bake to the 2K texture, apply the Rigify/humanoid or creature rig and the weapon sockets, generate LOD0–3 and the baked-animation (VAT) crowd version, export GLB/FBX. Tripo's own rigging is only a first pass.
  4. Validate: the asset validator (tris, bones ≤ 80, influences ≤ 4, texture size, LODs) plus the glTF validator.
  5. Import: Unity batchmode import preset (URP lit/ShaderGraph materials, Addressables group), PlayMode smoke scene, turntable render for the owner's review.
  6. Record: every generated file gets a line in Licences (tool, date, plan, task id).

◆Guardrails

  • Terms: check Tripo's current terms for your plan (commercial use, ownership of outputs, whether free-tier outputs are public). Verify before shipping anything; this guide is not legal advice. Record the plan name and date in LICENSES.md.
  • Spend: credits are an expense under the PHP 5,000 cap; the generator refuses to run without a cap argument.
  • No remote control: the generator calls Tripo's API only; no browser automation of the Tripo website, no sharing of the key with other tools.
  • Quality bar: AI meshes are a starting point. Nothing enters the game without the Blender polish step and an owner-reviewed turntable.

◆Roadmap

M0-08 (toolchain, the API bake-off) is replaced by MODEL-01 (ADR-033): the model request log, its views and the 2D requests. MODEL-01B added the inbox checker (tools/model-inbox.mjs); MODEL-01C adds the wiki Model requests page. M3 (character pipeline): build tools/tripo/generate.py and polish_tripo.py, then batch the four vertical-slice monsters.

Source: zoen/docs/production/TRIPO_PIPELINE.md · 1,221 words · edit the Markdown, not this page.