当前位置: 首页 > news >正文

【翻译】西川善司的「实验做出的游戏图形」「GUILTY GEAR Xrd -SIGN-」中实现的「纯卡通动画的实时3D图形」的秘密,后篇...

http://www.4gamer.net/games/216/G021678/20140714079/

 
  连载第2回的本回,  Arc System Works开发的格斗游戏 「GUILTY GEAR Xrd -SIGN-」解说的后篇送到了。前篇的最后预告的那样,本回,是只能看到Anime的3D图形的2D格斗游戏产生所采用的细小方法为中心的介绍。
 

变形的几何体,替换几何体

GUILTY GEAR Xrd -SIGN-的图形,看上去是Cel Anime风格,并不是什么都采用Toon Shader。这以外的部分布置的独特的方法也完成了很大的作用。
战斗场景。Ky和Sol正在伊利里亚的城下町对峙。前面的是旅店,左侧内部可以看到街道。
 
     首先,不经意的看下 GUILTY GEAR Xrd -SIGN-的战斗场景。各种各样的建筑物和背景对象排列着,这些不是[布景的一张绘画],而是通过3D模型来表现的,  从用户视点也很容易辨别。
    让对打的两个角色向左右移动的时候,近景会向左右很大的移动,远景会慢慢的向左右移动。是2D格斗游戏图形里常见的背景表现,实际上这里,隐藏着意想不到的秘密。
 
    希望看下下面的截图
 
伊利里亚城下 町的背景里的,建筑物的Mesh的单体表示,挪动摄像机。就看到了非常有冲击性的图形。
    那样,场景中的近景,建筑物等背景3D模型有相对强烈的远近透视,是因为 有意图 把模型的向深处扭曲。
    另一方面,一定距离以外的远景的3D模型群,虽然没有附加透视,但通过实际尺寸Scale,也被大幅的小型化了。
 
    这样配置模型是有理由的。
    没有附加透视的正确尺寸缩放的模型,变得无法表现出场景的深度感。
    远景对象缩小也是相同的理由,特意的缩小后放置在并不是那么远的距离上,战斗场景打斗时,与角色向左右移动一起,让远景物体一样向左右移动。
 
     真实的Scale的情况,如果要把建筑物就那么小的来放置位置,必须配置在相当远的地方。想到在现实世界也有经验的,远方的景色自己左右移动数米也几乎没有移动。变成这样的2D格斗游戏的背景也变得没有变化,为了更好的运动,把小的3D模型配置在场景近处。
 
GUILTY GEAR Xrd -SIGN-的远处的小的背景物很好移动的例子(※没有声音)
读了以上的说明的话,这次,对战斗中看不到的(屏幕)内侧的游戏世界是怎么样的也感兴趣的人是不是也有了呢。这一点, 石渡氏在下面进行说明。
 
石渡太輔氏(General Director)
石渡太輔氏:
     K.O的场景时,摄相机会旋转,通常 摄像机也会朝向 内侧的方向。因为这种情况,内侧的,Camera看到的范围的背景对象也要好好的设定。
   还有,剧情场景的情况,使用了一部分2D的渲染布景来做背景。随着照摄像机工作,渲染布景的2D背景动态的移动,2D背景自身用电视Anime的理论来处理的地方也是有的。
 
对话场景(上),从别的角度看的截图     
 
伊利里亚城内的拖拽摄像机  。关于战斗场景的视点内侧的模型也可以明白。   
 
   背景关联有1个补充,背景的集群角色(路人角色),接近战斗舞台的是做成3D模型,远景的东西是"纸片人",  变成动画的billboard。
 
   那么,在战斗中登场的主要角色是约4万面多边形的模型,像前篇介绍的那样,和一般的基于3D图形的游戏角色有稍微不同的动作方式。
 
 Faust的开襟 (?)追加部件的实现。
 
    关于一般的3D图形,角色是用模型内部配置的骨骼来运动的,这里追随成为外皮的3D模型的结构来获取姿势或变形,并实现动画。
      GUILTY GEAR Xrd -SIGN-是情况是,基本的动作上,虽然也是根据这种方法的,但例如像毛发,刀剑的形状变形那样的攻击动作就无法实现了,那种特殊情况,要把3D模型的一部分部件替换来处理。
 
头发变形的Milia的情况,准备了追加部件,来进行替换的样子
 
    这个理由 坂村氏在接下来做了叙述。
