自由学习记录（230）

默认情况下,root 不跟着绑定走。官方原话:"root joints are not linked to the rig ... if you try to move the rig, the root will remain in the same place"(root joint 没有连在 rig 上,移动 rig 时 root 留在原地)。所以默认情况下你在 Cascadeur 里移动角色(包括质心 COM 带动的身体),不会产生 root 的位移,root motion 导出的就是不动。

复制代码

Receiver：新增完整 mannequin
   ├─ 独立 RigInfo、COM
   └─ 独立 AutoPosing

Joint type（Joint Extra Attributes）

在 Joint Extra Attributes（关节额外属性）行为里：

作用是定义关节在导出时的类型。
选项只有三个：Root （根）、Limb （肢体）、LimbNode （肢体节点）。默认是 LimbNode。
官方原话：In most 3d software (like Maya or Blender) this parameter is ignored, but some programs - such as Daz Studio - make use of it. In Daz in particular, the root Joint should have its Joint type set to Root, while every other Joint should be a LimbNode.

用户该怎么对待 ：

普通工作流（Blender / Maya / Unity / Unreal）直接忽略，保持默认 LimbNode 就行。只有明确要导出到 Daz Studio 这类会读取这个字段的软件时，才需要把根关节改成 Root，其余改成 LimbNode。⁠Cascadeur

Box size multiplier 只是创建时的初始倍率，生成 rig 之后（包括在普通场景/动画模式下）仍然可以随时改大小。

官方文档写得很清楚：选中区间后点 Create cycle（或带 offset 的版本），时间轴上会立刻出现一圈边框，边框颜色代表循环类型：

亮紫色（bright purple）：普通循环（原地重复）
深紫色：带位置+旋转偏移的循环（角色会继续向前走+转向）
橙色（orange）：只带位置偏移的循环

这些是边框颜色，不是帧内部的填充色。

不计算连续的力波形，也不区分冲击峰和主动峰，也不考虑软组织缓冲。

开发团队在博客里也明确写过早期实现："工具只考虑区间第一帧和最后一帧的 COM 位置，以及区间长度。这些数据就足够算出 ballistic 曲线。然后把角色每一帧整体移动，让 COM 沿着这条曲线走。"后来改进成独立的 ballistic 对象，方便你调 Impulse Point、高度点和落点，再 snap。⁠Cascadeur

Snap centers of mass to selected trajectory

官方 Point Constraint 明确要求普通 Point Controller

因为 Unreal 的反射系统（Property System）把属性提升成了"一等公民"，而不是传统面向对象设计里单纯的数据字段。 ⁠Michaelnoland

传统观点里，属性（数据）确实是行为（方法）的子属性------类的方法才是主体，数据只是方法操作的对象。但在 UE 中，这个关系被反转了：引擎需要一套统一的、数据驱动的机制，让编辑器、序列化、垃圾回收（Garbage Collection, GC）、网络复制（replication）、蓝图（Blueprint）等系统都能自动感知并操作这些字段，而不用开发者手写大量样板代码。⁠Michaelnoland

当你写：
C++

复制代码

UPROPERTY(EditAnywhere, BlueprintReadWrite, Replicated)
float Health;

Unreal Header Tool（UHT，虚幻头文件工具）会在编译期解析这个宏，生成额外代码，给这个属性挂上以下行为：⁠Unrealengine

垃圾回收（GC）：引擎会跟踪这个属性引用的 UObject，防止提前释放。
序列化（Serialization）：保存/加载关卡、资产时自动读写这个值。
网络复制（Replication）：加上 Replicated 后，服务器改值会自动同步到客户端。
编辑器行为：在 Details 面板显示可编辑控件，支持 EditCondition、AdvancedDisplay 等元数据控制显隐。
蓝图访问：生成对应的 Get/Set 节点；如果指定了 BlueprintGetter / BlueprintSetter，还会绑定自定义函数，让属性本身就带有逻辑。

这些行为对开发者是"隐藏"的------你只声明了数据，UHT 在 .generated.h 和 .gen.cpp 里把行为补齐了。开发者社区（Epic 论坛、Unreal Community Wiki、知乎 UE 源码分析）普遍认为，这是 UE 能同时支持 C++ 和蓝图、又能保持编辑器实时预览的核心原因。

