VRM perfect sync not working? It's usually naming, not sculpting

Perfect-sync apps look your expressions up by exact name. A handful of things commonly go wrong, and they all look the same from the outside:

• Naming mismatches. Your shapes are called something close but not exact — eyeBlink_L where the app wants eyeBlinkLeft — so it matches some and drops the rest.
• Shapes exist but aren't wired. The mesh carries the deformations, but they were never referenced by a VRM BlendShapeClip (0.x) or Expression (1.0). A model can hold all 52 and expose none of them.
• VRM version mismatch. VRM 1.0 reworked the expression system. A 0.x-era tool reading a 1.0 file, or a 1.0 app reading a converted 0.x file, can silently drop expressions on import.
• Wrong convention. ARKit, VRoid and Unified Expressions naming are three different sets. Matching the wrong one is indistinguishable from missing shapes.
• Genuinely missing shapes. Some of the 52 were never created — the only case that needs actual sculpting or generation.

1. Read the shape-key names on the mesh. Open the file in any glTF/VRM inspector, or in UniVRM in Unity, and list the mesh's blendshape names. Half of all perfect-sync problems end here.
2. Check the clips, not just the mesh. Shape keys do nothing on their own — something has to reference them as a VRM expression. Confirm the clip list, not the shape list.
3. Check the VRM version against your app. Find out whether your file is VRM 0.x or 1.0 and what your app expects, and migrate with UniVRM if they disagree.
4. Check the app's expected naming convention. VSeeFace, Warudo and VMagicMirror each document which set they match; align your names to that document rather than to a forum post.

Tools for the fix: UniVRM in Unity lets you inspect, rebuild and rename expression clips by hand on any model, and handles VRM 0.x ⇄ 1.0 migration. For VRoid-topology models, HANA_Tool can add and wire the 52 shapes from scratch, which sidesteps the naming question entirely. None of this requires you to sculpt anything.

If some of the 52 don't exist on the mesh at all, no amount of renaming helps — the deformations have to be created, which is a sculpting job rather than a wiring one. That is worth knowing before you spend another evening in UniVRM chasing a name that was never there: check the mesh's shape-key list first, and if the geometry is absent, stop debugging the wiring.

Riggle doesn't produce the 52 ARKit shapes, and it doesn't rename or re-wire the ones you already have — that's roadmap, not product. It solves the neighbouring problem below, which is the one people most often mistake for this one.

There's a failure that looks similar and isn't. If your model came from Tripo, Meshy or a marketplace, it's usually rigged from the neck down and completely inert above it: no visemes, no blink shapes, often no jaw bone. That's not a naming bug — there is nothing to name, and no amount of UniVRM work will conjure geometry that was never made.

That's the case Riggle is built for. Upload the rigged .glb (or a .vrm to re-rig) and spend about twenty seconds marking the face: trace a polygon around the lips, click a point inside the mouth opening, tag the upper and lower lip, click each eye centre. Riggle turns those marks into a real lip mask on the mesh, zips the mouth into a closed rest pose biased toward the upper lip, and generates aa, ih, ee, oh, ou, blink with independent blinkLeft and blinkRight, happy, angry and surprised, plus eye-bone lookAt when the rig has eye bones. Out comes a VRM 1.0 with a video of every expression, each one pixel-diffed against the neutral render so a dead morph can't ship.

That's the VRM expression set, not perfect sync — enough for the avatar to talk, blink and react in a VRM app. Results are best on models generated with an open mouth, since the cavity geometry is what the visemes re-open; sealed mouths can be carved but come out coarser, and you'll see which you got in the preview before spending a token.