坂村英彦氏(Art Director 兼 Chief Animator)
坂村英彦氏:
    每个角色的运动,要像Cel Anime的动态表现那样,进行独特的控制。和一般的3D游戏图形不同, GUILTY GEAR Xrd -SIGN-的角色们,脸上的眼睛和鼻子,以及嘴的"大移动",有现实的人无法做到的那种部位的伸缩或肥大化,反过来缩小忽略的事情也是有的。
 
     玩家可以看到游戏画面上的漂亮的事。对于GUILTY GEAR Xrd -SIGN-的图形来说就是正义的。
 
关于一击必杀的剧情场景BEDMAN的使用例子。一开始,制作的是从哪个方向看都说得过去的外表一样的表情(上),初期印象的设定图(中央) 不同表现的地方很多。因此,驱动Rig,调整目鼻口的位置和角度(下)。因为追求[从摄像机里看的印象是要一样的]的事情,实现了角色有效果的演出。
 
    GUILTY GEAR Xrd -SIGN-上登场的角色,和一般3D游戏角色加入了同样的骨骼,这些骨骼的运动方法和控制方法,给予了高度的自由度。
    例如眼球,可以在脸内非常自由的移动,嘴是可以像脸部体积变化那样变形和开闭。手足也可以自由的伸缩。这就是为了实现我们常见的[Anime的积极的表情表现]而组装进去的。
    滑稽的[圆圆的眼球],表示愤怒的标志等漫画的记号表现,果然是这个系统无法对应的。为此,这种漫画表现必须要进行部位部件的替换,以及部分部件的附加,还有就是用Texture表现的方法来对应。
石渡氏:
        像突出手足的一部分的姿势,只是调整视角(Angle of view),并没有动态的来表现。要很大的显示突出的手,为了强调远近感要扩大视角,深度方向的脸就变得很小了。
    这种手被很大的显示的情况,拉伸3D模型方面的手腕,让手靠近摄像机。结果, GUILTY GEAR Xrd -SIGN-的摄像机视角没有变化,可以说是在角色模型上附加了视角 (笑)。
 
最终截图(上),为了实现这种而进行 “体格変更”的揭秘截图(下)
 
坂村氏:
    尽管如此,这种 「角色模型的部分进行扩大缩小或骨骼伸缩」的表现,标准状态的UE3并不能实现。
 
家弓拓郎氏(主程)
家弓拓郎氏:
    对于格斗游戏,根据动作进行部位或姿势的强调的事情是家常便饭的。挥出拳头的动作是要把拳头变得更大一些来表现,踢腿也是把脚伸长。为了进行这样的表现,必须要让骨头(bone)对应的 x轴,y轴,z轴分别的扩大缩小处理系统,UE3并没有对应的。
 
山中丈嗣氏:
    UE3本来就是为了制作照片真实系游戏而制作的游戏引擎。[把骨头的三个轴分别自由的扩大缩小]这种非现实的表现可能是没有必要的。
 
本村・C・純也氏:
    标准状态的UE3,是三个轴同时应用1个参数来对应骨头放大缩小的表现的。这么用的话,可以表现出变形的像二头身一样的角色。
通常头身和而头身角色(参考)。还有,这里展示的二头身角色,并不是本文谈到的[ 3个轴 同时扩大缩小来实现的UE3的基本机能],而是通过Arc System Works对UE3进行[3个轴分别扩大缩小的机能扩张]来实现的。
 
部位扩大的实际使用例子,上边是产品版使用的最终截图,下面是没有使用部位扩大的状态
 
     「为了进行GUILTY GEAR Xrd -SIGN-的有效果的动画制作的,三个轴分别扩大缩小骨头的结构是绝对必须的」是负责动画的 坂村氏所主张的。主程的 家弓氏中途放弃型的改造了UE3,把这个结构实现了。 [正是因为UE3提供了源代码才能做到] 坂村氏回顾到
 
    当初,虽然 家弓氏是 [制作进去的骨头太多,骨头自身移动等是无法对应处理的]这样来考虑 坂村氏的提案的, 坂村氏进行了反驳。
 
坂村氏:
    确实,怪物的部位肥大化表现或伸缩表现, 一部分 采用未改造版UE3的游戏里也实现出来了。因为是[一部分的角色]所以也是运行的。
 
    但是 GUILTY GEAR Xrd -SIGN-的情况是,登场角色全部都必须是这种表现,首先手足全部加入这种配置的情况进行试运算,可以判明骨头数膨胀了4倍。
 
