모바일 렌더링 최적화

이 페이지는 모바일 HDR 기능에서 최적의 충실도를 달성하면서 모바일 퍼포먼스를 최적화하는 방법에 대한 가이드라인과 모범 사례를 제공합니다. 여기에는 다음이 포함됩니다.

• 모바일 디바이스의 퍼포먼스 예산에 영향을 미치는 요인에 관한 정보

• 모바일 HDR 기능이 활성화된 상태에서의 프로젝트 패키징 모범 사례

• 언리얼 엔진 애플리케이션 내 퍼포먼스 병목 현상을 측정할 수 있는 툴 안내

퍼포먼스 예산 파악

애플리케이션의 타깃 디바이스에는 오브젝트를 메모리에 유지하고 이를 처리하는 데 사용할 수 있는 리소스에 제한이 있습니다. 애플리케이션을 빌드할 때 어떤 용도로 리소스를 사용할지 결정해야 합니다. CPU와 GPU의 속도, 스레드 및 대역폭 등 디바이스의 역량은 물론이고 디바이스의 메모리, 그래픽 메모리, 사용 가능한 디스크 공간을 잘 파악해야 합니다.

디바이스의 벤치마크를 실행하여 어떻게 실행될지와 어느 지점에서 퍼포먼스 병목 현상이 발생할지를 파악해야 합니다. 퍼포먼스 부담이 많은 애플리케이션이나 그 테크 데모를 실행한 다음, 퍼포먼스 통계를 관찰하여 디바이스 벤치마크를 실행할 수 있습니다.

퍼포먼스 통계 표시를 위한 콘솔 명령

몇 가지 콘솔 명령을 사용하여 퍼포먼스 통계를 확인할 수 있습니다. 모바일 디바이스에서 개발자 콘솔을 열려면 한 번에 손가락 4개를 사용하여 디스플레이를 탭합니다. 화면에 키보드가 열리고 콘솔 명령을 입력할 수 있는 프롬프트가 열립니다.

콘솔에 명령을 입력하여 화면에 디버그 정보를 표시할 수 있습니다. 다음 표에는 퍼포먼스 정보를 제공하는 명령 목록이 포함되어 있습니다.

일반 퍼포먼스 요인

디바이스에서 퍼포먼스 데이터를 찾는 위치는 숙지했으니, 이제 이 섹션에서는 언리얼 엔진의 모바일 렌더러에서 퍼포먼스에 가장 자주 영향을 미치는 요소를 알아봅니다. 애플리케이션에 영향을 미치는 요소가 무엇인지, 어떻게 영향을 미치는지를 이해하면 언리얼 엔진의 진단 툴을 사용하여 문제를 빠르게 식별 및 해결할 수 있습니다.

노멀 맵과 하이 폴리(버텍스) 메시 비교

언리얼 엔진의 모바일 렌더러는 다수의 버텍스를 렌더링하는 데 효율적이지만, 모바일 렌더러의 고퀄리티 노멀 맵은 비트 뎁스 관련 문제가 있으며 하이 폴리곤 모델보다 퍼포먼스 비용이 많이 들 수 있습니다.

퍼포먼스가 낮은 하드웨어에서 노멀 맵은 모델 표면의 리플렉션 및 라이팅 퀄리티를 크게 향상할 수 있습니다. 하지만 자동차의 차체처럼 정교한 셰이프는 노멀 맵에서 일반적으로 사용되는 8비트 델타를 초과하기 때문에 최종 렌더에서 밴딩이 보일 수 있습니다.

이러한 문제는 16비트 노멀 맵으로 보완할 수 있지만, 16비트 노멀의 픽셀 비용은 고밀도 메시의 버텍스 비용을 초과합니다. 16비트 노멀은 엔진에서 압축되지 않으므로 크기가 일반 노멀 맵의 8배입니다.

아래 예시에서는 노멀 맵이 없는 고밀도 차체를 사용합니다. Galaxy Tab S6가 타깃이라면, 이 차체는 약 500,000개의 버텍스를 결합합니다.

고해상도 노멀 맵 모범 사례

로우 폴리 모델에 대한 노멀 맵으로 고해상도 버텍스를 구우면 프로세스가 복잡해질 수 있으며, 엔진 내에서 노멀 맵 텍스처의 퀄리티를 떨어뜨릴 수 있는 요소가 많습니다. 노멀 맵을 구울 때 사용할 수 있는 툴세트는 많지만 xNormal을 권장합니다. 에픽게임즈의 xNormal 프로세스를 간략히 설명하면 다음과 같습니다.

1. xNormal에서 8k TIFF, 4xAA로 노멀 맵을 굽습니다.

2. TIFF를 photoshop으로 임포트한 다음, 1k 텍스처로 해상도를 낮춥니다.

3. 0.35픽셀 값으로 가우시안 흐림(Gaussian Blur)을 적용합니다.

