---

# biped-initial-setup

> slug: biped-initial-setup

在3ds Max中开始绑定时，Biped是您首先遇到的工具，但如果直接使用默认设置，在引擎阶段可能会遇到很大的麻烦。为了建立稳定的流程，请务必检查以下设置。

## 1. 修复层级结构的逻辑错误

![image.png](biped-initial-setup/image.png)

Biped的初始关节结构是根据旧版蒙皮方式设计的，在现代引擎环境中会产生一些不合逻辑的结构问题。

- **问题所在:** 在默认设置中，`Thigh`（大腿）会归属于`Spine`（脊柱）下方，`Clavicle`（锁骨）会归属于`Neck`（脖子）下方。
- **引发的问题:** 在引擎中添加角色转头或脊柱补偿动画功能时，移动脊柱会导致腿部跟随移动，结构变得异常复杂混乱。

### ✅ 必要检查项目 (Figure Mode)

![image_1.png](biped-initial-setup/image_1.png)

![image_2.png](biped-initial-setup/image_2.png)

在绑定设置前，请务必在**Figure Mode**中完成以下两项设置：

- **Triangle Pelvis（三角形骨盆）:** 必须**勾选**（将腿部层级结构正确归属到骨盆。）
- **Triangle Neck（三角形颈部）:** 必须**取消勾选**（从逻辑上分离锁骨和颈部的层级结构。）

---

## 2. 更改模式以准确确认轴心点

![image_3.png](biped-initial-setup/image_3.png)

对于精确的绑定，准确把握每块骨骼的中心点至关重要。

- **将Body Type更改为Classic:** 这是将Biped切换为Box形态时，能够最直观、最准确地确认轴心点位置的模式。
- **启用Box Mode:** 选中整个Biped后开启Box Mode，可以大幅提高工作效率。

---

## 3. 生产标准链接设置（推荐）

各项目可能有所不同，但以下是一般情况下最稳定的数据值推荐，供设置工作参考。

| **项目** | **推荐设置值** | **备注** |
| --- | --- | --- |
| **Spine Links（脊柱）** | **3个** | 表现最自然的脊柱弯曲。 |
| **Fingers（手指数量）** | **5个** | 人形角色标准 |
| **Finger Links（关节）** | **3个** | 与实际手指关节结构相同 |
| Porp | 1个 | Biped专用道具骨 |

---

**完成上述设置后，在引擎中进行动画后期修正工作时，将大大减轻TA团队和引擎团队的工作负担。**
@@

---

# rigging-master-path-setup

> slug: rigging-master-path-setup

https://youtu.be/qGYcZd67eNA?si=43ssOehRsUKK2pIi

# 3ds Max 绑定主路径设置指南 — 项目结构配置方法

# 🗂️ 需要具备的工作环境

> 为充分发挥Fast Ref 100%性能的流程构建提案

### 0. 参考流程说明 (Best Practice)

原则上，绑定原始文件和动画数据应如下分开管理，这是标准做法。

| **类别** | **绑定原始文件 (Rig)** | **动画文件 (Ani)** |
| --- | --- | --- |
| **动画数据** | **X（空）** | **O（包含数据）** |
| **绑定链接状态** | 原始文件 | 绑定文件处于**链接**状态 |

> 💡 说明：不过，由于基于3ds Max的游戏动画制作环境的特殊性，这种基于参考的流程方式可能较为陌生，或与现有工作方式存在差异。这是为了高效协作而设计的结构，请参考以下解决方案。

![image.png](rigging-master-path-setup/image.png)

## 1️⃣ 建立团队共享驱动器环境

### 建议

- 使用 **NAS** 或 **虚拟驱动器** 在团队内安装**共享驱动器**
- 例如：`N:\` 驱动器、`Z:\` 驱动器等

### ⚠️ 推荐NAS的原因

| 方式 | 优缺点 |
| --- | --- |
| **NAS（推荐）** | ✅ 同步快，基于SSD的设备多 |
| Google Drive | ❌ 同步慢 → 影响工作 |

---

## 2️⃣ 绑定主数据结构

### 核心原则

> 单独创建"绑定用主文件夹"，
> 团队内进行动画工作时必须只加载该路径下的文件

### 📁 推荐文件夹结构

```
project_name (建议使用英文)
│
└── rig
    │
    └── lilly (角色名)
        │
        ├── lilly_rig.max        ← 🎯 主文件（当前最新）
        │
        ├── texture/             ← 贴图文件夹
        │   └── 图片文件...      ← ⚠️ 必须使用相对路径链接！
        │
        └── old/                 ← 备份文件夹
            ├── lilly_000_rig.max
            ├── lilly_001_rig.max
            └── ...              ← 自由备份工作数据