家弓氏:
     我知道这个试预算后就差不多放弃了 (笑)。4倍的话,果然性能上是吃不消的。
    结果, 家弓氏对UE3的改造,对应了骨头的三轴分别扩大缩小处理。而且,移植到实际的制作阶段的时候,使用这个结构让手足等简便的扩大缩小,伸缩自如的调整的定制接口也制作了。这样一来,在肢体操作上,使用这个定制接口,就可以进行手足的扩大缩小,伸缩的调整的动作制作了。
 
动作的设定工作中,预览画面里进行手足的扩大缩小的例子。在 「SoftImage」上,把小型的窗口内的数字上下移动来变更任意轴的Scale,让Rig进行Setup。
 
家弓氏:
   辛苦的搭载了[骨头的三轴分别扩大缩小处理系统],在后面登场的UE4里是作为标准机能来实现的。嘛,除了我们以外也传达了[希望安装]的要求的很多吧 (笑)。

做成3D模型的特效群

 发出的必杀技等附带的特效类的东西,除了一部分例外的大多的都是3D模型。
    具体的,烟,火焰,各种闪光,防御特效等等。
 
石渡氏:
    Finish(必杀技)的时候等,有一部分摄像机的3D运动的演出,特效用billboard的话哗啦哗啦的感觉样子很不好,就下决心把特效群也用3D模型来做了 (笑)。
 
     这个是[说起来容易做起来难],实际问题,还是花相当多的力气活来实现的。
    例如,下面展示的烟的特效,看起来有一点像流体动画,实际上,是美术师通过手动1帧1帧的建模做出来的。飞舞着膨胀,破裂的爆烟效果,为了能像看到的那样,也是美术师1帧1帧做出来的。
 
烟的特效(上),模型是3D数据的缘故,移动摄像机,变得好看。
跳跃时产生的烟的Wire Frame 显示
Zato的影子融化的特效模型。附加动作前的素体。
 
本村氏:
    当初,用骨头来牵引多个球体模型运动的实验也做过的,是无法令人满意的东西 ……。结局是变成了力气活来实现 (笑)。
    操纵影子的 Zato,使用技能可以液态和溶解到镜子里活动,中途还可以变形为 Zato的角色模型,中途要另外准备[影子溶解]特效模型来进行替换。
这里是附加了动作完成版的影子溶解模型(上),下面是,3D模型的证明,尝试着改变了角度。
 
    顺便说一下,目前介绍的特效群的里面,烟等纯然的特效类没有进行光照(lighting),阴影等是直接烘培到Texture来做成的。也没有使用出现轮廓线的处理。火焰或闪光等发光系的特效,是只能看到光,并不实际的照亮周围,这个是2D格斗的情况,根据条件特效外观变化的话,担心游戏感觉会出现故障。
    另一方面, Zato的影溶等,对于附加在角色上的部件类型的特效,要进行光照。3D特效的采用,今后也要进行慎重讨论。

作出Cel Anime动作  Limited Animation

    现在,Toon Shader的这个技术名在游戏者之间相当的一般化了。可是,第一次看到 GUILTY GEAR Xrd -SIGN-的人,没有看出本作的图形是基于3D的情况并不少。其中的1个理由就是, GUILTY GEAR Xrd -SIGN-的图形好像[不是光滑和流畅的运动]的 。
 
    DreamCast的[JET SET RADIO ](SEGA 2000年)是这样,前篇举例的 「XIII」 (Ubisoft Entertainment,2003年)也是这样。过去基于Toon Shader的游戏图形是大量存在的,因为是3D图形,每秒30帧或60帧流畅的运动来显示的。这个理由也是理所当然的,终究基于的是实时的3D图形,因此这样只有Anime风格的Lighitng和Shading,角色的动作的动画图是每帧生成的完全也是当然的了。
 
    但是Arc System Works,得出了[这种流畅和GUILTY GEAR的风格是不符合]的判断。
    知道的人也可以思考下,电视Anime等基于Cel的Anime,是以每秒8帧或12帧的程度成立的。因此,观看电视Anime时,遇到 作画 出来的角色和基于CG的机械在同一个场景时,每秒8帧运动的角色和每秒60帧运动的机械的运动流畅度会感觉到差异,察觉到这种违和感的人也是有的吧。
    有时看电视Anime的Opening Music和Ending,全CG化的角色舞蹈的类型,也和Anime的正篇不一样,是光滑的运动的,可能会感觉到微妙的违和感。也许,越是看习惯基于Cel的Anime的人,越可能对Anime风格的图像流畅运动怀有违和感。
   
    关于这一点, 坂村氏是在下面做了描述。
 
 