4. 이미지를 16비트에서 8비트로 변환합니다.

5. 이미지를 24비트 TGA로 익스포트합니다.

6. 최종 노멀 맵을 언리얼로 임포트합니다.

굽기 프로세스에서 사용되는 표면 노멀이 엔진에서 보이는 것과 똑같이 보이도록 하려면 언리얼 내부에서 최적화된 노멀을 익스포트해야 합니다. 언리얼로 굽기 모델을 임포트하고 고유한 노멀을 만들도록 선택한 다음, xNormal에서 굽기 위해 언리얼에서 굽기 모델을 익스포트합니다. 이 단계는 xNormal에서 고해상도 모델로부터 오프셋을 적용할 메시의 표면 노멀을 인식해야 하므로 고퀄리티 노멀 맵을 만드는 데 중요합니다.

마지막으로, 스태틱 메시(Static Mesh)를 렌더링할 때 아티팩트를 줄일 수 있는 두 가지 옵션이 있습니다.

• 최대 정밀도 UV 사용

• 높은 정밀도 탄젠트 베이시스 사용

두 설정 모두 LOD(LODs) 의 디테일(Details) 패널에 있는 스태틱 메시 에디터(Static Mesh Editor)에서 사용 가능합니다.

드로 콜

드로 콜은 모든 프레임에서 발생하는 에셋 조회입니다. 애플리케이션에서 사용하는 드로 콜의 수는 씬의 고유 메시 수는 물론 각 메시에서 사용 중인 고유 머티리얼 ID의 수에 따라 다릅니다. 현재 그래픽 퍼포먼스 저하의 가장 큰 원인은 드로 콜이므로, 최대한 줄여야 합니다.

예를 들어 고도로 최적화된 자동차 모델은 개별 메시가 대여섯 개에 불과하고, 컴포넌트마다 머티리얼이 하나만 있을 수 있습니다.

최적화된 씬에서 양호한 드로 콜은 Galaxy Tab S6에서 약 700개, 퍼포먼스가 낮은 하드웨어에서 500개 이하입니다. 상당히 독특하거나 복잡한 머티리얼을 사용하는 편인 HMI 프로젝트는 Galaxy Tab S6에서 드로 콜이 100개면 양호하지만, 50개 미만이 적합합니다.

콘솔 명령 Stat RHI로 드로 콜 수를 출력할 수 있습니다.

메시 수 줄이기

드로 콜을 줄이는 가장 쉬운 방법은 월드에서 고유 메시의 수를 줄이는 것입니다. 언리얼로 임포트하기 전에 Maya, 3DSMax 또는 Blender와 같은 DCC(디지털 콘텐츠 제작) 툴세트를 사용하여 가능한 한 많은 오브젝트를 하나의 메시로 결합하여 줄일 수 있습니다.

머티리얼 ID 수 줄이기

메시의 고유 머티리얼 수를 줄이는 방법은 여러 가지가 있습니다.

가장 간단한 방법은 여러 머티리얼을 동일한 텍스처로 통합하는 Substance Painter 같은 프로그램을 사용하는 것입니다. 이를 통해 아주 간단한 언리얼 머티리얼로 다수의 머티리얼 유형을 활용할 수 있으며, 간단한 텍스처 입력을 통해 머티리얼 인스턴스에 대한 기반으로 사용할 수 있습니다. 또한 머티리얼 인스트럭션 수를 줄여 퍼포먼스를 추가로 개선할 수 있습니다.

두 번째 방법은 더욱 절차적인 접근법을 위해 마스킹을 사용합니다. 머티리얼은 색, 러프니스, 메탈릭 퀄리티 등 표면의 특정 특성을 나타낼 수 있습니다. 메시의 각기 다른 부분에 대해 별도의 머티리얼을 사용하는 대신, 마스크를 사용하여 메시의 UV의 부분을 분리하고 각 섹션에 다른 세팅을 적용할 수 있습니다. 흑백 텍스처를 사용하여 기본 마스크를 만들 수 있지만 버텍스 컬러를 사용하는 것이 더 효율적입니다.

최종 렌더

Vertex Color

아래 예시에서는 버텍스 컬러를 사용하여 여러 머티리얼 유형을 정의합니다. 머티리얼은 개별적으로 외형에 영향을 미칠 수 있는 파라미터를 정의합니다. 버텍스 컬러 마스킹은 효율성이 뛰어나고 텍스처 해상도에 의존하지 않으므로 더 뚜렷하게 분리할 수 있습니다.

머티리얼

머티리얼 복잡도가 올라가면 렌더링의 픽셀 비용이 상승할 수 있습니다. 각 픽셀에 대한 인스트럭션이 많을수록 렌더에서 최종 값을 계산하는 데 드는 시간이 오래 걸립니다. 불투명 머티리얼이 비용이 가장 낮지만 셰이딩 모델 또는 베이스 셰이더 코드에 따라 크게 달라질 수 있습니다.

