Chaos、WFC 与 FJA 原理与区别笔记

一、概述

项目	Chaos Destruction	WFC（波函数坍塌）	FJA（断裂关节约束）
本质	物理破坏系统	程序化生成算法	物理约束机制
核心对象	Geometry Collection（静态几何体集合）	网格 / 瓦片 / 约束	碎片之间的连接关节
主要用途	静态场景物理破碎、缓存回放	生成可控裂缝、图案、布局	控制碎片何时、如何脱离
引擎绑定	UE5 原生	需自研或插件	Chaos 内部机制
回溯方式	缓存回放 / 插值	Offset 插值（不重跑 WFC）	约束断裂状态决定物理是否激活

二、FJA（断裂关节约束）原理

FJA 是 Chaos 破碎系统中连接碎块、控制断裂时序的核心物理约束机制 ，可以理解为碎块之间的"可断裂关节"。在 Chaos 的 PBD 约束求解器中，对应的实现是 FJointConstraint。

1. 基本概念

在 Geometry Collection 中，碎块并非孤立存在。破碎层级类似于树状结构：包含一个根骨骼，带有构成破裂片段的一个或多个子骨骼，每个子骨骼进而可以包含自己的子骨骼。这些骨骼之间的连接关系，就是通过 FJA 约束来维护的。

2. 核心机制

• 连接碎块：FJA 在相邻碎块之间建立物理约束，使它们在未断裂时表现为一个整体。

• 断裂阈值：每个 FJA 有可配置的断裂条件（线性/角度的力或扭矩阈值）。当外力超过阈值时，约束断裂，碎块脱离并进入自由物理模拟。

• 塑性变形：FJA 支持线性/角度的塑性设置，允许约束在断裂前发生一定程度的永久变形。

• 休眠与唤醒：未断裂的碎块保持休眠（Kinematic），不参与物理求解，从而降低性能开销；断裂后才被唤醒。

3. 在破碎流程中的位置

text

Geometry Collection 创建
        ↓
Fracture Mode 切割碎块
        ↓
FJA 在碎块间建立约束（默认自动生成）
        ↓
运行时：外力作用 → 超过阈值 → FJA 断裂 → 碎块脱离
        ↓
碎块进入自由物理模拟（Chaos 刚体求解）

4. 与 Field System 的关系

Chaos 的 Field System（力场系统）提供对碎裂何时以及如何传播的空间控制 。FJA 则负责物理层面的连接与断裂。两者配合：Field 决定"哪里碎"，FJA 决定"碎块怎么连接和脱离"。

5. 限制

• FJA 是 Chaos 内部机制，主要面向静态 Geometry Collection。

• 不适用于骨骼网格的动态蒙皮场景。

• 断裂阈值和塑性参数需要在编辑器中配置，运行时修改有限。

三、Chaos 原理

1. 数据资产

• Geometry Collection：预切割的静态刚体碎片集合。

• 可从静态网格或骨骼网格创建，但骨骼网格会被烘焙成静态几何体。

• 丢失蒙皮权重、骨骼绑定、动态切割能力。

2. 切割方式

• Voronoi：随机种子点，生成胞元碎块。

• 平面切割：精确平面切分。

• 布尔运算：减去/相交形状。

• 运行时切割：仅限静态几何体，不适用于动态骨骼网格。

3. 物理与动画

• 碎块是刚体，无蒙皮。

• 碎块之间通过 FJA 约束连接，未断裂时保持休眠。

• 可绑定骨骼跟随动画，但一旦开启物理模拟就脱离动画控制。

• 想跟随动画 → 设为 Kinematic → 无物理散开。

• 想物理散开 → 脱离动画 → 碎片不跟随角色运动。

4. 回溯

• 缓存回放：录制物理模拟，运行时倒放或插值。

• 回放的是静态姿态，不能拼合到角色当前动画姿态。

• 性能极低，但内存/带宽占用大。

5. 骨骼网格限制

• 不能运行时切割动态骨骼网格。

• 标准流程：隐藏骨骼网格 → 生成预制 Geometry Collection。

• 碎片不保留蒙皮，不能跟随动画，不能回溯到当前姿态。

四、WFC 原理

1. 核心思想

• 基于约束传播 和最小熵坍塌。

• 每个格子有候选瓦片集合，通过邻居规则逐步消除不可能候选。

• 选择熵最小的格子坍塌，重复直到全部确定。

2. 输入输出

• 输入：瓦片集、连接规则、网格尺寸、随机种子。

• 输出：满足约束的裂缝网络 / 图案 / 布局。

3. 算法内部回溯（Backtracking）

• 当约束传播导致矛盾时，回退到上一个状态，尝试其他候选。

• 这个过程很贵，是 WFC 求解的成本。

• 但只在生成阶段发生，不在游戏回溯阶段。

4. 游戏中的回溯

• 破碎时跑一次 WFC，生成裂缝网络并切割碎片。

