Scenario 3D Asset Workflows
Overview
Scenario runs text-to-3D, image-to-3D, and 3D-to-3D models behind the same MCP generation loop used for images. The most reliable pipeline generates a concept image first, then feeds it to an image-to-3D model; direct text-to-3D exists (
) but image-to-3D has the larger catalog and more art direction control. Per-family contracts:
,
,
. Walkable scenes and Gaussian splats:
. Retexturing a finished mesh or scene with PBR materials:
scenario-patina-retexture
. Connection and the core generation loop: see the
skill. If a sibling skill named here is missing from your available skills, ask the user to install it (
npx skills add scenario-labs/skills --skill <name>
); unattended, proceed from tool schemas and flag the gap.
Quick reference
| Step | Tool | Notes |
|---|
| Find 3D models | with the capability and the user's own words ( for a name) | Capabilities: , , |
| Inspect inputs | | Always call before |
| Generate | | Pass reference images as asset IDs |
| Wait | | Any returned without assets ( after a timed-out wait, or after ) goes in ; never poll in a loop |
| Preview | | Interactive GLB/FBX/VOX/OBJ viewer on MCP App hosts |
| Download | | Returns a URL; save with |
Worked example: concept image to game-ready mesh
A realistic sequence for "make a 3D treasure chest prop":
- Generate the concept: pick a text-to-image model via with the user's own words as , then and with a prompt describing a single centered subject on a plain background. If the user has a reference, it (plus when multipart) and pass that asset ID instead.
- with and the user's own words as . Live members include the Hunyuan 3D, Meshy, Tripo, and Trellis families, and Scenario's own GPT-6 Astra 3D, which reconstructs one object from 1 to 8 photos or renders into an editable mesh with named parts and per-part PBR materials. Astra is built for props and hard-surface subjects, not characters, and its schema carries the cost levers a game team asks about first: and move the price (both ), and caps the delivered triangle count at export (10k to 50k for a game-ready asset; the default keeps fine detail and is not that). A refinement pass on a previous output was not exposed at authoring time: an edit is a new run with the corrected references.
- on the chosen model. 3D schemas vary widely: single image vs multi-view arrays, polycount targets, PBR toggles, topology choices.
- with
parameters={"image": "asset_xxx", ...}
and ( first to price a batch), then with (re-call it with the returned as if it times out). A downstream step (rig, retexture) has no payload to until its input mesh exists: quote it from as an estimate, then re-price it with on the real asset before launching.
- with the output to preview, then and
curl -L -o chest.glb "<url>"
for engine import.
Multi-view models accept several images of one subject from different angles; the count and the ordering vary per model, so take both from
(the first image is usually the front view).
Texture and lighting controls
Several image-to-3D families split texture from geometry, and each dial is one
away, so read them before promising a look. Authoring-time examples from the Tripo members:
- returns a bare mesh with no texture and is a field, the cheap path when the user will texture in a DCC. (, , , ) also moves the price, and a texture version picker, left empty, keeps the provider's default.
- strips lighting and shadows baked into the reference image so the mesh lights correctly in the user's engine. It defaulted to on; turn it off only when the painted shading is the art style, as on a hand-painted prop. The export stays a lit material either way, so for no engine relighting at all the user sets an unlit shader on import.
- The flag's description said PBR on, its default, ignores the texture parameters. A texture setting the user asked for is honored only with there, so read that description on the chosen member and say which one won.
- Geometry and texture take separate seeds (, ): hold and the image fixed and vary alone for texture variants on one shape.
- scales the output to real-world meters and defaulted to off: set it to for a real-scale engine import, or the mesh keeps its native size. The asset's still read the unit-normalized mesh (longest side 1.0) because the meters sit in the GLB's node scale, so is not proof it failed.
Inspecting results
renders 3D assets in an interactive viewer (GLB, FBX, VOX, OBJ) on hosts that support MCP Apps; other hosts get the
dashboard link. The viewer's capture button calls
, an app-only tool: it uploads the current camera view as a new image asset and posts the
back into the conversation. Use that capture as a reference image for follow-up generations or similarity
. Never call
yourself; it requires PNG canvas data only the viewer has.
Refining meshes
3D-to-3D utilities (
capability) cover retexturing, remeshing, UV unwrapping, and part segmentation. Find them with
:
plus the operation in the user's own words. Most take the source
in a
file field, usually named
(also
,
); 400
or
Provide a reference image or a 3D model
means the mesh went in under another name (an image field, or a URL), never that the tool wants something else.
Splitting a finished mesh into parts is a contested lane, so it stays a
pick: at authoring time several vendors offered mesh segmentation with a granularity control, one combined the split with a PBR retexture, and image-to-parts members build the parts from the picture instead. A convincing mesh is not a game-ready one: part separation, joint placement, materials, and animation are each their own pass, and polygon caps differ by topology on the members that offer both (a quad cap sat well under the triangle cap on one), so read the slider's
off the schema instead of promising a count. A named provider feature is a valid
target, but an empty result or one member's body-plan enum does not prove a capability is absent platform-wide. For an unmet need such as a hinged prop, use
with that need and inspect the returned schemas; if none exposes it, report it as unverified in the inspected models, without inventing a call from the provider's own site.
Rigging and animation
Rigging is a separate
step run on a finished mesh, not a flag on the generator. Find the models with
:
plus the rigging need in the user's own words.
Body plan picks the model. Humanoid models take the mesh and little else (a front-facing hint, or an approximate height, depending on the model) and infer a biped skeleton. Non-biped work goes to a model exposing
, whose values cover
,
,
,
,
, and
.
Three schema details decide whether the output is usable:
- Formats. Rigging models accept GLB, and often OBJ, FBX, or STL. None exposes an output-format field, so the rig comes back as GLB or FBX and most descriptions do not say which: expect a DCC pass when the engine needs the other.
- Size ceiling. A on the file input is the exception rather than the rule (one humanoid rigging model caps at 30 MB). Check the schema before assuming a large mesh needs decimating.
- Animation versus rig. Where a rigger exposes it retargets a preset clip, and its are rig-type prefixed (), so read them rather than guess. By default only the retarget file comes back: set to keep the plain rigged mesh too (the two come back as separate assets with identical , so tells them apart: the retarget has true and an , the plain rig false and null, and their order is not guaranteed).
When only motion is wanted, motion-transfer video models animate a still character image with no skeleton at all: see
. Video-to-motion models that auto-rig an uploaded mesh are the one place an
enum picks the engine target.
Common mistakes
- Running without : 3D model parameters differ far more between models than image models do.
- Passing a local file path as an image input: first, then pass the returned asset ID.
- Hardcoding model IDs: catalogs rotate (a
deprecated:<replacement_id>
tag names the successor). Re-discover each session, for the need or for a name.
- Pasting raw asset URLs into chat instead of calling .
- Forgetting with curl: download URLs may redirect before serving the file.
- Promising a named skeleton, an influence count, or bones for wings and extra limbs: pick the closest body plan, then finish the rest in a DCC.
- Sending a biped to a model: the enum has no biped value, because humanoids have their own rigging models.