7月19日，游戏开发者大会（GDC）正式开幕，开幕当天，网易雷火UX用户体验中心的交互原型开发工程师面包居与网易雷火仓颉动画中心的负责人张为一起进行了分享。面包居于2019年正式加入网易，在雷火UX用户体验中心负责交互原型相关的开发。张为2009年加入网易，目前是仓颉动画中心的负责人，负责了《倩女幽魂》《逆水寒》等多个游戏产品动画开发。
面包居（左）张为（右）
网易雷火UX用户体验中心，涵盖游戏体验设计、用户研究、数据挖掘、数据分析等多个游戏用户体验领域。
网易雷火UX用户体验中心
本次分享的内容是《如何让动画衔接更加自然？—— 基于人体模型的多片段动画混合系统》。
分享首页
以下是分享实录：
面包居：大家好，感谢大家可以来听这次分享，我是面包局，今天我和我的伙伴张为一起分享的主题叫做《How to make Animation Blend More Natural?--A mannequin – Based Mutil – Fragment Animation Blend System》，即如何让动画衔接更加自然 —— 基于人体模型的多片段动画混合系统，我们将会从该系统的应用场景，开发方式，动画制作等方面进行分享。
首先，我们来讲讲为什么制作这套系统，或者说什么样的场景适合这套系统,以及我们解决了什么样的问题。我们会以花样滑冰这项传统体育项目为例，来分享这套系统。之所以选择使用花样滑冰作为示例，是因为花样滑冰实在是太好看了，当然，还有其他的原因。
首先请允许我简单的介绍花样滑冰，并且大家可以和我一同想象将其转换为游戏中的一部分。花样滑冰有着多种不同类型的动作，旋转，跳跃，接续步等等，并且都有国际标准，数量很多但是可控，舞蹈动作是没有限制的，也就是说舞蹈动作的动画切片数量是未知的，因此我们需要制作大量的动画切片给角色。
第二点，在国际规则下，有长节目和短节目区别，其中有包含对动作的要求，理论上只要符合动作要求，动作可以是任意的，更不用说每个人的舞蹈动作了，这意味着玩家可以自定义一段组合动画，尽管我们可以穷举玩家所有的组合可能，但是组合实在是太多了，这意味着我们无法预设制作所有的动画组合。花样滑冰中的每个动作都不是连续完成的（除了连跳动作或者在某一天出现了超级运动员也说不定），动作之间需要通过普通滑行动作进行衔接，这意味着滑行的动画，其路径也要根据前后的动作顺序所定，因此我们需要计算这些路径，其中包含了角色的位移，旋转等信息。最后，花样滑冰的每个动作都是由运动员完成的，是遵循客观物理规律的，因此我们的动画无论从制作，衔接，都应该保证物理的合理性，而不仅仅是酷炫的表现效果。通过之前对花样滑冰的分析，我们可以总结出一些普适性的应用场景。其中包括数量庞大的动画切片，并且玩家可以自定义一段组合动画，或者说开发者也没有更多的精力与时间去组合每一种结果，尤其是调节之间的过渡，以及计算每一种情况的位移以及旋转等属性，并且要遵循物理规律以及其他的限制，对于花样滑冰来说，除了物理因素限制之外，国际规则的限制同样重要。
因此，有这些问题需要我们去解决，如何标准化制作的花样滑冰的动画，既要做到还原，并且还能确保统一的标准，这样的好处是衔接起来，计算的内容会减少，效果也会更佳。
第二个问题是，如何自动化的去拼接这些动画序列，无需手动去调整过渡曲线，解放动画师的生产力，并且保证混合是自然的。
第三个问题是，滑行的部分，因为前后的动作都是未知的，我们需要利用算法去生成对应的路径数据，其中包含了角色的旋转以及位移，并且我们需要一套可以直观测试的平台，来验证以及优化我们的方案，并不是直接在引擎中测试。同时，我们还需要对生成的滑行路径检测其对冰场的利用率，测试摄像机移动方案，因此需要搭建一套平台。
最后是关于物理规律的问题，两个动画之间的混合是依据插值进行计算的，其中有很多问题需要我们关注，比如身体部位的移动速度，旋转角度，左右脚的起跳与落地顺序。这些部分我们需要去遵循物理规律，并不是看起来过渡平滑就可以，因此我们需要对混合这一部分进行一些特殊的处理和限制。
这就是我们为什么要做这样一套系统，相信大家也能从中得到关于应用场景上的一些信息，以及我们需要解决哪些问题。
花样滑冰具有代表性
接下来就到了动画制作的部分，将由我的搭档，张为来分享关于动画的设计与制作中的一些经验。
张为：在进行角色动画的制作之前，需要先对整个动画系统进行一个标准的设计，这样可以确保之后的制作是有规律可循的，而不是随意的创作。因此我确定了这五个方向，包括动画片段体量预估，支持多角色设计，统一的动画标准，还原真实的动画，处理动画混合部分。基于这五个方向，进行具体的动画制作。
首先是动画片段的体量的预估，这对于后续的设计与制作起着决定性作用，因此需要认真衡量这部分的内容，在前期验证阶段，会进行少量的制作投入，各类动画制作一到两种，作为整个系统的验证，在确定系统无误之后，大量投入之后的制作，固定数量的动画优先制作，拓展部分则根据时间成本以及需求进行后续的补足。之前已经衡量过动画片段的体量了，可以说是相当大体量的动画，因此对于多角色，我们采用重定向的方法。支持多角色动画，这就要求我们构建角色模型时，使用相同的的标准骨骼。对于不同角色的差异化展示，我们选择在出场动画，入场动画，舞蹈动画中进行相应的制作，保证其能存在角色的动画差异性。在整个系统的设计当中，非衔接的动画，因为衔接路线是计算出来的，所以衔接动画是补包含位移与旋转的，但是对于其余所有类型的动画，都默认带位移与旋转，因此，所有动画的制作，位移和旋转是需要按照同一个比例制作的，并且要能够还原现实动作在冰场上的比例，这样是为了可以更好的还原动作，而不至于在冰场上，动画的位移和旋转出现不合理的情况，之后我们也会用路径平台去验证这部分。
第二个需要统一的是，动画的开头与结尾，因为所有动画的衔接顺序是不定的，因此为了保证衔接的顺畅性，我们将开头与结尾都尽量附带滑行动作的部分，因为花样滑冰本身的动作也是依靠滑行动作进行衔接的，因此开头与结尾加入这些部分，可以更好的帮助我们进行首尾的混合。最后是关于动画的质量控制，当然动画的精细程度越精细越好，但是为了资源成本以及制作成本，我们依旧需要做出控制，比如旋转跳跃时的手指动作就不需要过于精细，而是着重关注脚部以及身体本身的部分，但是对于一些舞蹈动作，就需要在精细度上做出优化。花样滑冰的动作是有严格要求的，因此我们在还原这部分动画时，会依照花样滑冰的国际规则进行最后的检验，比如起跳的脚是哪一只，旋转的周数等等。不仅仅是花样滑冰的国际规则，对于动画本身来说，有很多逻辑合理性的指标需要我们注意，比如跳跃动作中发生的位移，因为在我们的系统设计中，跳跃旋转等动画是依赖动画中位移的，因此我们需要对跳跃动作中发生的位移做出合理的还原，保证其符合物理逻辑。在后期的制作当中，对于一些复杂度高的舞蹈动作，我们也会采用动作捕捉的手段进行动画的制作，保证动画品质。最后是关于处理动画混合的问题，每一个动画的开头与结尾都附带一部分衔接滑行的动作可以更好的帮助动画之间的过渡。
为了保证衔接动画过渡的自然，我们选择制作4/8方向的衔接动画，方便我们更好的做衔接，最后是关于动画片段之间的过渡混合问题，如果真的要手动调整每一个动画之间的衔接，将会带来相当大的工作量，这一部分将由我们的系统进行自动化处理。关于动画制作的部分就分享到这里，关于所有的设计都是根据项目本身所决定的，希望可以给大家带来帮助，接下来还是由我的伙伴面包居继续为大家分享系统的其他内容。
图5 传统的Unity动画工作流
面包居：接下来和大家分享角色运动路径的计算与可视化平台，这将直接决定最后整体动画的数据流以及表现关于为什么需要开发这个可视化平台，我会告诉大家开发的优势。
我们的衔接动画的路径是通过计算得到的，我们可以直接在平台上可视化路径，帮助我们测试路径计算的算法。对于花样滑冰来说，场地的利用率也是我们考虑的关键点，因此我们也需要利用平台对场地的利用率进行分析调整，前面我的伙伴张为也提到了关于动画位移的检测，我们可以直接对动画片段的位移进行检测，帮助我们优化动画的逻辑部分。因为我们想要还原电视转播级别的花样滑冰，因此对于转播镜头的需求也相当关键，因此我们可以利用平台完成相应的测试。
最后，也是最为关键的，该平台的后端部分将会直接输出动画数据给到客户端进行执行。说完这些收益，大家应该能明白为什么我们要制作这个平台了。
平台的核心功能是关于路径的计算，首先我们需要的是为平台准备数据，这些数据是制作好的动画片段的数据，其中包含每一帧的旋转，位移，时间戳。后台会进行动画数据的检测以及保存。两个动作之间的衔接路径通过时长计算，轨迹计算，旋转方向计算三个部分，我们得出了整段动画的所有数据。
之后便是利用该平台，我们可以进行一些数据合理性的验证，图6是导入之后，我们发现在动画的前两帧有速度突变的问题，我们又重新检查了动画，修复了动画当中的问题，得到了图7稳定的动画，平台帮助我们反向检测动画的合理性，这对于标准的动画制作，起到了关键的作用。
图6 发生突变
图7处理突变
我们可以在平台上进行动画序列的选择，然后就可以清晰的得到可视化路径，基于这些可视化路径，我们可以反复对路线进行测试与优化。图8是不同的动画序列带来的不同路径。
图8 不同的路线展示
最后是平台与客户端结合的部分，数据导出一共分两个部分，离线导出的数据用以客户端做动画验证，另一部分则是玩家在线选择动画序列后，通过访问后端接口，获取动画数据，最终在客户端进行呈现的过程。
有了这套平台之后，解决了所有数据导向的问题，感谢团队的小伙伴开发这套系统，有了动画的路线，有了每个制作精良的动画片段，是时候将这些角色动画组合在一起了，这也是本次的分享中关于自然这个词的解释。
Gif1 平台效果展示
我们需要解决StateMachine带来的诸多问题，首先就是极其复杂的构建过程，这个过程是相当繁琐的，并且会随着动画片段数量的增加而加剧的，因此我们构建了一个自动化构建状态机的工具，工具核心的部分是构建设计，我们有相当多的动画片段，我们可以从其动画性质对其进行上层的抽象，所有的动画在抽象层的状态转化是一致的，因此我们抽象出其状态转换，之后我们对所有的动画片段打标签，完成标签之后，只需要根据动画类型构建状态机即可，开发者只需要给动画打上标签即可，不用在做复杂的连线工作，根据抽象的状态规则，遍历动画列表，按照对应状态设置即可，更多的更新也通过脚本直接构建。这样就可以解决状态机带来的诸多问题，不用复杂的人力劳动，也不用担心更新带来的问题。
图9 基于传统状态机结构
图10抽象层的状态构建
对于非衔接类的动画来说，我们的非衔接类的动画的位移是预先设定好的，还是保证能够尽可能的还原动作本身，只是通过人物的方向不同，使得不同的组合情况下，仅仅会受到前后动画的影响。对于衔接类动画，系统采用原地Loop的方式，主要是因为衔接滑行的动画位移与旋转取决与前后的动画，我们的可视化平台会在玩家选择好路径之后，返回我们动画的位移与旋转数据，衔接动画本身只需要完成滑行的表现即可，位移旋转完全由生成的数据控制。在花滑中滑行的方向，包括正面滑行与背面滑行，为了保证与落地更好的衔接，我们可以制作多方向的动画进行Blend，这算是动画制作的常规操作，我们需要计算出角色的运动方向，然后Blend动画就可以完成正滑与倒滑的过渡。
衔接动画
非衔接动画
当然，对于花样滑冰这样的项目来说，世界上最顶尖的运动员也无法保证能够完全成功，游戏中也应该包含这样的随机事件，那么动画系统应该怎么处理呢？
首先应对花样滑冰中出现的摔倒动作，摔倒动作出现在跳跃结束后的部分，我们选择的方法是制作几类不同程度的摔倒，保证其存在一定的不同，触发当然都是由服务器计算的结果决定。对于跳跃周数不对的问题，我们没法制作所有的情况，那么我们就从动画本身想办法，跳跃动画在起跳时，在进入悬空时，根据得到的数据，跳过相应的比例，即可表现为存周，需要处理的是，跳过部分的两端之间的值，是需要按照相邻时间进行插值的，不进行插值会导致动画发生跳变。
在所有的准备，都完成搭建之后，关键的内容在于混合这一部分，大家都知道，两个动作之间的混合往往需要动画师手动去调节过渡时间，过渡比例，但是对于花样滑冰这样的项目来说，组合多，并且其中的滑行部分中人物的旋转，位移每次都会随着玩家的选择而改变，因此，动画师很难去做这样的工作，并且也会消耗大量的时间，因此，我们提出了自动化进行过渡时间的以及曲线的调节。自动化的算法的关键是选择参考因子，参考因子是你过渡时最为关注的点，你可以选择一个，也可以选择多个，当选择多个的时候，需要注意优先级。
接下来就是混合区间的确定，这部分需要计算两个动画左右脚相关的属性，计算得出方向，速度等重要数据，我们在做一步验证，验证混合部分的曲线，脚部的属性过渡是否平滑，主要是防止发生突变。这样就自动化完成了动画片段间的过渡混合。
在完成了基于脚部的自动化混合之后，并不意味动画之间就没问题了，当然这里说的没问题，不仅仅是看上去动画之间没有一些过渡上的问题，对于花样滑冰这样的动画来说，保证其物理合理性，以及一些客观条件的限制。物理合理性我们衡量的点，包括肢体移动的速度，肢体移动的平滑度，肢体的旋转限制。
这很好理解，两个动画混合时，可能会因为肢体状态值差距，导致肢体移动的速度出现太快或着太慢的影响，还包括加速度的突变都是影响的重要因素，因此在完成自动化Blend的时候我们需要进行一个阈值检测，对肢体移动的速度，移动的平滑度，肢体的旋转限制等需要考虑的物理因素进行计算检测，在开始过渡的时间点，到下一个动画播放，计算这些被关心的值，然后与预设的阈值进行检测，在阈值范围的内的值保持其正确性，超过阈值的，我们需要对其进行特殊处理，我们通过动态补帧以及平滑过渡计算处理这个问题。
旋转限制在于过渡的时候发生一些不可能完成的旋转，比如人体的腰身超过180度旋转，我们通过旋转角度预测计算的方式，保证其参数正确性。下方gif展示就是我们通过以上方法得到的过渡动画，可以看到过渡部分过渡自然，也没有出现任何违背物理因素的变化。上述展示就是我们通过以上方法得到的过渡动画，可以看到过渡部分过渡自然，也没有出现任何违背物理因素的变化。
混合之后的动作
到这里，关于制作的核心部分就结束了，我会对其中的内容进行一些总结，并且有一些新的启发与大家进行分享。
本次分享的系统解决了以下问题，对于多片段动画的混合，包括一些差异性的演示动画，提前预设所有情况是需要大量成本的，自动化构建可以省去很多的工作，使得动画师可以把自己的创作重心放在动作本身，而不需要对每种情况都要反复调整，自动化这个过程是相当必要的，对于玩家来说，每个人都能自己创作动画，是一件相当有乐趣的事，能够大大加深游戏的乐趣与玩家的参与感。
从这次系统的构建，有一些经验想和大家分享，首先是建立大局观，对于一个复杂动画系统，盲目的投入开发，无论从时间成本上还是人力成本来说都是相当有风险的，我们需要在制作前对于动画系统进行规划，无论是从程序工具还是动画制作本身，都是需要提前设计的，选择适合自己的方案。其次是之前分享过的可视化工具，对于花滑这样的系统来说，动画因为是玩家决定顺序，衔接动画都是计算得到的，那么对于路径的提前测试，场地的利用率，镜头系统都是需要提前验证，因此有一个可视化的路径工具，可以在前期提供大量的测试帮助，最后在引擎中完成最终的演示部分。
对于这样的系统，是不适合前期投入大量制作的，我们的经验是先投入小部分资源，做核心功能的验证以及调整，确定方案之后再进行大量的开发。最后也是最重要的，对于这种还原度较高的动画需求，一定要注意物理与客观的合理性，这样才能保证动画过渡的自然，而不仅仅是表现上的自然。
感谢大家，这就是我们分享的所有内容，希望能对大家起到帮助，也希望可以一起交流。
