실시간 렌더링 최적화 가이드라인

실시간 렌더링을 위한 최적화 및 개발 모범 사례를 소개합니다.

Choose your operating system:

Windows

macOS

Linux

이 페이지는 실시간 렌더링 기능으로 최적의 충실도를 달성하면서 퍼포먼스를 파악하고 최적화하는 방법에 대한 가이드라인과 모범 사례를 제공합니다.

이 페이지에서는 아래와 같은 내용을 살펴봅니다.

  • 퍼포먼스 예산에 영향을 미치는 요인

  • 프로젝트 패키징 모범 사례

  • 퍼포먼스 병목 현상을 측정하는 툴 소개

퍼포먼스 예산 파악

프로젝트 개발 시 애플리케이션의 타깃 플랫폼에는 오브젝트를 메모리에 유지하고 이를 처리하는 데 사용할 수 있는 리소스에 제한이 있습니다. 프로젝트를 빌드할 때에는 어떤 용도로 리소스를 사용할지 결정해야 합니다. CPU와 GPU의 속도, 스레드, 대역폭 측면에서 플랫폼의 성능을 숙지해야 합니다. 잠재적 메모리, 그래픽 메모리, 사용 가능한 디스크 공간도 모두 고려해야 할 중요한 요인입니다.

프로젝트가 어떻게 실행될지, 어디서 퍼포먼스 병목 현상이 나타날 것인지 파악하려면 타깃 플랫폼을 기준으로 프로젝트를 벤치마크 해야 합니다. 퍼포먼스 부담이 큰 애플리케이션이나 테크 데모를 실행한 다음, 퍼포먼스 통계를 관찰하여 플랫폼이나 디바이스를 벤치마크할 수 있습니다. 정기적으로 같은 방식을 통해 프로젝트를 테스트하고 벤치마크하는 것이 중요합니다.

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

퍼포먼스 통계는 프로젝트를 실행하는 동안 몇 가지 콘솔 명령을 사용하여 확인할 수 있습니다. 프로젝트를 실행했거나 개발 빌드로 패키징했다면 콘솔 창을 통해 콘솔 명령을 입력할 수 있습니다.

모바일 애플리케이션에 표시된 콘솔 창과 화면 키보드

모바일 애플리케이션에 콘솔 창이 표시됩니다.

콘솔과 손가락 4개를 탭하는 명령은 개발 빌드에서만 사용할 수 있습니다. 출시나 테스트 빌드에서는 사용할 수 없습니다.

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

명령

설명

Stat GPU

각기 다른 프로세스를 위해 GPU에서 사용하는 시간을 밀리초 단위로 표시합니다.

Stat Unit

각기 다른 프로세스를 위해 CPU에서 사용하는 시간을 밀리초 단위로 표시합니다. 게임 스레드, 렌더링 스레드, GPU 시간도 표시합니다.

Stat UnitGraph

시간에 따른 CPU 및 GPU 사용량을 보여주는 그래프를 표시합니다. 이를 통해 급증 현상을 식별할 수 있습니다.

Stat TextureGroup

각기 다른 텍스처 풀에서 사용하는 메모리의 양을 표시합니다.

디바이스에서 애플리케이션의 퍼포먼스를 분석하는 데 사용할 수 있는 추가 콘솔 명령은 [Stat 명령]()을 참조하세요.

일반 퍼포먼스 요인

퍼포먼스 데이터를 확인하는 곳을 알아보았으니, 이제 퍼포먼스에 흔히 영향을 미치는 대표적인 요인을 살펴보겠습니다. 프로젝트에 영향을 미치는 요소가 무엇인지, 어떻게 영향을 미치는지를 이해하면 엔진의 내장 진단 툴을 사용하여 문제를 식별 및 해결할 수 있습니다.

고해상도 노멀 맵 모범 사례

로우 폴리 모델에 대한 노멀 맵으로 고해상도 버텍스를 구우면 프로세스가 복잡해질 수 있으며, 엔진 내에서 노멀 맵 텍스처의 퀄리티를 떨어뜨릴 수 있는 요소가 많습니다. 노멀 맵을 구울 때 사용할 수 있는 툴세트는 많지만 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 사용(Use Full Precision UVs)

  • 높은 정밀도 탄젠트 베이시스 사용(Use High Precision Tangent Basis)

두 세팅 모두 디테일(Details) 패널의 LODs 섹션에 있는 스태틱 메시 에디터(Static Mesh Editor) 에서 사용할 수 있습니다.