UE 提取 root motion 时不一定严格只看 root bone 的位移。很多情况下它会结合 pelvis 或其他骨骼的运动来计算（尤其是 Humanoid / 特定 skeleton 设置下）。

你自己导入一个普通角色（没有自带这个约束），再用 Rig 控制器移动它，就会出现 root 留在原地、身体走出去的情况。Manny 因为已经绑好了

用分层保护 Base Pose

把打磨好的 Base Pose 单独放在一个层上锁住。再在上面加 breathing cycle（呼吸循环）

start 和 end 都回到同一个 Base Pose，方便引擎随机播放。

在生物力学和动画领域，有个相关但更精确的概念叫 leading joint hypothesis（leading joint hypothesis，LJH） 。Natalia Dounskaia 等人的研究指出，多关节肢体运动中，通常有一个"leading joint"（常是近端关节，如肩或髋）通过主动发力产生交互力矩（interaction torques），驱动远端关节的运动；远端关节更多是"被动跟随"。这简化了中枢神经系统的控制策略，也解释了为什么自然动作看起来协调而有重量感。⁠Pmc.ncbi.nlm.nih

日常伸手、投掷等任务中，肩关节常作为 leading joint，交互力矩对肘关节的影响远大于反向。

鸟类磁罗盘:是倾角罗盘,不读极性,靠眼睛里的隐花色素自由基对,需要短波光。

僵尸蚂蚁 Hughes 2011:被真菌操纵的蚂蚁在正午前后咬住叶脉,死在约 25 cm 高的孢子适宜带。

Go to Box Controller mode → Select every Box → Commands → Go to T-pose 。⁠Cascadeur

选中全部（包括 pelvis / root 那层 Box）时，角色会跳回场景原点（origin），

Go to Bind Pose ：主要针对选中的 Joint（骨骼），把当前帧的关节重置到 bind pose。

Transform > Go to Model Pose：把当前帧设成模型的默认 pose（无动画数据时的状态）。有时比 T-pose 更贴合 UE5 Manny 样本的原始外观。

独立使用 Collision Penetration Cleaning 时

单独点工具栏的 Collision Penetration Cleaning 按钮时：

需要先选 Interval，它会找最深穿透的帧，然后在整个选中 Interval 上按距离衰减应用修正，最后做 Blending（默认 Bezier，窗口大小 5 帧）。
这时是直接改 Interval 内容的，不是只改关键帧。

但在 AutoPhysics 平衡流程里，它是作为 filter 被调用的，所以跟着 Snap 的"只改关键帧 / 全帧"选择走。

AIBA 最常见且最著名的含义是 Association Internationale de Boxe Amateur （法语，国际业余拳击协会，International Amateur Boxing Association），后来更名为 International Boxing Association（国际拳击协会）。

Point Controllers 和 Box Controllers ：最推荐用来跨文件复制姿势。它们保存了 local transform 数据，在 Local 模式下复制粘贴最稳定可靠。⁠Cascadeur

AutoPosing（Au-to-PO-sing）：只能在 Global 模式下可靠复制。Local 模式会错位，因为 AutoPosing 控制器不存储相对父级的 local 数据。

变通方法：开启 Local + Relative to pivot （相对枢轴），选中控制器后再选一个父级控制器作为 pivot（手用肘，臂用肩），按 Alt + 右键设 pivot，再复制粘贴。⁠Cascadeur

部/手指姿势：社区普遍推荐用 Box Controllers + Local 模式，效果最好。

Retargeting（Retargeting Copy / Paste，

**播放内存：**如果整首解压，按 16 bit PCM 计算约 28.6 MiB ，按 32 bit 浮点采样计算约 57.1 MiB。这是数据量估算，实际 Unity 内存还取决于加载方式和内部缓冲。
**播放 CPU：**压缩音频需要解码。流式播放会边读边解码，降低整首常驻内存的需求，同时增加持续解码和读取工作。

原始 FLAC
└ 转成 Unity 支持的 WAV 源资源
└ Unity 导入设置
├ Compression Format：Vorbis
├ Load Type：Streaming
├ Load In Background：开启
└ 保留双声道，先保持 48 kHz

