---

# biped-initial-setup

> slug: biped-initial-setup

When you first start rigging in 3ds Max, Biped is the first thing you encounter — but using the default settings as-is can cause serious problems at the engine stage. Please check the following settings to ensure a stable pipeline.

## 1. Fixing Logical Errors in the Hierarchy

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

Biped's initial joint structure was designed for older skinning workflows, which makes it somewhat illogical in modern engine environments.

- **Problem:** In the default settings, `Thigh` ends up parented under `Spine`, and `Clavicle` ends up parented under `Neck`.
- **Issues that arise:** When adding animation correction features in the engine — such as head rotation or spine correction — moving the spine also causes the legs to follow, creating extremely complex structural conflicts.

### ✅ Required Settings (Figure Mode)

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

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

Before your rigging setup, be sure to configure the following two settings in **Figure Mode**:

- **Triangle Pelvis:** Must be **checked** (correctly parents the leg hierarchy to the pelvis.)
- **Triangle Neck:** Must be **unchecked** (logically separates the hierarchy of the clavicle and neck.)

---

## 2. Changing the Mode for Accurate Pivot Inspection

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

Accurately identifying the center point of each bone is critical for precise rigging.

- **Change Body Type to [Classic]:** This mode provides the most accurate visual confirmation of pivot positions when switching Biped to Box form.
- **Activate Box Mode:** Selecting the entire Biped and enabling Box Mode significantly improves workflow efficiency.

---

## 3. Production-Standard Link Settings (Recommended)

These may vary by project, but the following values are generally the most stable. Use them as a reference during your setup work.

| **Item** | **Recommended Value** | **Notes** |
| --- | --- | --- |
| **Spine Links** | **3** | Produces the most natural spinal curvature. |
| **Fingers** | **5** | Standard for humanoid characters |
| **Finger Links** | **3** | Matches actual finger joint structure |
| Porp | 1 | Prop bone for Biped |

---

**Completing the settings described above will save the TA and engine teams from unnecessary hardship when doing animation post-correction work in the engine later on.**
@@

---

# rigging-master-path-setup

> slug: rigging-master-path-setup

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

# 3ds Max Rigging Master Path Setup Guide — Project Structure Configuration

# 🗂️ Required Work Environment

> A pipeline setup proposal for getting 100% out of Fast Ref

### 0. Reference Pipeline Overview (Best Practice)

As a general rule, it is standard practice to manage rig source files and animation data separately, as shown below.

| **Category** | **Rig Source (Rig)** | **Animation File (Ani)** |
| --- | --- | --- |
| **Animation Data** | **X (Empty)** | **O (Data Included)** |
| **Rig Link State** | Source file | Rig file in **Linked** state |

> 💡 Note: However, due to the nature of game animation production environments based on 3ds Max, this reference-based pipeline approach may be somewhat unfamiliar or differ from existing workflows. This structure is designed for efficient collaboration, so please refer to the solutions below.

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

## 1️⃣ Setting Up a Team Shared Drive Environment

### Recommendations

- Install a **shared drive** within the team using **NAS** or a **virtual drive**
- e.g., `N:\` drive, `Z:\` drive, etc.

### ⚠️ Why NAS is Recommended

| Method | Pros/Cons |
| --- | --- |
| **NAS (Recommended)** | ✅ Fast sync, many SSD-based devices |
| Google Drive | ❌ Slow sync → disrupts workflow |

---

## 2️⃣ Rig Master Data Structure

### Core Principle

> Create a dedicated "rigging master folder,"
> and always load only files from that path during team animation work

### 📁 Recommended Folder Structure

```
project_name (English recommended)
│
└── rig
    │
    └── lilly (character name)
        │
        ├── lilly_rig.max        ← 🎯 Master file (current latest)
        │
        ├── texture/             ← Texture folder
        │   └── images...        ← ⚠️ Must be linked with relative paths!
        │
        └── old/                 ← Backup folder
            ├── lilly_000_rig.max
            ├── lilly_001_rig.max
            └── ...              ← Freely back up work data