坂村氏:
    结果是,我们一边采用60帧动画的3D图形系统,一边强行的采用作画Anime的帧布局。 GUILTY GEAR Xrd -SIGN-的剧情场景(事件场景),要比Cel Anime的每秒8~12帧多一次,以每秒15帧为基本。
    对于战斗场景因为动作是和技能的性能直接联系的,[1个姿势用多少帧来表示],与规格进行配合,在脚本上来对帧做分别的指定。每个姿势的表示帧时间不是固定的,每个技能是 「2F, 3F, 3F, 1F, 1F, 2F, 2F, 3F, 4F」 (※筆者注:1F≒16.67ms)的感觉。
 
    在Anime业界,把像迪士尼那样每秒24帧作画的动画称作[Full Animation],同样是连续帧显示的,每秒8~12帧程度运动的通常称作[Limited Animation],强硬的粗糙帧分布的 GUILTY GEAR Xrd -SIGN-的动画,确实是L imited Animation System
    Limited Animation,和普通的3D图形的动画在制作风格有一些差异。
    一般的3D游戏图形的角色动画,是有对角色模型内部配置的骨头的[轨道]进行修正的印象。轨道的制作是使用高次曲线函数(F Curve),或者是基于动作捕捉取得的数据。
    与之对应的, GUILTY GEAR Xrd -SIGN-的 Limited Animation是,让角色一点点的运动,1帧1帧的姿势修正的做成。像粘土动画(clay animation )一样的流程。
 
坂村氏:
   最开始是使用F Curve每秒60帧的Full Frame的来运动角色,也试验了从这60帧的动画中抽去(帧)的制作手法,但是那样的话,只能看到[丢帧的3D图形] (笑)。
 
Full Animation和Limited Animation的差异
动画~
 
相同的动作,前半是5次Full Animation,后半是5回limited Animation处理的例子
 
    实际制作相关,首先是故事板( 絵コンテ )的制作
    这个故事板是,例如必杀技是[全体60真构成的][30帧时出拳,这个时候开始产生碰撞判定]等等,作为格斗游戏的配置也是这样设定的。而且,这个故事板会被交给动画师,[每帧的角色模型的姿势]就被决定了。
 
May的必杀技相关的故事板。20张记录了54帧的信息
 
   Arc System Works的美术师,因为都是2D格斗游戏相关的动作制作的专家,那样的角色姿势也是擅长的吧。[没有依赖类似F Curve等算数的动作生成]。
 
    20个Frame的幻灯片演示
 
    用2秒来显示  [基于上面的故事板制作的20帧]的幻灯片例子
    即便是Limited Animation,游戏的配置也是每秒60帧来显示,这是为什么呢,[影像配置是每秒60帧]的意义,是动画的帧的更新率,成为前面所说的[制作显示的帧的间隔]。
    例如,有个姿势是2F时间的设计的情况,对于每秒60帧(1帧约16.67ms)的显示系统,一样的姿势是33.33ms (=16.67ms×2F)的间隔来显示。
 
    另外一方面,角色跳跃时产生的放射性轨迹的活动和运动的飞行道具等等的运动都是60fps来更新的。还有,考虑到最新的还没有描述的,玩家的指令输入的时机也是以1/60秒的间隔来接受的。
 
石渡氏:
    想要剧情场景变的好看,每帧调整姿势时,要把角色模型的各个部分的位置,以及这个角色专用光源的位置等等,1帧1帧的调整。摄像机围绕角色的动画的情况,每帧都要调整鼻子的位置 (笑)。
     GUILTY GEAR Xrd -SIGN-的独特的图形表现,不光是先进技术,只有有这种熟练的Anime的绘画能力和品位的积累才能实现。
May的一击必杀确认的Limited Animation(※没有声音)
 

让游戏系统更像2D格斗的技巧(1) ~碰撞判定的设定和3D的美观的吸收

