Live2D与E-mote

眼看10月快到了,而本月却没有什么可写的内容(摊手)。思来想去只能再拿以前的话题凑一篇出来。

Live2D(L2D)和E-mote(EMT)都是用少量原画便可生成可动的2D人物动画的引擎。两者的效果相似,经常不明真相的吃瓜群众将其中一种错认为另外一种,或是妄议L2D比EMT效果好很多,这种看法其实就好像说Unreal画质比Unity好很多一样——并非一个真的比另一个高多少,而是你 不 会 用。

网格调整

L2D和EMT实现机理大体是相似的,具体可以阅读某巨硬大佬的文章。简单来说,都是在一个贴图上取一堆关键点,设置它们在关键帧的位置并依此对贴图扭曲,然后中间帧补间。因此,网格调整是此类引擎最核心的功能。

对于一张贴图来说,L2D除了可以按照传统的矩形网点进行变形(左图),还可以按照贴图的有效区域生成不规则形状的网点(右图)。不规则的三角网格可以更精细地调整每个区域的变化量,不过也会明显提升学习难度和对经验的要求,很多时候你在某个关键帧调到完美了,结果却发现中间的补间帧的显示效果一塌糊涂。

而EMT中,同样是在关键帧设置网点位置来进行变形,但是只允许以矩形为基础进行网格变形。优点和缺点当然是与L2D相反:其实大多数时候你不需要逐个调整那些网点,只要对矩形网格做一个整体的扭曲就足够了(整体扭曲的效果多数时候还是比较自然的);但是真的要做一些非常精细的调整,可能就要在原贴图、补间函数和图层分配等其他方面多下功夫了。下图显示了当人物做向下探身的动作时,下半身按矩形网格向下扭曲(看起来效果就是裙子盖住了更多腿部的部分,以给人弯腰的感觉)。

总结:L2D由于更高的可定制性胜出,但是操作复杂,需要经验。同时在这一功能上,EMT是L2D的子集(L2D有可能兼容EMT,而EMT无法兼容L2D)。

 

编辑器

L2D的编辑器是用Java搓的,使用感受那只有一个字——。光看内存和CPU占用,似乎也不是特别多的样子,但是加载模型后却总是卡的不行,点击按钮没有反馈是常态。在i5 8G的SP4上卡到几乎无法使用。编辑器设计整体比较简单(因为功能就那点)。

EMT的编辑器使用krkr(Z)搓的,对你没看错,就是那个做AVG用的游戏引擎吉里吉里。一个做galgame的游戏引擎能做设计软件(笑)?所以EMT的编辑器看上去就有点土,而且奇怪的BUG非常多!由于krkr的机制,基本上一旦触发了一点小BUG,程序就会报错并退出。这些BUG凸显了TJS在设计AVG之外的领域是一门多么辣鸡的语言。引用一句某大触的话:“8102年还不重写编辑器的EMT是屑”。不过,比起L2D的编辑器,EMT编辑器的资源占用要小很多,在SP4上也可以使用。EMT的编辑器功能很杂,而且不同版本(免费版、全功能版、Motion版、Indie版等等)差别很大,容易使人混乱。另外,EMT编辑器的设计根本没有考虑过“国际化”三个字,甚至很多功能是硬编码了日文的(比如用于调整位置的功能图层已经硬编码成“レイアウト”,如果你修改模型文件给它换个名字,那读取时就报错退出一气呵成,所以无论你打开什么模型,你几乎必定会看到这个“レイアウト”。)

总结:综上所述,只要你电脑性能够强,L2D编辑器的体验会大大好于EMT,所以L2D胜出。

其他功能

尽管在网点调整上,EMT比L2D要粗糙,但是EMT却还有很多各式各样的功能,就比如说这个混合模式(BlendMode),几乎是把PS上有的都搬过来了,看来是要与PS无缝对接。通过这些混合模式,确实能实现一些比较高级的效果,比如模拟光照、遮罩等。另外一个功能,就是EMT内置了胸部、头发晃动的计算并可以调整各种参数,以及自动眨眼功能。而这些在L2D里需要自己设置时间轴实现(包括眨眼)。不过最新版L2D据说已经在加一些模拟物理的功能进去了。

事实上EMT编辑器内含的功能远不止这些,EMT编辑器内置了一个EMT Logo的模型,那个Logo并不是人物而且有一个非常复杂的动画,这就已经证明了EMT并不是一个只能做人物动画的工具,也有做其他动画的潜力(换言之,像是没有AS脚本功能的Flash)。EMT中支持的功能图层有10种之多,而暴露给普通用户的仅有Mesh、Object(Texture)、Layout、Motion四种:

