首页 诗词 字典 板报 句子 名言 友答 励志 学校 网站地图
当前位置: 首页 > 教程频道 > 软件管理 > 软件架构设计 >

事关Animation Tree的工作漫笔(二)

2013-10-08 
事关Animation Tree的工作随笔(二)上回说到,游戏项目中客观会遇到逻辑状态的复杂性和动画状态的单一性之间

事关Animation Tree的工作随笔(二)

上回说到,游戏项目中客观会遇到逻辑状态的复杂性和动画状态的单一性之间的矛盾,那么Animation Tree是如何解决这个问题的呢?

这又需要引入一个定律:就是逻辑状态无论有多么复杂,但一套逻辑状态组合一定唯一对应一个具体的动画。

举例来说:已知控制当前游戏对象的逻辑状态有是否技能中、是否受击、是否中毒、是否眩晕。


那么我们可以建立一个下面的关系:

 

技能中否是否否否否是受击否否是否否否是中毒否否否是否是是眩晕否否否否是是否最终动作默认站立待机动作当前技能动作当前受击动作中毒待机动作眩晕动作

眩晕动作

(设眩晕动画优先级高于中毒)

技能动作

(设技能动作优先级高于受击)

 

给定每个逻辑的输入,最终的动画结果基本一定是唯一的。

这就是Animation Tree的原理。把整个角色动画,依照不同的逻辑单元组合,最终在给定既定的逻辑取值的情况下,能得到唯一的动画结果。无论是使用什么具体的方案,万变不离其宗。

 

这中间有几个需要注意的问题:

1、优先级,这个优先级一般与逻辑无关,只是动画本身的优先级,例如上表中的倒数第二列,中毒和眩晕全都触发时,一般眩晕的优先级会高于中毒的优先级。再如最后一列,当中毒和技能同时触发时,技能有限级一般会高于中毒优先级。这就意味着眩晕和技能条件的判断要早于中毒的判断,并享有对整个树的优先处理权,眩晕条件一旦达成,其之后的中毒条件甚至根本就不用去判断了。

2、融合,角色当前属于眩晕动画状态,眩晕解除后,一般不会直接跳转到接下来的状态,而是需要走一个动作融合,这时需要注意接下来到底要转到哪个状态的问题。表面上看,人们不可能知道一个状态解除后接下来会转向什么状态,但实际上在既定的项目中,这一点是可以做到的。

3、逻辑状态本身的互斥性,例如,上表中,不太可能出现眩晕和技能同时存在的情况,因为眩晕的目的旨在剥夺玩家的行为控制能力。在制作具体的Animation Tree时可以灵活根据这些条件进行一些优化和优先级的合理排布。

 

Animation Tree,目前接触过UE3的Animation Tree思路和CE3的Animation Graph思路。这两个思路是分别从两个不同的出发点入手解决同一个问题。

UEAT的出发点是:逻辑状态无论有多么复杂,但一套逻辑状态组合一定唯一对应一个具体的动画,也就是说,无论AT有多么复杂,最终的结果一定是单一的。这种具有单一结果的情况,一般人们应该都会选择树来做为数据结构。所以,UEAT看起来像下面这个样子(图片来自UDK官网):

事关Animation Tree的工作漫笔(二)

4中,被一堆绿色节点包围的那个节点,就是UEAT的根,所有的条件依照这个根以树状排布。

 

AG不是特别熟悉,这里只是根据笔者现在的经验来写,可能会有疏漏,望懂CE的大牛补充。

CEAG的出发点与UEAT不同:逻辑状态无论有多么复杂,但一套逻辑状态组合一定唯一对应一个具体的动画,所以CE把重点放在了这些状态组合上,AG的编辑界面里排布着大量的关联节点,每个节点的进入条件就是状态的各种组合,从一个节点跳转到另一个节点,如果有路径,就顺路径混合,否则直接按照节点混合直接跳到目标节点(图片来自CE官网):

事关Animation Tree的工作漫笔(二)

事关Animation Tree的工作漫笔(二)

上图是节点间的转移路径,下图是某个单一节点的条件,一个是Action条件,一个是当前角色速度的条件。

 

个人推荐使用UEAT的方案,图表一旦大起来的时候,树状逻辑组织的可读性显然高于图状逻辑组织,而CEAG更糟糕的是将节点间的不同性隐藏在了节点内部的属性上,不把节点全部点开一次你是不可能明白这张图到底想干嘛的,而UE则直接从树根追溯到叶子就知道这张图是怎么回事了。但是UEAT的缺点是任意两个动画叶子之间的Blend并不是特别好设置,因为叶子间的切换,需要首先追溯到两个叶子的共同树枝,然后根据这个共同树枝来进行混合,如果有下面这种情况,就很难对付了。

事关Animation Tree的工作漫笔(二)

顺便做个广告,Surface Pro的1024级压感电磁笔爽死了,谁用谁知道。

如图所述,1到3、1到4的公共根是Blend节点,节点Blend时间0.1s,所以如果要这两个路径的Blend区分,这里的处理就需要麻烦点。AG处理这个只需要走两条不同的Blend路径就可以。

但是笔者仍然推荐AT,道理很简单,可读性太重要了,而且Blend这种看起来对就是对的的坑爹玩意儿,一般不会有人揪着0.1和0.3不放的,真需要叶子间那么精确到0.1和0.3的可能性不是很大,即便有了,也可以通过回调或者自定义等手段避免掉。但是,学AT的时候,半个小时就明白这玩意儿是怎么回事了,学AG的时候,把整个例子的所有节点走一遍就是一上午,还没来得及排布各个条件的优先关系。AG这种思路太过于直接地考虑程序的实现性了,而忽视了整个体系的方便性,感觉像给自己用的东西,不像给人用的东西。

 

逻辑状态中最重要的关系就是优先级关系,各个不同体系的逻辑条件,其优先级基本直接决定了最后的结果,所以,像UEAT这样的组织方式,最直接地表述了这样的关系,必然产生的结果就是优良的可读性和可控性。

关于AT的组织和概念就基本上差不多这样了。

接下来准备介绍一些常见的AT组织的桥段。

热点排行