Ootii和Mecanim&Morpheme类的传统动画图管线的问题
- 我们一开始使用ootii的运动系统做原型。
- Ootii是unity上比较主流和大量使用的5星运动解决方案，在之前经过数个Asset Store Solution的对比评估后，我认为它是Asset Store上传统动画技术上做得最到位的方案。
- 但是过于复杂和冗余的代码和系统框架依然给开发调试带来了巨大的麻烦，特别是在要调整某个动画细节效果的时候，需要彻底理解和排查代码才能定位到导致出问题的点。
- 对于这种网状问题过去的基本解决方案是用Int类型的ID+全局过渡来保证上层逻辑的控制权。但是你要保证动画的效果够好的话，在动画图层处理转换关系少不了。
- 整体来说ootii基本是上个时代的高层运动系统方案的较为完善的构架，它比较统一地处理了旧时代常见的动画状态机+混合树系统的常见结构组织问题。
- 它有统一的优先级管理系统和动画图的自动生成以及代码回生成。
- 不过这种蜘蛛网式的动画技术已经逐渐难于满足当代的大量动捕动画使用和独立开发者人少难于维护，同时因为代码构架的复杂度，调试起来也相当不便（你碰上一个动作问题，需要从逻辑层调试到动画控制器层再调试到动画图层，最后还可能问题处在动作资源上，相当的麻烦）。
Motion Matching技术和Kinematica
- 从GTA和大镖客1时代下来，动画图一直是游戏界主流的动画解决方案。中间顶多有UE3的Anim Tree到后来的Blend Tree+状态机系统的转变。
- 刚好我和菠萝在以前都负责过游戏中动画管线的工作，过去10年在商业项目制作中我们已经被动画图坑了不知道多少次了。
- 所以现在开始逐渐转用Ubi和The Last Of 2 中使用的Motion Matching技术解决运动数据组织和各种动画对位问题。
- Unity的Kinematica遥遥无期，菠萝早先的参考Disney实现的Motion Filed在落地应用上没有Motion Matching技术扎实。在最近经过了数周的评估后，最后决定花75刀购入了Motion Matching For Unity的Solution。这个基础方案有着相当高的产品级管线，进一步可以发现开发者明显是常年混迹于游戏动画技术领域的老兵，在管线上针对上个时代的旧动画技术做了彻底的处理。
- 在初步的使用和熟悉后，可以进一步确定是适合当前我们项目需求的Solution，按照早先unity的新技术发布来看，Kinematica在发布时决定难于满足产品级应用需求，所以果断决定采用Motion Matching For Unity中间件。
- 如果说有什么缺点的话，就是相对的需要花不少功夫封装出自己的上层运动系统，对缺少TA和程序的团队在调教这种新技术的习性上可能得花不少功夫。目前还在Beta版，在价格和未来是否能够有长期的支持还是未知数。
- 所以我们的解决是逐步替代之前使用的ootii运动系统。
- 既然买了代码，如果有必要之后自己做后续维护和魔改，目前看还是需要做不少编码整合工作。
新的Motion Matching管线特点
后续工作
- 目前上集成原型的状况上来看，在即时Banking和Turn动画的时候还难于保证响应性，动作效果也有一些问题。还需要逐步调教以及做一些编码针对灵敏度和表现进行处理。
- 进一步的评估信息会随着技术验证的进度逐步更新
参考
- Motion Matching and The Road to Next-Gen Animation（ Ubi在GDC 2016关于Motion Matching的演讲
- E3 2018: How The Last of Us Part 2 Redesigned Combat for Playing as Ellie（访谈中有一些顽皮狗如何控制Motion Matching的动作灵敏度的信息
- GDC2016【For Honor-荣耀战魂】的次世代动画技术
- Announcing Kinematica: Animation meets machine learning（unity的技术演示，本来预计2019.3要上的，然而并没有，而且遥遥无期
- Motion Matching For Unity