这个视频展示了问题的样子。两个独立的问题，同样的根源。 问题1：结果漂移。 选择一个范围内的晚期参考帧，向后快进，范围的开始部分会完全脱离——不是轻微偏差，脱离。标准工具没有独立的参考帧。它始终从 Frames[0] 中计算 keep-offset，因此要使帧100成为参考帧，只有一个方法：写范围为 100 → 0。然后它反转帧数组并从后向前遍历，评估和写入键值：评估100 → 读取控制 → 写入键值100 评估99 → 读取控制 → 写入键值99 当它评估99时，键值100已经被修改。新键值的插值、控制装置输出以及产生的姿势都反馈到下一次评估中。错误在遍历中传播。它不是一个坏的变换乘法——源动画在计算中被重写，逐帧进行。 (反向遍历还假设评估是无状态的，但实际上不是。约束缓存、IK缓存、AnimInstance代理中的前一帧数据、后处理输出—— SetHasJumped(true) 不保证清除任何这些。) 问题2：一些快照根本不起作用。 如果您选择的父骨骼由您正在写的控制驱动，直接或间接，您会得到一个固定点方程而不是快照。写入子骨骼重新评估骨骼，父骨骼移动，刚刚计算出的关系不再成立。隐形版本通过后处理动画BP传递。如果父骨骼是骨骼或 socket，读取的就是姿势 后 后处理已经运行。被写入的控制也喂入了该姿势，依赖链脱离了 Control Rig 图表——您无法通过查看骨骼找到它。 解决方案是结构性的，而不是数学性的。 在写入任何内容之前缓存每个父骨骼和子骨骼的变换，始终评估正向，批量写入最后。读取源并修改它成为分离的阶段。这个变化处理了两个问题。正向评估消除了方向依赖的状态。没有从修改的序列中计算任何内容，因为没有内容在末尾修改。缓存将父骨骼从实时评估的量转换为静态轨迹数据，这断开了依赖循环——标准工具拒绝的快照变得普通。一个值得知道的属性：烘焙对 原始 父骨骼轨迹进行对齐。如果存在真实循环，重新运行骨骼后不一定会留下父骨骼不动。这是问题的固有特性，而且通常是您想要的。 与之无关但值得一提的是：烘焙后出现的奇怪曲线很可能是三次/自适应切点之间的密集键值过度， 而不是评估错误。将烘焙输出设置为线性。详细信息：https://github.com/septsaber/engineering-notes/blob/main/control-rig-snapper-drift.md 在我们这边实现为内置工具，而不是插件，所以没有下载内容——但方法可以轻松复制。