C++
从开发者的角度来看，Unreal引擎的动画功能之所以显得极其丰富，是因为其针对每个功能都设计了一套专用资产和工作空间。这种设计是从工业实践中提炼出来的，非常细致入微。Unreal引擎的底层架构主要服务于注重3C（Camera、Character、Combat）的角色扮演游戏，例如战争机器。这类游戏对动画的要求极高，需要灵活地动态混合预设动画，并支持复杂的姿势调整。因此，在主角动画流程中，每帧采样十几个动画片段的操作也变得轻而易举。相比之下，Mecanim虽然部分实现了类似的功能，但用户的实际体验却有所不同。Mecanim的操作更偏向于傻瓜化，适合简单场景下的动画切换；而当涉及到自定义代码时，开发者往往无法实时看到效果，这使得整个开发过程显得不够直观。再加上Mecanim的原作者早已不再维护，许多功能变成了黑盒，用户只能通过动画事件进行一些基础处理，比如根运动计算。而在更高阶的需求上，早期像FinalIK这样的插件几乎可以满足大部分要求，这也导致了Unity原生动画解决方案在社区中的讨论热度较低。大多数使用Unity的开发者，其需求仅限于播放预设动画以及偶尔关注动画切换时的插值效果。对于他们而言，现有的动画系统已经足够使用。甚至夸张地说，不仅是过去8年，即便从2011年开始算起，只要稍作性能优化，这套系统对他们来说依然够用。新项目仍然在纠结是选择Animancer还是FinalIK，这种情况足以说明问题。后来Unity推出了Playable模块，本有机会弥补重度混合动画方面的短板，但其API设计晦涩难懂，核心功能仍隐藏在引擎底层。尤其是PosePlayable这一关键功能不可用，让广大依赖编译版本的社区用户难以深入挖掘其潜力。再之后，Unity又推出了AnimationStream，允许在不依赖Transform的情况下直接在
C++层面插入动画运算逻辑，这才为动画开发带来了一丝转机。而FinalIK等头部插件也迅速跟进，继续保持其行业地位。然而，本月社区矛盾的激化让这一点点进步也变得前途未卜。举个例子，无论是1993年的毁灭战士还是VR战士，两者虽然出自同一年代，但并不能简单地说它们的动画系统之间存在多少年的差距，这只是因为两者的动画模块设计理念不同罢了。不过，如果Unity一直坚持宣称自己能够制作3A级游戏，那么仅凭当前Animation Rigging的完成度来看，说它与Unreal相比在面向使用者的动画基建方面落后8年，也并不为过。或许，Unity确实需要在这方面多下功夫补足差距。
