Blender to VRM converter — upload the .blend itself

The .blend is opened, not imported — and that changes what to check

A .blend is a whole project, so the converter opens it the way Blender would (with the file's own scripts and driver expressions switched off — an upload is untrusted) and then does what you would do by hand before an export: it un-hides collections that are excluded from the view layer, reveals armatures and meshes that were hidden behind a control rig or switched off next to a WIP copy, and leaves cameras, lights and empties out. The glTF exporter only sees what the view layer sees, so without that step a perfectly good character would come back as “no rig” with its skeleton sitting right there in the scene.

Textures are the part that trips most Blender uploads. A .blend usually points at image files on your disk rather than carrying them; opened on our side, those paths lead nowhere and the model would come out grey — so the converter stops with NO_TEXTURES and returns the credit instead. Two ways around it: File → External Data → Pack Resources before saving, so the images travel inside the .blend, or zip the .blend together with its textures folder and upload the .zip. The converter binds the images back by the filenames the materials reference.

Linked libraries do not travel either. If your character is linked or appended from another .blend, the uploaded file carries only the reference, and the scene opens empty — the failure names the missing library. Make the character local (Object → Relations → Make Local, or File → Append it into one file) and upload that.

One project, one character. A .blend that holds several rigged figures — costume variants side by side, a finished character next to an old copy — converts all of them into one file, and the humanoid can only drive one. The converter measures how much of the mesh the mapped skeleton actually moves and refuses below half, rather than delivering an avatar where three quarters of the geometry stands still. Delete the other characters (or move them to a separate file) and upload the one you want.

Rigify control rigs: DEF- bones are the skeleton, the rest is ignored

A Rigify rig ships hundreds of bones, but only the DEF- ones carry skin weights; MCH-, ORG- and the visible controls (torso, hand_ik.L, foot_fk.R) drive them through constraints that a VRM cannot hold. The converter strips the DEF- prefix and maps the deform chain: DEF-spine through DEF-spine.006 become hips, spine, chest, upper chest, neck and head — Rigify's dot-numbered spine is a real chain of seven bones, not Blender's duplicate suffix, and it is read as one. Controls and mechanism bones are left out of the humanoid on purpose.

Shape keys on the meshes come through as VRM expressions where their names say what they are (blink, a, i, u, e, o, joy, angry and the VRoid-style Fcl_ names); a shape key called Key 1 arrives as a blendshape but drives nothing. Face rigs built from bones rather than shape keys do not carry over — that is a limit of the VRM format, not of the file.

Blender bone names the converter maps

The deform skeleton Rigify generates, left side shown; the right side is the same name with .R. Any other naming a Blender character might carry — Mixamo, Unity humanoid, plain Hips/Spine/Head — is read by the same converter; this is the one that is specific to Blender.

Eye.L and Eye.R take the eye slots when the character has them, and the Rigify finger chains (DEF-f_index.01.L through DEF-f_pinky.03.L, thumb included) resolve to the VRM finger bones. Auto-Rig Pro's .x / .l / .r suffixes and a plain Hips/Spine/Head armature are read by the same rules. Verified on the rigify family of our regression corpus (72 bones, 15 of 15 required mapped). On a successful conversion the result panel names the profile it recognized.

What can go wrong with a Blender file

A conversion that cannot finish tells you which of these it hit, and returns the credit — you are never charged for a failure.

Frequently asked questions