Unity动画模块与UE5的差距分析

Unity 动画团队曾提到，Mecanim 的架构设计大约在 2009 年敲定，并于 2012 年随 Unity 4 发布（当时还是 UE3 的时代）。在那个时期，Mecanim 的架构被认为非常灵活，但随着现代游戏对动画需求的日益复杂，它逐渐显得力不从心。为了弥补这一不足，Unity 推出了 Playable API，开放了一系列底层动画接口，允许开发者实现更多运行时程序化动画功能。然而，这套 API 虽然功能强大，但问题频出。Playable 的核心特性之一是支持无限嵌套：一个动画Playable 可以将自身的评估结果（例如速度、姿态、曲线属性等）作为另一个Playable 的输入，通过 AnimationStream 来传递动画数据流，最终生成角色的运动与姿态数据。然而，Unity 似乎并未预见到用户会构建复杂的树状结构，因此在这方面的测试和优化几乎为零。结果就是，这套 API 的稳定性堪忧。用编程语言来类比的话，就好比基础的 if、for 和 switch 语句单独使用时一切正常，但当它们被深度嵌套时，程序就会崩溃。目前，Unity 对 Mecanim 的开发已基本停止，仅维持一些常规的 bug 修复工作，而这些修复往往进展缓慢。至于备受期待的 DOTS 动画系统，其发布日期仍然遥不可及。曾经有人尝试在 Unity 中利用 Playable API 复刻 UE 的 AnimGraph 功能，但在这一过程中遇到了大量问题。提交了二十多份 bug 报告后，大部分要么被确认但随后石沉大海，要么直接被告知不予修复——官方的理由包括人力不足、问题影响范围过大，甚至担心修复可能导致现有功能出现问题。最终，只有一个 bug 得到了修复。面对如此多的 bug，开发者不得不花费大量时间设计 workaround 来实现所需功能。起初，会对 Unity 不修复 bug 感到不满，但后来又开始担忧，一旦修复可能会影响已经勉强可用的功能。与此同时，DOTS 动画系统的开发进程也令人担忧。即便询问能否提供功能列表或预览包，得到的回答始终是无法满足请求，给人一种缺乏明确开发方向的感觉。