口罩前处理方法(Java)

[最后更新时间:2022/10/06]

Cubism SDK for Java 目前是 alpha 版本。beta 版和正式版的规格可能会有所变化。

在 Live2D Cubism SDK for Java(alpha 版)中,为了保持智能手机等的绘图速度,
在模型绘制过程开始时,采用了为一个掩模缓冲区绘制所有掩模形状的“预处理方法”。

在原理绘制方法中,每次绘制需要蒙版的Drawable时,都会绘制蒙版形状(见图)。
使用这种方法,每次 Drawable 需要遮罩时,都会发生切换渲染目标和清除缓冲区等相对昂贵的处理。
因此,它可能会导致智能手机上的绘图速度降低。

 

但是,仅仅提前准备好掩码需要多个掩码缓冲区,这会给内存带来压力。
为了解决这个问题,通过对一个掩码缓冲区执行以下处理,可以降低内存压力,同时将其视为正在使用多个掩码缓冲区。

 

面罩集成

由于所有蒙版都是预先生成的,因此接受相同蒙版指定的 Drawable 可以减少使用相同蒙版图片生成的图纸数量。

这个过程是由 CubismClippingManagerAndroid.initialize 函数在 CubismRendererAndroid.initialize 函数的调用中完成的。

 

 

按颜色信息分离

掩码缓冲区实际上是一个 RGBA 视频数组,就像普通的纹理缓冲区一样。
普通遮罩仅使用此 A 通道来应用遮罩,而不是 RGB 通道。
因此,通过在 RGBA 中具有单独的掩码数据,一个掩码缓冲区可以作为四个掩码缓冲区处理。

 

 

拆分分离

当 4 个掩码图片不够用时,通过2等份、4等份和9等份处理掩码缓冲区来增加掩码数量。
由于还按颜色信息进行划分,因此最多可以容纳 36 个 4 x 9 的不同蒙版。

此外,为防止蒙版图片被压扁,请使用应用蒙版的所有可绘制矩形绘制蒙版。
因此,需要使用掩码生成范围、掩码和矩阵。

检查矩形

在蒙版生成的第一步中,对于每个蒙版,检查适合所有蒙版的矩形。

 

 

分色和分色后的布局决策

确定每个蒙版所属的蒙版缓冲区的颜色通道和分割位置。

 

 

蒙版绘制,使用蒙版生成矩阵

根据绘制前检查的矩形范围及其所属位置,准备用于掩码生成和掩码使用的转换矩阵。

 

 

掩码缓冲区的动态调整大小

OpenGL ES 2.0 渲染器提供了一个 API 来在运行时调整遮罩缓冲区的大小。
目前,掩码缓冲区的大小设置为256*256(像素)作为初始值,但是如果将掩码生成区域切成9块,则在85*85(像素)的矩形区域中绘制的掩码形状) 是,进一步放大它并将其用作剪切区域。
因此,剪裁结果的边缘会模糊或渗色。
作为解决方案,我们提供了一个 API,可以在程序执行时变更掩码缓冲区的大小。

例如,通过将掩码缓冲区大小从256*256更改为1024*1024,如果将掩码生成区域切成9块,则可以在341*341的矩形区域中绘制掩码形状,因此可以也可以用作剪切区域,以消除剪切结果中的模糊或模糊边缘。

* 增加蒙版缓冲区的大小⇒如果要处理的像素数增加,速度会变慢,但绘制结果会很漂亮。
* 减少掩码缓冲区的大小⇒ 由于要处理的像素数减少了,所以速度会更快,但是绘制结果会很脏。

 

 

预处理方法能提高性能的原因

作为移动终端特有的情况,GPU的Clear指令和渲染目标切换指令的处理成本可能高于其他指令。
在使用原理方法绘制时,这些昂贵的指令会被执行的次数与需要遮罩的 Drawable 数量一样多。
然而,在预处理方法的情况下,可以减少这些指令的执行次数,这有望提高智能手机等的性能。

我们正在进行一项实验以实际了解效果。
本实验的测量方法和结果请参考“(Native)掩模预处理方法”中的“为什么预处理方法可以提高性能”

 

将遮罩处理切换为高清方式

每次绘制时生成蒙版会对低端设备产生性能影响。

但是,这种方法适用于屏幕质量比运行时性能更重要的情况,例如最终输出为视频的情况。

在 Cubism SDK for Java(alpha 版)中,您可以将掩码处理切换为高清方法。
要切换到高清方法,请将 true 传递给以下 API。

© 2010 - 2022 Live2D Inc.