长 BGM、环境音、大量音源的开放世界短--中时长、需要零延迟、或内存充裕且不希望 I/O 的情况

相同或相近码率下，Vorbis 通常不输 MP3，低码率时往往更好（尤其是高频和瞬态）。社区和盲测里常见说法是：Vorbis 128 kbps 左右可以接近或优于 MP3 160--192 kbps 的听感。

MP3 的主要专利在 2017 年左右到期

这些值一直同时可见、可编辑。改其中一个，另一个会根据父级变换自动对应更新，但面板不会把"显示内容"从一套换成另一套。⁠Cascadeur

在 Object Properties → Transform 行为里，Global 和 Local 是两套独立、同时存在的属性，不会因为工具栏开关而整套切换显示：

Global position
Local position
Global rotation
Local rotation
Local scale

Cascadeur 的 Point Controller （角色动画里最常用的控制点）主要存储的是 Global Position。官方 Graph Editor 文档写得很清楚：

each point controller stores only its global position; the rotation is calculated from the positions of 3 point controllers that control the bone, and the scale is not stored at all.⁠Cascadeur

Local Position 往往是从 Global + Parent Matrix 推算出来的，或者反过来（取决于当前是 IK 还是 FK）：

Joint / Mesh 等完整 Transform 对象有真正独立的 Global rotation / Local rotation，而 Point Controller 的旋转是由三个点位置推算出来的，没有独立存储。

传统 Forward / Deferred 路径下，Unity 对一个 Renderer（包括整块 Terrain）最多只选少数几个 Reflection Probe（历史上常提到每物体最多 2 个）

分别测试了地形 LOD、实例化、阴影、地表视差和法线贴图，都没有消除这条线；只关闭生成地面对局部反射探针的选择，分界就消失了。

水面和建筑仍保留自己的局部反射

河流仍有偏窄、偏陡、局部转弯偏紧的问题。

https://alvagranholm.artstation.com/projects/zDWrmd

雪控制器原来每秒给约 30 块地形重新上传整套材质资源，即使资源完全没变；这批操作实测约 19.9 毫秒 ，另外每帧搜索地形约 0.87 毫秒。

性能结果分开看：

项目	修改前／问题	本轮验证结果
世界准备	冷生成约 33.8 秒	两次缓存启动约 2.09、2.16 秒
画面出现后的 `GameLoad` 卡顿	约 10.65 秒	约 2.26 秒
草甸重建	曾出现单帧约 1 秒	分帧处理，实测最大一次约 25.5ms
稳定 Game 帧率	Scene 与 Game 同时持续绘制	240 帧平均 11.50ms，约 87 FPS
进入 Play 的编辑器过程	约 10 秒	仍约 9.8 秒，其中重载约 6.8 秒

帧率提升的一个主要原因是暂停了后台 Scene 视图的持续重绘，没有降低游戏画质。入口是：

Tools → Performance → Pause Background Scene View During Play

草地、泥土、石头的高清贴图不需要每块重复保存。 每块只保存"这里混合哪几层、各占多少"，共同引用同一套材质和贴图。

还要另外计算水面网格、物体摆放记录、碰撞相关数据、文件结构等。不过项目里已经有两个真实文件，可以直接看量级：

武器轨迹+手约束，AutoPosing 摆不了道具链。

非人形/尾巴，FAQ 写明非人形只能走 Point。

原始 PCG 相邻块的高度和地表权重是连续的；我加的草甸局部覆盖用了另一套采样坐标，导致同一条边两侧的草地权重最大相差约 96%。它还把"局部换外观"做成了"替换整块地形的一层纹理"，扩大了影响范围。这两处是我之前实现的问题。

用 Copy Tools 的 Moving → Fixed Pivot 。以第 5 帧左脚的位置 为准，对齐第 5～10 帧；这段范围内各帧保留自己的姿势，整体平移。

切到 Point Controller 模式，选中这个人物的全部点控制器。
顶栏坐标选 Global ，开启旁边的 R（Relative to pivot）。
按住 Alt＋鼠标右键 ，点击左脚作为支撑的那个点。两帧必须使用同一个点；想对齐脚底接触位置，就选对应脚底点，不要改选脚踝。
打开 Settings → Copier ，把 Mode 设为 Relative ，Pivot 设为 Moving。
时间轴选中 5～10 帧区间 ，按 Ctrl＋Shift＋C（Copy Interval）。
保持人物选择和时间区间，把当前播放帧放在 第 5 帧 ；将 Copier 的 Pivot 改为 Fixed。
按 Ctrl＋Shift＋V（Paste Interval）。

