这篇讲 UE 5.6 里的毛发系统（Groom）。它分成两半：前半 回答"头发这东西到底怎么变成一个能算的东西"，尽量不假设你懂图形学或物理；后半 回答"UE 具体把它写成了哪些代码、调哪些参数"，这部分会大量出现类名和函数名，看不懂可以先跳过，不影响读懂前半。

前言

游戏里的头发，常见的做法是贴图造假：在头皮上贴几片带头发图案的透明卡片，看起来像有头发，但它不是一根一根的。UE 的 Groom 是另一条路——它把每一根头发当成一根真的细线来算，所以它能做到真的甩动、互相碰撞、透光。

代价就是：贵。贵到需要一整套专门的流程，而这篇就是把这套流程从"它是什么"讲到"它怎么算出来的"。

太长不看（TL;DR）

给没时间通读的你，三句话先记住：

• 是什么：Groom 把每一根头发当成一根会动的细线逐根算（真发丝），而不是在头皮上贴带头发图案的卡片（发片）；换来的是真的甩动、碰撞、透光，代价是贵、需要专门管线。
• 上手只盯三个层级：资产定基线 → 组件覆盖（总开关不开就不生效）→ 求解器组件 / CVar 最外层钳制。想调某个效果，先查"改哪里才算数"的参数地图。
• 最容易"没反应"：三条驱动路（物理求解 / Deformer / 蒙皮绑定）或插值数据不满足时会静默失效——不报错、停在默认姿态。看到"毛发不动"，先查这三条路的条件，而不是到处找 bug（见5.2 节）。

阅读说明（版本 / 读者 / 结构）：本文以 UE 5.6 的 HairStrands 插件与渲染器源码为基准。默认读者是完全没接触过毛发系统的开发者或者美术创作者：前半（第 04 章）只讲物理原理，不依赖任何引擎知识；下篇（第 511 章）讲 UE 具体实现与上手，其中标注"源码细节，可跳过“的部分，看不懂类名不影响理解。想直接上手，跳到第 9 章；想先看全文骨架，看下面的目录。

名词解释

文中会出现一批固定叫法。先在这里各给一句定义，读到生词可以回来查：

目录（TOC）

• 第 0 章 入门：头发难在哪
• 第 1 章 把一根头发变成能算的东西
• 第 2 章 让头发动起来：不"用力"，而是"拉回去"
• 第 3 章 头发怎么和世界打交道
• 第 4 章 每一帧到底发生什么
• 下篇 · UE 是怎么把它实现的（第 5~9 章）
  • 第 5 章 系统组成：UE 把它拆成了几块
  • 第 6 章 数据从哪来：Groom 资产
  • 第 7 章 怎么算：求解实现
  • 第 8 章 怎么画：这么细的东西怎么显示
  • 第 9 章 上手：改哪里、会出什么问题、多贵
• 第 10 章 和别的方案比：Groom 与 gFur
• 第 11 章 附录

第 0 章 入门：头发难在哪

一句话：头发难做，是因为它"又多、又细、又软"；UE 的选择是老老实实一根一根算，再用一堆工程手段把成本压下来。

0.1 头发为什么难做

把头发和普通物体（比如一个箱子）比一下，难点有三个：

1. 多。一头长发动辄十几万根。箱子只有一个，头发有十几万个"独立的东西"都是软的。
2. 细。一根头发比屏幕上的一个像素还细。也就是说，用普通的"画三角形"的方式，很多头发根本挤不进一个像素里，会互相盖住、闪烁。
3. 软。它不是刚体，每一根会甩、会相互纠缠、会被风带着动、会透光（不然一大把头发会像一堵黑墙）。

这三点决定了：头发既不能用"画普通模型"的办法算，也不能用"算一个刚体"的办法算，需要一套专门的东西。

0.2 常见的两种做法

UE 的 Groom 属于后者。它并不排斥前者：同一条头发也可以按远近切换成"发卡"，甚至用一片纹理来画（后面第 8 章讲）。

0.3 一根头发在引擎里长什么样

要"算"头发，第一步是把它变成能存、能改的东西。做法是：把一根连续的长头发，切成有限的一小段一小段，每一段的接头处记两件事——位置和朝向。

