scenario-sparc3d

Scenario Sparc3D Image-to-3D

Overview

Sparc3D, Hitem3D's image-to-3D family on Scenario, turns one to four photos into a watertight mesh with no text prompt: the source images are the entire art direction. A base line handles props and objects, a Portrait line human heads and busts, each in 2.1 and 2.0 generations. Discover them with search and treat model_schema_get as the contract: members disagree on which knobs exist and how values are spelled.

Connection and the core loop: the scenario skill in this repo; model-agnostic 3D work: the scenario-3d 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

Names from the live schema; differences as of authoring time:

Parameter	Role	Differences across members
images	1 to 4 views: front, then back, left, right	same
requestType	numeric: mesh only or mesh plus texture	same
resolution	detail and topology tier	1536fast/1536pro on 2.1, 1536profast/1536pro on 2.1 Portrait, 1536/1536pro on 2.0; absent on 2.0 Portrait
face	target face count, 100K to 2M, default 2M	absent on 2.0
pbr	PBR material, default true	inert without texture output

At authoring time requestType 1 meant bare mesh, 3 (the default) textured. Resolution defaults differ: 2.1 opens on its fast tier, 2.1 Portrait on pro.

Views are positional

In images, slot one is the front view; extras are back, left, and right, in that order, all of one subject. A front view alone works; extra views buy stabler geometry on unseen sides. One centered subject on a plain background converts best.

Long jobs, moving prices

resolution buys generation detail; face sets delivered mesh weight (500K for lightweight assets, 2M for high fidelity). requestType, resolution, and pbr all move cost, spanning four times on one member at authoring time, so dry_run the exact parameter set before a batch. Runtimes are long (medians near 17 to 21 minutes at authoring time, a slow quartile reaching past 30), so jobs_wait timeouts are normal: re-call with pending_job_ids, never a second model_run, never job_get polling.

Worked example: a game prop from one concept image

1. search with target="models", query="sparc3d", public=true. Prefer the newest non-deprecated base hit, e.g. model_hitem-sparc-3d-2-1 (a live hit at authoring time: re-discover each session).
2. model_schema_get with that id: knob presence and resolution spelling come only from here.
3. upload_asset the concept image, or generate one first with a text-to-image model.
4. model_run with that model_id, dry_run=true, and parameters={"images": ["asset_front"], "requestType": 3, "resolution": "1536fast", "face": 500000, "pbr": true} for the cost estimate; re-estimate after touching any cost knob.
5. Repeat model_run with wait=false, then jobs_wait with the returned job id, re-called with pending_job_ids on timeout; expect several rounds.
6. asset_display to preview the mesh, then asset_download for engine import. No schema field selects the container (the catalog advertises GLB, OBJ, STL, and FBX): confirm the delivered format from the returned asset before promising an engine target.

Common mistakes

• Passing a prompt: no member takes text; direction lives in the source images.
• A bare string for images: one view still goes as ["asset_x"].
• A side view in slot one: it is read as the front.
• Carrying knobs across members: the non-pro tier is spelled three ways, face is missing on 2.0, resolution on 2.0 Portrait.
• Expecting pbr to texture a mesh-only run: it acts only when requestType asks for texture.
• Sending a creature or prop to Portrait: a head and face specialist, not a higher-quality tier.