这里用的是 Paste Interval ，不要按 Ctrl＋Alt＋V，后者会把单个姿态铺进区间。

官方明确给出了"相对运动 Pivot 复制、相对当前帧固定 Pivot 粘贴"的用法；以上是据此整理的操作，尚未在你当前文件里实测 。Copy Tools 官方说明

启动缓存共约 27.4 MiB，包括 25 块详细地形的高度、地表、水面及起始远景。输入变化会使缓存失效，统一重建入口是：

Tools → World Exploration → Bake Starting World Caches

大地图每次关闭都会销毁底图，下一次打开才重新开始生成，并没有复用已准备的数据。

别按世界/父级拷，按我指定的那个点当原点拷」

角色披风的 KayKitCapeCloth.LateUpdate() 单帧耗时约 55--70ms ；同一批帧中，近景生成约 2.1--3.2ms，远景约 2ms。*披风曾独占 55--70 毫秒 ，现已改为 Burst 求解，采样约 1.9 毫秒

进入 Play 后，技能预览窗口仍在后台模拟和绘制，采样中占了约 40 毫秒。现在让它在 Play 期间暂停、退出后恢复预览，再复测高速移动；这样才能区分游戏本身的开销和编辑器预览的开销。

披风保留原来的顶点数、约束次数和碰撞规则，改用项目已有的 Burst 执行同一套顺序计算；

默认视角下，GPU 平均约 2.2 毫秒 ，CPU 约 21.5 毫秒，等待画面提交的时间几乎为零。这一轮主要卡在 CPU，不能归因于显卡算力不足。

`FollowPlayer.Update()` 在没有滚轮输入时也做整套 UI 射线检测，占约 3.3 毫秒 ；路线规划约 2.1 毫秒 ；雪系统定期重新扫描场景，单次约 4.3 毫秒。先处理这些已经测到的重复工作。闭包并不是提速开关，项目里已经用了闭包和 LINQ

Game 窗口的 VSync 当前关闭，显示器是 165 Hz，80 FPS 没有被一个 60 FPS 上限挡住。

12.5 毫秒的 80 FPS 预算

没有工具命令干扰的 391 帧 中，游戏主线程工作平均 11.67 毫秒 ，Editor 与其他开销平均 2.90 毫秒 ，GPU 平均 2.13 毫秒。

一项很具体的浪费：技能面板和武器商店都已完全透明、处于关闭状态，但两个 RectMask2D 仍在每帧做裁剪，采样约 0.75 毫秒。我会在关闭动画结束后停掉这部分裁剪，打开前恢复，保持面板数据、交互逻辑和显示效果不变。

草缓存第一次实测：同样 10,423 株、56 批绘制 ，准备阶段累计 CPU 时间从约 702 ms 降到 42 ms。但仍有约 20 ms 的地表准备工作，而且最大单次切片没有改善

关闭 R（Relative to pivot），然后重新复制。左上角显示 Global，但 R 开着，不能据此认定正在复制绝对世界位置。 官方单独说明了 R 会让位置按 Pivot 计算

瞄准时使用 Box Sweep 检查路径。
确定目标位置，检查角色是否有足够空间。
松开按钮后切换移动状态。
角色以约 100m/s 的速度快速移动，内部每次移动最多 0.5m。
到达目标后恢复之前的速度，并检查是否需要攀爬。

视觉方面则有：

Radial Blur（径向模糊）
Tunnel Vignette（隧道暗角）
Peripheral Distortion（外围画面扭曲）
FOV 变化
色彩分离
手部金色发光和烟雾

特别注意：这里的 100m/s 等细节来自第三方逆向复现，不是 Arkane 公布的原始游戏源码。Kirikirin

Overwatch 首席工程师 Tim Ford 曾表示，他们对 Teleportation 非常谨慎，因为瞬移能力容易引起漏洞和利用问题。Reaper 在游戏初期就给他们带来了不少麻烦。