```

### 🎯 核心要点

| 项目 | 说明 |
| --- | --- |
| **主文件** | 始终只将最新的绑定文件放在根目录 |
| **old文件夹** | 用于备份旧版本 |
| **texture** | 必须使用相对路径链接！ |

---

## 3️⃣ 路径规则（非常重要！⚠️）

### ❌ 绝对禁止

```
C:\프로젝트\캐릭터\릴리_리그.max     ← 韩文路径 ❌
C:\project (복사본)\rig\lilly.max   ← 特殊字符 ❌
```

### ✅ 推荐

```
C:\project_present\rig\lilly\lilly_rig.max  ← 仅限英文 ✅
```

### 🤔 为什么韩文路径不可用？

```
使用Python脚本时会出现编码问题！

问题:
  - UTF-8与CP949等，不同程序的字符处理方式不同
  - 路径识别失败 → 错误发生概率 ↑↑

结论:
  - 流程自动化必须使用英文路径！
```

---

## 4️⃣ 推荐数据整理

### 当前状态（推测）

- 动画文件夹中混有绑定数据
- 难以确定哪个文件是最新版本

### 整理方向

```
Before:
  animation/
    ├── shot_001.max
    ├── lilly_rig_v3.max      ← 绑定文件混入其中
    └── shot_002.max

After:
  rig/                        ← 绑定专用
    └── lilly/
        └── lilly_rig.max

  animation/                  ← 动画专用
    ├── shot_001.max          ← 通过Fast Ref连接绑定
    └── shot_002.max
```

---

## 5️⃣ 遵守团队内部规则（初期适应）

### 实施方案

- 初期可能会感到些许不便
- **至少1个月**严格遵守此规则
- 之后将成为团队文化

### 📊 实际案例（基于Blender的公司）

```
适用期间: 1~2个月

结果:
  ✅ "绑定同步"流程文化形成
  ✅ 动画工作生产效率提升
  ✅ 混乱显著改善（约15%以上）
