마스크 전처리 방법(Native)

[마지막 갱신일: 2019/09/03]

 

Live2D Cubism SDK for Native에서는 스마트폰 등으로 그리기 속도를 유지하기 위해,
모델 묘화 처리의 최초로 1매의 마스크 버퍼에 대해서 모든 마스크 형상을 묘화 하는 「전처리 방식」을 채용하고 있습니다.

원칙적인 드로잉 방법은 마스크가 필요한 Drawable을 그릴 때마다 마스크 모양을 그립니다 (그림 참조).
이 방법에서는 Drawable이 마스크를 필요로 할 때마다 렌더 타겟의 전환·버퍼의 클리어 등 비교적 고비용의 처리가 발생하게 됩니다.
따라서 스마트폰 등으로 그리기 속도가 저하되는 원인이 될 수 있습니다.

그러나, 미리 마스크를 준비하는 것만으로는 마스크 버퍼가 복수장 필요하게 되어, 메모리를 압박하게 됩니다.
이 점을 해결하기 위해, 1장의 마스크 버퍼에 대해서 이하의 처리를 실시하는 것으로, 마치 복수장의 마스크 버퍼를 이용하고 있는 것처럼 취급하면서, 메모리의 압박을 억제할 수 있습니다.

 

마스크 통합

미리 모든 마스크를 생성하기 때문에 동일한 마스크 지정을 받은 Drawable은 동일한 마스크 이미지를 사용하여 생성하는 매수를 줄일 수 있습니다.

이 처리는 CubismRenderer_OpenGLES2::Initialize 함수 호출에서
CubismClippingManager_OpenGLES2::Initialize 함수에 의해 수행됩니다.

 

 

색상 정보로 분리

마스크 버퍼는 실체로서 통상의 텍스쳐 버퍼 등과 같이 RGBA의 영상용 배열입니다.
일반 마스크 처리에서는 이 A 채널만을 사용하여 마스크를 적용하지만 RGB 채널은 사용하지 않습니다.
거기서 RGBA로 별개의 마스크 데이터를 가지는 것에 의해 1매의 마스크 버퍼를 4장의 마스크 버퍼로서 취급할 수 있게 됩니다.

 

 

분할 분리

마스크 이미지가 4장에서는 부족해졌을 때, 마스크 버퍼를 2분할, 4분할, 9분할로 취급함으로써 마스크의 매수를 늘립니다.
색 정보로의 분할도 있으므로 4x9의 36장까지 다른 마스크를 유지할 수 있게 되어 있습니다.

또한 마스크 이미지가 부서지는 것을 방지하기 위해 마스크 적용을 받는 모든 Drawable 사각형으로 마스크를 그립니다.
이 때문에 범위의 생성과 마스크 생성, 마스크 사용으로의 매트릭스의 생성이 필요하게 됩니다.

 

 

 

직사각형 확인

마스크 생성의 첫 번째 단계에서 각 마스크에 대해 마스크 적용 대상이 모두 맞는 사각형을 확인합니다.

 

 

색분리, 분할분리를 받은 레이아웃 결정

마스크마다 소속되는 마스크 버퍼의 색채널, 분할 위치를 정합니다.

 

 

마스크 그리기, 마스크 사용의 매트릭스 생성

그리기 전에 조사한 구형 범위와 소속 장소에 근거해 마스크 생성용, 마스크 사용용의 변환 매트릭스를 준비합니다.

 

 

마스크 버퍼의 동적 크기 조정

GLES2 렌더러는 런타임에 마스크 버퍼의 크기를 조정하는 API를 제공합니다.
현재, 마스크 버퍼의 사이즈는 초기치로서 256*256(픽셀)을 설정하고 있습니다만, 마스크 생성 영역을 9매로 자르는 경우,
85*85(픽셀)의 구형 영역에 묘화한 마스크 형상을, 한층 더 확대해 클리핑 영역으로서 사용합니다.
그 결과 클리핑 결과의 가장자리가 흐리거나 흘러나오는 현상이 나타납니다.
이를 해결하는 방법으로 마스크 버퍼의 크기를 프로그램 실행시 변경하는 API를 제공합니다.

예를 들어, 마스크 버퍼의 크기를 256*256 ⇒ 1024*1024로 함으로써 마스크 생성 영역을 9매로 자르는 경우, 341*341의 직사각형 영역에 마스크 형상을 그릴 수 있으므로,
클리핑 영역으로 확대하여 사용해도 클리핑 결과의 가장자리의 흐림이나 번짐을 없앨 수 있습니다.