머티리얼 에디터(Material Editor)의 통계(Stats) 창에서 머티리얼의 인스트럭션 수의 판독값을 찾을 수 있습니다.

인스트럭션 수는 머티리얼에 있는 수학 함수의 수에 따라 증가합니다. 노드가 많을수록 머티리얼 렌더링 비용이 증가합니다. 일부 특정 작업은 비용이 더 높습니다. 더욱 복잡한 머티리얼을 빌드할 때 인스트럭션 수를 제한해야 합니다.

반투명(Translucent) 및 투명(Transparent) 머티리얼은 가장 비용이 높은 머티리얼 유형 중 일부입니다. 개별 반투명 레이어는 픽셀당 비용이 높으며, 여러 투명 레이어가 스택 및 렌더링되면 비용이 더욱 높아집니다. 이를 오버드로(overdraw)라고 합니다.

비히클의 헤드라이트 및 테일라이트는 대표적으로 문제되는 투명 영역입니다. 대부분 손으로 그린 텍스처 맵을 사용하여 머티리얼 복잡도를 줄입니다. 평면 텍스처로도 복잡한 셰이프와 심도를 묘사할 수 있습니다.

텍스처 해상도 최적화

고해상도 텍스처의 경우 디바이스와 디바이스의 텍스처 메모리 모두에서 많은 공간을 필요로 하며, 텍스처가 클수록 렌더링 및 처리에 더 많은 픽셀이 필요합니다. 충실도를 높일 수는 있지만 디바이스의 스크린 해상도와 텍스처의 시야각을 고려했을 때 텍스처 크기로 인한 효과는 점점 줄어듭니다. 원하는 수준의 충실도를 얻으려면 가급적 가장 작은 텍스처를 사용하는 것이 중요합니다.

텍스처 요구 사항을 결정하려면 우선 카메라 위치와 모델을 보는 시야각(FOV)을 완성해야 합니다. 이는 모든 메시 및 머티리얼의 스크린 스페이스를 결정하는 데 도움이 됩니다.

카메라 위치가 결정되면 특수 디버그 텍스처를 사용하여 다양한 머티리얼에 사용할 텍스처 해상도를 결정할 수 있습니다. 이 텍스처는 밉맵(mipmap)의 행동을 사용하여 각기 다른 컴포넌트에 필요한 해상도를 결정하고 각 밉맵에 다른 색상을 적용합니다. 이를 통해 머티리얼에서 사용하는 밉이 무엇인지, 어떤 텍스처 해상도를 사용해야 하는지 쉽게 식별할 수 있습니다.

포함된 텍스처를 언릿(unlit) 머티리얼의 이미시브 채널(Emissive channel)에 연결한 다음, 해당 머티리얼을 메시에 적용합니다. 적절한 카메라 거리에서 메시를 볼 때 색 코딩은 엔진에서 렌더링에 사용하는 밉 레벨을 나타냅니다. 관찰된 가장 높은 레벨이 노멀 및 앰비언트 오클루전 맵의 네이티브 텍스처 크기가 되어야 합니다.

패키지 크기 및 부팅 시간

애플리케이션과 에셋을 패키징할 때 디스크의 패키지 크기와 런타임 부트업 퍼포먼스 사이에서 절충이 이루어집니다.

Zlib 압축이 활성화되면 애플리케이션의 패키지 크기가 더 작아집니다. 하지만 애플리케이션을 로드하는 데 더 많은 CPU 시간이 필요하며, 이로 인해 부트업 속도가 감소할 수 있습니다. 최적의 부팅 시간을 위해 압축을 비활성화할 수 있습니다.

권장 스트리밍 세팅

DefaultEngine.ini에서 다음 스트리밍 세팅이 권장됩니다. 에셋의 비동기 로드를 위해 애플리케이션 시작 시 추가 시간을 제공하여 스타트업 시간을 개선할 수 있습니다.

[/Script/Engine.StreamingSettings]
	s.PriorityAsyncLoadingExtraTime=275.0
	s.LevelStreamingActorsUpdateTimeLimit=250.0
	s.PriorityLevelStreamingActorsUpdateExtraTime=250.0

권장 패키징 세팅

DefaultEngine.ini에서 다음 패키징 세팅이 권장됩니다. 이러한 세팅은 에셋 패키징 시 활용되는 압축량을 줄이며, 압축 해제된 .pak 파일은 스타트업 시 Zlib 압축 파일보다 더욱 빠르게 로드됩니다.

[/Script/UnrealEd.ProjectPackagingSettings]
	bCompressed=False
	BuildConfiguration=PPBC_Development
	bShareMaterialShaderCode=True
	bSharedMaterialNativeLibraries=True
	bSkipEditorContent=True

