【Unity】Animation Playable Bug、限制及解决方案汇总

先自荐一下我的PlayableGraph监控工具，比官方的Visualizer好用得多：https://github.com/SolarianZ/UnityPlayableGraphMonitorTool

PlayableGraph Monitor

Bug

文中提及的各项Bug及解决方案的最小化测试工程可在此仓库下载：https://github.com/zdirtywork 。

【可规避】UUM-30899

使用

AnimationClipPlayable

播放动画时，调用

Playable.Pause()

方法后，角色仍继续移动（姿态可以正常暂停）。

解决方案：对

AnimationClipPlayable

调用一次

SetTime()

方法。或者使用

SetSpeed(0)

代替

Pasue()

。

【可规避】UUM-14492

已暂停的Playable会在角色的可见状态改变时（进入相机视野，无论Scene窗口还是Game窗口）自动恢复播放。

解决方案：使用

SetSpeed(0)

代替

Pasue()

。

【可规避】UUM-32824

将正在播放的PlayableGraph的UpdateMode设为

Manual

（这之后，

PlayableGraph.IsPlaying()

方法会返回

false

），然后再调用

PlayableGraph.Play()

方法（这之后，

PlayableGraph.IsPlaying()

方法会返回

true

，但仍需要手动驱动更新），然后再将PlayableGraph的UpdateMode设为任意

非Manual

值，PlayableGraph无法按预期恢复自动播放。

解决方案：调用

PlayableGraph.Stop()

方法，然后再调用

PlayableGraph.Play()

方法，强制刷新状态。参考下方连接中的示例工程。

【可规避】【不会修复】UUM-33177

连续调用2次

Playable.SetTime()

方法无法消除对跟运动的影响。例如，一个具有跟运动的动画当前播放到第5秒，使用

SetTime()

方法将其时间设置到10秒后，角色不仅会将自己的姿态变为动画第10秒所对应的姿态，从第5到第10秒之间所应产生的跟运动也会被施加到角色身上，具体表现就是角色位置突变。

Unity表示不会修复此Bug。

解决方案：在

AnimationClipPlayable

后面接一个

AniamtionScriptPlayable

，在其Job中手动将时间差导致的跟运动数据剔除。参考下方连接中的示例工程。然后你会遇到UUM-36098。

【可规避】UUM-36098

在使用Humanoid动画时，通过

AnimationStream.velocity

属性修改跟运动速度不生效。

解决方案：不要用

Animator

自己的跟运动计算方法，而是手动从

AnimationStream

中收集跟运动数据，然后手动施加给角色。参考下方连接中的示例工程。然后你会遇到UUM-33952。

【Unity 2022无法复现】【不会修复】UUM-33952

Time.timeScale

的值会影响

AnimationStream

中动画跟运动旋转数据的值。很神奇的Bug，具体表现是，当

Time.timeScale

的值大于

0.85

时，从

AnimationStream

中取出的跟运动旋转数据和

Animator

中的跟运动旋转数据不一致，并且在

Time.timeScale

的值大于

后，

Time.timeScale

的值越大，两者中的跟运动旋转数据差距越小。情况非常多，参考下方连接中的示例工程。

我只在简单的PlayableGraph中注意到此问题，当PlayableGraph连接的复杂了以后，这个问题就变得不明显了。另外，使用UUM-36098中提及的方式手动计算跟运动时，角色会有轻微滑步，估计和这个Bug有关。

Unity表示不会修复此Bug。但我在Unity 2022中没能复现这个问题，可能他们说的是与此问题相关的其他底层逻辑Bug不会被修复。

【可规避】【不会修复】UUM-34442

当

AnimationScriptPlayable

输入到了

ScriptPlayable<T>

的非第0个输入端口时，其Job中的

ProcessRootMotion()

方法和

ProcessAnimation()

方法不会执行。

Unity表示不会修复此Bug。

解决方案：使

ScriptPlayable<T>

只有1个输入端口，然后在

ScriptPlayable<T>

前输入一个

AnimationMixerPlayable

或

AnimationLayerMixerPlayable

，把原本

ScriptPlayable<T>

上的多个输入端口改为Mixer的多个输入端口。参考下方连接中的示例工程。

【可规避】UUM-33944

当

AnimationScriptPlayable

的有效权重不为

时，在其Job中通过

PropertyStreamHandle

修改动画曲线值不生效。

解决方案：在

Animator

上绑定一个名为

GravityWeight

的属性。暂不清楚此方法会不会造成其他负面影响。参考下方连接中的示例工程。

UUM-31822

当

Animator.applyRootMotion

属性为

false

时，绑定

Animator

组件所处节点的

TransformStreamHandle

会导致角色位置异常。

限制/规则

PlayableGraph.IsPlaying()

方法的返回值

Editor中逐帧播放时，

PlayableGraph.IsPlaying()

方法总是返回

false

。我对此提过Bug单，但Unity说设计如此不是Bug。我觉得这个设计太烂了！原因有二：

Runtime应该对Editor无感知，逐帧播放是存粹的Editor功能，而它却改变了Runtime接口的行为。
如果Runtime代码依据 PlayableGraph.IsPlaying() 方法的返回值执行不同逻辑，这里很有可能导致逐帧调试时出现Bug。

AnimationScriptPlayable

的输入不受权重影响

AnimationScriptPlayable

预期用户手动处理其输入Playable中的数据，因此，连接输入Playable时设置的权重不会实际作用到输入数据上，而是要用户手动处理。

角色未被渲染时，

AnimationScriptPlayable

的Job中的

ProcessAnimation()

方法不会执行

符合预期，因为角色不可见时计算其姿态通常没有意义，浪费性能。如果希望在角色不可见时仍执行

ProcessAnimation()

方法，可以将

Animator.cullingMode

设为

AlwaysAnimate

。

没有直接或间接输出到

AnimationPlayableOutput

的

AnimationScriptPlayable

不会执行其Job中的

ProcessRootMotion()

方法和

ProcessAnimation()

方法

符合预期，因为这种情况下动画数据始终无法施加到角色身上，计算了也是白算，浪费性能。

标签： unity bug 游戏引擎

本文转载自: https://blog.csdn.net/qq_21397217/article/details/130816815
版权归原作者 Arvin ZHANG 所有，如有侵权，请联系我们删除。

【Unity】Animation Playable Bug、限制及解决方案汇总