山中丈嗣氏(Director)
    一边采用3D图形,一边要让为这个漂亮的画面2D化而采用的各种努力产生结果,让截图可以在外行看来肯定的判断是[2D图形]的等级而努力着。
   但是,开发组还没有满足,为了[游戏感觉上更贴近2D格斗游戏]而进行改良。关于这个的概要, 山中氏在接下来回顾。
山中氏:
     「作为2D格斗游戏的碰撞判定数据」,和我们动手开发的历代的2D格斗游戏一样,在2D的矩形领域来进行设定的。但是 GUILTY GEAR Xrd -SIGN-基于3D的图形,因为游戏性是2D格斗游戏的,并没有采用和一般的3D游戏那样,用球体和立方体,胶囊形状那样,立体的碰撞判定的结构。
Arc System Works内部称为 「碰撞设定工具」的工具。碰撞上,和以前的2D格斗游戏一样,使用矩形的状况。
    碰撞判定区域,具体的被攻击 区域 (受到攻击时会受伤害的 区域 )和攻击 区域 (接触到敌人就会给予伤害的区域)的设定,前篇稍微接触的一样,作为熟悉的公司内工具来使用。关于 GUILTY GEAR Xrd -SIGN-,通过Limited Animation System作出的角色动作,1帧1帧的被看作2D图形,对应这个帧,用公司内部工具,作为2D进行碰撞判定设定
角色的外表没有做什么准备的例子(上)。画面左端和中央的Sol的显示方式有变化。下面是这个碰撞判定领域的显示,有着明显的偏移。
 
    但是,这里有1个课题。
    3D图形是,从视点所见的视野用四边型的画面切下来显示结果。但是,原本的来说,我们看到的视野,尽管是无意识的,但成为了从球面内壁展开的东西。
    这里的问题是,[球面内壁形状的视野]透视到四边形的显示方式。赛车游戏是,从自车后面的视野内飞出的车,到了自车位置侧面附近时,看起来会有奇怪的拖延。这个是,作为地图采用的是麦卡托投影法,会有在画面外围附近被拉长一样的弊病出现。
    实际上,即使是 GUILTY GEAR Xrd -SIGN-,什么方法都不用的来绘制角色的话,可以确认画面内左右端的角色会显示的稍胖,中央的会看起来稍瘦的倾向。就这么放着不管的话,前面所说的[作为2D数据设定的碰撞判定区域],会和角色在画面的位置产生偏移。
 
    为了消除这个偏移,要对应角色在画面内的位置,对碰撞判定区域做适当的调整,或者是抑制因为角色在画面内的位置变得"胖或瘦",在修正碰撞判断区域和一直保持一致之间做选择也是有必要的。
 
     GUILTY GEAR Xrd -SIGN-的开发组,从这两者中选择了,后者的方法。2D格斗游戏的情况,因为对打的角色在画面的左右或中央位置外观有很大变化是很难受,是理所当然的选择。
    顺便说一下,基于3D图形的2D格斗游戏的前辈的Street Fighter IV也是,和 GUILTY GEAR Xrd -SIGN-选择了同样的方法。
    译注:这个在OpengGPU也翻译过的,链接:
 
    那么,实际的"胖瘦"调整是,当3D模型在2D画面绘制的时候进行[3D->2D投影 ]的方法窍门。
     3D→2D的投影是,近处的看起来大,远处的看起来小的[透视投影],和它不同的有[平行投影](正交投影), GUILTY GEAR Xrd -SIGN采用的事,30%左右透视投影,70%左右平行投影的强度组合的[混合(  hybrid )投影]。
    使用这个,角色在靠近左右端时就变得胖,在中央附近就变瘦的的情况得到了抑制,在画面的哪个位置都是大体上一致的大小。
石渡氏:
    严格的话,同样的混合投影也要在纵方向上使用,(虽然没有使用)在横方向是致命的错误,但试玩者们也没发觉到违和感,就把导入放弃了。
 
透视投影100%的画面(上)和它的碰撞判定区域 
 
平行投影100%の画面(上) 和它的碰撞判定区域 
 
透视投影30%,平行投影70%组合的最终版(上)和它 碰撞判定区域
 
