Meshy 7 launched August 10, 2026, and the headline feature is auto-rigging: upload a humanoid mesh, flip `enable_rigging` to true, and get a deformation-ready skeleton back in under 30 seconds. The geometry side backs it up — Meshy 7 scored 81.0% overall proportion on the single-view 3D geometry alignment benchmark, ahead of Tripo 3.1 and Rodin 2.5, and the model went live in the REST API on August 12. What the marketing page doesn't lead with: the rigged output exports as FBX, not GLB, and the bone naming doesn't map to a Unity Humanoid avatar or a Godot `Skeleton3D` node by default. Here's what actually happens when you drag that file into an engine.
What Meshy 7 ships: topology, rigging, and the FBX gotcha
The API gives you real control over what comes out. `topology` accepts `quad` or `triangle`, with target counts from 1,000 to 300,000. Quad topology is the one you want for anything that's going to animate — quads deform cleanly at elbows and knees, where a triangle-dominant mesh pinches under a bend. `ultra_mode` adds 5 credits for finer surface detail on the preview pass. Image-to-3D without texture runs 20 credits, 30 with texture, 35 for 8K texture, on top of whatever rigging and animation you enable.
The part that trips people up: static meshes export as GLB, but a model with `enable_rigging=true` exports as FBX with an embedded skeleton and skin weights. If your pipeline assumes GLB end to end — because that's what every other step in a glTF-based workflow uses — the rig is a format swap you have to plan for, not an optional extra.
```bash
curl -s -X POST "https://api.meshy.ai/openapi/v2/image-to-3d" \
-H "Authorization: Bearer $MESHY_KEY" \
-H "Content-Type: application/json" \
-d '{"image_url":"$IMG","topology":"quad",
"target_polycount":8000,"enable_rigging":true}'
```
That request returns a task ID; poll it, and the completed asset link points to an FBX once rigging is enabled, a GLB if it isn't. Miss that distinction and your import script silently fails on the wrong extension.
Testing the import: Unity, Godot, and where the bones misalign
An independent production review in June 2026 timed the full path — prompt to auto-rigged character running in Unreal Engine — at under an hour, around $0.60 per model. That number holds up in our own pass through Unity and Godot, but "running" and "animating correctly" aren't the same claim.
In Unity, dragging the FBX into the project and setting the Rig tab to Humanoid triggers Unity's automatic bone mapping. It succeeds most of the time because Meshy's skeleton follows a Mixamo-style hip/spine/arm naming convention that Unity's mapper already recognizes. Where it fails: fingers. Meshy's auto-rig frequently collapses hand bones into a single palm joint or skips them, so Unity's Humanoid mapper flags "Hand" as unmapped and drops to a lower confidence muscle setup. Check the Avatar Configuration window after import — a green checkmark on the body doesn't mean the hands mapped.
In Godot 4.7, importing the same FBX through the built-in importer builds a `Skeleton3D` node, but bone roll and twist aren't guaranteed to match what a `AnimationPlayer` retargeted from a Mixamo clip expects. Shoulders are the usual failure point — without a dedicated twist bone (which Meshy's auto-rig doesn't generate), a 90-degree arm raise pinches the deltoid geometry instead of rotating cleanly. You'll see it immediately if you drive the rig through a stress pose: T-pose to A-pose, then a full overhead raise.
| Engine | Import path | Common failure | Fix |
|---|---|---|---|
| Unity | FBX → Humanoid avatar | Hand/finger bones unmapped | Manually assign in Avatar muscle map |
| Godot 4.7 | FBX → Skeleton3D | Shoulder pinching, no twist bone | Add manual twist bone or retarget in Blender first |
| Unreal Engine 5 | FBX → Skeletal Mesh | Retarget to UE5 Manny/Quinn mismatch | Run through IK Retargeter, not direct import |
The retopology angle matters here too — we covered what to verify when you skip manual retopology on AI output in our Tripo/Meshy retopology piece, and the same rule applies to rigging: automated doesn't mean production-ready, it means production-adjacent.
Gotchas worth knowing before you commit an AI-rigged character to a build:
Weight painting is automatic but not clean at contact points — shoulders, hips, and neck are where you'll see the mesh pinch or balloon under extreme poses, because Meshy's auto-weights are computed from proximity, not from a hand-tuned envelope. Hero characters — anything the camera holds on for more than a couple seconds — still need a manual weight pass in Blender before they're trustworthy, which lines up with what the June production review found.
If you've hit broken bone scale on import before, the fix is usually the same root cause across tools: our armature-scale writeup covers why a 0.01 vs 1.0 unit scale mismatch snaps bones to the origin, and Meshy output isn't immune — check the FBX's unit scale before you blame the rig.
For comparison, Heavy Assault Trooper in our catalog ships with a hand-authored humanoid rig, twist bones included, so it's a useful ground truth to drop next to an AI-rigged import in the same scene and compare deformation side by side. If you're scripting the comparison instead of downloading manually, the same REST API pattern we've documented for pulling BitSoul models works for pulling Meshy output into the same pipeline.
Net: Meshy 7's 30-second rig is real and the geometry benchmark gains are real, but treat the output as a first pass. Budget time for a hand check on fingers in Unity, shoulder twist in Godot, and a full retarget pass in UE5 — not a full re-rig, but not a drag-and-drop either.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*