※마스크 버퍼의 사이즈를 크게 한다 ⇒ 처리하는 픽셀이 증가하면 속도는 느려지지만, 묘화 결과는 깨끗해진다.
※마스크 버퍼의 사이즈를 작게 한다 ⇒ 처리하는 픽셀이 줄어들기 때문에 속도는 빨라지지만, 묘화 결과는 더러워진다.

 

 

전처리 방식으로 성능 향상을 기대할 수 있는 이유

휴대 단말기 특유의 사정으로 GPU에 대한 Clear 명령이나 렌더링 타겟 전환 명령의 처리 비용이 다른 명령보다 높을 수 있습니다.
원칙적인 방식으로 그릴 때는 이러한 처리 비용이 높은 명령을 마스크가 필요한 Drawable의 수만큼 실행하게 됩니다.
그러나 전처리 방식의 경우에는 이러한 명령을 실행하는 횟수를 줄일 수 있으므로 스마트폰 등에서의 성능 향상을 전망할 수 있습니다.

실제로 그 효과를 파악하기 위해, 렌더링에 있어서의 각 처리 단위로의 시간 코스트를 측정해 보겠습니다.
측정 방법으로 아래에 표시된 소스 코드로 확인합니다. 레이어는 빌드별로 분리하여 측정합니다.
또, 테스트 대상의 모델은 Haru 일체입니다.
측정하는 단말로서는 Android기를 2종류, Windows기를 1종류 준비했습니다.
측정은 Android 측에서 clock_gettime 함수, Windows 측에서 QueryPerformanceCounter 함수를 사용하여 버퍼에 결과를 캐시하여 평균값을 계산한다는 방침으로 측정합니다.

클리핑 마스크 생성부(레이어 1)

CubismClippingManager_OpenGLES2::SetupClippingContext는 그리기 타겟의 전환과 채우기 시간을 측정합니다.

 

모델 그리기 전체(레이어 1, 2 혼합)

그리기 전, 정렬, 그리기 후 처리의 측정을 합니다.

레이어를 나누어 마스크 생성과 그 이외의 묘화라고 하는 큰 프레임에서도 측정합니다.

 

메쉬 그리기(레이어 1)

CubismRenderer_OpenGLES2::DrawMesh는 셰이더에 대한 설정 시간과 그리기 명령 단일 시간을 측정합니다.

 

레이어 3

큰 프레임으로 Update 흐름
파라미터 계산, 모델 업데이트, 렌더링의 세 가지로 나누어 갑니다.

 

 

결과

  Android1 Android2 Winpc1
L1clear  1781.20  218.80  26.80
L1gldraw  45.47  51.63  10.58
L1sharder  12.31  9.34  5.37
L1post 1.50 1.00 0.10
L1switch 10.70 56.30  7.80
L1predraw 15.90 8.20 2.20
L1sort 7.60 7.00 0.60
L2MaskMake 2686.80 1357.60 318.50
L2draw 4004.10 4013.20 1217.00
L3paramupdate 392.00 375.40 89.70
L3modelupdate 1357.50 1410.90 1070.40
L3rendering 6715.70 5233.70 1892.00

위의 표는 앞에서 설명한 부분의 실행 시간입니다.
휴대 단말기는 Clear의 비용이 높거나 렌더링 타겟의 전환이 다른 명령에 비해 무거운 것을 알 수 있습니다.
이 무거운 명령이 원칙적인 방식으로 그릴 때 마스크가 필요한 Drawable의 수만큼 실행됩니다.
이 계산이 한 번으로 끝나기 때문에 스마트폰 등에서의 퍼포먼스의 향상을 전망할 수 있습니다.

 

 

마스크 처리를 고화질 방식으로 전환

앞서 언급했듯이, 그릴 때마다 마스크를 생성하는 방식이라면 낮은 사양 단말기에서는 성능에 영향이 있습니다.

그러나, 최종적으로 동영상으로서 출력하는 경우와 같이, 런타임에서의 퍼포먼스보다 화면의 품질을 중시하는 경우는 이쪽의 방법이 더 적합합니다.

2018/12/20 이후의 SDK에서는 마스크 처리를 고화질 방식으로 전환할 수 있습니다.
고화질 방식으로 전환하려면 다음 API에 true를 전달합니다.

© 2010 - 2022 Live2D Inc.