石渡氏:
    还有1个必须要导入的 ,二个角色重叠的状况的处理系统。
    关于像素画(=Sprite)是,上面绘制的角色,会把下面绘制的角色覆盖的感觉来显示。在3D图像上, 角色是立体的大小,两个人距离接近,一个角色的突出的手腕就会插入到另一个角色里。回避这种情况的策略的讨论是有必要的。
 
    最终的是,绘制攻击方的角色时,会在3D空间上把深度(Z)值向视点方向做越1米的Offset,这样就不会有重叠发生了。总之,攻击方的角色,会无视被攻击方的角色的3D的前后关系,用深度(Z) Test一直合格的进行绘制。
深度调整前的角色绘制(上)和它的ZBuffer(下)。两个的中间部分重叠了。
深度调整后的角色绘制(上)和它的ZBuffer(下)
 
本村氏:
    对打的两个角色,在3D坐标系处理时在同一个Z轴上相对的。在绘制的时候能够介入使用一些方法。
    使用双臂抓投对手的技能的时候,被投掷的一方会插入到投掷放的手腕中,要把这个Offset去掉进行调整。一部分,火焰的特效 要遮掩来做欺骗的地方也是有的。
 
Sol和Ky对峙的状态(上)摄像机移动后所看到的是下面的截图。看出角色一起在同一个轴上
 
GUILTY GEAR Xrd -SIGN-的让摄像机旋转的战斗场景
    通过这些处理系统的实现,大多数不自然的状况都没有了,像巨人角色的[Potemkin],深度方向上很大,会有和其他角色紧贴在一起的情况,确认陷进角色里的情况也有。只是,做了[不妨碍游戏]的判断,就这样照原样保留了。

让游戏系统更像2D格斗的技巧(2) ~Gauge的绘制和角色反转时的处理

   
    重视2D格斗游戏玩起来更容易的画面的制作,要进行体力槽等各种Gauge(槽)的绘制。Gauge类是,把要渲染的Texture贴在平面 多边形上的东西,这个多边形,是在战斗到角色的后侧的Z位置进行配置的。这是因为,角色高跳和 Gauge重合的情况时, Gauge会在角色的后面进行绘制。
    但是,空中的打上攻击动作开始时,摄像机角度变化的演出时, Gauge是例外的绘制在前面。
本村・C・純也氏(Lead Modeler 兼Technical Artist)
 
本村氏:
    像视点环绕那样,摄像机角度大胆的变化的演出的时候, Gauge会陷入到背景那样的干涉被预见到,把 Gauge在角色后面的特殊处理无效化, Gauge类在角色的前面了。
    通过[进入摄像机视角演出的时候,玩法自身暂时的中断, Gauge配置在前面,玩家也不会有反应 ]来判断的。
 
通常的战斗场景和 Gauge类在角色的后面(上),摄像机角度变化时是在前面(下)显示
 
    现实世界里,二个格斗家会采用朝向对手把左肩向前的战斗姿势来对峙,这个被侧视角捕捉的场合,朝右的格斗家是胸部被摄像机看到的姿势,朝左的格斗家是背部被摄像机看到的姿势。但是2D格斗游戏的情况,角色向左和向右的在画面上[看到的姿势]有变化,就很难进行游戏。2D格斗游戏不是左右对称的对峙就会有困难。
    对于以前的2D格斗游戏,这个处理只是单纯的把像素画描绘的Sprite左右反转来表示就可以了。那么,3D图形实现的 GUILTY GEAR Xrd -SIGN-也同样的进行Sprite反转显示。
「GUILTY GEAR XX #RELOAD」的图,2D时代的GUILTY GEAR对峙的样子
(C)ARC SYSTEM WORKS
    事实上,如果只是把角色模型左右线对称的反转,把这个3D模型沿纵轴(Y轴)对称线进行反转(=[构成3D模型的顶点的X坐标]的正负值替换)再进行替换就可以了。当然,前面说的角色专属光源也必须要配合角色模型的反转迅速的转过来。
    这时还可能有的问题是,一部分角色的衣服上描绘的文字。例如Sol的腰带上刻了[Free]的文字,单纯的反转角色的3D模型的情况,文字就变成镜像文字。
 
    实际的游戏画面这里可以很好的回避,这就是,在反转的时候,把[描绘文字部分的Texture Mapping用的UV Map]做切换,正方向的文字是通常Texture Mapping处理的结果。3D模型反转时,文字Texutre不能是镜文字,适当的,修改成为正方向贴上。
在使用战斗场景中,接近角色的地方。请注意腰带部分的[Free]和覆盖手甲的装具部分等的符号。
Sol的文字Texture Atlas。底色(透明色)的部分是中性灰色( neutral gray = 0.5)
    
