Higgsfield 3D

Higgsfield 3D — Meshes, Rigs, and 3D Jutsu Scenes

QUICK FACTS

Routing aids — read the linked sections for the full rules. Nothing in this sub-skill is field-tested.

• 17 3D models in the 2026-09-26 snapshot, six jobs: single image→3D, multi-view→3D, text→3D, rig, remesh / retexture, 3D Body →
• THE law: the mesh reproduces only what is in the source image — to add or change props, clothing or held objects, edit the IMAGE first, then convert the edited result →
• Multi-view beats single-view for geometry: 2–4 views of the same subject → multi_image_to_3d / tripo_h3_1_multiview_to_3d →
• The prompt field: the MCP schema says only sam_3_3d accepts one; the CLI marks it REQUIRED on the three text→3D models — send it there, confirm with get_cost →
• Server-enforced rules: animation needs rigging; texture options need texturing ON; Hunyuan std caps the prompt at 200 characters and has no PBR →
• Rig + animate: humanoids rig best; animation_action_id comes from a 678-action library (ids 0–696, not contiguous — look up, never guess) →
• get_cost: true preflights for free; never auto-resubmit after a transport timeout →
• 3D Jutsu = private Blender 5.2 scene projects: inspect (query) → guarded edit (run) → show_scene LAST →
• A generated GLB cannot enter a 3D Jutsu scene — imports are curated-catalog assets only in this version →
• Film use 1: a mesh turnaround as a multi-angle reference — UNMEASURED →
• Film use 2: a 3D blockout rendered front-on from the camera's side becomes the SOURCE FRAME for the staging template — UNMEASURED →

---

What this sub-skill is for

Higgsfield now generates 3D assets (GLB meshes, optionally textured, PBR-mapped, rigged and animated) and hosts 3D Jutsu, a private Blender scene editor driven through Python. This sub-skill documents what each surface is for, what its parameters are, the rules the server enforces, and the two uses that matter to this repo's film work: a consistent multi-angle reference, and a physical staging reference.

It is a routing and discipline layer, the same as the rest of this library: it picks the model and writes the inputs; the execution surface (MCP connector, CLI, web UI) runs the job — see ../higgsfield-stack/SKILL.md.

Everything here comes from the platform's own schemas (provenance at the end). No 3D job and no 3D Jutsu edit has been run from this repo. There are no quality rankings, speed claims or prices in this file — none were measured, so none are stated.

Not this sub-skill: Cinema Studio 2.5's 3D Mode (Gaussian splatting inside a generated image) — that is ../higgsfield-cinema/SKILL.md § 3D Mode. And not a Blender tutorial: 3D Jutsu's Python surface is documented only as far as its tool contracts go.

---

The catalog — 17 models, six jobs

[OFFICIAL — platform, 2026-09-26] — ../../specs/models_explore_snapshot_3d_2026-09-26.json. ../../scripts/sync_specs.py has no 3D type yet, so there is no generated 3D spec table: this table is read straight from the snapshot. Names and providers are as the snapshot states them.

Three duplicate pairs. image_to_3d / meshy_image_to_3d, multi_image_to_3d / meshy_multi_image_to_3d and 3d_rigging / meshy_rigging carry the same name, provider and parameter list in the snapshot. The MCP generate_3d schema names the unprefixed ids as its defaults, and CLI 1.1.23 model get knows only the unprefixed ids (the meshy_-prefixed three return No model with job_type). Use the unprefixed ids. Whether the pairs share a backend is not stated anywhere — do not claim it.

Picking a model

When unsure, the connector's own instruction is to call models_explore(action:'recommend') before any generate_* tool [OFFICIAL — Higgsfield MCP server instructions, 2026-09-26].

---

The source-image law

[OFFICIAL — Higgsfield MCP tool schema, generate_3d, 2026-09-26] verbatim:

"The mesh reproduces only what is in the source image — to add or change props, clothing, or held objects, edit the image first with generate_image, then convert the edited result."

What that means in practice (the first three lines restate the schema; the rest is labeled):

• Fix it in 2D, then lift it. A missing prop, the wrong jacket, an empty hand — all of it is an image edit before it is a 3D job. There is no mesh-side "add a sword".
• Retexturing is the one post-hoc surface change the catalog offers (meshy_v5_retexture); geometry changes go back to the image.
• The image-side tools for that edit are the image sub-skills this library already has — ../higgsfield-gpt-image-2/SKILL.md (reference sheets, edits) and ../../templates/ad-asset-prep.md (prop three-views, product sheets).
• [INFERENCE — untested] A single-view source shows one side of the subject; the model has to supply the rest. That is the problem multi-view input exists to reduce (next section) — plan the source images for the angles you will need, not just the pretty one.

---

Multi-view beats single-view

