摘要

         本文主要总结了枪神纪的动画融合系统，同时对比介绍了《神秘海域2》的动画融合系统，接着用一个实际遇到的动画需求来分析两个系统的优缺点，最后尝试着从枪神纪的角度来总结两者的差异。(本文仅涉及了双方的动画融合系统，更多的关于每个动画模块(基础移动，攻击，技能)的实现，将会在下一篇文章中进行介绍。)

背景

         第三人称游戏往往拥有丰富的动画表现，一个动画融合系统是每个动画模块完美融合的前提，动画融合系统不仅决定了各个动画模块之间的状态管理，更决定了他们之间的融合方式，最后直接反映到美术制作流程。

枪神纪的融合系统

         枪神纪只使用一颗动画树(Anim Tree)去同时管理动画状态与动画逻辑，实际上这颗动画树更像是一个树状流程图，如下图所示，每一个方框代表一个动画模块。在实际的执行过程中，例如针对我们的双枪角色， 首先是判断他是否处于胜利镜头， 再判断他是否处于掏枪状态，接着判断是否处于胜利展示状态…… 整个动画树就是这样一个个状态判断下去，最后决定了动画树中每个叶子节点的权重。

         把动画融合系统定下来之后，最终加入各个动画子模块之后，最后的动画树成型图如下：

         举个例子，角色有可能在往前跑步射击的过程中被敌方玩家打了，此时角色就同时处于受击状态，前跑状态，开火状态。 那么按照我们的动画树逻辑，会去使用前跑状态的Full Body动画，叠加上受击动作的Additive动作，以及Partial Blend他的瞄准方向的Aiming Pose。

神秘海域2的Animation Layering

         反过来看神秘海域2的技术方案。他并不是使用一个动画树去Blend所有的动作，而是把动作分为各个层级，每个层级一个动画树，然后层级之间再通过Blend， Additive， Partial Blend融合起来，与此同时更关键的是每一个子层可以处于自己的状态。

         《Game Engine Architecture》里动画那一章详细地阐述了这个方案：例如下图就把动画拆成了4层，每一层管理着自己的状态，并被统一更新管理着：

         某一时刻，每一层动画可以处于自己的状态中，例如下图，他们各自处于了自己的State K， State H， State F， State B状态中，并按照自己的状态更新动画。

         当更新完自己的状态之后，他们再通过预先设计好的融合方式，把各个层的最终Pose融合起来。

         下面的视频来截取自神秘海域2 在GDC 10上的演讲，我们看到，左边的角色在播放Base Layer，这个层负责更新全身的基本运动，右边的角色在播放Weapon Layer的动画，这个层负责武器动画逻辑，而中间的角色正是这两个层融合在一起的最终的效果。

http://v.youku.com/v_show/id_XNjcyODUxNjky.html

         UE3实际上也可以实现Animation Layering的功能， 因为我们很容易就能通过自己定义节点中的融合行为来达到Animation Layerin，例如针对上面的分层和混合方式，只需要写一个复合节点N，使N的动作输出定义为：

LERP(Input1, Input4) + Input2 + Input4.

         那么就把这个Layering扁平化成一个树形结构，如下图所示：

         然而，这只是解决了同一个状态下，各个节点的融合问题，却无法模拟出N层独立的状态管理，可见Animation Layering的核心是独立状态管理。

衣服的动画的问题

         一般的射击游戏动画都会将人物的动画分为上下半身分离去处理，例如跑步中换枪，下半身依然在跑步，而上半身播放一个换枪的动作，这就是一个最简单的跑步中换枪的动画融合实现。下图是一个典型的角色的骨骼：

         我们从Hips分为上半身骨骼和下半身骨骼：

         然而问题出现了，衣服的飘带动画更多的和基础的行走模块相关(随着行走的方向飘动），但是却分配到上半支的骨骼中，这样以来就会导致在播放上半身动画时，飘带的动画就忽然切到了上半身的中。例如角色行走过程中开火，开火仅仅是一个很短的动画，飘带基本不动，如果生硬的把整个上半身在开火状态时强制切换到开火状态，那么整个飘带就会一抖一抖，影响了最后动画的品质。

         下图说明了飘带骨骼所处的层级关系：

         针对这样的问题，按照神秘海域2里的Animation Layering的方法，只需把飘带分到另外一个层级， 在那个层级里按照基本位移的状态更新自己的动画，而最后再叠加上去基础动画就可以：

         但是枪神纪整个动画树就只维护了一套状态，因此，不能使用这一套方案。 为了解决这个问题, 我重新写了分支节点融合逻辑，加入了一个分支后的排除分支列表，去Hack了动画树，让本属于上半身的骨骼去按照下半身的状态更新自己。

         正常的融合过程如下，蓝色的骨骼代表读取开火序列数据，橙色的表示读取行走序列数据：

         经过修改节点之后，让他从B_Cloth0开始继续读取行走的序列数据：

总结

         上面的修改让枪神纪暂时满足了需求，但是当我们的动画逻辑进一步复杂，出现三重融合分支的时候，那么这样的融合逻辑就开始变得混乱，到那个时候，就不得不采用Aniamtion Layering的动画融合设计才能满足需求。但是，从性能方面来看，采用Animation Layering的设计时，虽然灵活性大大的提高了，但是却维护了更多的状态管理，并且增加了一次额外的Additve动画的计算，动画系统的消耗也就更多了。因此，即使目前枪神纪有机会再一次重新设计自己的动画融合方案，从效率的角度来看，我们还是会采用目前的一套动画树，一套状态管理的设计。

参考

1. Animation and Player Control in Uncharted: Drake's Fortune and Uncharted II: Among Thieves, http://www.gdcvault.com/play/1012300/Animation-and-Player-Control-in

2. Game Engine Architecture , Chapter  11: Animation System, First Edition, Jason Gregory.