L2D中比较实用的特色功能大概就是套用模板功能:把PSD拖到模板模型上,会根据各个部位的位置接近程度自动映射模板的对应部位。不过实际效果也没有那么好。至于纸娃娃系统,我还没有看出有什么很大的用处。

总结:论功能数量,EMT确实比L2D更多,因此EMT胜出。可惜的是,EMT并没有把所有功能暴露给用户,而且不同的EMT编辑器版本的功能区别也很大,加之编辑器存在的BUG和国际化问题,进一步限制了EMT的发展。在这些功能上,L2D是EMT的子集。

文件格式

 通过观察两种引擎的模型文件的格式设计,能够理解很多对应引擎的原理。两种引擎的模型解析我都搓了,分别是FreeMote(EMT)和FreeLive(L2D)。如果你也想深入了解这两种引擎,可以参考我的实现。

EMT的模型格式/工程格式实际上是一种二进制序列化的、可内嵌资源的JSON。这种格式是M2公司的得意之作,最早是用于打包krkr游戏里的资源和脚本,所以此格式通用性比较强。

L2D的模型格式是传统的二进制序列化的对象的序列,工程格式却是(他们自己造的)二进制序列化的XML。与EMT相比,L2D的模型格式缺乏前向兼容性(向上兼容性)。

举个例子,假设这两种格式有一个描述坐标点的Point类型:class Point { int X; int Y;}。对于连续的两个点(1,2),(3,4),EMT会将它序列化成JSON形式(实际是二进制的JSON)的 { "X" : 1, "Y" : 2}, { "X" : 3, "Y" : 4};而L2D会把它序列化成按顺序的值的序列(实际也是二进制)1;2;3;4。如果不考虑格式变动的兼容,自然是L2D最省空间。但是若新版本中要求Point类型增加一个描述颜色的int Color,则新版本生成的模型会变成:(EMT) { "X" : 1, "Y" : 2, "Color" : 127}, { "X" : 3, "Y" : 4, "Color" : 255};(L2D) 1;2;127;3;4;255。这时我们会发现,EMT旧版本引擎仍然能打开新版本的模型,只是Color字段不会生效;而L2D旧版本引擎不可能打开新版本模型,会直接崩溃,因此所有开发的应用程序必须升级引擎才能兼容新版本模型。或许正是因为意识到了这一点,L2D的工程文件并没有采用同样的设计,而是换成了二进制XML,因此才有可能像JSON一样实现向上兼容。

不过EMT的格式在加密方面犯了不少错误。在早期版本中,模型的几乎所有字节都要加解密。或许是意识到这对效率造成的影响太大,在之后版本中改为只加密头部(几十个字节),由于要确定后面内容的位置需要查询头部,所以EMT的设计者自认��这样搞没什么问题。但是事实上问题很大,这就催生了我搓的无需头部就能加载模型的技术Dullahan Load(FreeMote)。此外其加密方式也存在问题,因此才有了在多数情况下都可以直接推得Key的FreeMote.Purify。

总结:EMT的格式设计具有前向兼容性和自我描述性,以及内嵌资源和加密设计,因此优于L2D。不过其设计存在部分缺陷。

FreeMote与FreeLive

FreeMote是我搓的解析EMT相关格式的工具和库,也可以用于修改某些krkr游戏的脚本和图片资源等,甚至能用于修改EMT模型。

FreeLive是我搓的解析L2D相关格式的工具和库,目前模型格式基本可用,但其他内容(包括工程格式)还在施工中。

DualVectorFoil是我搓的仿L2D的2D人物动画系统,最终目标是同时兼容L2D和EMT(估计很难实现)。 

关于起名

虽然巨硬改名部一直饱受嘲讽(把VSTS改名成Azure DevOps的操作确实不咋地,感觉DevOps并不是一个好名字),但是辛苦搓了这么长时间的轮子,起一个好名字总是要的。

FreeMote中的工具名大都源于编程工具:

PsBuild:名字来自MSBuild

PsbDecompile:名字来自JustDecompile

EmtMake:名字来自cmake/nmake

 

FreeLive中的库名是来自某知名魔法少女动画:

FreeLive.Kyubey:名字来自外星生物“QB”;Cubism的谐音

FreeLive.Charlotte:名字来自可爱的小吃货“零食魔女”;Character Load & Update

FreeLive.LawOfCycles:名字来自魔女毁灭引擎“圆环之理”;L2D Of Cubism

 

DualVectorFoil:名字来自降维工具“二向箔”。

添加评论

Loading