image_2.png

드로 콜

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

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

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

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

드로 콜 수는 PIE인지, 디바이스인지에 따라 달라진다는 점을 명심하세요. |

메시 수 줄이기

드로 콜을 줄이는 가장 쉬운 방법은 월드에서 렌더링되는 고유 메시의 수를 줄이는 것입니다. 메시는 여러 방법으로 줄일 수 있습니다. 엔진의 내장 툴을 사용해 메시를 결합해도 되고, 비저빌리티 컬링을 사용해도 됩니다.

  • 고유 메시 결합하기

    • 메시는 모델링 프로그램과 같은 외부 DCC 애플리케이션으로 직접 결합할 수 있습니다.

    • 혹은 계층구조적 레벨 오브 디테일과 같은 에디터 내 월드 빌딩 툴을 통해 드로 콜을 줄일 수 있도록 메시와 텍스처를 결합하여 레벨에서 메시를 자동 생성할 수도 있습니다.

  • 비저빌리티 컬링

    • 엔진은 여러 비저빌리티 및 오클루전 컬링 메서드로 렌더링되는 메시의 수를 줄입니다. 컬 디스턴스 볼륨은 메시의 크기와 플레이어 카메라와의 거리에 의해 지정되는 부가 메시를 삭제할 수 있는 배치 볼륨입니다.

머티리얼 ID 수 줄이기

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

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

image alt text

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

최종 렌더

버텍스 컬러

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

버텍스 컬러를 사용하여 여러 머티리얼 유형을 분리하는 머티리얼

머티리얼

머티리얼 복잡도는 렌더링된 프레임의 픽셀 비용을 높일 수 있습니다. 각 픽셀에 대한 머티리얼 인스트럭션이 많을수록 렌더에서 최종 값을 계산하는 데 드는 시간이 길어집니다. 불투명 머티리얼이 비용이 가장 낮지만 셰이딩 모델 또는 베이스 셰이더 코드에 따라 크게 달라질 수 있습니다.

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

인스트럭션 수를 표시하는 통계 창

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

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

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

image alt text

텍스처 해상도 최적화

프로젝트의 텍스처를 최적화하는 방법에는 몇 가지가 있습니다. 거의 모든 크기의 텍스처를 사용하며 화면에 필요한 부분만 렌더링할 수 있는 내장 버추얼 텍스처링을 사용할 수도 있고, 표준 텍스처링 방법을 사용할 수도 있습니다.

버추얼 텍스처로 활성화되지 않은 표준 텍스처의 경우 특히 고해상도 텍스처는 메모리와 디스크의 저장 공간을 많이 필요로 할 수 있습니다. 충실도를 높일 수는 있지만 스크린 해상도와 텍스처의 시야각을 고려하면 텍스처 크기 반환이 줄어듭니다. 원하는 수준의 충실도를 얻으려면 가급적 가장 작은 텍스처를 사용하는 것이 중요합니다.

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

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

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

예시 밉맵 머티리얼

디버그 밉맵 머티리얼이 적용된 메시의 예시.

패키지 크기 및 부팅 시간

언리얼 엔진 프로젝트와 에셋을 패키징할 때에는 디스크의 패키지 크기와 런타임 부트업 퍼포먼스 사이에서 절충이 이루어집니다.

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

프로젝트 세팅(Project Settings) > 패키징(Packaging)에서 Zlib 압축 세팅을 확인할 수 있습니다.

권장 스트리밍 세팅

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) 을 선택합니다.

image alt text

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

image alt text

사이즈 맵 사용에 대한 추가 정보는 쿠킹 및 청킹을 참조하세요.

사이즈 맵은 에디터 내에서 사용되는 에셋의 풋프린트를 읽습니다. 프로젝트 패키징 이후 메모리 사용량이 달라집니다. 이는 쿠킹 프로세스 도중 발생하는 여러 유형의 압축 때문입니다. 일반적으로 사이즈 맵은 에셋이 가져갈 수 있는 가장 큰 크기를 나타냅니다.

통계

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

image alt text

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

프리미티브 통계를 보여주는 통계 창

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

메모리 보고서

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

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

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

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

부팅 시간 분석

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

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

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

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

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

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

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

언리얼 엔진의 이전 버전을 위해 작성된 페이지입니다. 현재 언리얼 엔진 5 버전을 위해 업데이트되지 않았습니다.