Performance & Design Considerations
Slate 및 UMG 성능 및 최적화 지침에 대한 Epic의 공식 문서
UMG와 Slate는 렌더링(GPU)과 연산(CPU) 측면 모두에서 매우 높은 성능을 제공하는 프레임워크입니다.
하지만 최적의 사용자 경험을 위해서는 두 가지 측면 모두를 고려하여 UI를 설계해야 합니다.
이 내용은 "성능을 향상시키는 방법" 가이드가 아니라, UMG/Slate로 애플리케이션을 구축할 때 반드시 인지해야 할 고려사항과 성능 개선을 위한 여러 접근법을 소개하는 참고 자료입니다.
UI의 복잡도는 일반적으로 활성화되어 있고 화면에 표시되는 위젯의 수와 관련이 있습니다. (화면에 보이지 않는 위젯은 Tick이 발생하지 않으며, 화면에 없을 때는 기능이 실행되지 않아야 합니다.)
UI의 기술적 설계에서 일반적으로 권장되는 방식은 게임플레이 코드에 반응형(Reactive)으로 동작하는 것입니다. (게임이 UI에 크게 의존하지 않는 경우 특히 권장)
UI가 게임플레이 코드의 진입점이 되는 것은 괜찮지만, 그 이후에는 게임플레이 코드의 결과를 수신(Listen)하고 이에 반응(React)하는 구조가 성능과 재사용성 측면에서 바람직합니다.
2.1 CPU Considerations
Slate/UMG는 Invalidation과 캐싱 개념을 사용하여 데이터를 지속적으로 폴링(polling)하지 않습니다.
이유는 폴링이 성능상 비효율적이거나, 멀티스레드 코드 사용 시 기능적으로 올바르지 않을 수 있기 때문입니다.
언리얼에서 성능이 좋은 UI는 이벤트 기반(event based)으로 설계하는 것이 일반적입니다.
UMG에는 Property Bind(속성 바인딩) 기능이 있지만, 이 기능은 매 프레임마다 업데이트되므로 이벤트 기반 프레임워크를 사용하는 것보다 CPU에 훨씬 더 부담을 주기 때문에 사용을 권장하지 않습니다.
| CPU 기술 설계 시나리오 |
|---|
| RTS 게임에서 병력 분대의 이동 위치를 지정하기 위해 UI 마커를 표시해야 하는 경우, 플레이어가 월드에서 유효한 위치를 선택하면 해당 위치에 UI 마커가 표시되고, 병력이 그곳으로 이동하게 됩니다. |
| 좋은 예시 | 나쁜 예시 |
|---|---|
| 플레이어 매니저 오브젝트가 UI 마커 위젯을 생성하고 병력 이동을 관리합니다. 플레이어가 선택한 월드 위치를 플레이어 매니저 오브젝트가 UI 마커 위젯에 전달하고, 위젯은 해당 위치를 화면 좌표로 변환하여 표시만 담당합니다. | 플레이어가 월드 위치를 선택하면 그 값을 UI 마커에 직접 전달하고, UI 마커가 병력에게 직접 이동 명령을 내리며 병력 이동까지 모두 처리합니다. |
Performance regarding Animations
여러 위젯의 Desired Size(희망 크기)를 무효화(Invalidate)하는 애니메이션을 대량의 위젯에 적용하면, Widget Layout 재계산에 많은 CPU 시간이 소모될 수 있습니다.
- 이전 버전의 언리얼 엔진에서는 UMG 위젯에서 애니메이션을 재생할 때 Sequencer와 별도로 동작했습니다(Sequencer가 도입된 이후에는 곧 Sequencer 기반으로 업데이트됨).
- Sequencer가 적용된 초기 버전에서는 UMG 위젯이 애니메이션 중에 자동으로 volatile로 설정되었습니다.
- 최신 버전의 언리얼 엔진에서는 UMG 위젯이 애니메이션 중에도 volatile로 자동 전환되지 않습니다.
Volatile을 언제 사용해야 할까?
항상 정답은 아닙니다. UMG 위젯을 애니메이션하거나 시각적 상태를 변경하면, 해당 프레임에 위젯이 무효화되고 새 상태로 다시 캐싱됩니다(이후 다시 무효화될 때까지).
Volatile로 설정하면 위젯이 무효화되거나 캐싱되지 않고, volatile 위젯만을 위한 별도의 코드 경로를 거치게 됩니다.
상황에 따라 성능이 개선될 수 있으므로, 필요한 기간 동안만 volatile을 켰다가 더 이상 필요 없을 때 꺼주는 방식으로 활용할 수 있습니다.
- Volatile 사용 시 유의사항:
- 위젯 상태가 캐싱되지 않고, 화면에 표시되는 동안 매 프레임마다 폴링됩니다.
- 위젯 계층 구조(부모/자식 위젯)에 영향을 줄 수 있으므로, 하위 위젯이나 상위 위젯에도 영향을 미칠 수 있음을 주의하세요.
Performance regarding Widget Components
Widget Component는 프로토타이핑이나 월드 내 VR/AR UI 구현에는 매우 유용합니다. 하지만 UI를 월드 안에 배치하면서도 화면 크기, 레이아웃 제어, 논리적 배치 등을 신경 써야 할 때는 적합하지 않습니다.
각 Widget Component는 실제로 정적 메시 평면(static mesh plane)에 렌더 타겟 텍스처를 머티리얼 슬롯 0번에 적용해서 보여주는 방식입니다.
각 Widget Component마다 UMG 위젯 객체를 생성하고, 이를 텍스처로 렌더링해서 월드에 표시합니다.
텍스처 메모리 사용량 때문에(특히 VR/AR이 아닌 경우) Widget Component를 과도하게 사용하는 것은 권장되지 않습니다.
대안으로, 여러 "위젯"을 한 번에 렌더링하는 커스텀 Slate Widget을 만드는 방법이 있습니다.
이때 사용할 수 있는 것이 SMeshWidget인데, 위젯 하나당 1 드로우콜로 처리할 수 있습니다.
단, 여러 위젯 요소를 하나의 텍스처로 그리려면 기술 아트 역량이 필요합니다.
SMeshWidget이란?
1 드로우콜로 렌더링할 수 있는 Slate 위젯입니다.
Paragon에서는 각종 상태바와 아이콘을 화면에 그릴 때 사용되었습니다.
매우 강력하지만, 이런 요소들을 코드로 직접 그려야 하므로 흔히 쓰이지는 않습니다.
텍스처, 파티클뿐 아니라 3D 모델/메시 등 원하는 모든 것을 렌더링할 수 있습니다.
Nick Darnell이 UE4에서 SMeshWidget으로 파티클을 그리는 예제를 공유한 적이 있습니다:
Carey Hickling이 Unreal Fest에서 "Optimizing and Building UI for AAA Games"라는 발표에서 SMeshWidget의 장단점을 설명합니다:
YouTube 링크
또 다른 참고 자료로, Epic의 Lyra 예제 프로젝트의 indicator 시스템을 살펴보는 것도 좋습니다. 관련 파일:
SActorCanvas.h/.cppIndicatorLayer.h/.cppIActorIndicatorWidget.h/.cppIndicatorDescription.h/.cppIndicatorLibrary.h/.cppLyraIndicatorManagerComponent.h/.cpp
GPU Considerations
일반적으로 GPU 최적화에서 고려해야 할 사항들은 3D 공간에서 작업할 때와 크게 다르지 않습니다. 예를 들어:
- 텍스처 메모리 크기
- 머티리얼 셰이더의 연산 복잡도
- 드로우 콜(Draw Call) 수
프레임워크가 제대로 설계되어 있다면, Slate/UMG는 언리얼 엔진의 3D 렌더링 기능을 일부 활용하여 작업을 통합하기 때문에 GPU 최적화가 큰 문제가 되지 않습니다.
하지만 언리얼 엔진에서 주의해야 할 점은, 플랫폼 종류에 따라 서로 다른 텍스처를 자동으로 교체해주는 안정적인 방법이 없다는 것입니다.
예를 들어, 모바일과 PC 간에 텍스처를 전환하려면, 사용하지 않는 텍스처가 원하지 않는 플랫폼의 하드 디스크에 포함(쿠킹, 로딩, 참조, 저장)되지 않도록 직접 시스템을 구축해야 합니다.