[OFFICIAL — platform, 2026-09-26] multi_image_to_3d: "1-4 images of the same subject from different angles … More images improve geometric accuracy." The MCP schema says the same: use it "when 2-4 views of the same subject are available (better geometric accuracy)".

• Same subject is the whole condition. Four images of four slightly different characters are not four views. [INFERENCE — untested] Views cut from one generated sheet are more likely to agree than four separate generations — the same reasoning the cinema sub-skill applies to location sheets (../higgsfield-cinema/SKILL.md § Location Reference Sheets: alt angles "from a single seed" keep light and material consistent).
• Role names differ by model: Meshy multi-image takes role image (max 4); Tripo multiview and Hunyuan take image_references. The server "may auto-coerce when unambiguous" — still pass the declared role.
• Tripo wants its views ordered, and the order is not published in the schema. Do not guess a front / left / back / right convention into a delivery.

---

The prompt field — two surfaces disagree

• [OFFICIAL — Higgsfield MCP tool schema, generate_3d, 2026-09-26]: "Optional text guidance. Only sam_3_3d accepts a prompt (to disambiguate which object to lift). Other 3D models ignore it."
• [OFFICIAL — platform CLI 1.1.23, higgsfield model get <id> --json, 2026-09-26]: prompt is required on meshy_v6_text_to_3d, hunyuan3d_v3_1_text_to_3d and tripo_3d; optional (default empty) on sam_3_3d; absent from every image-input, rig, remesh, retexture and body model.

The MCP sentence is accurate for the image-input models and cannot be literally true for text→3D (a text→3D job with its prompt ignored has no input). Do not settle it by guessing: for text→3D, send the prompt, and run get_cost: true first — the server returns adjustments showing what it did with the request before anything is spent. For texture direction on the image-input models, the fields are texture_prompt / texture_image_url (Meshy) — not prompt.

---

Parameter rules the server enforces

[OFFICIAL — platform CLI 1.1.23, model get rules, 2026-09-26] — each is a server-side constraint; breaking one rejects the job.

Two defaults that bite: image_to_3d / multi_image_to_3d return an untextured mesh unless should_texture: true is set; meshy_v7_image_to_3d textures by default. Meshy target_polycount defaults to 30,000 (range 100–300,000); Meshy should_remesh defaults on, and when off, "returns the raw triangular mesh and topology/target_polycount are ignored".

---

Rigging and animation

[OFFICIAL — platform, 2026-09-26] + [OFFICIAL — Higgsfield MCP tool schema, 2026-09-26]

• Two routes to a rig: enable_rigging: true on a generating model (Meshy image, multi-image, 6 text, 7 image), or 3d_rigging on a mesh you already have. 3d_rigging takes model_url — a public HTTPS GLB without embedded credentials, or (per the MCP schema) a prior 3D job_id.
• Humanoids rig best. The schema's own caveat: "Works best on humanoid/character subjects; non-bipeds (animals, objects) may rig poorly."
• Pose: pose_mode a-pose / t-pose — "Recommended with enable_rigging for cleaner skeletons." rigging_height_meters (default 1.7) scales the skeleton.
• Animation: enable_animation: true + animation_action_id. The library holds 678 actions with ids in 0–696 — the ids are not contiguous, so never compute or guess one. The schema's named picks: idle 0, walk 30 (Casual_Walk), run 16 (RunFast), jump 466 (Regular_Jump), wave 28 (Big_Wave_Hello), dance 64 (All_Night_Dance).
• Look it up: MCP animation_actions (read-only, no job; groups WalkAndRun, BodyMovements, DailyActions, Dancing, Fighting; each result carries a preview GIF — when several fit, show the previews and let the user pick) or CLI higgsfield preset list animation-action --query walk.
• Rigging and animation each add cost (schema wording) — preflight.

---

Cost and submission discipline

• Preflight is free: MCP generate_3d with get_cost: true "preflights credits without submitting"; CLI higgsfield generate cost <model_id> [--param value]…. Apply the adjustments the server returns. This file lists no prices — they were not measured.
• Cost drivers the schema names: texturing ("Costs more credits"), rigging and animation ("Adds cost"). count 1–4 multiplies the job.
• Timeouts: "On a transport timeout the submission outcome may be unknown: do not automatically resubmit. Reuse returned job IDs and retry only after the original outcome is known."
• Inputs: medias[].value is a media_id or a prior job_id, never a URL (web media goes through media_import_url; local files through media_upload_widget). The exception is the model_url field on rig / remesh / retexture, which is a URL — for remesh and retexture the snapshot says to upload the GLB through the media API with type=file and pass the returned URL.
• Surface choice and the general two-step preflight: ../higgsfield-stack/SKILL.md § Preflight discipline.

---