游戏开发论坛

 找回密码
 立即注册
搜索
查看: 7032|回复: 0

《蓝色协议BLUE PROTOCOL》技术分享解读!

[复制链接]

4万

主题

4万

帖子

8万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
85217
发表于 2020-11-19 14:40:18 | 显示全部楼层 |阅读模式
「ブループロトコル」を“劇場アニメクァ£ティ”たらしめる手法とは?ゲーム制作におけるアニメ表現技法を紹介【CEDEC2020】 OnlineGamer

蓝色协议现在也算是最强的三渲二游戏之一了,所以一直在等发售好扒,没想它还没正式上线就发了这东西,看来也是个和ARC一样乐于分享的团队……同时也让行业技术壁垒进一步得到了降低,大家饭碗更加不稳了。

但是藏着也没啥用,对你有威胁的人反正肯定都会知道的,还不如让大家都知道。藏技术本来就是件很无聊的行为,你自己独有的技术能有几个?又能起到多大效果?而你不说,当其他人不会说么?

不要违抗时代的步伐。

描边

它使用用模型扩边法绘制头部,并用后处理描边处理其他部分。

微信图片_20201119142624.jpg

模型扩边用了单独储存共点平均法线的方式来修复分叉,是常见做法。它并没有继续解释,我在这补充一下,这个描边法线想在蒙皮网格上正常使用需要转到切线空间,或者直接储存在切线上。

如果想做得更好一点,还可以根据法线的角度方差来增强这部分的描线宽度,这样就能把发尖做出来。

后处理部分则是重点。后处理描边之前不适用主要是可控性差,而像二之国那样增加可控性会耗费比较高的成本。而它现在只用来绘制头部以外的部分,则降低了一定要求。

根据深度和粗细来控制线条的粗细是常用的做法,关键如何指定描边的粗细(通常内部会比外部细,小物体会比大物体细),而它没有给出任何解释。但即使是选择不控制粗细,至少也要通过Mask来屏蔽头部的后处理阴影。

我觉得或许是选择了多个采样点中深度最高的那个像素坐标的信息。这样做虽然在多个物体交会处会不准确,但大概率是OK的,毕竟大家的参数其实差别不大。颜色的定制也可以用这种方法,如果想节省带宽可以用LUT索引来取代具体的颜色值。

然后就是,它用的是外描边(忽略比自己深度低的部分的贡献),还是双侧都有?如果用外描边,好处就是和扩边描边表现比较一致,双侧则更容易实现描边的软过渡(消除锯齿)。但蓝色协议也可能是靠TAA来消除这部分锯齿的,所以不太好判断。我觉得是后者。

微信图片_20201119142633.jpg

这部分用色彩差异来生成内部描边。不过蓝色协议其实这些物件都是单独建模了的,本来就能生成大部分描边,只是因为后处理的深度差异太低了,需要利用这些数据强化描线的粗细。另外,原文表示描线的粗细是由这张图的亮度差决定的,画面结果也确实像是这样。但是用这种方式定义宽度必然容易产生冲突,而看结果,大部分情况生成的描边都是等宽的(clamp到最大值了?)

我觉得他们应该放弃了精确定义不同部位的描线粗细差异,就算有参数应该也只是屏蔽描边用。毕竟真需要纠结细节的时候,也可以直接换普通扩边描边。

暗部和投影

微信图片_20201119142636.jpg

它搞了一个逆光时亮部区域增大为70%来解决背部缺少光照的问题。

这是个办法,缺点就是逆光的时候轮廓光的感觉有点过强了,另一个方案是逆光扭转光源,缺点是转过阈值时会发生突变。

但这样做会导致亮部区域和自投影区域重叠了,那么它们实际上没有应用自投影?还是将自投影的Normal bais也一并扩大了?目前看,很可能是前者。但投影显然也是必须要有的,而他们用了固定的控制图和后处理阴影两种方式。

微信图片_20201119142640.jpg

此图的蓝色区域就是降低光照阈值的依据。在正面能够看到阴影,但是光照从下方发射时阴影就会消失。这个方案其实效果并没有真实投影好,既然这样做就说明并没有真实投影。

微信图片_20201119142644.jpg

这个帽子的投影其实是通过偏移采样深度图来生成的(偏移一定距离采样深度和当前深度比较,高的话就是阴影),可以看到它异常地和投影物边缘保持了等宽。这其实已经是一种常用技法了,需要预先生成pre-depth,不需后处理,嘴上说成后处理只是一种让人容易理解的说辞。而这个种影子其实最适合的地方是额发的投影。

要我说的话……正常的投影还是需要有的,只有正常的投影才能处理裙子投腿,头发投背这样的情景,虽然大部分情况自投影需要屏蔽,但只有一处用,也该有。而处理好屏蔽物体自投影的问题也可以做到不和70%亮部冲突,虽然确实麻烦。现在这样也是他们自己权衡后的结果吧。

微信图片_20201119142647.jpg