阴影文字Texture的例子
本村氏:
    文字的 Texturing的时候,还加入了一个小技巧,实现了[将Texture的亮度的2倍,和Base Texture进行合成(Blend)的配置]。是把设计的Texture亮度的0.5倍进行保存的,变成2倍,再按照1.0倍设计的Texture进行使用的原因是,Texture图像的亮度超过0.5的情况,底色 变得过亮。把这个配置很好的实现,[立体设计的阴影文字]可以很方便的表现。
    文字的 Texturing是,把像半透明贴纸一样的1个多边形,覆盖的贴在3D模型的表面的印象。想象成在塑料模型上贴上贴纸或贴花(Decal)能容易理解一些。
    这个结构的根本,是 把作为花纹和基底 的Base Texture,与文字用的Texture分开,看起来是为确保充分的分辨率。
    相当于贴花的文字Texture进行绘制时,和基底(Base Texture)进行Blend是重要的一点, GUILTY GEAR Xrd -SIGN-使用 「×2乘法计算」的Blend公式来做乘法Blend的应用。
    把Base Texture作为[Dest],文字用的Texture作为[Source],计算公式是下面这样。
          Dest×Source+Source×Dest  =  结果是乘法计算的2倍
    这种情况,因为是Texture内容的2倍的值 和基底(Base Texture)进行乘算,得到了 (文字Texture的颜色)[不足0.5是暗,0.5是透明,超过0.5是亮]的结果。
    因为这个Blend方法并不是UE3标准配备的机能,通过 家弓氏手动来追加实现。
    阴影文字简单的尝试,就必须把表示文字的亮的部分的Texture和表示暗部的Texture分别Texture Mapping。但如果是这种技术,1个Pass的Texturing就实现了。

重点有效的使用Post Effect

    近年来照片真实系的3D游戏图形,倾向实现各种各样的Post Effect。对于这个,把像Cel Anime作品风格为目标的 GUILTY GEAR Xrd -SIGN-的场合,可以说是相对次要的东西。虽说如此,但Post Effect的Pass还是有的。
 
    像前篇传达的一样, GUILTY GEAR Xrd -SIGN-的Anti-Aliasing的处理采用了FAXX,FXAA是用Post Effect实现的。还有 GUILTY GEAR Xrd -SIGN-的RenderTarget采用的是aRGB的16位浮点数类型的64位Buffer,因为实现了对应 HDR(High Dynamic Range)Rendering Pipeline,高亮度部分溢出的Light Bloom效果的Post Effect也被使用了。
战斗场景,让FXAA有效化的最终截图(上),和无效化状态的截图(下)
 
这个是同样的战斗场景,最终截图(上)和所有Post Effect都无效化的截图(下)的比较
 
石渡氏:
    最近的Anime也是,因为 这种Light Bloom的效果也被普通的使用了,所以考虑不会有违和感。除此之外, Diffusion的效果,也用Post Effect给予了。
本村氏:
     对于有明暗精确的二值划分感觉的Anime的画面, Diffusion在 增加柔和的风格上是非常有用的。和Light Bloom 在亮度值1.0以上的地方才处理相比, Diffusion在较少的亮度值的地方也能表现效果。
 
     Light Bloom和 Diffusion,都是给予把亮部模糊溢出的效果的东西,分别作为系统的Filter处理来实现的。具体的是,  使用 Light Bloom Filter后,进一步的使用 Diffusion Filter。 Diffusion虽然在散乱的处理上比较有限,但是有在某种程度的亮度地方都可以使用的印象。 石渡氏是,[主要的格斗游戏部分,太过模糊的话游戏也会变得难玩,这种Post Effect加强的地方以剧情场景(Cut Scene)为中心]这样的叙述着。
    通过Material,可以设定Texture给予1.0以上的 亮度 来作为发光体。
 
Light Bloom有效(上)和无效(下)
Diffusion 有效(上)和无效(下)
使用发光体Texture的Ramlethal(上)和 Potemkin(下)