디스크에서 패키지 크기 분석

언리얼 엔진에는 에셋의 데이터 풋프린트에 인사이트를 제공할 수 있는 몇 가지 유용한 툴이 있습니다.

사이즈 맵

사이즈 맵(Size Map)은 에디터에 있는 에셋의 상대적 메모리 사용량을 읽고 비교합니다. 이를 사용하려면 반드시 AssetManagerEditor 플러그인을 활성화해야 합니다. 이후 콘텐츠 브라우저(Content Browser)에서 폴더를 우클릭하고 컨텍스트 메뉴에서 사이즈 맵(Size Map)을 선택합니다.

사이즈 맵에 폴더와 파일에서 사용하는 메모리 양을 나타내는 아이콘이 포함된 창이 표시됩니다. 아이콘이 클수록 파일이 더 많은 공간을 사용합니다.

사이즈 맵의 사용에 대한 자세한 내용은 쿠킹 및 청킹을 참조하세요.

통계

통계(Statistics) 툴은 레벨에서의 에셋 사용량에 대한 더욱 구체적인 정보를 제공합니다. 이 툴은 창(Window) 메인 메뉴에서 찾을 수 있습니다.

통계 창은 레벨 파일의 에셋 수를 분류하고, 전체 레벨 또는 특정 레벨만 표시할 수 있습니다. 프리미티브 통계(Primitive Stats)는 트라이앵글 수, 메모리 사용량 및 수에 대한 정보를 나열합니다.

이 목록에 표시되는 다른 데이터로는 텍스처 사용량과 스태틱 메시 라이팅 정보가 있습니다. 통계 창의 목록 모드는 어떤 에셋이 가장 많은 메모리를 사용하고 있는지 빠르게 보여줍니다. 쿠커 통계(Cooker Stats) 데이터 역시 마지막 패키지 프로세스에서 쿠킹된 모든 에셋 목록을 보여주므로 매우 중요합니다.

메모리 보고서

통계 및 사이즈 맵 툴이 언리얼 에디터 내부에 있는 파일의 데이터 풋프린트를 보여주는 반면, Memreport -full 콘솔 명령은 타깃 디바이스에서 실행된 애플리케이션의 설치로부터 사용할 수 있습니다. 디바이스의 압축 세팅을 사용하여 존재하는 파일의 크기를 정확하고 구체적으로 살펴볼 수 있습니다.

Development 환경설정에서 앱이 빌드되어 디바이스에 로드되면 콘솔 창을 가져와 명령을 입력할 수 있습니다. 이 메모리 스냅샷은 디바이스의 프로젝트 디렉터리에 저장됩니다. 디렉터리는 보통 Game/[앱 이름]/[앱 이름]/Saved/Profiling/Memreports/이지만 이는 달라질 수 있습니다.

.memreport 파일은 대부분의 텍스트 에디터에서 읽을 수 있는 텍스트 파일입니다. 텍스트의 시작에는 할당된 메모리 및 풀 크기에 대한 일부 정보가 포함되어 있으며, 텍스트 곳곳에서는 로드되었던 레벨, RHI 통계, 렌더 타깃, 씬 정보 등에 대한 레코드를 보여줍니다. 이 모든 정보가 쿠킹 및 패키징 프로세스를 통해 형성된 실제 데이터를 나타내므로 중요합니다.

Listing all textures를 검색하면 텍스처 유형, 그룹, 크기, 메모리 풋프린트에 대한 구체적인 정보와 함께 애플리케이션의 모든 텍스처 목록을 찾을 수 있습니다. 이 목록은 메모리 크기별로 정렬되며 큰 텍스처가 먼저 표시됩니다. 이는 가장 많은 메모리를 사용하는 텍스처가 무엇인지 빠르고 쉽게 찾는 방법입니다.

부팅 시간 분석

부팅 시간에 영향을 미치는 요인은 다음과 같습니다.

• 초기 에셋을 로드하고 압축을 푸는 데 필요한 시간

• 애플리케이션의 전체 크기

• 사용자의 설치에서 활성화되어야 하는 모든 플러그인

• 파싱되어야 하는 스트링 데이터의 양

• 사용자 디바이스에서의 모든 메모리 할당 또는 단편화

애플리케이션의 부팅 시간을 분석할 수 있는 여러 툴이 있지만 언리얼 인사이트(Unreal Insights)를 가장 추천합니다. 타깃 디바이스에서 원격으로 퍼포먼스 데이터를 프로파일링할 수 있습니다. 이 툴세트에 대한 전체 정보는 언리얼 인사이트 섹션을 참조하세요.

Android 애플리케이션에서 언리얼 인사이트를 사용하는 방법에 대한 예시는 Android 디바이스에서 언리얼 인사이트 사용하기를 참고하세요.