他甚至提到，Moira 并不真正瞬移，她是先隐身再移动。Gadgets 360

4. Elden Ring：隐身高速移动 + 无敌帧

peakd.com

Bloodhound's Step（猎犬步法）。

这个动作看起来非常像瞬移，但核心是：

高速向指定方向移动。
移动期间暂时隐身。
拥有独立的无敌帧。
可以在锁定目标时绕行。

SCHOpenhauer 说过一句很狠的话：

"WHEN we READ, aNOther PERson THINKS for US: we MEREly rePEAT his MENtal PROcess."

「阅读时，是另一个人在替我们思考；我们只是重复他的思考过程。」

出自〈On READING and BOOKS〉。他当时批评的是读书：人可以不断读别人的想法，却很少自己想。把"书"换成 AI，这个一百多年前的争论居然又回来了。

JOHN DEWey 在《deMOCRacy and eduCAtion》里换了个角度：

"WHEN it is TOLD, it is, to the ONE to WHOM it is TOLD, aNOther GIVen FACT, NOT an iDEa."

「一个想法被讲给别人时，对听的人来说，它又变成了一个被告知的事实，而不是一个想法。」

他接着说，讲解既可能激起对方的思考，也可能压灭刚刚萌生的思考。

值得注意的细节：官方 Outliner 截图中，auto_posing (0) 的 Type 显示为 Tool。也就是说，Tool 本身也是一种可以存在于 Scene 中、被 Outliner 管理的对象，而不只是顶部 Toolbar 上的按钮。Total lines: 0 / Total lines: 0 / Outliner

特别注意：Outliner types 只控制 Outliner 中的显示，不等于隐藏 Viewport 中的对象。Viewport 的显示由另外的 Visible 功能控制。Outliner / Glossary

动画师 GLEN KEANE 讲过一件事，我觉得和你说的距离很接近。

他在迪士尼工作时，白天经常被会议和其他事情打断，有时只有午休一小时能连续画。他会拿粗铅笔飞快地把整场戏画下来，叫它 SCRIBble TEST，大概是"涂鸦测试"。

"I DASH through the SCENE and ROUGH it OUT in what I CALL a SCRIBble TEST."

「我飞快地画完整场戏，用我称为'涂鸦测试'的方式把它粗略画出来。」

1990 年访谈原文

那些画在别人眼里可能只是一堆乱线，但他自己能从里面认出想要的表演感觉。之后他才把画整理清楚，让助手能画中间帧。

多年后谈到画画的工具，他又说过一句："LET me DRAW."「让我画。」他不喜欢笔尖和内心想表达的东西之间被塞进太多复杂步骤。不过他也说自己喜欢计算机动画，所以他针对的不是电脑本身，而是那些挡在表达前面的操作。访谈原文

这套设计背后的概念

Cascadeur 把 Scene Object 看成一组 Behaviors 的集合。

Basic：对象的基础显示、选择属性。

AutoPosing Link：与 AutoPosing 控制器的关联信息。

飞行组件是在角色生成后才添加的，而空中攻击组件只在 Awake 时查找一次飞行组件，因此保存的是空引用。结果是角色已经飞起来了，攻击组件仍判断"没有跳跃，也没有飞行"，左键在入口就被拦住。

大致估计了脚的位置（ballparking my foot placement）

第二阶段：统一解决整段动画的前进距离

具体这样做：

切换到 Side View。
选中角色的全部 Points。
进入 Interval Edit Mode。
选择 Linear Modification。
开启 Ghost，并设置为 Every Frame。
开启 Wireframe。
沿前进方向整体移动动画区间。

他的观察目标是：

让不同 Ghost Frame 中的脚部位置产生合理的重叠关系。

将 Frame 20 的脚部姿势复制到 Frame 19，让脚提前一帧进入稳定接触。

一个重要区别：

之前是确定整个角色每个周期前进多少；现在是确定脚在接触地面期间应该如何保持位置。

还有一个很有价值的技术：Global Relative

视频 54:00--57:35

他在复制另一条腿的动画时遇到了一个问题：

角色已经在世界空间中移动了，直接拖动 IK Key，会导致脚部试图返回原来的 World Position。