结束

    以上,就是 GUILTY GEAR Xrd -SIGN-采用的独特的图形技术,分2回来介绍。
    只看完成的最终游戏游戏画面,因为是 相当的自然 2D图形,没有发现是基于3D图形的玩家也很多。
    实际上,作为开发方,最初也是担心[真的能用3D图形系统再现2D格斗游戏图形么],开发完成时是[基于3D图形的事情会被注意到么?]这部分担心。作为开发小组也想在游戏系统方面再多加入一些[3D游戏图形特有]的演出,不过作为街机游戏,仍然要以[2D格斗游戏要容易玩,没有违和感]为优先,好像现在的状态变得稳定了。
    发售预定了的 PS4&PS3版上,请期待那种[3D图形特有的]附加要素的加入吧。


    还有,作为开发组,这次的 GUILTY GEAR Xrd -SIGN-的项目总的来说,积累了大量对于[使用3D图形来做2D图形表现]的技术诀窍。同时,也确实感到这种方式还有未开发的表现领域,今后还要进行这个系统的技术开发,好为以后的作品所使用。
    确实,3D图形的研究领域有 「NPR」(Non Photo Realistic)的表现和 Stylized Rendering等等非写实的领域,日本的Anime风特化的东西还是很少。在这个领域进行开发,必须要有可以理论的分析日本的Anime的风格的能力和知识,以这个意义来说 GUILTY GEAR Xrd -SIGN-的开发组是胜任的。
    还有2D格斗以外的应用等等,不光是新技术的开发,技术的应用力也提高了,希望让我们再一次的震惊吧。

相关文章:

  • 仿小米便签图文混排 EditText解决尾部插入文字bug
  • 前端展示用部分CSS
  • 解剖SQLSERVER 第三篇 数据类型的实现(译)
  • DB2数据库用 With语句分隔字符
  • 处理和引发事件的规范
  • 图像的边缘提取
  • Linux之shell编程基础
  • 測试之路2——对照XML文件1
  • 魅族 连接 mac 调试
  • PhotoSwipe - 移动开发必备的 iOS 风格相册
  • https://github.com/cykl/infoqscraper/
  • 数据结构实验之栈四:括号匹配
  • django 安装/部署过程
  • 使用expdp的心得
  • 安装Ubuntu开发工具中心
  • [deviceone开发]-do_Webview的基本示例
  • 2018一半小结一波
  • android高仿小视频、应用锁、3种存储库、QQ小红点动画、仿支付宝图表等源码...
  • CSS 专业技巧
  • Hibernate最全面试题
  • in typeof instanceof ===这些运算符有什么作用
  • Koa2 之文件上传下载
  • Material Design
  • MySQL的数据类型
  • Quartz实现数据同步 | 从0开始构建SpringCloud微服务(3)
  • 检测对象或数组
  • 离散点最小(凸)包围边界查找
  • 名企6年Java程序员的工作总结,写给在迷茫中的你!
  • 适配mpvue平台的的微信小程序日历组件mpvue-calendar
  • 微信端页面使用-webkit-box和绝对定位时,元素上移的问题
  • 一些关于Rust在2019年的思考
  • 原生Ajax
  • 【干货分享】dos命令大全
  • kubernetes资源对象--ingress
  • ​ArcGIS Pro 如何批量删除字段
  • # Apache SeaTunnel 究竟是什么?
  • # 数论-逆元
  • #Lua:Lua调用C++生成的DLL库
  • #NOIP 2014# day.1 T3 飞扬的小鸟 bird
  • #鸿蒙生态创新中心#揭幕仪式在深圳湾科技生态园举行
  • $(function(){})与(function($){....})(jQuery)的区别
  • (C语言)二分查找 超详细
  • (delphi11最新学习资料) Object Pascal 学习笔记---第2章第五节(日期和时间)
  • (Redis使用系列) SpringBoot中Redis的RedisConfig 二
  • (TipsTricks)用客户端模板精简JavaScript代码
  • (动手学习深度学习)第13章 计算机视觉---微调
  • (二)Linux——Linux常用指令
  • (二十一)devops持续集成开发——使用jenkins的Docker Pipeline插件完成docker项目的pipeline流水线发布
  • (附源码)springboot 基于HTML5的个人网页的网站设计与实现 毕业设计 031623
  • (附源码)springboot猪场管理系统 毕业设计 160901
  • (附源码)ssm学生管理系统 毕业设计 141543
  • (附源码)基于SSM多源异构数据关联技术构建智能校园-计算机毕设 64366
  • (机器学习-深度学习快速入门)第一章第一节:Python环境和数据分析
  • (亲测有效)解决windows11无法使用1500000波特率的问题
  • (一)SpringBoot3---尚硅谷总结