```

---

## 📋 检查清单

```
□ 设置团队共享驱动器（推荐NAS）
□ 创建绑定主文件夹结构
□ 整理现有数据（专门安排时间）
□ 共享路径规则（禁止韩文！）
□ 承诺遵守1个月规则
```

---

> "构建这样的流程将对长期提高工作效率大有裨益！" 🚀
@@

---

# naming-convention-guide

> slug: naming-convention-guide

在绑定与动画流水线中，统一的命名规则不仅仅是约定俗成，更是决定项目稳定性的核心要素。

## 1. 命名规则的重要性

为了实现自动化系统和高效协作，遵守项目专属规则至关重要。例如，引擎团队基于`Root`骨骼构建了系统，但传入的数据使用了`root`或`world`等随意名称，就可能导致整个流水线严重受阻。

## 2. 命名的基本组成

- **前缀（Prefix）：** 添加在名称前面，定义对象的性质（Control、Skin等）。
- **后缀（Suffix）：** 添加在名称后面，表示方向（L、R）或状态。

## 3. 主要命名规范（Naming Case）

根据项目特点选择合适的命名风格。

- **帕斯卡命名法：** `RootNode`（每个单词首字母大写）
- **蛇形命名法：** `root_node`（单词之间用下划线`_`连接）
- **驼峰命名法：** `rootNode`（第一个单词全小写，后续单词首字母大写）

## 4. 理解与分析3ds Max Biped结构

仔细观察3ds Max标准的Biped（`Bip001 L Foot`），我们可以发现一个重要规律。

> **"原来如此！3ds Max基本上采用帕斯卡命名法，并使用空格（" "）来分隔单词！"**

熟练的工作者应能从现有数据中推断出**{类型} {方向} {部位}**这样的规则。即使加入新项目，也需要有尊重现有工作流程、灵活适应的能力。

## 5. 实务建议：避免空格，使用下划线（`_`）

现有Biped数据中常包含空格，但在现代流水线中，强烈推荐使用**下划线（`_`）**。

- **原因：** 空格会导致与Maya的兼容性问题、引擎迁移时的特殊字符替换错误，以及脚本运行时的语法错误。
- **解决方案：** 保持现有Biped骨骼名称不变，对于额外的设置（Control等），请明确使用下划线，例如`Ctrl_L_Prop1`。

---

## 💡 结论：3ds Max绑定命名的黄金法则

在3ds Max绑定环境中，以最广泛使用的**Biped为基础**最为合适。

1. **基本语法：** 以帕斯卡命名法为基础，单词之间为防止错误使用**下划线（`_`）**而非空格。
2. **Biped骨骼：** 现有Biped系统的骨骼名称为标准，保持不变。
3. **扩展节点：** 新增的控制器或辅助骨骼，最好与Biped的部位名称保持统一。

---

## 📌 常用命名列表

以下是实务中常用名称的整理，供团队参考。

### **前缀（类型列表）**

- **`Ctrl_`**: 动画师实际打关键帧的控制器元素
- **`Off_`**: 控制器的上级偏移组（用于修改和管理）
- **`Skin_`**: 分配为网格蒙皮节点的实际骨骼
- **`Pt_`**: 点（Points），主要在绑定系统内使用的辅助节点

### **中间部分（方向与位置）**

- **`L` / `R`**: 左（Left）/ 右（Right）
- **`C` / `M`**: 中央（Center/Middle）— 通常可省略。

### **后缀（部位名称）**

部位名称尽量与**Biped的名称保持统一**最为理想。

- **推荐示例：** `Ctrl_L_Calf`（○）/ `Ctrl_L_Knee`（×）
- **原因：** 即使是膝盖部位，如果Biped的实际骨骼名称是`Bip001 L Calf`，为减少混淆，以`Calf`为基础命名更为高效。
- **主要名称：** `Thigh`、`Calf`、`Foot`、`Spine`、`Neck`、`Clavicle`等
@@

---

# bone-option-pitfalls

> slug: bone-option-pitfalls

您好，这里是**OtakuSolutions**。

今天，我们要和大家分享一个从绑定新手到从业老手都意外容易忽略的问题——**3ds Max Bone选项的陷阱**，以及由此引发的**真实事故案例**。

### 😱 真实案例："导入动画后角色变形了"

在进行绑定工作时，你可能会遇到这样令人抓狂的情况。

1. **案例A（引擎不一致）：** 在Max视口中，骨骼的**Squash（挤压）**效果明明运作正常，但上传到引擎（Unity/Unreal）后，角色形状纹丝不动。
2. **案例B（数据幽灵）：** 保存并重新加载动画数据（Save/Load Animation）后，明明没有碰过的**骨骼上出现了奇怪的缩放（Scale）值**，导致绑定扭曲变形。

---

### 🔍 为什么会发生这种情况？

#### 1. 视口"视觉渲染"与"实际数据"的区别

Bone选项中的拉伸和挤压，只是**在3ds Max视口内**看起来像那么回事的"假变形"。

- **实际数据：** Transform（位置、旋转、缩放）的值根本没有发生变化。
- **结果：** 由于引擎基于"数据"运行，数据没有变化的骨骼在引擎中自然不会动。只看Max界面觉得"哦，效果不错！"，结果在引擎里吃了哑巴亏。

#### 2. 加载动画时产生的数据混乱

更大的问题出在复用动画数据时。在Bone选项开启的状态下保存并加载动画，Max会试图将这种"视觉变形"强制换算为"数据"，从而引发错误。

- **结果：** 原本不存在的**缩放值以1.1、0.9**等形式被随意写入骨骼，导致在替换绑定或复用动画时，整个工作流程一团糟。

---

### 💡 专业绑定师的解决方案："诚实的绑定"

专业的游戏绑定师应该使用**正规方法**，而不是依赖这些捷径选项。

- **LookAt Constraint & Script Controller：** 如果想要控制骨骼长度，请自行设计绑定结构，通过计算两点间距离来使**实际的缩放值**发生变化。
- **数据透明性：** 只有这样，在引擎中才能得到相同的结果，交换动画数据时数值也不会出现偏差。

---

### 🚀 [Tool] 事故预防用：Bone选项批量关闭脚本

如果您对已经处理过的骨骼感到不安，请使用以下脚本一次性清除所有骨骼的"障眼法选项"。这是回归正确绑定方式的第一步。

```maxscript
-- Bone의 가짜 스트레치/스쿼시 옵션을 완전히 끄고 데이터 혼선을 막습니다.
for b in objects where classof b == BoneGeometry do (
    b.realignSelf = false
    b.freezeLength = false -- 길이 고정 해제 (데이터 계산 방해 방지)
    b.stretch = #none      -- 가짜 스트레치 해제
    b.sidefin = false      -- (선택사항) 불필요한 핀 제거
    print (b.name + " : Clean up completed.")
)
```

---

### 📝 总结

> **"绑定靠的是'数据'，而不是眼睛。"**
> Bone选项看似方便，但在游戏生产中反而可能成为毒药。现在就来检查一下您的骨骼设置吧！
@@

---

# 3ds Max → Unity FBX 导出完整指南

> slug: max-to-unity-fbx-export

这是将在 3ds Max 中完成绑定和蒙皮的角色**正确导入 Unity** 的标准流程。
理解"为什么这样做"，即使场景不同也能自行应对。

---

## 0. 成功标准 — 看到这个画面就完成了

将 FBX 拖入 Unity，选择 **Root**（顶层对象）后，Inspector 中的 Transform 应显示如下：

| 项目 | 值 |
|------|-----|
| **Position** | 0, 0, 0 |
| **Rotation** | 0, 0, 0 |
| **Scale** | 1, 1, 1 |

![目标 - Unity 场景全貌](max-to-unity-fbx-export/image.png)

![目标 - Root Transform](max-to-unity-fbx-export/image_1.png)

**为什么这些值很重要?**
Root 保持 `0 / 0 / 1` 的干净状态，才能确保 Prefab 实例化、动画重定向、物理和碰撞体计算都可预测。
如果 Scale 进来是 `0.01`，或 Rotation 是 `-90`，误差就会积累到所有子骨骼、网格和动画片段中，事后追查原因将非常困难。**在导入时解决问题是最省事的做法。**

---

## 1. 为什么坐标和单位会不一致？（必备背景知识）

3ds Max 和 Unity 使用**不同的坐标系和默认单位**。FBX 文件充当两者之间的翻译桥梁——如果导出选项错误，翻译就会出偏差，上述值就会出错。

| 项目 | 3ds Max | Unity |
|------|---------|-------|
| **上方向轴** | **Z-up**（Z 朝上） | **Y-up**（Y 朝上） |
| **坐标系手向** | 右手坐标系 | 左手坐标系 |
| **内部长度单位** | 场景单位自由（**推荐 cm**） | **1 unit = 1 meter，固定** |

两个核心要点：

- **轴**：必须将 Max 的 Z-up 转换为 Unity 的 Y-up，否则角色会横倒。
- **单位**：Unity 的 "1 = 1 米" 是绝对固定的。在 Max 中使用 cm 工作时，1cm = 0.01m，FBX 必须正确吸收这 100 倍的差值，Scale 才能落到 `1`。否则 `0.01` 会原样保留。

> 本指南的所有步骤，最终目标都是**"将轴设为 Y-up，将单位基准设为 cm"**。

---

## 2. STEP 1 — 确认场景单位（cm 基准）

首先确认 Max 场景使用什么单位。进入 `Customize > Units Setup` 菜单。

![Units Setup 菜单位置](max-to-unity-fbx-export/image_2.png)

将 `Display Unit Scale` 设置为 **Metric → Centimeters**。

![Units Setup - Centimeters](max-to-unity-fbx-export/image_3.png)

**为什么用 cm?**
BipedPlus 的内部计算（高度、缩放等）以 **cm 为基准（SSOT）**。而且 Max 的标准导出惯例就是 cm，所以设置为 cm 后，后续的 FBX 单位转换会最干净地对齐。

> 即使工作室流程锁定在 m（米），**至少在绑定和导出阶段推荐使用 cm**。（m 场景支持是工具后续改进计划）

---

## 3. STEP 2 — 轴对齐（Z-up → Y-up）

Max 是 Z-up，Unity 是 Y-up。导出前需要**以 Root 为基准，将方向对齐到 Unity 惯例（Y 朝上，Z 朝前）**。

![Max 骨架层级与轴向](max-to-unity-fbx-export/image_4.png)

> 在 3ds Max 中，将 **Y 设为上方，Z 轴设为正面（前方）**，即可与 Unity 的方向对齐。

对齐方法：选择 Root，**以世界坐标为基准绕 X 轴旋转 +90°**。（Rotate Transform Type-In → `Absolute:World` X = 90）

![World X +90° 旋转](max-to-unity-fbx-export/image_5.png)

**为什么是 X 轴 90°?**
要将 Z-up 空间变换为 Y-up 空间，需要将上方向向量从 Z 旋转 90° 到 Y。这个旋转正好弥补了两个引擎"上方向"定义的差异。

---

## 4. STEP 3 — 只选择导出对象（蒙皮骨骼 + 网格）

导出时，**只选择蒙皮骨骼树 + 网格（几何体）**。控制器、辅助体、绑定组（`Ctrl_World`、`Grp_Rig`、`Drv_Root` 等）**不要包含在内。**

![只选择蒙皮骨骼 + 网格树](max-to-unity-fbx-export/image_6.png)

**为什么不能导出整个骨架?**
Unity 实际需要的只是**蒙皮网格 + 驱动它的骨骼**。绑定控制器/辅助体在游戏引擎中毫无用处，而且还会：

- 增加不必要的骨骼层级，使导入变重，
- 混入带有缩放/偏移的控制节点，导致 **Scale 0.01 之类的污染**。

> 原则：**只导出"游戏需要的内容"。**

---

## 5. STEP 4 — FBX 导出选项

### (1) Include — 动画和变形

- 勾选 **Animation**
- 勾选 **Deformations → Skins, Morphs**（蒙皮权重和形态键需要一起导出）

![FBX Include 选项](max-to-unity-fbx-export/image_7.png)

### (2) Advanced Options — 单位和轴

这是最关键的部分。前面讲解的单位和轴转换在这里最终确定。

| 选项 | 值 | 含义 |
|------|-----|------|
| **Units → Automatic** | 勾选 | 自动检测并转换场景单位 |
| **Scene units converted to** | **Centimeters** | 场景是 cm，所以以 cm 导出 |
| **Scale Factor** | **1.0** | 无额外倍率（转换由单位负责） |
| **Axis Conversion → Up Axis** | **Y-up** | 对齐 Unity 的上方向轴 |

![FBX 单位·轴选项](max-to-unity-fbx-export/image_8.png)

**为什么是这个组合?**
`Scale Factor 1.0` + `cm` + `Y-up` 的组合下，Unity 导入时会自动吸收 cm→m（÷100）和轴转换，使 **Root Scale 精确落在 1.0**。随意改动 Scale Factor 会重新引入 100 倍/0.01 倍的误差。

> Unity 的 Up 轴是 Y，所以导出时**必须选 Y-up**。

---

## 6. STEP 5 — 在 Unity 中验证

将 FBX 导入 Unity，选择 Root，确认是否与 **[0. 成功标准]** 一致：

- Position 0, 0, 0
- Rotation 0, 0, 0
- Scale 1, 1, 1

三项全部匹配，即导入成功。

---

## 7. 常见错误与故障排除

### 错误 1 — Root Scale 以 `0.01` 进来

![错误示例 - Scale 0.01](max-to-unity-fbx-export/image_9.png)

> **不要包含 Transform 不是默认值的 Root 骨骼。**

**原因**：将 Transform 未重置（非默认值）的 Root/控制节点包含在导出中。该节点上的 `0.01` 缩放（或 cm↔m 未转换量）会直接 bake 进 Unity Root。

**解决方法**：
- 从导出对象中**排除控制器/辅助体 Root**，只导出 Transform 干净的蒙皮骨骼树 + 网格。（参见 STEP 3）
- 再次确认 FBX 选项中 `Scale Factor` 为 `1.0`，`Units = Centimeters`。

---

### Q&A — Scale 显示 `0.9999999`，有问题吗?

![Scale 0.9999999](max-to-unity-fbx-export/image_10.png)

**结论：正常。** 3D 图形以**浮点数（floating point）**存储值，经过多次矩阵变换（旋转、单位换算等）后，`1.0` 可能会细微偏移为 `0.9999999`。这不是误差，而是**运算的自然舍入结果**，对实际使用没有影响。

**如果仍然想要干净的 `1.0`**：将该节点的 Transform 用 **PRS 通道重置**，然后将 Position 替换为 **Position Constraint**，将 Rotation 替换为 **Orientation Constraint**。（用纯 PRS 替代 Transform Script）

![Transform Script → PRS + Constraint](max-to-unity-fbx-export/image_11.png)

这样可以消除累积误差，使值归整。

![整理后 - Scale 1.0](max-to-unity-fbx-export/image_12.png)

---

## 8. 最终检查清单

导出前只需确认这 5 项：

- [ ] **单位**：场景设置为 Centimeters（`Customize > Units Setup`）
- [ ] **轴**：Root 绕 World X 旋转 **+90°**（Y-up 对齐）
- [ ] **选择**：只选蒙皮骨骼树 + 网格（排除控制器和辅助体）
- [ ] **FBX 选项**：Units `Automatic / cm`，Scale Factor `1.0`，Up Axis `Y-up`，勾选 Animation·Skins·Morphs
- [ ] **Unity 验证**：Root Transform = `0/0/0 · 0/0/0 · 1/1/1`

> `0.9999999` 的 Scale 是正常的浮点误差。只有觉得有必要时，才用 PRS 重置 + Constraint 整理。