于是他尝试 FK，结果也不理想，因为 Hip 的旋转会影响腿部复制结果。

最后采用：

Global Relative + Copy Interval + Paste Interval

具体来说：

选择需要复制的腿部动画区间。
将复制参照点设在腿部上方的 Hip 位置。
选择 Global Relative。
Copy Interval。
到新的时间区间 Paste Interval。

这样复制的是相对于参照点的世界位置偏移，而不是原来的绝对世界坐标，也不会把 Hip 的旋转方向带进来。

他的工作流实际上是把三个问题拆开：

工作阶段	解决的问题
Pose Blocking	身体、四肢应该摆成什么姿势
Interval Translation	整个周期应该向前移动多少
Foot Plant Refinement	脚落地时如何保持接触

Unity 脚本和吹雪 Shader 无报错；草地区域测试为 0 个雪团，雪坡测试为 82 个；重置能复现，停止预览会释放模拟资源。约 80 个雪团的单步 CPU 更新测得约 0.14--0.17 ms，

复制代码

可交互积雪区域：长期保存
├ 世界中的位置与范围
├ 轮廓、边缘过渡、雪厚
└ 流动与踩踏参数
   ↓ 与当前已加载地形求交
贴坡雪层 Mesh：自动生成
├ 跨两个 chunk → 生成对应的两部分
├ chunk 卸载 → 回收对应部分
└ chunk 重建 → 按同一份区域定义重新贴合

这里还有两个不能靠"自动生成"一笔带过的问题：

问题	应怎样处理
两个 chunk 的雪层接缝	接缝顶点使用一致的世界坐标采样和边界高度；流动、踩踏也读取同一坐标下的数据，不能各自重置 UV
雪层与 Terrain 的细节层次不同	近处雪层需要足够密的网格；切换远近细节时处理好贴合与淡出，不能靠统一抬高几厘米遮住裂缝

最终的 1080p 独立开发版离屏渲染测试如下。60 FPS 对应每帧约 16.7 ms：

路线	平均帧时间	99% 帧不超过	最慢一帧
普通移动，90 秒／360 米	5.70 ms	10.67 ms	46.80 ms
65 m/s 直线飞行，约 1.3 公里	8.57 ms	13.99 ms	16.90 ms
65 m/s 急转弯，约 1.3 公里	10.88 ms	14.70 ms	21.95 ms

构建后编辑器预览未恢复水面 Renderer、导致下一次 Play 初始化失败的问题。最后一次暖启动的世界准备阶段约 1.70 秒 ；退出 Play 后，编辑预览约 0.66 秒复用缓存。

Cycle 的工作方式：

选择一个包含 Keyframe 的时间区间。
点击 Create Cycle。
首尾帧会被合并，形成循环衔接。
拖动 Cycle 的边界，扩大循环覆盖的时间范围。
后续修改有效循环区间，其他重复区间会同步反映修改。

目的	操作
复制选中的 Keyframe	按住 `Shift` + 鼠标中键拖动
移动选中的 Keyframe	鼠标中键拖动
复制整段角色动画数据	`Ctrl + Shift + C`，粘贴 `Ctrl + Shift + V`
复制时间轴区间的 Keyframe / Interpolation	`Edit → Copy Timeline Interval`，再 Paste Timeline Interval

Copy Timeline Interval：复制时间轴上的帧与插值结构，不等同于复制 Controller 的姿势数据。

如果你想要传统的复制、粘贴流程：

Edit → Copy Timeline Interval
选择目标时间区间。
Edit → Paste Timeline Interval

注意：这两个操作复制的是 Timeline 的帧序列和 Interpolation（插值）结构，不是完整的角色姿势数据。Keyframes / Edit Menu

复制代码

InteractiveSnow_CrossChunkSlope（保存到场景）
├ 雪区轮廓、雪厚、踩踏深度、流动参数
└ 根据当前加载地形生成
   ├ chunk A 的贴地雪层
   └ chunk B 的贴地雪层
      卸载时回收，重新加载时重建

底层 Terrain 的高度和碰撞没有修改。原来的"幽灵雪团"已移除，废弃文件移到 E:\CodexTrashCan。流动改为雪层自身的纹理与小幅起伏沿坡移动，脚印仍按固定世界坐标采样。