```

### 🎯 Key Points

| Item | Description |
| --- | --- |
| **Master file** | Always keep only the latest rig at the root |
| **old folder** | For backing up previous versions |
| **texture** | Relative path linking is required! |

---

## 3️⃣ Path Rules (Very Important! ⚠️)

### ❌ Strictly Prohibited

```
C:\프로젝트\캐릭터\릴리_리그.max     ← Korean path ❌
C:\project (복사본)\rig\lilly.max   ← Special characters ❌
```

### ✅ Recommended

```
C:\project_present\rig\lilly\lilly_rig.max  ← English only ✅
```

### 🤔 Why can't Korean paths be used?

```
Encoding issues occur when using Python scripts!

Issues:
  - Different programs handle characters differently (UTF-8 vs CP949, etc.)
  - Path recognition failure → Higher probability of errors

Conclusion:
  - English paths are required for pipeline automation!
```

---

## 4️⃣ Recommended Data Organization

### Current State (Estimated)

- Rig data is mixed in with animation folders
- Difficult to identify which file is the latest

### Organization Direction

```
Before:
  animation/
    ├── shot_001.max
    ├── lilly_rig_v3.max      ← Rig files are mixed in
    └── shot_002.max

After:
  rig/                        ← Dedicated to rigging
    └── lilly/
        └── lilly_rig.max

  animation/                  ← Dedicated to animation
    ├── shot_001.max          ← Connect rig via Fast Ref
    └── shot_002.max
```

---

## 5️⃣ Following Team Rules (Initial Adjustment)

### Action Plan

- It may feel somewhat inconvenient at first
- Strictly follow these rules for at least **1 month**
- It will then become part of the team culture

### 📊 Real-World Case (Blender-based Studio)

```
Application period: 1–2 months

Results:
  ✅ "Rig synchronization" pipeline culture established
  ✅ Animation workflow productivity improved
  ✅ Confusion significantly reduced (approx. 15%+)
