How Higgsfield Does 3D: Images In, Rigged Models Out

Most of what Higgsfield makes is flat — images and video. Its 3D tools do something different: they turn a picture (or a text description) into an actual 3D model you can download, open in Blender or a game engine, and spin around. On top of that, Higgsfield can rig the model with a skeleton and play a pre-made animation on it, so a still character becomes one that walks, waves, or dances.

Under the hood the 3D features are built on a few third-party engines — Meshy for image-to-3D and rigging, Meta’s SAM 3 for single objects, and a Tripo model for text-to-3D — but you drive them all through the same loop as the rest of Higgsfield: describe or upload, generate a job, get the result, spend credits. This article explains what that produces and how the pieces connect.

The output: a GLB mesh

Every 3D generation returns a GLB file. GLB is the standard, portable 3D format: one file holding the mesh (the shape), its textures, and — if you asked for it — a skeleton and animation. You can open a GLB in Blender, Unity, Unreal, Godot, three.js, or any online GLB viewer, so whatever Higgsfield makes drops straight into a normal 3D pipeline.

By default the mesh comes textured (colored to match the source). You can also ask for PBR material maps (metallic, roughness, normal), which is what makes a model react correctly to lighting in a game engine rather than looking flat.

Four ways to get a model

Higgsfield’s 3D catalog is a small set of models, each suited to a different starting point. You do not pick by hand in a chat — the assistant (or the app) selects the right one — but knowing the four cases tells you what is possible:

The image-based models are the ones most people use: Higgsfield is strongest at turning a picture you already have — often one it generated moments earlier — into a matching 3D model.

The pipeline: mesh → texture → rig → animate

A 3D generation is a short chain of optional stages, and the options depend on each other, which is worth understanding so you know why a setting is greyed out:

1. Mesh (always). The raw geometry is built from your image or prompt.
2. Texture (optional). Surface color is baked on. PBR maps are an add-on to texturing, so PBR requires texturing to be on.
3. Rig (optional). An auto-generated humanoid skeleton is fitted to the mesh. This works well on humanoid characters and poorly on animals or objects, which have no matching bone structure.
4. Animate (optional). A pre-made animation clip is played on the rig, so animation requires rigging. You choose the clip by id (more on the library below).

Each added stage costs more credits and takes longer, so a bare mesh is the cheapest and fastest; a fully textured, PBR, rigged, animated character is the most expensive.

The golden rule: the mesh only contains what the image shows

This trips people up, so it is the one rule to remember. A 3D model reproduces only what is in the source image. If your character’s photo does not show a hat, the mesh has no hat; you cannot ask the 3D step to “add a sword.” The fix is to change the image first: edit or regenerate it with generate_image so the prop, clothing, or held object is visible, then convert that edited image to 3D. Higgsfield’s 2D and 3D tools are meant to be used together this way.

Rigging and the animation library

When you rig a humanoid mesh, Higgsfield fits a skeleton and can then play a clip from a large 678-animation library (the same one Meshy exposes). The clips are grouped so you can find one by intent rather than by guessing:

• Groups: WalkAndRun, BodyMovements, DailyActions, Dancing, Fighting.
• Categories inside them include Idle, Walking, Running, Jumping, Dancing, Punching, Climbing, Swimming, Sleeping, and more.

Each clip has a numeric animation_action_id. A few common ones:

idle: 0    walk: 30 (Casual_Walk)    run: 16 (RunFast)
jump: 466 (Regular_Jump)    wave: 28 (Big_Wave_Hello)    dance: 64 (All_Night_Dance)

For anything beyond those, the animation_actions tool searches the whole library by name or category and returns a preview GIF for each clip, so you can look before you pick rather than choosing an id blind. Ask the assistant something like “show me some sword-attack animations” and it lists previews for you to choose from.

A couple of rigging tips that meaningfully improve results:

• Use an A-pose or T-pose. Generating the character in a canonical a-pose or t-pose gives the auto-rigger a cleaner skeleton than an arms-down photo does.
• Set the height. A rough real-world height in meters (default 1.7) scales the skeleton sensibly.

Knobs worth knowing

You rarely need these, but they explain the quality/size trade-offs:

• target_polycount — triangle count, from 100 up to 300,000 (default around 30,000). Higher means more detail and a bigger file.
• topology — quad for smooth, editable surfaces (better if you will edit in Blender), triangle for dense detailed geometry.
• symmetry_mode — enforce, detect, or disable symmetry during generation.
• Textured vs. untextured — turn texturing off for a plain white mesh (useful for 3D printing or re-texturing yourself).

A worked example

Say you generated a stylized character image and want a rigged model of it waving. In a Higgsfield-connected assistant you would say:

Turn this character image into a 3D model, textured, rigged as a humanoid, in an A-pose, and make it wave.

Behind that, the assistant calls the 3D tool roughly like this:

generate_3d
  model: "image_to_3d"
  medias: [ { value: "<image job id or uploaded media id>", role: "image" } ]
  should_texture: true
  enable_rigging: true
  pose_mode: "a-pose"
  enable_animation: true
  animation_action_id: 28        # Big_Wave_Hello

It submits the job, polls until the GLB is ready, and hands you the download URL. The result is one file: a textured, rigged character playing the wave clip.

Cost and timing

3D generation is paid and asynchronous, like everything else in Higgsfield. The base mesh is the cheapest part; texturing, PBR, rigging, and animation each add credits, and a bigger polycount costs more. Preview any job’s cost before committing by asking the assistant to estimate it (a get_cost preflight that spends nothing), and you can request up to four variations of a mesh in one call.

Where 3D fits with the rest of Higgsfield

The 3D tools are most useful in combination with the 2D ones. A common path is:

1. Generate or refine a character image (for example with a Soul avatar for a consistent face, or Nano Banana Pro for a crisp one).
2. Edit the image so it shows exactly the props and clothing you want in 3D.
3. Convert it to a rigged, animated GLB.
4. Drop the GLB into your game, AR scene, or renderer.

That chain — image first, then lift to 3D — is the intended way to use these tools, and it is why the “the mesh only shows what the image shows” rule matters so much.

Troubleshooting

• The rig looks broken. Auto-rigging targets humanoids. Animals, vehicles, and objects have no matching skeleton and will rig poorly; skip rigging for those, or rig by hand in your own tool.
• A prop is missing from the model. The mesh only contains what the source image shows. Add the prop to the image first, then re-convert.
• The mesh is too heavy for my engine. Lower target_polycount, or use quad topology for a cleaner, lighter, editable base.
• I picked the wrong animation. Browse animation_actions with a search term and compare the preview GIFs before committing, rather than guessing an id.

Recap

Higgsfield’s 3D turns an image (or a prompt) into a downloadable GLB mesh, and can texture it, add PBR, fit a humanoid skeleton, and play one of 678 animation clips on it. The stages stack in order — mesh, texture, rig, animate — each adding cost, and the mesh only ever contains what the source image shows, so you shape the look in 2D first and lift it to 3D last.