野猪确实生成了，但 FBX 导出单位与 Unity 蒙皮包围盒不一致，安装时又按错误尺寸缩放，导致实际模型缩小了约 100 倍。只检查对象、碰撞体和 Renderer 包围盒会漏掉这个问题。

视频讲的是旧版识别逻辑：

Collision Radius
Max Speed

2025.2 开始，Cascadeur 引入新的 Custom Logic Fulcrum Point 算法，默认启用。2026.2.3 的默认工作流应该优先检查新算法的参数。Custom Logic Fulcrum Point / Fulcrum Points

一词族里：

apPEND：附加，比如在文件末尾追加内容。
apPENDage：附属部分；在解剖语境里可以指从身体主体伸出去的肢体。
appenDICular：与这些附属部分有关的。

骨骼分类把头、脊柱和胸廓看成身体的「轴」，叫 AXial SKELeton ，中轴骨骼；从轴连接出去的四肢，以及连接它们的肩带、骨盆带，合称 appenDICular SKELeton，附肢骨骼。

攻击距离边缘反复切换的原因，是原来稍微越界就立即清掉攻击计时、恢复追击。现在加入距离缓冲，并保留已经开始的攻击节拍。以 5 米射程为例：

情况	当前行为
正在追击	接近到 4.65 米以内再停下攻击
已经站定攻击	允许距离小幅波动，超过 5.35 米才需要追击
出手后敌人跑远	不反复重播起手；命中时检查距离，超出容差则不结算伤害，当前节拍结束后追击

用实际攻击方法做了隔离复现：目标在 4.95～5.05 米之间交替 300 帧，没有一次切回追击

arRANGEMENT 是「编曲」或「改编后的版本」；arRANGE 是动词，arRANGer 是编曲者。

在音乐视频或演出说明里经常看到：

arRANGEd by...：由某人编曲或改编。
piANo arRANGEMENT：钢琴改编版。原曲可能是管弦乐、流行歌，或者其他乐器的作品。
SOlo piANo arRANGEMENT：改编成钢琴独奏版。
an arRANGEMENT for piANo and STRINGS：为钢琴和弦乐编配的版本。

声部（Voices），再把这些声部分配给不同的乐器（Instruments）

一个 Keyframe，不容易判断它与相邻 Keyframe 的运动关系。

阶段 A：Blocking

Apply on selected interval 是一个修改作用范围的开关（Edit Scope），不是临时修改层，也不是可以随时撤销的事务。

例如，你选中了 Frame 10--20：

切换到 Apply on selected interval。
将某个 Object Property 从 False 改成 True。
这个修改会应用到所选范围内的帧。
切回 Apply on current frame。
之前已经写入的 True 不会消失，之后的修改才重新限制在 Current Frame。

所以要区分两个东西：

编辑模式状态：红框，控制接下来修改的作用范围。
已经写入的 Property 值：动画数据，不会因为退出编辑模式而自动撤销。

Ctrl + Click Track 的作用是将当前 Track 加入多选（Multi-selection），而不是合并 Track，也不会直接修改动画数据。

还有一个很重要的联动行为：

如果你已经在 Track A 上选中了一个 Timeline Interval，再按住 Ctrl 点击 Track B，Cascadeur 会在 Track B 上选中相同的 Interval。

不是 Maya 那种一个属性对应一条 Channel。一个 Track 可以容纳多个对象，而在 Track 上打 Key，会记录其中对象的全部可 Keyable 属性。

Ctrl + Right-click（Ctrl + 右键点击）某一帧：在所有 Animation Tracks 上，同时选中相同帧号的位置。

Track 决定对象属于哪个组，Edit Mode 决定这次允许选择哪些类型。

另外，Edit Mode 的 Selectable Menu 可以自定义，所以它不完全是固定的七种过滤规则。右键 Toolbar 下方的 Edit Mode 指示器即可找到。Edit Modes / Animation Tracks

普通 FK：

肩膀旋转。
手臂继承肩膀的旋转。
手臂的运动轨迹随父级变化。

Global Forward：

肩膀旋转。
手臂不继承这种父级旋转。
保留自身的全局旋转运动趋势。

它适合躯干调整不应该破坏手臂运动轨迹的情况。

不同软件的区别在哪里？

