Summary
When downloading a rigged model as GLB via meshy_download_model (task_type='rigging') and importing it into Blender, the exported file has a broken transform/scale setup and a few extra artifacts. The rendered result is fine, but the scene is very hard to work with and easily looks "empty/broken" to users (and to AI agents driving Blender via MCP). These all originate in the Meshy export, which this MCP server is the front door for.
Tested pipeline: meshy_image_to_3d (pose_mode='t-pose') → meshy_rig (free walking/running) → meshy_download_model (task_type='rigging', GLB) → Blender import_scene.gltf.
Issues
1. Extreme object scale (0.01) with 100× baked data (main issue)
In the rigged GLB, both the mesh object (char1) and the Armature have object scale = 0.01, while the mesh vertices / bone data are baked 100× larger.
- Object_scale × data → correct world size (character ≈ 1.6–1.7 m), so F12 render is correct.
- But because the bone data is 100×, the Armature's viewport display is ~10 × 12 × 11 m, completely enclosing/occluding the 1.6 m character.
- Net effect: open the imported file and the viewport shows a giant octahedron/"sphere" (the bone display) and the character appears tiny or hidden — users think the import failed or the scene is empty.
Expected: object scale should be 1.0 (or a clean uniform value) with un-baked data, so the armature display and the mesh share a sane real-world scale out of the box.
2. Bundled hidden helper object / collection
The GLB ships with a hidden Icosphere (~2 m, hide_render=True, hidden in outliner) and import creates a glTF_not_exported collection to hold such helpers. This is unexpected clutter in a "character" export.
3. Auto-rig foot skin weights cause stretching
With the free auto-rig walking/running animation, the feet/shoes stretch into long smears on lift/plant frames (visible from the side, not the front), with minor foot-through-floor penetration (foot world z down to ≈ -0.02). Foot vertices appear to be pulled by the lower-leg bones (LeftLeg/RightLeg); the end-effector (foot/toe) auto-weights are inaccurate. Re-mesh + re-rig helps but extreme stride frames still stretch.
4. (Minor / possibly by design) No root motion
The bundled walking/running animations have no root motion — the character walks in place. This is convenient for framing but worth documenting; please clarify whether root-motion variants are possible.
Environment
- meshy-mcp-server (latest), Blender 4.x/5.x, glTF import.
- Models: humanoid character, image-to-3d → rig.
Ask
Primarily 1 (the 0.01-scale / 100×-baked transform on rigged GLB exports) and 3 (foot auto-weights) are the impactful ones. Could the rigged GLB be exported with a unit object scale and clean (applied) transforms, drop the hidden Icosphere helper, and improve end-effector weights? Happy to provide a sample task ID / GLB if useful.
Summary
When downloading a rigged model as GLB via
meshy_download_model(task_type='rigging') and importing it into Blender, the exported file has a broken transform/scale setup and a few extra artifacts. The rendered result is fine, but the scene is very hard to work with and easily looks "empty/broken" to users (and to AI agents driving Blender via MCP). These all originate in the Meshy export, which this MCP server is the front door for.Tested pipeline:
meshy_image_to_3d(pose_mode='t-pose') →meshy_rig(free walking/running) →meshy_download_model(task_type='rigging', GLB) → Blenderimport_scene.gltf.Issues
1. Extreme object scale (0.01) with 100× baked data (main issue)
In the rigged GLB, both the mesh object (
char1) and theArmaturehave object scale =0.01, while the mesh vertices / bone data are baked 100× larger.Expected: object scale should be
1.0(or a clean uniform value) with un-baked data, so the armature display and the mesh share a sane real-world scale out of the box.2. Bundled hidden helper object / collection
The GLB ships with a hidden
Icosphere(~2 m,hide_render=True, hidden in outliner) and import creates aglTF_not_exportedcollection to hold such helpers. This is unexpected clutter in a "character" export.3. Auto-rig foot skin weights cause stretching
With the free auto-rig walking/running animation, the feet/shoes stretch into long smears on lift/plant frames (visible from the side, not the front), with minor foot-through-floor penetration (foot world z down to ≈ -0.02). Foot vertices appear to be pulled by the lower-leg bones (
LeftLeg/RightLeg); the end-effector (foot/toe) auto-weights are inaccurate. Re-mesh + re-rig helps but extreme stride frames still stretch.4. (Minor / possibly by design) No root motion
The bundled walking/running animations have no root motion — the character walks in place. This is convenient for framing but worth documenting; please clarify whether root-motion variants are possible.
Environment
Ask
Primarily 1 (the 0.01-scale / 100×-baked transform on rigged GLB exports) and 3 (foot auto-weights) are the impactful ones. Could the rigged GLB be exported with a unit object scale and clean (applied) transforms, drop the hidden
Icospherehelper, and improve end-effector weights? Happy to provide a sample task ID / GLB if useful.