```

---

## 📋 Checklist

```
□ Set up team shared drive (NAS recommended)
□ Create rigging master folder structure
□ Organize existing data (set aside time for this)
□ Share path rules (no Korean!)
□ Commit to following rules for 1 month
```

---

> "Building this pipeline will be a great help in improving long-term work efficiency!" 🚀
@@

---

# naming-convention-guide

> slug: naming-convention-guide

In rigging and animation pipelines, consistent naming conventions go beyond simple agreements — they are a core factor that determines the stability of a project.

## 1. The Importance of Naming Rules

Adherence to project-specific rules is essential for automation systems and efficient collaboration. For example, if the engine team builds a system based on a `Root` bone but receives data with arbitrary names like `root` or `world`, it can cause significant disruption to the entire pipeline.

## 2. Basic Components of Naming

- **Prefix:** Placed at the beginning of a name to define the nature of the object (Control, Skin, etc.).
- **Suffix:** Placed at the end of a name to indicate direction (L, R) or state.

## 3. Major Naming Cases

Choose the appropriate convention based on the nature of the project.

- **Pascal Case:** `RootNode` (capitalize the first letter of each word)
- **Snake Case:** `root_node` (connect words with an underscore `_`)
- **Camel Case:** `rootNode` (first word in lowercase, subsequent words capitalized)

## 4. Understanding and Analyzing the 3ds Max Biped Structure

If you look closely at 3ds Max's standard Biped (`Bip001 L Foot`), you can discover an important rule.

> **"Aha! 3ds Max basically uses Pascal Case and uses a space (' ') to separate words!"**

A skilled artist should be able to infer rules like **{Type} {Direction} {Part}** from existing data. Even when joining a new project, you need the flexibility to respect and work within the existing workflow.

## 5. Practical Recommendation: Avoid Spaces, Use Underscores (`_`)

While existing Biped data often includes spaces, modern pipelines strongly recommend using **underscores (`_`)**.

- **Reason:** Spaces cause compatibility issues with Maya, character substitution errors when migrating to engines, and are a major cause of syntax errors when running scripts.
- **Solution:** Keep the names of existing Biped bones as-is, but for additional setups (Controls, etc.), use underscores clearly, like `Ctrl_L_Prop1`.

---

## 💡 Conclusion: The Gold Standard for 3ds Max Rigging Naming

In the 3ds Max rigging environment, use **Biped as your base** — it's the most widely used standard.

1. **Basic Grammar:** Use Pascal Case as a foundation, but use **underscores (`_`)** instead of spaces between words to prevent errors.
2. **Biped Bones:** Keep the bone names of the existing Biped system as-is, as they are the standard.
3. **Extended Nodes:** It's best to give added controllers or auxiliary bones a sense of unity with Biped's part names.

---

## 📌 Frequently Used Naming List

Here is a list of names commonly used in production for your team's reference.

### **Prefix (Type List)**

- **`Ctrl_`**: Controller elements that animators actually key
- **`Off_`**: The parent Offset group of a controller (for modification and management)
- **`Skin_`**: Actual bones assigned as skin nodes to a mesh
- **`Pt_`**: Points, auxiliary nodes mainly used within the rigging system

### **Middle (Direction and Position)**

- **`L` / `R`**: Left / Right
- **`C` / `M`**: Center / Middle — can usually be omitted.

### **Suffix (Part Names)**

It is best to **unify part names with Biped's naming** as much as possible.

- **Recommended Example:** `Ctrl_L_Calf` (O) / `Ctrl_L_Knee` (X)
- **Reason:** Even for the knee area, if the actual Biped bone name is `Bip001 L Calf`, it is more efficient to base the name on `Calf` to reduce confusion.
- **Key Names:** `Thigh`, `Calf`, `Foot`, `Spine`, `Neck`, `Clavicle`, etc.
@@

---

# bone-option-pitfalls

> slug: bone-option-pitfalls

Hello, this is **OtakuSolutions**.

Today, we'd like to share the **pitfalls of 3ds Max Bone options** that many people — from rigging beginners to seasoned professionals — surprisingly overlook, along with **real-world incident cases** they cause.

### 😱 A Real Case: "I Imported the Animation and the Character Was Deformed"

When working on rigging, you may encounter these baffling situations.

1. **Case A (Engine Mismatch):** The bone's **Squash** effect looks great in the Max viewport, but when uploaded to the engine (Unity/Unreal), the character's shape doesn't move at all.
2. **Case B (Data Ghost):** After saving (Save/Load Animation) and reloading animation data, strange **Scale values appear on bones** that were never touched, causing the rig to twist.

---

### 🔍 Why Does This Happen?

#### 1. The Difference Between "Visual Rendering" in the Viewport and "Actual Data"

The stretch and squash in Bone options are "fake deformations" that only look convincing **within the 3ds Max viewport**.

- **Actual Data:** Transform (Position, Rotation, Scale) values do not change at all.
- **Result:** Since the engine operates based on "data," bones whose data hasn't changed naturally won't move in the engine. It's like saying "Oh, it works great!" looking only at the Max screen, then getting blindsided by the engine.

#### 2. Data Confusion When Loading Animations

The bigger problem occurs when reusing animation data. If you save and load animation with Bone options enabled, Max tries to forcibly convert these "visual deformations" into "data" and causes errors.

- **Result:** **Scale values like 1.1 or 0.9** get injected into bones where none existed, causing the entire workflow to break down when replacing rigs or reusing animations.

---

### 💡 The Professional Rigger's Solution: "Honest Rigging"

A professional game rigger should use **proper methods** instead of shortcut options.

- **LookAt Constraint & Script Controller:** If you want to control bone length, design the rig structure yourself so that **actual Scale values** change by calculating the distance between two points.
- **Data Transparency:** Only then will the result be identical in the engine, and numerical values won't drift when exchanging animation data.

---

### 🚀 [Tool] For Accident Prevention: Batch Bone Option Off Script

If you're worried about bones you've already worked on, use the script below to remove all "smoke-and-mirrors options" from every bone at once. It's the first step back to proper rigging.

```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.")
)
```

---

### 📝 In Summary

> **"Rigging is done with 'data,' not with your eyes."**
> Bone options may seem convenient, but in game production, they can actually be harmful. Check your bone settings right now!
@@

---

# 3ds Max → Unity FBX Export Complete Guide

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

The standard procedure for **correctly importing a rigged and skinned character from 3ds Max into Unity**.
Understanding *why* each step is needed allows you to handle any scene variation on your own.

---

## 0. Success Criteria — This Is All You Need to See

After dragging the FBX into Unity and selecting the **Root** (top-level object), the Transform in the Inspector must look like this:

| Field | Value |
|-------|-------|
| **Position** | 0, 0, 0 |
| **Rotation** | 0, 0, 0 |
| **Scale** | 1, 1, 1 |

![Goal - Unity scene overview](max-to-unity-fbx-export/image.png)

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

**Why do these values matter?**
A clean Root of `0 / 0 / 1` ensures that Prefab instantiation, animation retargeting, and physics/collider calculations all behave predictably.
If Scale comes in as `0.01` or Rotation as `-90`, that error accumulates across every child bone, mesh, and animation clip — making it extremely hard to trace later. **Catching problems at import time is always cheaper.**

---

## 1. Why Do Coordinates and Units Mismatch? (Essential Background)

3ds Max and Unity use **different coordinate systems and default units.** The FBX file acts as a translation bridge between them — if the export options are wrong, the translation breaks and the values above get corrupted.

| | 3ds Max | Unity |
|--|---------|-------|
| **Up Axis** | **Z-up** (Z is sky) | **Y-up** (Y is sky) |
| **Handedness** | Right-handed | Left-handed |
| **Internal Length Unit** | Free (**cm recommended**) | **1 unit = 1 meter, fixed** |

Two things are critical:

- **Axis**: Max's Z-up must be converted to Unity's Y-up, or the character will fall on its side.
- **Units**: Unity treats "1 = 1 meter" as absolute. Working in cm means 1 cm = 0.01 m, so the FBX must correctly absorb that 100× difference for Scale to land at `1`. If it doesn't, `0.01` stays.

> Every step in this guide ultimately exists to ensure **"Y-up axis, cm-based units."**

---

## 2. STEP 1 — Verify Scene Units (cm)

First check what unit your Max scene is using. Go to `Customize > Units Setup`.

![Units Setup menu location](max-to-unity-fbx-export/image_2.png)

Set `Display Unit Scale` to **Metric → Centimeters**.

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

**Why cm?**
BipedPlus's internal calculations (height, scale, etc.) use **cm as the single source of truth (SSOT)**. cm is also the standard Max export convention, so setting it here makes the FBX unit conversion downstream clean and predictable.

> Even if your studio pipeline is locked to meters, **cm is strongly recommended at least for the rigging and export phase.** (Meter-scene support is on the tool roadmap.)

---

## 3. STEP 2 — Axis Alignment (Z-up → Y-up)

Max uses Z-up; Unity uses Y-up. Before exporting, **align the Root to Unity's convention (Y is up, Z is forward)**.

![Max rig hierarchy and axes](max-to-unity-fbx-export/image_4.png)

> In 3ds Max terms: **set Y as up, Z as the forward (front) axis** — this matches Unity's orientation.

How to align: Select the Root and **rotate +90° on the World X axis**. (Rotate Transform Type-In → `Absolute:World` X = 90)

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

**Why X-axis 90°?**
To rotate from Z-up space to Y-up space, you need to roll the up vector 90° from Z to Y. This rotation bridges the gap between how each engine defines "up."

---

## 4. STEP 3 — Select Only What to Export (Skin Bones + Mesh)

When exporting, select **only the skin bone tree + mesh (geometry)**. Controllers, helpers, and rig groups (`Ctrl_World`, `Grp_Rig`, `Drv_Root`, etc.) must **not be included**.

![Only skin bones + mesh selected](max-to-unity-fbx-export/image_6.png)

**Why not export the entire rig?**
All Unity needs is the **skinned mesh + the skeleton that drives it**. Rig controllers and helpers are useless in a game engine, and they also:

- Add unnecessary bone hierarchy that bloats the import, and
- Introduce control nodes with baked scale/offset offsets that cause **Scale 0.01-style contamination**.

> Rule: **export only what the game needs.**

---

## 5. STEP 4 — FBX Export Options

### (1) Include — Animation & Deformations

- Check **Animation**
- Check **Deformations → Skins, Morphs** (skin weights and morph targets must be exported together)

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

### (2) Advanced Options — Units & Axis

This is the most critical section. The unit and axis conversions explained above are finalized here.

| Option | Value | Meaning |
|--------|-------|---------|
| **Units → Automatic** | Checked | Auto-detect and convert scene units |
| **Scene units converted to** | **Centimeters** | Scene is in cm, so export in cm |
| **Scale Factor** | **1.0** | No additional multiplier (units handle conversion) |
| **Axis Conversion → Up Axis** | **Y-up** | Match Unity's up axis |

![FBX units & axis options](max-to-unity-fbx-export/image_8.png)

**Why this combination?**
`Scale Factor 1.0` + `cm` + `Y-up` lets Unity absorb the cm→m (÷100) conversion and axis flip automatically at import, resulting in **Root Scale landing exactly at 1.0**. Touching Scale Factor arbitrarily reintroduces the 100× / 0.01× error.

> Since Unity's up axis is Y, you must always export with **Y-up**.

---

## 6. STEP 5 — Verify in Unity

Import the FBX into Unity, select the Root, and confirm it matches **[Section 0. Success Criteria]**:

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

If all three match, the import is complete.

---

## 7. Common Mistakes & Troubleshooting

### Mistake 1 — Root Scale comes in as `0.01`

![Bad example - Scale 0.01](max-to-unity-fbx-export/image_9.png)

> **Do not include a Root bone that is not at its default transform.**

**Cause**: A Root/control node whose transform has not been reset (zeroed) was included in the export. The `0.01` scale baked into that node (or the unabsorbed cm↔m delta) gets baked into the Unity Root.

**Fix**:
- Exclude **controller/helper Root nodes** from the export selection; only include the skin bone tree + mesh with clean transforms. (See STEP 3)
- Double-check that `Scale Factor` is `1.0` and `Units = Centimeters` in the FBX options.

---

### Q&A — Scale shows `0.9999999`. Is that a problem?

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

**Short answer: it's fine.** 3D graphics store values as **floating-point numbers**. After multiple matrix operations (rotation, unit conversion, etc.), `1.0` can drift to something like `0.9999999`. This is a natural rounding result of the arithmetic — not an error — and has no practical impact.

**If you still want a clean `1.0`**: Reset the node's transform on the **PRS channels**, then replace Position with a **Position Constraint** and Rotation with an **Orientation Constraint**. (Replace Transform Script with pure PRS)

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

This eliminates accumulated drift.

![After cleanup - Scale 1.0](max-to-unity-fbx-export/image_12.png)

---

## 8. Final Checklist

Before exporting, verify these five points:

- [ ] **Units**: Scene is set to Centimeters (`Customize > Units Setup`)
- [ ] **Axis**: Root rotated World X **+90°** (Y-up alignment)
- [ ] **Selection**: Skin bone tree + mesh only (no controllers or helpers)
- [ ] **FBX Options**: Units `Automatic / cm`, Scale Factor `1.0`, Up Axis `Y-up`, Animation · Skins · Morphs checked
- [ ] **Unity Verification**: Root Transform = `0/0/0 · 0/0/0 · 1/1/1`

> A scale of `0.9999999` is normal floating-point drift. Only clean it up with PRS reset + Constraint if it bothers you.