# Supported auto-mapped Models & Visemes

In this guide, **"supported models & visemes"** means CrystalLipSync can **auto-map visemes** and/or **auto-detect eye mappings** from known naming conventions.

Manual setup is always available. That means any character model (including fully custom rigs) is still supported as long as it has usable viseme blendshapes and/or jaw/eye bone targets you can map manually.

This page summarizes what CrystalLipSync supports for:

* Character/model families
* Viseme naming conventions
* Eye movement mapping conventions
* Custom models with non-standard naming

***

### Quick Support Matrix

| Model / Standard                        | Lip Viseme Auto-Map                  | Eye Blink Auto-Detect | Eye Look Auto-Detect     | Notes                                                                                                  |
| --------------------------------------- | ------------------------------------ | --------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------ |
| **VRM (0.x naming)**                    | ✅                                    | ✅                     | ✅                        | Supports VRM-style names like `Fcl_MTH_A` (mouth) and `Fcl_EYE_LookUp` (eyes).                         |
| **DAZ3D Genesis 2/3/8**                 | ✅                                    | ✅                     | ✅                        | Supports `vsm*`, `eCTRLv*`, and `eCTRLEyes*` naming families.                                          |
| **DAZ3D Genesis 8.1**                   | ✅                                    | ✅                     | ✅                        | Supports DAZ FACS viseme forms like `facs_ctrl_v*`.                                                    |
| **DAZ3D Genesis 9**                     | ✅ (plus supplement)                  | ✅                     | ⚠️ Bone-driven policy    | Eye movement is intentionally bone-driven; viseme mapping supports FACS + supplementary mouth entries. |
| **Reallusion iClone / CC3 / CC4 / CC5** | ✅                                    | ✅                     | ✅                        | Supports CC pair naming (`Open`, `Explosive`, etc.) and `V_*` forms.                                   |
| **ARKit / Live Link Face style**        | ✅ (preset combos)                    | ✅                     | ✅                        | ARKit models get preset multi-blendshape viseme combinations.                                          |
| **Oculus / VRC 15-code visemes**        | ✅                                    | N/A                   | N/A                      | Standard viseme code names are supported by matcher (`sil, pp, ff...`).                                |
| **Custom / Unknown rigs**               | ✅ (scored matcher + manual fallback) | ✅                     | ✅ (if names/bones found) | Generic tokenized/fuzzy matcher, manual mapping, jaw bone mode, and eye-bone fallback.                 |

***

### Core Viseme Set

CrystalLipSync uses a fixed **15-viseme** set:

`SIL, PP, FF, TH, DD, KK, CH, SS, NN, RR, AA, E, I, O, U`

This is the internal target set used by:

* Runtime viseme weights
* Blendshape auto-mapping
* Profile per-viseme multipliers

***

### Supported Viseme Naming Conventions

CrystalLipSync's auto-mapper supports multiple naming families and separator/case variants.

### 1) Oculus / VRC-style viseme codes

* Examples: `viseme_aa`, `vrc.v_aa`, `sil`, `pp`, `ff`, `th`, `dd`, `kk`, `ch`, `ss`, `nn`, `rr`, `aa`, `e`, `i`, `o`, `u`

### 2) Reallusion iClone / Character Creator

* CC3 pair style: `Open`, `Explosive`, `Dental_Lip`, `Tight-O`, etc.
* CC4/CC5 variant style: `V_Open`, `V_Explosive`, `V_Dental_Lip`, `V_Tight_O`, etc.
* Direct profile aliases are also recognized (e.g., `AE`, `EE`, `Er`, `Oh`, `Ah`, `Th`).

### 3) DAZ Genesis families

* Genesis 2 style: `vsm*` (e.g., `vsmAA`, `vsmEH`, `vsmM`, `vsmRest`)
* Genesis 3/8 style: `eCTRLv*` (e.g., `eCTRLvAA`, `eCTRLvF`)
* Genesis 8.1 / 9 FACS viseme style: `facs_ctrl_v*` and related variants

### 4) ARKit / descriptive naming

* ARKit-style/descriptive mouth names are recognized via signature and keyword matching (e.g., `jawOpen`, `mouthFunnel`, `mouthPucker`, `mouthStretch*`).

***

### ARKit Model Behavior

When a mesh is detected as ARKit-style:

* CrystalLipSync applies a **preset combination mapping**.
* Each viseme can use **multiple blendshapes with tuned weights**.
* This is different from standard single-index mapping and usually gives better FACS-style articulation.

***

### DAZ Genesis Notes

### Genesis 2 / 3 / 8 / 8.1

* Visemes: supported via DAZ naming families above.
* Eye look: supports DAZ `eCTRLEyes*` patterns (including bipolar up/down and side/side controls).

### Genesis 9

* **Lip Visemes:** supported (including FACS detection).
* **Supplement:** optional Genesis 9 FACS mouth blendshapes can be added as extra entries to improve articulation.
* **Eye Movement Policy:** eye look/brow blendshape auto-mapping is intentionally disabled in auto-detect path; eye movement is intended to use eye bones.

***

### Eye Movement Support by Naming Family

`CrystalEyeBlink` look blendshape auto-detection supports:

* **ARKit / CC ARKit profile** (`eyeLookUpLeft`, `eyeLookOutRight`, etc.)
* **DAZ eCTRL** (`eCTRLEyesUpDownL`, `eCTRLEyesSideSideR`, etc.)
* **DAZ Genesis 9 FACS eye look variants**
* **VRM look names** (`Fcl_EYE_LookUp`, etc.)
* **Generic/iClone-style fallback patterns**

If look blendshapes are missing, CrystalEyeBlink can use **Humanoid eye bones** as fallback.

***

### Custom Models (Non-Standard Rigs)

Custom models are supported through layered fallbacks:

1. **Scored auto-map** (token, prefix, alias, keyword, fuzzy matching)
2. **Manual mapping** in `CrystalLipSyncBlendshapeTarget`
3. **Jaw bone mode** (for rigs with weak/no viseme blendshapes)
4. **Combined mode** (blendshapes + jaw bone)
5. **Eye-bone fallback** for gaze when look blendshapes are unavailable

This means a model does **not** need to be a named preset family to work.

***

### Important Clarification: "Supported" vs "Auto-Detected"

* **Supported** means the runtime/editor can drive the rig if mappings/bones are configured.
* **Auto-detected** means CrystalLipSync can identify mappings automatically from names.

For unusual naming conventions, manual mapping may still be required even when the rig is fully supported at runtime.

***

### Practical Recommendation

For best results:

1. Run setup/auto-map first.
2. Verify all 15 viseme slots.
3. Manually adjust missing or weak mappings.
4. Use `CrystalLipSyncProfile` to normalize behavior across characters.
5. For Genesis 9 eye movement, prefer eye-bone workflow.