• 回溯时不重新跑 WFC ，只对每个碎片的 Offset 做插值。

• 成本极低。

5. 与蒙皮结合

• 在绑定空间切割骨骼网格，保留顶点蒙皮信息。

• 碎片每帧由当前骨骼蒙皮驱动，叠加 Offset。

• 回溯时 Offset 从破碎值衰减到单位变换。

• 碎片拼合到角色当前姿态，而非破碎时旧姿态。

五、三者核心区别

维度	Chaos	WFC	FJA
定位	物理破坏系统	程序化生成算法	物理约束机制
层级	宏观：整个破碎流程	生成阶段：裂缝设计	微观：碎块间的连接控制
输入	静态几何体 / Geometry Collection	瓦片集、约束、种子	碎块间的连接参数、断裂阈值
输出	物理碎块、缓存动画	裂缝网络、图案、布局	断裂决策：何时/如何断开
运行时切割	仅静态几何体	可生成裂缝，需自行切割	不涉及切割
骨骼网格支持	不能动态切割，只能替换	可绑定空间切割，保留蒙皮	不适用于骨骼网格
蒙皮保留	否	是（自行实现）	否
碎片跟随动画	有限（Kinematic）	是（蒙皮驱动）	否
回溯到当前姿态	否	是（Offset 衰减）	否
裂缝可控性	弱（Voronoi 随机）	强（约束规则）	不涉及裂缝生成
变体数量	受预制缓存限制	种子无限	受预制约束限制
内存占用	大（缓存）	小（规则+种子）	小（约束参数）
网络同步	重（变换/缓存）	轻（种子+参数）	重（约束状态）
物理真实	强	无（需结合 Chaos）	强（是 Chaos 的一部分）
回放性能	极低	低（插值）	低（休眠时不参与求解）
适用场景	静态场景物理破碎	可控裂缝、骨骼动态破碎、风格化效果	Chaos 破碎的时序与连接控制

六、三者协作关系

text

┌─────────────────────────────────────────────────────────┐
│                    WFC 生成阶段                          │
│  输入：瓦片集 + 约束规则 + 种子                           │
│  输出：裂缝网络                                          │
│  （内部回溯求解，成本较高，仅执行一次）                     │
└──────────────────────┬──────────────────────────────────┘
                       │ 裂缝网络
                       ▼
┌─────────────────────────────────────────────────────────┐
│                  几何切割阶段                             │
│  静态网格 → 切割为 Geometry Collection                    │
│  骨骼网格 → 绑定空间切割，保留蒙皮信息                     │
└──────────────────────┬──────────────────────────────────┘
                       │ 碎块
                       ▼
┌─────────────────────────────────────────────────────────┐
│              FJA 约束建立阶段                             │
│  在相邻碎块间建立 FJointConstraint                        │
│  设置断裂阈值、塑性参数                                   │
│  未断裂碎块保持 Kinematic 休眠                            │
└──────────────────────┬──────────────────────────────────┘
                       │ 约束就绪
                       ▼
┌─────────────────────────────────────────────────────────┐
│                  物理模拟阶段                             │
│  外力 → 超过阈值 → FJA 断裂 → 碎块脱离                    │
│  碎块进入 Chaos 刚体求解                                  │
│  （或用蒙皮+Offset方案替代骨骼网格场景）                   │
└──────────────────────┬──────────────────────────────────┘
                       │ 散落状态
                       ▼
┌─────────────────────────────────────────────────────────┐
│                   回溯阶段                                │
│  不重新跑 WFC，不重新物理模拟                              │
│  仅对碎片 Offset 插值 → 拼合到当前姿态                    │
└─────────────────────────────────────────────────────────┘

各角色定位：

• WFC：负责"裂缝长什么样"------可控、可复现、无限变体。

• FJA：负责"碎块什么时候断开、怎么断开"------物理连接与断裂时序。

• Chaos：负责"断开后怎么动"------刚体物理、碰撞、缓存回放。

七、结合使用方案

方案一：静态场景破碎

text

WFC 生成裂缝 → Chaos Geometry Collection 切割 → FJA 建立碎块约束 → 物理模拟 → 缓存回放回溯

• WFC 提供可控裂缝，FJA 控制断裂时序，Chaos 负责物理。

方案二：骨骼角色动态破碎

text

WFC 生成裂缝 → 绑定空间切割（保留蒙皮）→ 蒙皮 + Offset 驱动 → 回溯时 Offset 衰减到当前姿态

• 不使用 Chaos 的 FJA，因为碎块需要保留蒙皮跟随动画。

方案三：混合方案

text

静态场景：WFC + Chaos（含 FJA）
骨骼角色：WFC + 蒙皮偏移
统一回溯时间轴控制两者

方案四：网络同步

text

服务器传：WFC 种子 + 参数 + FJA 断裂阈值
客户端本地：生成裂缝 → 建立约束 → 本地物理模拟