至于身体上标记的固定阴影区域,他们采用了差异不大时候融合,差异大时变得更暗的做法,让逆光时候也能看到这些阴影细节,不失为一个折中的好办法。

微信图片_20201119142650.jpg

一般天光其实都是顶光(为了生成较少的建筑阴影),所以直接打人脸上都会完蛋。蓝色协议是直接在人物身上将天光方向拉平了50%,也就是仰角最多45度。这样倒是有挺多好处的,而且可以回避在逆光时,巨乳会被顶光单独照亮的问题(我是用自投影解决的)。

但有一说一,其实身体不少部分都更适合用顶光照明,比如手臂肩膀,平光产生的垂直阴影部分太少了。所以比较好的方法其实是身体正常打光,脸部单独修(然后就会出现照亮巨乳的和暗处的脸部不协调的问题)。

嘛,毕竟没自投影,也只能这样。

其实还有个脸部法线修正的问题。虽然他们没说,但也不一定没修。其实一般模型只要做的足够平滑,光照稍微往上拉一点,就足够形成良好的明暗边线了。所以也不太好判断。

他们强调了因为贴图精度问题而没有使用法线纹理,所以暗部的定制只能用上面提到的固定暗部纹理来实现。头发上肯定用了(在发瓣边缘涂深),脸上用没用也不好说。

微信图片_20201119142652.jpg

这个则是他们比较有价值的设计。通常情况,我们都是专门给一张暗部纹理来表示暗部的色指定,虽然不算麻烦但终究是一个美术工作量。但暗部到底应该是什么样的颜色其实是有规律的,对于纯色贴图尤其如此。

微信图片_20201119142655.jpg

所以他们做了一个变色工具,看界面,第一排的Hue R YR Y GY G……表示的其实是色环,那么数值就是某个Hue的颜色在暗部应当进行的偏色。后面的Saturation和Value则应该对应饱和度和明度,表示的也是暗部应该增减的饱和度和明度值,分为8档绘制了变化曲线。

我不知道是离线生成还是实时计算,其实都行。实时可以用LUT。

它这样有个好处是可以更方便地做服装染色。

而且对非赛璐璐风格的作品帮助更大,因为那些作品的贴图绘制成本较高。

高光

微信图片_20201119142658.jpg

边缘光他们采用了和投影类似的深度检测法,以便生成固定宽度的边缘光,根据光照方向决定偏移距离即可。这个边缘光主要还是面光时出现,用于勾勒人物边缘。

微信图片_20201119142700.jpg

微信图片_20201119142703.jpg

他们为了做一个头发光点搞这么麻烦也是奇了。他们的目标是让光点随着镜头距离而缩小,并不会根据镜头角度移动,整个过程也和法线无关,和一般人想实现的各向异性效果完全不同。但为了实现它,使用了UV2单独为这些高光元素准备UV,这并不是为了拉直UV,而是为了精度和留出可供缩放的空白区域。

微信图片_20201119142706.jpg

然后用一张RGBA控制图来处理。R通道是基本亮度,GB通道记录的是当前像素距离光斑中心点的距离值,A通道不明,有可能是缩放幅度。

具体做法是,当渲染一个像素时,根据读取到的BG通道数据,和当前UV相加,得到光斑中心。然后反过来减这个BG值同时进行一个根据距离的缩放。数值放大的时候,光斑在视觉上就会缩小。

这种做法可以确保光斑的边缘形状和R通道保持一致。

但是……离线生成这张图就要做不少工作,必须让人手动指定每个光点的中心然后生成控制图,而且在固定距离看,人物光斑其实并没有任何变化。

但这种方式似乎是可以做和Normal挂钩的缩放的。一般做法不行,是因为光斑上每个像素点的Normal是不同的,根据Normal缩放的程度就不同,会导致光斑扭曲。但它这个方案,每个点都可以找到一个共同的中心点,只要使用这个中心点的Normal……

对,我取不到这个点的Normal,所以不行。

所以只能如此。

表情

微信图片_20201119142708.jpg

他们这也是挺骚的。

骨骼搞这么多,应该是没有BlendShape做的快的,性能也很抱歉。估计只有在特写时才会开启,那样还行。

BlendShape其实也可以复用的,用SkinWarp一类可以让眉毛睫毛模型跟随脸部一起运动,而脸大家都一样的。

组合也可以通过Mask。

硬要用骨骼搞……是为了减少资源量,或者是为了适应捏脸?

我是不懂了,反正也不做捏脸,应该不会这么搞。

也可能是方便做连续的表情动画吧,BlendShape只能做成多个关键帧,用骨骼调这个或许更方便点。

特效

微信图片_20201119142712.jpg

做不透明的特效应该算是一种风格指导吧。(当然并不是全都是不透明的)

不过必须是不透明特效才有下面的事情。

微信图片_20201119142714.JPG

微信图片_20201119142716.jpg

它们更多使用了体积模型来作为特效的载体,而如果是透明特效……会有排序问题。

微信图片_20201119142718.jpg

这个顶点移动具体怎么弄的还不清楚,总之是为了实现更加有体积感,而非片状的特效。