拿你使用过的几个软件对照：

软件	IK 的主要使用方式	特点
Blender	IK Constraint	指定末端 Target、Pole Target、Chain Length
Unity	Two Bone IK Constraint	指定 Root、Mid、Tip、Target、Hint
Unreal Engine	Two Bone IK、Full Body IK	从单条肢体到全身多目标求解
Cascadeur	Timeline 上的 IK Kinematics	控制动画插值期间，运动影响如何沿骨骼层级传递

官方资料可以验证这些差异：

Blender：可以设置迭代次数、骨骼链长度、Pole Target 和 Stretch。Blender 5.0 Manual
Unity：Two Bone IK 把原本的 FK 骨骼链转换成由 Target 控制的 IK 链。1.0.3
Unreal Engine：Full Body IK 使用 Position Based IK 框架，允许多个 Effectors 同时影响身体，并给各个骨骼设置 Stiffness 和 Preferred Angles。Control Rig Full-Body IK in Unreal Engine | Unreal Engine 5.9 Documentation / Full Body IK | Unreal Engine 5.8 Documentation

Cascadeur 有一个特别值得注意的区别

它的 Timeline 上的 IK/FK，并不完全等同于其他软件里常见的 IK Constraint。

Cascadeur 把 Kinematics 作为动画插值的一个属性：

IK：从骨骼链底部向顶部传递影响。
FK：从骨骼链顶部向底部传递影响。
GR：Global Rotation，第三种运动传递方式，避免普通 FK 中父级旋转对肢体造成的继承影响。

尤其是 IK Keyframe：它固定对应 Rig Elements 的 Global Coordinates；FK Keyframe 则采用相对于父级的 Local Coordinates。

这也是为什么 Cascadeur 可以把 IK/FK 设置在 Interval 上，而不是只能给某个控制器添加 IK Constraint。Kinematics in Cascadeur / Interpolation

FABRIK ：FORward And BACKward Reaching InVERSE KineMATics，前向与后向迭代的反向运动学。

假设骨链是「肩 → 肘 → 腕 → 手」，目标是让手碰到门把手：

先把手的位置放到目标处，从手往肩依次调整关节位置，保持每段骨骼长度。
这时肩可能被带离原位，于是把肩放回原处，再从肩往手依次调整关节。
手可能又偏离目标，于是重复这两遍，直到足够近或达到迭代上限。
根据得到的新关节位置，更新骨骼旋转。

CCD ：CYclic COordinate Descent，循环坐标下降。

先转动靠近手的一个关节，让「该关节到手」的方向朝目标靠近。
更新它后面的骨骼，再处理下一个关节，比如从腕到肘、再到肩附近。
扫完整条链后，如果手还不够靠近，就再扫一遍。

可以把区别记成：FABRIK 先反复调整关节位置；CCD 每次旋转一个关节。 两者都不是只算一次就必然到达，也不会因为手碰到目标就自动保证姿势好看。初始姿势、关节限制、目标位置和迭代次数都会影响结果。

没有固定倍数，主要取决于 IK（Inverse Kinematics，反向运动学）使用什么 Solver。

如果把同一条骨骼链的 FK（Forward Kinematics，正向运动学）计算量定义为 1×，可以用下面的工程估算：

算法	相对 FK 计算量（粗略估算）
FK	1×
Analytic Two-Bone IK	2--5×
CCD IK	5--15×
FABRIK	5--20×

这些是同一条骨链上的粗略工作量比较，不是统一硬件上的实测基准。

学术证据：两者都有明确的论文历史

CCD：1991 年

Li-Chun Tommy Wang、C.C. Chen：

A Combined Optimization Method for Solving the Inverse Kinematics Problems of Mechanical Manipulators

发表在 IEEE Transactions on Robotics and Automation，7(4)，489--499 页。

DOI: 10.1109/70.86079
doi.org/10.1109/70.86079

FABRIK：2011 年

Andreas Aristidou、Joan Lasenby：

FABRIK: A Fast, Iterative Solver for the Inverse Kinematics Problem

发表在 Graphical Models，73(5)，243--260 页。

DOI: 10.1016/j.gmod.2011.05.003
www.andreasaristidou.com/publications/papers/FABRIK.pdf