• WFC 种子同步带宽极低。

• FJA 阈值参数同步量小。

• 碎片变换不需要逐帧同步。

先拆开两种同步策略

策略 A：服务器权威，客户端只收状态

• 客户端把撞击事件发给服务器。

• 服务器跑 WFC 生成裂缝 → 切割 → 物理模拟。

• 服务器把每个碎片每帧的位置和旋转广播给所有客户端。

这种情况下：

• 用 Chaos 还是 WFC，带宽几乎一样大。

• WFC 只省了服务器"生成裂缝"的计算，但碎片状态照样要传。

• 客户端只是播放，没有本地模拟。

策略 B：客户端本地生成 + 本地物理

• 服务器只广播破碎事件：撞击点、方向、力度、WFC 种子、时间戳。

• 每个客户端本地：

  • 用相同种子跑 WFC，生成相同裂缝。

  • 本地切割，本地物理模拟。

• 服务器不传碎片每帧状态。

• 只在必要时发关键帧校正，或者干脆不校正。

这种情况下：

• 带宽极小（几十字节的事件 + 种子）。

• 但要求客户端物理足够确定性，否则各客户端碎片位置会漂移。

• Chaos 和大多数商业物理引擎不保证跨平台确定性，所以纯靠种子复现物理，实际中很难做到完全一致。

WFC 的非确定性可以彻底解决

WFC 是离散算法 ，不是连续物理模拟。这意味着它可以用工程手段强制确定：

1. 用整数/定点数代替浮点

• 熵值、权重、概率全部用整数表示。

• 避免所有浮点运算。

• 这样跨平台结果完全一致。

2. 用确定性随机数生成器

• 不用 rand()，用自己实现的 PCG、XorShift 等。

• 相同种子 → 相同序列，所有平台一致。

3. 固定执行顺序

• 约束传播、格子选择全部单线程，或固定顺序的确定性并行。

• 不用哈希表遍历，用有序数组或固定索引。

4. 确定性并行

• 如果并行，任务划分和合并顺序必须固定。

• 或者干脆单线程，WFC 网格不大时单线程足够。

做完这四件事，WFC 就是100% 跨平台确定的。

相同种子 → 相同裂缝网络 → 所有客户端完全一致。

---

Chaos 为什么做不到

Chaos 是连续物理模拟，它的非确定性来自：

1. 浮点运算：物理引擎大量使用浮点，跨平台精度差异不可避免。

2. 多线程求解：接触点、约束求解顺序不可控。

3. 迭代求解：有限迭代留下残余力，误差累积。

4. 混沌系统：微小误差指数级放大。

这些是物理引擎的本质特性 ，不是工程实现问题。

你无法通过"改用整数"或"固定顺序"来解决，因为：

• 物理需要浮点精度。

• 物理需要多线程性能。

• 物理系统本身就是混沌的。

所以：

Chaos 的非确定性无法根除，只能靠同步状态来规避。

chaos修改工程代价极高：为什么"改源码"不是理想方案

尽管技术上可行，但修改Chaos源码来追求确定性，是一个代价高昂且风险巨大的选择。

1. 巨大的维护成本 ：这是最核心的问题。一旦修改了引擎源码，就相当于永久性地维护了一个"引擎分支" 。每次Epic发布新版本（如从UE 5.5升级到5.6），你都需要手动合并你的修改 ，解决大量的编译冲突，并进行广泛的回归测试 ，以确保你的改动没有引入新的Bug或性能倒退。有开发者估计，这项工作大约需要一名全职工程师来负责。

2. 无法根治的浮点运算差异 ：即使你修改了物理求解器，游戏中的其他系统（如角色移动组件 CharacterMovement）依然使用硬件浮点运算 ，其在不同机器上的结果依然可能不一致。要彻底解决，可能需要在整个引擎层面 强制使用严格的浮点模型（fp:strict），但这会对性能产生严重影响，且实施难度极大。

3. 潜在的物理行为改变 ：修改底层的求解器逻辑（例如迭代次数、约束排序方式）可能会改变物理模拟的最终表现，导致原本调试好的破碎效果或物理交互出现偏差。

4. 性能与确定性的权衡 ：开启确定性的代价是牺牲性能。例如，为了确定性而对约束进行排序，会带来额外的CPU开销。在高性能需求的游戏场景中，这个代价可能无法接受。

八、一句话总结

WFC 是"裂缝生成器"，FJA 是"断裂开关"，Chaos 是"物理引擎"。

WFC 决定碎成什么样------裂缝可控、变体无限、带宽极低。

FJA 决定碎块之间怎么连、什么时候断------是 Chaos 内部维持碎块连接的物理约束机制。

Chaos 决定断开后怎么动------刚体物理真实，但绑定静态几何体，不支持动态骨骼蒙皮。

三者各司其职：WFC 生成裂缝，FJA 控制连接，Chaos 模拟物理