flowchart LR
  A["真实的一根头发
连续、无数个点"] -->|切成有限段| B["一串'珠子'
每颗珠子 = 位置 + 朝向"]
  B --> C("珠子0 发根
钉在头皮上")
  C --- D("珠子1")
  D --- E("珠子2")
  E -.-> F("...")
  F --- G("珠子N 发梢
自由")

可以把一根头发想象成一根串珠手链：

• 珠子 = 头发上的采样点，它记住自己"在哪"（位置）。
• 珠子之间的绳子 = 一段头发，它记住相邻两颗珠子的"距离、方向、相对角度"。
• 每颗珠子上还别着一个小箭头（朝向），用来记录"这段头发是扭着的还是没扭"。

发根那颗珠子被钉在头皮上（跟着头动），发梢那颗珠子自由（可以乱飞）。头发怎么动，就变成了"这串珠子怎么动"。

0.4 整条流水线：三步

从"美术做好的头发"到"屏幕上会动的头发"，一共就三步：

flowchart LR
  subgraph S1["第一步：准备数据"]
    A["美术软件里做的头发
导成 Groom 资产"]
  end
  subgraph S2["第二步：每帧算它怎么动"]
    B["把每根头发算一遍
受力 -> 变形 -> 碰撞"]
  end
  subgraph S3["第三步：画出来"]
    C["把算完的头发
光照、上阴影、合成到画面"]
  end
  S1 --> S2 --> S3

• 第一步产出的是"静止姿态"的头发（还没受力时的样子），它决定了后面所有计算"往哪儿弹回去"。
• 第二步是这篇前半（第 1~4 章）的主题：一根头发怎么算。
• 第三步在第 8 章详述：这么细的东西怎么画。

本章小结：头发难在"多、细、软"，所以不能当普通模型画，也不能当刚体算。UE 的做法是把每根头发切成有限段，每段接头处记"位置 + 朝向"，于是"头发怎么动"被转化为"这串珠子怎么动"。整条流水线只有三步：准备数据、每帧计算、画出来。

第 1 章 把一根头发变成能算的东西

一句话：一根头发只会三种变形（拉伸、弯曲、扭转）；要算它，就得把它切成有限段、给每颗珠子补上一个"朝向"，再配上"重量"。

1.1 头发只会三种变形

不管你多用力扯头发，它只会发生三件事：

关键点：这三件事的"软硬程度"差了非常多个数量级。头发几乎拉不动（拉伸很硬），却很容易弯（弯曲很软）。所以"用一根弹簧来代表头发"是不行的——那根弹簧要么被拉长（违反"拉不动"），要么硬得像钢丝（弯不起来）。

正确做法是分开建模：拉伸、弯曲、扭转各算各的。[7]

1.2 把头发切成有限的段

真实的头发是一条连续曲线，上面有无数个点，计算机没法一个个处理。必须把它切成有限段。[1]

flowchart LR
  subgraph C["连续曲线（无穷多个点）"]
    X["从头到尾连续"]
  end
  subgraph D["离散成 N+1 颗珠子"]
    P0(("珠子0
发根")) --- P1(("珠子1"))
    P1 --- P2(("珠子2"))
    P2 -.-> PN(("珠子N
发梢"))
  end
  C -->|每隔一小段取一个点| D

切完之后，一根头发由三样东西描述：

• 珠子（节点）：记位置和朝向，是"可以被改"的最小单位。
• 绳子（边）：记相邻两颗珠子之间的距离、方向、相对角度，三种变形规则都作用在它上面。
• 静止姿态（rest pose）：还没受力时的样子，是所有规则"弹回去"的目标——就像橡皮筋松手后要回到原长。

代价：段数决定精度。段切得少，头发就表达不出细腻的层次（看起来一根根是直的）；段切得多，效果好但更贵。这个"每根头发切几段"是后面最常调的旋钮之一。

1.3 为什么每颗珠子还必须记"朝向"

只记位置不够。举个反例：这两种情况仅靠位置无法区分：

只看两端位置，这两件事长得一模一样：

  弯了：   o        o        o   （中间那颗偏离了直线）
  转了：   o        o        o   （整根被扳到了另一个方向）

两者都表现为"端点位置变了"。

• 如果只有位置，“这根头发弯了"和"整根头发被转了个角度"分不出来。
• 一旦每颗珠子带上"朝向”（那个小箭头），两件事就能区分了：弯是"箭头和绳子不一致"，转是"箭头自己也一起转了、和绳子仍然一致"。

正因为有了朝向，弯曲和扭转才有可定义的对象。[7]

1.4 朝向怎么沿着头发一路传下去

这里有个陷阱。假设你从头到尾给每颗珠子都"凭切线随便定一个朝向"——朝向里包含一个"绕头发自身转了多少"的分量，这个分量是自由的、没有唯一答案。结果就是：朝向会沿着头发一路越拧越麻花，最后算出来的头发是"扭成麻花"的。

解决办法叫平行移动框架：每次只按"相邻两段之间最小的那个旋转"去更新朝向，绝不额外引入绕自身的转动，于是不会累积出虚假的扭转。[5]

它有两种用法：

• 一开始初始化时：必须从头（发根）到尾（发梢）一根一根顺着传，保证整根头发上的朝向是连贯的。
• 每帧计算时：只按相邻珠子局部修正，这样才可以并行（每颗珠子各算各的，不用等别人）。

1.5 每颗珠子有多重

最后一件事：给每颗珠子配上"重量"和"转动惯量"（可以理解成"转起来有多费劲"）。

为什么需要？因为规则被违反时，要决定"谁动多少"。直觉是：轻的动得多，重的动得少。发根那颗珠子通常"很重"（几乎不动），发梢那颗"很轻"（到处乱飞）。引擎用的正是这个直觉——按"重量/转动惯量的倒数"来分配修正量。

注意有两套，别混：

• 管位置的规则，看重量（质量）。
• 管朝向的规则，看转动惯量。

在 UE 里，这两套量由数据接口的 ComputeNodeMass 与 ComputeNodeInertia 提供（第 7 章细讲）。

本章小结：一根头发只会拉伸、弯曲、扭转三种变形，而且三者软硬差距极大，必须分开算。要能算，就把它切成有限段：珠子记位置和朝向，绳子记两颗珠子之间的关系，静止姿态是弹回的目标。朝向是必须的，否则"弯了"和"整根转了"无法区分；朝向的传播要用平行移动框架，避免沿头发累积出虚假的扭转（初始化时串行传、每帧并行局部修正）。最后给珠子配上重量和转动惯量，让规则被违反时按"谁轻谁多动"来分配修正。

第 2 章 让头发动起来：不"用力"，而是"拉回去"

一句话：与其给珠子加力（容易算炸），不如先规定"头发本来应该是什么样"，每帧把偏离的地方按比例拉回去。这就是 UE 求解器全部规则的共同做法。

2.1 为什么不直接"加力"

最直觉的想法是：把每段头发当成一根弹簧，受力就伸长/弯曲，算出力再让珠子动。

但弹簧有个麻烦：“有多硬"和"每帧算多长"是绑死的。弹簧越硬，就越需要把每帧切得非常非常小来算，否则会算飞（数值发散）。而头发恰恰需要"拉伸极硬、弯曲极软”——硬的那部分会把整根头发逼到用极小步长，成本爆炸。[3]

2.2 换个思路：写成"规则"，再把违反的地方拉回去

换个问法：不问"力有多大"，而问"本来应该是什么样，现在差了多少，把差的那部分补回去"。

这就是约束的思路。一条约束就是一句"应该满足的话"，比如：

"这两颗珠子之间的距离，应该等于静止时的距离。"

如果现在被拉长了 3 厘米，那就把这两颗珠子往回推一点，让距离缩短一些——不是一次推到位，而是每次推掉一部分。一帧里把这条规则重复推很多遍（叫"迭代"），结果就越来越接近满足。[3]

这种"先把位置预测出来、再按规则反复拉回去"的做法，英文叫 PBD（位置动力学）；UE 用的是它的改进版 XPBD。

2.3 一条规则上要写清楚的三件事

其中"有多软"这一项，UE 会先把它除以"每步时长的平方"再用。为什么要这么绕？为了让同一套参数在不同帧率下含义一致——不想出现"帧率越高头发越硬"这种事。[4]

但要澄清一个常见误解：这样做并不代表"结果和帧率无关"。因为每帧迭代次数是固定的，步长变大时，同样的迭代次数收敛得更不充分，头发还是会变软、变滞后（第 4 章展开）。

2.4 拉伸、弯曲、扭转其实是同一件事

回到第 1 章那三种变形。实现上它们是同一个公式，区别只在"这条规则管几颗珠子"：

珠子越"轻"、规则越"软"，这条规则被违反时就越容易拉回来。UE 里这是同一个函数用不同参数（NodeOffset）实现的，第 7 章细讲。[7]

2.5 “箭头"的两种记法

因为有了朝向（箭头），“弯曲"就有两种写法：

• 写法 A（看方向）：把绳子方向拉回"父珠子的箭头转过静止角度后的方向”。简单、稳，弹簧一族用这种。
• 写法 B（看相对旋转）：直接规定"相邻两颗珠子的箭头之间应该转多少”。它一次就把弯曲和扭转都管住了，是"杆"一族的用法；麻烦在于：一个旋转用两个相反的四个数字（四元数）都能表示，取解时要挑对，否则会在某个角度突然翻车（俗称"双覆盖"问题）。[6][7]

UE 两套求解路线正好对应这两种（弹簧族 vs 杆族），第 7 章细讲。

2.6 阻尼：让它别抖

阻尼（damping）像"泡在水里"的阻力。它不改变头发最终该停在哪，只影响"多快停下来"。

• 阻尼太小：头发来回弹、抖。
• 阻尼太大：头发变得迟钝、像泡在糖浆里。

对毛发来说，合适的阻尼是"看着不抖、也不像泡酱里"——这取决于迭代次数和子步数（第 4 章）。

2.7 发根硬、发梢软

真实头发是渐变的：发根粗硬、发梢细软。实现里不是用一个常数，而是沿头发逐点采样成一张表——从头到尾，刚度/摩擦/粗细都按位置给不同值。

这张表的密度 = 每根头发切了几段。段数不够时，渐变会变成一格一格的阶梯——这就是"怎么调都不够自然"时最该看的旋钮。

本章小结：直接给头发加弹簧力不可行，因为"刚度"和"步长"绑在一起，硬的部分会把步长逼到极小。UE 改用"约束"：先规定头发应该满足的规则，每帧把违反的部分按比例拉回去，迭代多次逼近。一条规则要写清楚"规则是什么、有多软（柔度）、影响谁（重量/惯量）"。拉伸、弯曲、扭转其实是同一个公式，区别只在管几颗珠子；朝向有两种记法（看方向的、看相对旋转的），后者同时携带弯曲与扭转但要处理"四元数二义"。阻尼不改变终点，只影响多快稳住；刚度参数沿头发渐变，由"切几段"决定其分辨率。

第 3 章 头发怎么和世界打交道

一句话：头发会被角色"甩"起来，是因为它是在跟着角色一起动的坐标系里被算的；而碰撞和风都用了更省事、但有代价的近似。

3.1 撞到身体

头发撞到头皮/身体时，要处理两件事：

• 别穿进去：一旦珠子跑到身体里面，就把它推出来。
• 擦过去的摩擦：贴着身体滑动时，按摩擦决定"黏住不动"还是"滑过去"。

实现上有两种：硬约束（直接推出去，简单但可能抖）和软约束（允许暂时穿一点点，换来更顺滑，代价是需要多迭代几下）。UE 两种都有（第 7 章）。[6]

3.2 头发和头发之间

十万根头发两两判断"撞没撞"是不可能的（组合数太大）。省事的做法是体素化：把所有头发的密度灌进一个三维网格（就像把头发塞进一堆小格子里），格子之间互相"排斥"，近似出头发互相推开的效果。

代价要说清楚：这种做法不产生具体的接触点和接触法线，所以它没有"逐点的摩擦"这回事；能分辨的最小间距由网格粗细决定——太粗会粘成一坨，太细又贵。UE 用一个速度网格 + 一个压力网格来做（第 7 章）。

3.3 风

把每一小段头发当成一根很细的圆柱，风对它的阻力是两项相加：

阻力 = 与速度成正比的部分（慢速时主导）
     + 与速度平方成正比的部分（快速时主导）

迎风面的大小，取决于"风的方向和头发方向的夹角"——正对着风时最粗，顺着风时最细。这也是为什么"甩得越快，阻力增长得越不成比例"：快速时是平方项在起作用。

3.4 角色动，头发为什么会被甩

头发是在一个跟着角色一起动的坐标系里算的。于是角色本身的速度、转动、加速，就变成了作用在头发上的一股"假力"（就像公交车急刹车时你会往前倾）。

• 好处：头发默认跟着角色走，不会因为角色一停就整体"留在原地"。
• 前提：角色每帧的加速必须被正确地喂进去，否则头发会莫名其妙往某个方向飘。

要注意：喂进去的是每帧算出来的速度（用相邻两帧位置相减得到），不是动画师设计的速度曲线——所以它和帧率有关（第 4 章）。UE 里由组件的"线/角速度比例"和"瞬移阈值"控制（第 7 章）。

3.5 为什么一模拟头发就往下掉

美术摆好的头发姿态，通常不是"刚好被重力托住"的姿态。你一开模拟，重力立刻把它往下拽，头发就塌下来了，和美术想要的不一样。

常见解法：开模拟前，先让重力和头发自己达成一次平衡，得到一个"自然下垂"的姿态；然后把它和美术原始姿态按一个系数混合，当作新的"静止姿态"。说白了，就是把"往下掉"这件事本身定义成新的静止样子。UE 里对应"重力预载"（第 7 章）。

本章小结：头发是在跟随角色的坐标系里被算的，所以角色的运动变成一股"惯性假力"，头发才会被甩起来；喂进去的是逐帧差分的速度，因此与帧率相关。碰撞分两条：和身体碰撞有"推出 + 摩擦"，头发之间只用体素化近似排斥——不产生接触点和法线，也就没有逐点摩擦，能分辨的间距由网格粗细决定。风把每小段头发当细圆柱，阻力是"线性项 + 平方项"，迎风面积随风与头发的夹角变化。静止姿态与重力天然矛盾，解法是先解一次重力平衡，再和原始姿态按系数混合，把"下垂"定义成新的静止姿态。

第 4 章 每一帧到底发生什么

一句话：一帧 = 先按力把珠子推一下 + 反复把规则拉回去 + 收尾；“换个帧率，头发手感就变了"的根子在"每步多长”，不在迭代本身。

4.1 一帧的三段

flowchart TD
  A["这一帧结束了多少时间（delta）"] --> B["第一段：让珠子按力自由动一下
（先算速度，再算位置，叫'预测'）"]
  B --> C["第二段：把违反的规则一条条拉回去
重复很多遍（迭代）"]
  C --> D["第三段：收尾
只修正当前珠子，把最后一点误差抹平"]
  D --> E["把珠子的位置/朝向交给渲染，画出来"]

三段各司其职：第一段负责"顺着力动"，第二段负责"别违反规则"，第三段负责"收干净"。第 7 章会看到 UE 里这三段分别对应哪些函数。[3]

4.2 两个不同的旋钮：子步 与 迭代

它们常常被混为一谈，其实管的是两件不同的事：

一句话：子步管时间切多细，迭代管规则解多透。少子步会在快速甩动时"跟不上、穿透"；少迭代会让头发整体发软、拉不住。

4.3 为什么换个帧率，手感就变了

这里要分清三个时间量：

1. 一帧多长（delta）：机器跑得快就短，卡一下就长。
2. 每帧算一次：求解器每帧被调用一次，拿到的就是这一帧的 delta。
3. 每一步多长：delta 会被一个上限拦一下（太长就截断），再按子步数平均分。

由此得到三个结论：

• 超长帧会被截断：比如切关卡卡了半秒，求解不会让头发"瞬移半秒"，而是让这一帧的模拟变慢。表现是"头发跟不上角色"——这是为了稳定付出的代价。
• 改帧率 = 改刚度：因为每步长度直接来自 delta，帧率高时步长小、收敛充分（靠近设定的硬度）；帧率低时步长大、收敛不足（更软更滞后）。这就是"同一份头发在不同机器上手感不一样"的来源。
• 按"帧数"计数的东西会随帧率变：比如重置后有一段"启动缓冲"，它是按帧数算的，60 帧下这段真实时长就是 30 帧下的一半。

成熟求解器的通常做法是两层补偿：位移大的帧自动多切几段（动态子步）+ 迭代数跟着步长放大，让等效手感不随帧率漂。UE 提供了 r.HairStrands.EnableAdaptiveSubsteps 等开关，但插件里没有做固定步长（第 7 章）。[4]

4.4 现象对参数

这张表是全篇"调参直觉"的来源：

4.5 为什么这类计算适合显卡并行

规则之间会互相牵扯（同一颗珠子被好几条规则用到），所以不能无脑并行。做法叫分组着色：把"不抢同一颗珠子"的规则放进同一组，组里可以同时算，组与组之间排队。

一条规则管几颗珠子，就能分成几组——比如管相邻两颗的（拉伸）按 x % 2 交替，管三颗的（弯曲）按 (x / 2) % 2 交替，管四颗的（扭转）按 (x / 3) % 2 交替。这三个式子的取值都只有 0/1，所以三种约束实际都是两色（红/黑）交替，差别只在取模步长；经典红黑着色就是前者的特例。UE 的实现与此一致（第 7 章）。

还要记住一点：分组的顺序会影响结果——这就是"同样的参数，不同求解器结果略有差异"的原因之一。

本章小结：一帧分三段——按力预测、反复拉回规则、收尾修正。子步与迭代是两个不同的旋钮：子步把一帧切成几段（管大位移准不准），迭代把规则反复解几遍（管软硬）。手感随帧率变化的根子在"每步多长"：delta 先被上限截断、再按子步均分，所以低帧率会让模拟变慢变软，“改帧率等于改刚度”；按帧计数的机制（如重置后的启动窗口）也会随帧率改变真实时长。规则之间互相牵扯，需要按"管几颗珠子"做分组着色，组内并行、组间排队，而且分组顺序本身影响结果。

下篇 · UE 是怎么把它实现的（第 5~11 章）

下篇把前 4 章的每一条道理，对应到 UE 的具体类名 / 函数名 / 资产字段。看不懂类名没关系：每章开头都有一句"白话导读"和一个"一句话"结论；标注"源码细节，可跳过“的部分跳过去也不影响理解。真正要动手的人重点看第 9 章（上手地图）和第 11 章（控制台速查）。

第 5 章 系统组成：UE 把它拆成了几块

一句话：UE 把这件事分成"准备数据、计算、画出来"三块，谁管哪份数据分得很清楚；其中"计算"这块的流程是写在 Niagara 资产里的，不在 C++ 里。

白话导读：前 4 章讲的是"物理上应该怎么算”，不依赖任何引擎。从这章起进入 UE 的具体实现，会出现大量类名（如 UGroomAsset）。看不懂类名就先看每节的白话部分，它们讲的是同样的道理。

5.1 三块与一条数据流

毛发插件叫 Groom，位于 Engine/Plugins/Runtime/HairStrands，内部又拆成 7 个模块，各管一摊：

而"画出来"这部分不在插件里，在引擎渲染器的 Engine/Source/Runtime/Renderer/Private/HairStrands。

flowchart LR
  subgraph ASSET["准备数据（HairStrandsCore）"]
    GA["UGroomAsset
头发资产"]
    BA["UGroomBindingAsset
发根钉到网格上"]
  end
  subgraph RUNTIME["运行时（HairStrandsCore）"]
    GC["UGroomComponent
挂在角色身上的组件"]
    GI["FHairGroupInstance
每组的实际数据"]
  end
  subgraph SOLVE["计算（HairStrandsSolver + Niagara）"]
    SC["UGroomSolverComponent
划分曲线 + 出设置"]
    NB["Niagara 系统
真正在 GPU 上算"]
  end
  subgraph RENDER["画出来（Renderer）"]
    SP["FHairStrandsSceneProxy
可见性 / 光照 / 合成"]
  end
  GA --> GC
  BA --> GC
  GC --> GI
  GI -->|几何与参数| SC
  SC -->|入队| NB
  NB -->|变形后的位置| GI
  GI -->|交给渲染| SP

各层各自拥有什么（源码细节，可跳过）：

5.2 头发"怎么动"的三条路

一个发组怎么动，UE 提供了三条路，优先级从高到低、不是叠加：

flowchart TD
  A["每个发组 / 每个 LOD"] --> B{"开了物理求解吗？
IsSimulationEnable"}
  B -->|是| S["走物理求解（Niagara / Solver Deformer）"]
  B -->|否| C{"开了 Deformer 吗？
IsDeformationEnable"}
  C -->|是| D["走 DeformerGraph 骨骼驱动"]
  C -->|否| E{"绑定类型 BindingType"}
  E -->|Skinning 且有绑定资产| F["蒙皮绑定（默认）"]
  E -->|Rigid 且有已注册网格| G["刚性跟随网格"]
  E -->|资源不全| H["降级为'没绑定'（静默）"]

• 物理求解：真正会自己算头发怎么动的那条。由资产开关和组件覆盖共同决定（IsSimulationEnable）。
• Deformer：不是物理解算，而是用一张"骨骼驱动图"来摆头发；资产开关是 FHairSolverSettings::bEnableDeformation。
• 蒙皮绑定：默认路径。头发被"焊"在身体网格上，靠网格变形跟着动。绑定类型由 FHairLODSettings::BindingType 决定（NoneBinding / Rigid / Skinning，默认 Skinning）。

最容易踩的坑是：这三条路判定不满足时不会报错，而是"毛发不动 / 停在默认姿态"。看到"毛发没反应"，先查这三条路的条件，而不是到处找 bug。

5.3 为什么把求解放在 Niagara 上

好处很直接：用 Niagara 就能在 GPU 上算、能通过"数据接口"把资产里的参数和网格喂进去、还能白拿它现成的调度和子步框架。

代价也很直接：求解的"流程编排"（先算什么、循环几次、怎么分支）写在了 Niagara 系统资产里，不在 C++ 代码里。于是：

• 调试时在 C++ 里看不到"它到底迭代了几次"，只能看资产配置；
• 流程随二进制资产走，跨版本升级和版本管理比纯代码更麻烦。

这也是"同一个求解器组件，在不同项目里表现不一样"的根源。

5.4 三层时序

sequenceDiagram
  participant GT as 游戏线程
  participant NI as Niagara 实例
  participant GPU as 显卡
  GT->>GT: 组件 Tick：更新设置、判断要不要重置、更新跟随的骨骼
  GT->>GT: 求解器组件 Tick：按距离划分曲线
  GT->>NI: 到点触发求解
  NI->>GPU: 展开流程：预测 -> 迭代 -> 收尾
  GPU-->>GT: 写回变形后的位置与朝向，供渲染读取

顺序由 tick group 推导，保证"在骨骼更新之后、渲染之前"发生。所谓"同一帧内"，指的是渲染读到的是本帧算完的结果。

5.5 前半的量，在后半的哪里（对照表）

本章小结：UE 把毛发分成"准备数据、计算、画出来"三块，按"谁拥有哪份数据"划边界。毛发怎么动有物理求解、Deformer、蒙皮绑定三条路，它们不是叠加关系，条件不满足时是静默失效而非报错。求解之所以放在 Niagara 上，是为了 GPU 计算、数据接口和现成的调度框架，代价是"流程编排"落在资产里而不在代码里。执行跨游戏线程、Niagara、GPU 三层，顺序由 tick group 决定。

第 6 章 数据从哪来：Groom 资产

一句话：屏幕上十万根头发，真正存下来、真正参与计算的只有少量"骨架”；其余是照着骨架"长"出来的，配置则以"发组"为单位。

白话导读：这章回答"这些头发是从哪来的、怎么存的"。如果你只想搞懂原理，记住一句就够：存的是少量骨架，画的是大量填充。

6.1 两级数据：控制线与可见发丝

• 控制线（Guides）：真正参与计算的少量"骨架头发"。
• 可见发丝（Strands）：屏幕上实际画出来的那一大把，每一根都记着"我最像哪根骨架、像多少"，由骨架插值"长"出来。

两者的数量比就是"一根骨架撑起几根真发"。要注意的坑：插值数据一旦缺失，不会报错，而是让形变相关功能整体失效（头发停在默认姿态）——这是最容易被误判的故障。

6.2 发组：配置的最小单位

头发在资产里按"发组"组织（比如"刘海"、“后脑"各是一组）。每种配置都是一张数组，按组的编号一一对齐（第 0 张对应第 0 组，以此类推）（源码细节，可跳过）：

改组数会让这些对齐关系和绑定一起失效，这是修改资产时最容易出事的地方。

6.3 绑定：把发根钉到网格上

头发要跟着身体动，就得知道"每根发根落在身体网格的哪个位置”。UGroomBindingAsset 就是把这件事提前算好存下来：每根发根落在哪个三角形上、用哪几个顶点按什么权重插值（源码细节，可跳过：RootToUniqueTriangleIndexBuffer / RootBarycentricBuffer / MeshInterpolationWeightsBuffer 等，封装在 FHairStrandsRootBulkData）。

两件事必须知道：

• 不提供绑定资产时，投影会在运行时现算，启动时有一笔较大的 GPU 开销——表现就是"第一次看到角色卡一下"。
• 绑定资产里存的是源网格的三角形编号，所以跨骨架复用会出问题：绑定与网格的 LOD 数量不一致时会直接判定不兼容（回退成未绑定、毛发不动），而 LOD 数量一致时不会报错、却会给出错误的形变。

6.4 LOD 与"第一次进游戏卡一下"

LOD（远近不同精度）有三种模式：

另外，资产里的设置会被**编译成一份"派生数据"缓存在磁盘上。改动设置会改变它的"钥匙"，从而触发重新生成——这就是“改完设置第一次进游戏卡一下”**的原因：它在现生成 PostLoad / PostEditChangeProperty 时触发重建。

本章小结：控制线是参与计算的少量骨架，可见发丝是由它插值长出来的一大把；插值数据缺失不会报错，而是让形变功能整体失效。配置以"发组"为单位、按编号对齐，改组数会连带失效。绑定资产把"发根落在网格哪个三角形、怎么插值"提前烘焙好，省掉运行时投影，代价是跨骨架复用会出错。LOD 有 Default / Manual / Auto 三种，Auto 会忽略手工设置；派生数据的重建就是"改完设置第一次进游戏卡顿"的来源。

第 7 章 怎么算：求解实现

一句话：求解器组件自己不算，它只负责"划分要算哪些头发、把设置准备好"，真正的计算发生在 Niagara 系统图和 GPU 上。

白话导读：这章把第 2~4 章的每一条道理，对应到 UE 的具体类与函数。看不懂函数名就只看每节的结论句。

7.1 谁出设置、谁真正执行

这是最容易搞错的一点：UGroomSolverComponent 不是执行者。

它的 TickComponent 里只有"标脏 + 划分曲线"，没有任何解算代码。走哪套求解系统由枚举 EGroomNiagaraSolvers 决定。

7.2 前 4 章的公式落在哪（源码细节，可跳过）

规则本身写在 Engine/Plugins/Runtime/HairStrands/Shaders/Private/ 下，统一用 Setup -> Solve -> Project（准备 -> 解 -> 收尾）三段命名：

第 2 章说的"同一条规则管几颗珠子"，在这里就是参数 NodeOffset：

NodeOffset = 0  ->  拉伸（相邻两颗）
NodeOffset = 1  ->  弯曲（管三颗）
NodeOffset = 2  ->  扭转（管四颗）

与 4.5 节的"分组着色"一致：拉伸按 x % 2、弯曲按 (x / 2) % 2、扭转按 (x / 3) % 2——三个式子的取值都只有 0/1，因此三者都是两色（红/黑）交替，区别只在取模步长。

“有多软”（柔度）不是资产上的一个字段，而是在准备阶段算出来的：

柔度 = 4.0 / (杨氏模量 * pi * 杆半径 * 静止长度 * 杆半径 * dt^2)

式中"杆半径"在源码里对应的参数名是 RodThickness（它被填进截面积公式中 R 这一项，即 面积 = pi * R^2 里的 R）。

那个 dt^2 就是 2.3 节说的"按步长平方归一化"。

7.3 自碰撞网格长什么样

自碰撞用两个数据接口：速度网格（UNiagaraDataInterfaceVelocityGrid）和压力网格（UNiagaraDataInterfacePressureGrid）。

它们都用同帧 ping-pong：一边读一边写会读到"写坏一半"的数据，所以准备了两块缓冲（CurrentGridBuffer / DestinationGridBuffer），写完之后要 Swap() 一下才能读。分辨率由 GridDimension 控制，通道数是固定的（速度网格 6 个、压力网格 18 个）。分辨率越高，能分开的头发越细，显存也按分辨率的三次方增长。

7.4 参数的三个来源与覆盖边界

参数可以来自三个地方，“改哪里才算数"要先分清楚：

1. 资产（HairGroupsPhysics）：基线值。
2. 组件覆盖（UGroomComponent::SimulationSettings）：只有当"覆盖总开关"打开时才参与。
3. 求解器组件（FGroomSolverSettings）与 CVar：更外层的控制。

资产里能调的参数（源码细节，可跳过）：

“发根硬发梢软"这张沿头发分布的表，对应数据接口里的 ParamsScale：

ParamsScale：32 * 4 个数
  四条曲线：拉伸缩放 / 弯曲缩放 / 半径 / 粗细
  以 VertexCoord = i / (StrandsSize - 1) 逐点采样
  每条曲线最多 32 个采样点

关键上限：每条曲线最多 32 个采样点；而"每根头发切几段”（StrandsSize）的可选值本身只有 2/4/8/16/32，上限正好也是 32。也就是说采样点数与段数一一对应、上限同为 32，精度因此被封死在 32 点——这是 2.7 节说的"怎么调都不够自然"的原因之一。

另外，同名参数可能分属不同路径：资产上的 SubSteps / IterationCount、数据接口里的 SubSteps（默认 5）/ IterationCount（默认 20）、组件上的 NumSubSteps（默认 2）/ NumSolverIterations（默认 5）是三套不同的东西，不能互相推导。

7.5 按距离决定"这帧算多少”

SelectDynamicCurves 按"离镜头多远"决定这帧要算多少根控制线：

距离比例 = clamp((距离 - 最近距离) / (最远距离 - 最近距离))
要算的控制线数 = (1 - 距离比例) * 总控制线数

一个反直觉点：划分的结果和帧率无关，但划分本身的消耗和帧率成正比——每帧都要重算一遍，距离没变结果一样，CPU 时间照花。

还要区分：“算多少”（模拟 LOD）和"画多少"（渲染 LOD）不是一回事。

7.6 生命周期与重置

重置会在三种情况发生：初始化、瞬移（位移超过 TeleportDistance）、不可见/隐藏；数据接口还会在"网格资产被换掉"时触发重置。

重置后有一段按帧计数的"启动缓冲"（上限由 r.HairStrands.SimulationMaxDelay 控制，默认 4 帧）。因为按帧计数，这段的真实时长会随帧率变化（4.3 节）。

7.7 一轮求解的完整时序

sequenceDiagram
  participant GT as 游戏线程
  participant SC as 求解器组件
  participant NB as Niagara
  participant GPU as 显卡
  GT->>SC: TickComponent：标脏
  SC->>SC: SelectDynamicCurves：按距离划分
  SC->>NB: 入队
  NB->>NB: 取 delta（先被上限截断）-> 按子步数均分
  loop 每个子步
    NB->>GPU: 预测（AdvectNodePosition / AdvectNodeOrientation）
    loop 每次迭代
      GPU->>GPU: 准备 -> 解 -> 收尾（拉伸 / 弯曲 / 扭转 / 碰撞）
    end
  end
  GPU-->>GT: 写回位置与朝向 -> 渲染读取

哪些机制会随帧率变化：

本章小结：求解器组件只负责"出设置 + 划分曲线"，真正的计算在 Niagara 与 GPU 上。前 4 章的每一条道理都能落到具体函数：三类规则在同一族 shader 里靠 NodeOffset 区分；柔度由杨氏模量、杆半径、静止长度和步长派生（dt 平方在分母）；“发根硬发梢软"由最多 32 个采样点的逐点表承载，所以精度上限就是"每根切几段”。自碰撞用读写型数据接口做同帧 ping-pong，写完必须交换缓冲才能读。参数有资产、组件覆盖、求解器组件三层，“总开关没开"和"这个字段本来就不给覆盖"是两种不同的没生效。按距离裁剪的是"算多少”，且开销随帧率增长；重置后的启动缓冲按帧计数，时长随帧率变。

第 8 章 怎么画：这么细的东西怎么显示

一句话：头发比像素还细，直接按普通方式画会互相盖住、闪烁；所以 UE 换了个顺序——先搞清楚哪些像素上有头发，再只给这些像素上色。

白话导读：前面都在讲"算"。这章讲"画"。只要记住"先找哪些像素有头发、再只算这些像素"这一句，剩下都是细节。

8.1 三种画法（可切换）

坑：强制某一种画法时，如果资产里没有那类数据，会什么都不显示（不是报错）。r.HairStrands.UseCardsInsteadOfStrands 的提示就明确说了这点。

8.1.1 Groom（发丝）与 Cards（发卡）之间怎么用 LOD 切换

三种画法不只"能手动强制切"，更常规的用法是把它们做成一套 LOD 降级链：近处/主角用真发丝（Strands，最真最贵），拉远后自动换成发卡（Cards，中等），更远再换网格（Meshes，最省）。“怎么切"由 Groom 的 LOD 系统驱动：

1. 每个 LOD 等级可指定一种画法：LOD 0 用 Strands、LOD 1 用 Cards、LOD 2 用 Meshes——画法本身就是 LOD 的一部分（9.5.2 节 的 Visible Geometry Type 就是在选当前 LOD 用哪种几何）。
2. 靠"屏幕占比"触发：相机拉远，头发在屏幕上占的面积变小，一旦跌破该等级的 Screen Size 阈值，就自动降到下一级（Strands→Cards→Meshes）。LOD Mode（Default / Manual / Auto）+ Auto LOD Bias 决定这套判定是自动还是手写；Minimum LOD 钳制"最低允许降到哪一级”（9.5.2 节）。
3. 资产必须有那级的数据：想切到 Cards，资产里必须先 Add Card asset；想切到 Meshes，必须先 Add Mesh asset。缺数据的等级一旦被选中，会什么都不显示——这是"远处头发突然没了"最常见的根因（9.5.4 节 / 9.5.5 节）。
4. 渲染 LOD 与模拟 LOD 分开：换画法（渲染 LOD）降的是"怎么画"；而"算多少根"由独立的模拟 LOD 控制（SelectDynamicCurves，7.5 节）。Cards/Meshes 通常不参与逐根求解，所以远处头发连物理也一起省了。

一句话：Groom↔Card 的切换 = “LOD 等级里把画法降级 + 屏幕占比触发 + 资产得有那级数据”。要启用，先确认资产里建了 Cards/Meshes 数据，再在 LOD 面板把对应等级的 Visible Geometry Type 设好、调 Screen Size 阈值；别直接强制 r.HairStrands.UseCardsInsteadOfStrands——那是不看距离的硬切换，没数据照样黑屏。

8.2 一条专用的流水线

毛发走的是自己的一套流程，入口在 Engine/Source/Runtime/Renderer/Private/HairStrands：

flowchart TD
  subgraph P1["第一步（RenderHairPrePass）"]
    A["按区域分组 AABB"] --> B["体素化（把密度写进 3D 网格）"]
    B --> C["深阴影（沿光线分层记录遮挡）"]
  end
  subgraph P2["第二步（RenderHairBasePass）"]
    D["可见性：算出哪些像素有头发、有多少层"] --> E["按屏幕小块（tile）聚合成清单"]
    E --> F["只给清单里的样本算光照"]
  end
  subgraph P3["第三步（RenderHairComposition）"]
    G["合成回画面（按需要插在半透明前或后）"]
  end
  P1 --> P2 --> P3

两个关键设计：

• 先可见性、再着色：先把"哪个像素有头发、有几层"整理成一份很紧凑的清单，然后只给清单里的东西算光照。这样光的计算量正比于"真正看得见的头发"，而不是"画了多少段"。
• 按小块聚合（tile）：把屏幕切成 8x8 的小块，只挑"里面有头发的块"去处理，没有头发的块直接跳过。这是毛发在大屏幕上还能跑得动的关键。

8.3 光照怎么打

头发和普通物体不一样，它会透光——一大把头发不是一堵黑墙。所以光照分三路：

头发的散射模型（光打到一根头发上往哪散）在源码里以 R / TT / TRT 等分量 + “双重散射"命名，本质是经典头发散射模型加近似，对应参考 8。

8.4 远近与"头发突然冒出来”

• 远处的头发会按"页"流送（一页固定装多少根），加载/卸载的粒度正是"页"。所以不看细节时，一旦发生流送，表现是头发突然出现或突然消失，不是渐显。
• CPU 侧还有两个开关决定"数据用完就扔"和"异步加载"（ReleaseAfterUse / AsyncLoading），它们是在内存和"第一次进场景卡顿"之间做取舍。

8.5 光追与抗锯齿

• 光追：毛发可以参与光追（默认开，且需要资产主动勾选）。两个调优项是"每段拆成几个小包围盒"（拆得越多光追越快、构建越慢）和"光追时把头发半径缩放多少"。
• 抗锯齿：毛发太细，会闪。可见性那一步会额外产出一张"遮罩"和"速度"，交给 TAA/TSR 这套时序抗锯齿去处理，避免边缘闪烁和拖影。

8.6 几个"看起来像 bug"的开关

另有一个"说明和实现不一致"的例子：r.HairStrands.SwapType 的提示写 Default:1，实际默认是 2。遇到这种一律以源码为准。

本章小结：毛发比像素细，所以不走普通画法：先算可见性、按 8x8 小块聚合、只给"有头发的块"着色、最后合成。这个顺序就是它的性能设计——tile 聚合是关键。画法有曲线、发卡、网格三种，缺数据时会什么都不显示。光照分三路（体素间接光、深阴影直射光、LUT 多次散射），因为头发会透光。流送以"页"为粒度，表现是突然出现/消失。光追有两个调优项，细几何的抗锯齿靠可见性产出的遮罩交给 TAA/TSR。

第 9 章 上手：改哪里、会出什么问题、多贵

一句话：同一个效果往往在三个地方都能改，先弄清"改哪里才生效"；再记住成本大致由哪些量相乘决定。

白话导读：这章是给真正动手的人看的"地图"，遇到问题可以直接查表。

9.0 第一次上手：最小路径与最易踩的坑

如果你是第一次接 Groom，按下面 5 步走完，就能看到一个能动的、不出错的毛发（每步对应正文出处）：

1. 导入资产并烘焙绑定：把头发导成 UGroomAsset，并为角色网格烘焙一份 UGroomBindingAsset。不烘焙，首次显示会现算投影、卡一下（6.3 节）。
2. 挂组件：给角色加 UGroomComponent，把资产和绑定填进去（5.1 节）。
3. 确认"三条路"之一成立：开物理求解（IsSimulationEnable），或开 Deformer，或走蒙皮绑定。三条都不满足时毛发会静默停在默认姿态，不报错——这是新手"毛发没反应"的头号原因（5.2 节）。
4. 开模拟后先做重力预载：否则头发会被重力直接拉塌，和美术摆的姿态不一致（3.5 节）。
5. 看效果再按表调：软 / 抖 / 穿模 / 像塑料，分别对应哪个旋钮，见4.4 节的现象对参数表；“改哪里才算数"见下文的参数地图。

最易踩的 5 个坑（都不会报错，靠查条件定位）：

9.1 改哪里才算数（参数地图）

判据：资产是基线；只有"覆盖总开关"打开，组件上的值才会参与；CVar 在最外层统一钳制。

9.2 常见故障：约束 + 触发条件 + 引擎行为

写成"在什么前提下，出现什么条件，引擎会怎样”，方便直接对照：

9.3 成本大概怎么算

求解侧 约等于 头发根数 x 每根切几段 x 迭代次数 x 子步数 x 每秒帧数
渲染侧 约等于 头发段数 x 屏幕占用（涉及的 tile 数）

两侧的瓶颈通常不同：求解吃"头发规模 + 迭代"，渲染吃"屏幕覆盖率"。想加效果时，先判断瓶颈在哪一侧，再决定加曲线/段数（更细）还是加迭代/子步（更稳）。

9.4 出问题先看哪

注意"字段在、但提示与行为不一致 / 存疑"的情况（如 SimulationFrameRate 存在但未被使用、SubSteps 的 “24 fps” 提示无固定步长实现、r.HairStrands.SwapType 提示与默认疑似不一致；以下均基于 UE 5.6 源码观察，需在高版本复核）：这类清单统一汇总在11.2 节，遇到一律以你所用版本的源码和资产为准，别被提示误导。

9.5 界面上的选项逐一说明（附全部面板截图）

GroomAsset 编辑器各面板都藏着性能选项。决定"这套毛发整体贵不贵"的规模类选项（发量、每根段数、控制线数、碰撞网格、求解密度）在 Strands / Interpolation / LOD / Physics(StrandsParameters) ；决定"每帧怎么算得更准更省"的在 Physics（迭代 / 子步 / 约束开关）。 下文按面板逐一说明每个字段，⚠＝影响运行性能（影响不分大小都写入，并给出相对量级：高 / 中 / 低——量级是按 9.3 节 成本模型推导的相对排序，非官方数字）。截图取自 UE 5.6 的 MetaHuman Groom 示例资产。

9.5.1 Strands（发丝渲染）——发量规模类

9.5.2 LOD（细节等级）——算多少 / 画多少

9.5.3 Interpolation（控制线 / 插值）——求解骨架规模

9.5.4 Cards（发卡）

9.5.5 Meshes（网格）

9.5.6 Dataflow（数据流）

9.5.7 Material（材质）

9.5.8 Binding（绑定）

9.5.9 Physics（物理）· 上：求解器与外力

9.5.10 Physics（物理）· 下：约束与求解参数

9.5.11 Preview settings（编辑器预览）——非运行时

调参直觉（更新）：想大幅降本，先在规模类动手——降 Strands Pt/Curve、Interpolation Imported Guides、Physics Strands Size/Density、Collision Grid Dimension，或切 LOD / Cards / Meshes 画法；想每帧更省，动 Physics 的 Sub Steps / Iteration Count / Solve·Project 开关。观感旋钮（刚度、阻尼、摩擦、重力、风、粗细）几乎不省钱。标注"（推断）“的是按计算模型推导、非官方明示的结论；标注”（间接）“的表示通过影响别的东西（如收敛、光栅面积）间接产生成本。截图均取自示例资产，字段默认值随资产不同。

本章小结：同一效果可在资产、组件覆盖、求解器组件、CVar 多处调，“改哪里生效"靠参数地图：资产定基线，覆盖总开关打开后组件值才生效。故障可统一写成"前提 + 触发条件 + 结果”：设置无效来自总开关/字段范围/插值缺失，没反应来自绑定不匹配或三条路都不满足，观感与时间异常来自迭代不足、网格过粗、包围盒过小或帧率变化。成本大致是"求解侧相乘"与"渲染侧相乘”，加效果前先定位瓶颈在哪一侧。

第 10 章 和别的方案比：Groom 与 gFur

一句话：UE Groom 是"真发丝 + 逐根物理求解"的重路线，gFur 是"发壳 + 骨骼级近似"的轻路线；一个追求"动得对"，一个追求"看起来像、还很省"。

白话导读：这章把两条路线并排比。结论先给：它们不是替代关系，而是互补——远景/群体用 gFur，近景/主角用 Groom。下面分设计、性能、工程三块看。

对照对象是市场插件 gFur（GiM，自述 “Shell based fur plugin”，官方支持 UE 5.0~5.4、另有 UE 4.27 版；本地源码在 Source/GFur、Source/GFurEditor、Shaders/Private）10。

10.1 设计对比

10.2 性能对比

读法：Groom 的成本是"多项相乘"（曲线 x 段数 x 迭代 x 子步 x 帧率），gFur 的成本主要压在"几何量"（层数 x 顶点数）。让 gFur 变便宜，第一件事就是减层数；让 Groom 变便宜，要先判断瓶颈在求解侧还是渲染侧（见第 9 章的成本模型）。

10.3 工程与集成对比

10.4 怎么选

设计侧重一句话：gFur 侧重"看起来像"——把钱花在分层观感（壳偏置、噪声、材质光照）上，动态用骨骼级近似换，参数故意做得很少、谁都能接；Groom 侧重"动得对"——把钱花在逐根约束、时间基准、自碰撞和光照/阴影/光追的正确性上，代价是集成复杂、参数面庞大。

本章小结：两条路线的分野在"几何表示"与"动态粒度"：gFur 用发壳 + 骨骼级近似，换来极低的集成与性能成本，代价是无法表达扭转与自碰撞、不参与透光/深阴影/光追、且仅限 Windows 开发（目标平台覆盖 Win64 与主机）；Groom 用真曲线 + 逐根求解，换来物理正确与光照可扩展，代价是成本高、参数面大、集成重。二者互补：gFur 能把 groom 导出给 UE Groom，而 UE 自身也有发卡/网格这类廉价表示（8.1 节），所以"远景发壳、近景曲线"可以并存。

第 11 章 附录

11.1 源码文件索引

11.2 控制台速查

基于 UE 5.6 源码观察、待高版本复核的"字段/提示与行为不一致"情况（以下结论只对当前所见 5.6 成立，不保证高版本仍然如此，作者会在更高版本复核）：FGroomSolverSettings::SimulationFrameRate——字段存在，但全项目搜索仅命中声明与 UHT 反射生成、无业务引用，蓝图亦搜不到，判为"未被使用"；FHairSolverSettings::SubSteps——提示写 “solver calls done at 24 fps”，但源码里没有固定 24fps 步长的实现（求解仍按帧 delta），字段本身有效；r.HairStrands.SwapType——提示写 Default:1，实际默认值疑似为 2，待源码复核。

11.3 参考

• [1]《计算机图形学基础》(Fundamentals of Computer Graphics, 5th ed.)：曲线表示， 1.2 节。
• [2]《计算机图形学基础》：计算机动画， 4.1 节。
• [3] Position Based Dynamics（2007）： 2.1 节 / 4.1 节。
• [4] XPBD: Position-Based Simulation of Compliant Constrained Dynamics（2016）： 2.2 节 / 2.3 节 / 4.3 节。
• [5] There Is More Than One Way to Frame a Curve（1975）： 1.4 节。
• [6] Strands: Interactive Simulation of Thin Solids using Cosserat Models（2002）： 2.5 节 / 3.1 节。
• [7] Discrete Elastic Rods（2008）： 1.2 节 / 2.4 节。
• [8] Light Scattering from Human Hair Fibers（2003）： 8.3 节。
• [9] UE 5.6 引擎源码（HairStrands 插件、渲染器毛发 pass 集、着色器目录）：以文件名 / 类名 / 函数名定位。
• [10] gFur（GiM，Shell based fur plugin，官方支持 UE 5.0~5.4、另有 UE 4.27 版）。