微信图片_20201119142721.jpg

下面这个是个由多个Mesh进行插值变化的特效,GGX以前也常这么玩的。

微信图片_20201119142723.jpg

他们提到了一个使用不透明特效遇到的问题:多个特效叠加的时候特效遮挡太严重了。他们的方案是让特效移到远处有一个消隐的效果,应该是增加Cutout的值。

微信图片_20201119142725.jpg

但效果也不算好吧,而网点抖动也可以做到让特效一定程度重叠。

估计他们就是要坚持这种不透明特效的感觉。

此外有一点我忘说了。不透明特效还有个好处是对taa更友好。taa的帧间混合是基于深度的,处理透明物体很容易瞎,表现出来是移动镜头透明度变低。为了避免这个问题需要让透明物体也写速度buffer,但透明物体覆盖住的物体就不行了,而它这种alphatest为主的方式就没这问题。

否则……估计只能放弃taa,那么高光边界就很难这么锐利而且没锯齿。那么就只能考虑模糊边界,或者想办法把msaa开起来,延迟部分就不好办。方案选择会有不少变化。


パラ

微信图片_20201119142727.jpg

他们抛出这么个词然后假装我们都知道是啥意思。反正我是不知道。

它指的是上图左上角那块偏蓝的部分,有点类似屏幕暗角。在整个游戏里都始终存在存在,是蓝色协议的画面特色,也对其“动画感”的产生起到了很大的效用。

微信图片_20201119142730.jpg

微信图片_20201119142732.JPG
效果放大10倍的效果

这个效果基本是一个蓝色的变色遮罩,是一个软边的弧形,存在于屏幕上方,和太阳方向有关。

其实说白了,就是一个画遮罩进行区域调色的后处理特效。如果走正常动画流程,这一步都是肯定有的。所以如果你想做出和动画差不多的画面,当然也应该走这个流程。而且,这个东西不能用光照代替,因为光照是HDR下的,而后处理特效是LDR的。而调色只有在LDR才是对的。

它必须是一个后处理效果。但后处理效果一般不会再去画指定Mesh,只会给你一个参数调整工具,怎么设计这个效果就是个问题。

蓝色协议的剧情动画部分之所以亮眼,也是因为有这种效果:

无非就是各种遮罩圆的位置,硬软边。不太在乎性能是可能的。虽然他们什么都没说,只要知道是这是用后处理做的,就可以试试。只考虑固定过场是可以搞的。

后处理也是可以调用管线内容画Mesh的,定制能力足够就行。要效果就不要纠结这点性能。

场景

蓝色协议的场景其实基本就是写实场景,只做了一些微小的变化。它肯定不是最好的,但是目前的性价比不错。

微信图片_20201119142734.jpg

他们基本走的就是传统PBR流程,模型法线什么都正常做。只是稍微调整了下基本色贴图。

微信图片_20201119142736.jpg

走的也依然是Substance流程,只是专门设计了一些比较卡通的画笔,之后就用这些画笔铺量了。当然,设计这些画笔的时候还是要有一些“卡通化”设计的。AO的强度,大倒角,高饱和什么。但只要设计一次其他人就可以普通地执行了。

能落地的方案,才有意义。

然后它说了一些其他的卡通化方法,首先是草:

微信图片_20201119142739.jpg
原图

微信图片_20201119142741.jpg
根据距离改变草的颜色,远处的草纹理会变为纯色,而且变亮

微信图片_20201119142743.jpg
加入云的阴影

微信图片_20201119142745.jpg
增加草的运动,图看不出来

它还提到了给草地加入一些闪烁的两点,图上看不出来。

之后提到了SunFlare,应该是那个屏幕后处理效果。卡通渲染很依赖体积光,所以自然会有好的效果,假也没关系,假才是对的。

微信图片_20201119142748.jpg

此外就是一个叫SNN的过滤器,谷歌搜SNN Filter就行了,我贴个shadertoy的地址。

https://www.shadertoy.com/view/MlyfWd

是SNN和Kuwahara的对比,左边那个是SNN。

EN,72采样,计算量可以忽略,跑应该还是能跑。

旁边的Kuwahara应该是个类似的算法,64采样。

可以考虑降低下width。

微信图片_20201119142750.jpg

它还有一个调整阴影色的方案。近处蓝色,远处变为绿色。

因为大概还是在用延迟管线做场景,如果可以自由定义阴影色就意味着要添加两张GBuffer这太夸张了。我觉得就是根据深度值插值两个颜色,并乘到间接光或者天光上。

大概就是这样,希望碧蓝幻想 RELINK早点出,我不想试,只想抄书。

文/flashyiyi
来源:知乎
日文原文:https://s.famitsu.com/news/202009/08205405.html

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

作品发布|文章投稿|广告合作|关于本站|游戏开发论坛 ( 闽ICP备17032699号-3 )

GMT+8, 2024-10-7 09:58

Powered by Discuz! X3.4

Copyright © 2001-2021, Tencent Cloud.

快速回复 返回顶部 返回列表