퍼포먼스 확장: 언리얼 엔진 4.26의 시퀀서

By 에픽게임즈 시니어 프로그래머 Andrew Rodham |
2020년 12월 4일
리얼타임 시네마틱 콘텐츠의 다양한 특성, 스케일, 충실도를 구현하며 언리얼 엔진 퀄리티의 한계에 지속적으로 도전함에 따라 언리얼 엔진의 시네마틱 툴 시퀀서의 런타임 기능을 객관적으로 평가하고 최적화 가능 영역을 모색할 수 있습니다

언리얼 엔진 4.26의 시퀀서는 내부 아키텍처를 개편하여 상당한 최적화를 이루어냈고 이를 통해 대규모 시네마틱 및 동시 UI 애니메이션의 퍼포먼스가 전보다 훨씬 개선되었습니다. 이번 기술 블로그에서는 데이터 지향 설계 법칙을 사용하여 시퀀서의 데이터 구조와 런타임 로직을 재구성한 방법에 대해 알아보겠습니다. 이를 통해 대규모 데이터 세트 처리와 서드 파티 확장성 개선 면에서 고도로 향상된 최적화 가능성 등 다양한 이점을 누릴 수 있습니다. 이런 최적화는 앞으로도 시퀀서에서 더욱 상호작용적이고 역동적인 콘텐츠 제작을 가능하게 해 줄 것입니다.
 

시퀀스에는 어떤 기능이 있나요?

참고로 말씀드리면 시퀀서는 컷씬의 키프레임된 애니메이션, 게임 내 이벤트, UMG 위젯, 오프라인 렌더링 무비 등을 만들 수 있는 언리얼 엔진의 비선형적 편집 툴입니다. 이는 기본적으로 오브젝트 바인딩, 트랙, 섹션이라는 세 가지 요소로 구성됩니다.
 
[그림 1] 시퀀서 내 엘리먼트 위치
 
섹션은 일반적으로 각 트랜스폼, 프로퍼티, 애니메이션이 타임라인에서 취해야 할 상태를 정의하는 키프레임 데이터와 기타 프로퍼티를 포함합니다. 게임 내에서 시퀀스를 재생할 때, 엔진은 이 모든 트랙과 섹션으로 게임 월드에서 원하는 오브젝트에 의도된 상태와 프로퍼티를 적용합니다.

4.26 이전 버전에는 각 트랙과 섹션마다 특정 시간에 평가하고 원하는 오브젝트에 프로퍼티를 적용하기 위한 모든 데이터와 로직이 담긴 자체 런타임 인스턴스가 있었습니다. 이런 인스턴스는 기존의 오브젝트 지향 패러다임을 사용하도록 설계되어 가상 API를 통해 액세스되었습니다. 이 접근법은 트랙이 적은 경우에는 무난한 퍼포먼스를 내지만, 트랙 수와 상대적 복잡성이 높아질수록 퍼포먼스가 저하됩니다. 나아가 다수의 애니메이션이나 시퀀스를 병렬로 실행하면 각 인스턴스의 파이프라인이 초기화되어 높은 퍼포먼스 비용이 누적됩니다.

많은 CPU 프로파일 데이터를 액세스할 수 있게 되면서, 가상 함수 호출의 내재적 오버헤드와 열악한 캐시 집약성으로 인해 최적화를 위한 노력의 효과가 스케일의 확장에 따라 크게 감소한다는 사실이 분명해졌습니다. 또한, 트랜스폼 트랙과 같은 트랙은 블렌딩, 일부만 애니메이팅한 트랜스폼, 상대 트랜스폼 원점, 어태치먼트, 컴포넌트 속도 등 처리해야 하는 요소들이 점점 증가하며 부담이 심해지고 있었습니다.

그래서 이런 콘텐츠를 콘솔 및 모바일 하드웨어상에서 여타 게임 시스템과 함께 실시간으로 실행하는 데 필요한 최적화를 실현하려면 보다 시스템적인 재설계가 분명히 필요했습니다.
 

속도 지향 설계

시퀀서 런타임의 새로운 토대를 살펴볼 때는 다음과 같은 설계 목표에 집중하였습니다.

확장성
새로운 런타임의 도입으로 수백 개의 트랙 및 시퀀스를 가진 콘텐츠를 제작하고 이런 콘텐츠를 전체적으로 평가하는 로직의 최적화도 가능해졌습니다. 여기에는 다음을 포함합니다.
  • 활성 시퀀서 트랙의 개수로 인해 퍼포먼스가 빠르게 저하되지 않도록 데이터를 할당하고 구성합니다.
  • 프레임별로 필요한 비용에 비해 필수적이지 않다고 확인된 로직과 브랜치를 완전히 제거할 수 있습니다. 가장 빠른 코드란 없습니다. 이건 시퀀서 평가 코드의 가장 표면적인 부분뿐만 아니라 모든 측면에 적용 가능합니다.
  • 평가 로직은 복잡하거나 비효율적인 추상화를 통한 메모리 상호작용 없이도 일괄적으로 필요한 데이터에 직접적으로, 효율적으로, 아무런 방해 없이 액세스할 수 있어야 합니다.

동시성
평가 로직 작성은 단순해야 하고 안전하고 효율적인 방식으로 다수의 코어로 자연스럽게 확장해 나가야 하며, 상하향 종속성의 표현적 정의(예를 들어, 모든 커브의 병렬적 평가 등)를 포함해야 합니다. 이를 통해 파이프라인을 단 한 번만 구성하면 된다는 종합적인 장점 덕분에 다수의 소규모 애니메이션과 초대형 시퀀스에서 이점을 얻을 수 있습니다.

확장 가능성
핵심 시스템을 재구현하지 않아도 기본 기능에 로직을 빌드할 수 있어야 합니다. 핵심 기능과 상호작용하는 상하향 기능은 적정한 선에서 추가할 수 있어야 합니다. 여기에는 다음을 포함합니다.
  • 현재 프레임의 모든 데이터가 파이프라인의 어떤 지점에서든 분명하게 표시되면서 변경 가능해야 합니다.
  • 안정적으로 종속성을 관리합니다.
이런 설계 목표와 시퀀서의 문제 영역은 다음과 같은 이유로 인해 자연스럽게 데이터 지향 설계 법칙을 고려하게 되었습니다.
  • 시퀀서의 주요 데이터는 동질적이며 순차적 배치가 가능합니다.
  • 일반적으로 각 데이터 변환 로직이 매우 독립적이며 컨텍스트에 구애받지 않습니다(예를 들어 커브의 f(x) 실행 등).
  • 제어 및 데이터 플로가 매우 선형적이며, 순환 또는 재귀적 종속성이 없습니다(예를 들어 이미 계산된 값의 재계산이 필요한 로직이 없음).
  • 초기 구성과 최종 프로퍼티 설정자에만 스레딩 제한이 있습니다.

4.26 버전에서는 시퀀서의 기반이 되는 런타임이 재설계되면서 엔티티 컴포넌트 시스템 패턴 기반의 평가 프레임워크를 통한 캐시 효율적이고 투명한 방식으로 평가 데이터를 내놓게 되었습니다. 내부에서 템플릿이라고 부르는 트랙 인스턴스에는 더 이상 평가가 필요하지 않습니다(하지만 레거시 런타임은 여전히 새 시스템과 함께 실행됩니다). 대신 각 트랙 유형별 데이터와 로직이 분리됩니다. 엔티티는 이제 소스 트랙 데이터와 관련된 컴포넌트 파트를 나타내며, 시스템은 특정 컴포넌트 또는 컴포넌트 조합과 관련된 단일 로직 데이터 변형을 나타냅니다. 이제 시스템에서 쿼리와 일치하는 모든 데이터를 일괄 실행합니다. 덕분에 모든 트랜스폼 프로퍼티를 캐시 효율적으로 적용하거나 한 번의 가상 함수 호출만으로 모든 플로트 채널을 평가할 수 있게 되었으며, 애니메이션이 적용되는 트랜스폼 프로퍼티의 수에 상관없이 캐시 누락이 거의 발생하지 않습니다.

그 결과 4.26 버전부터는 마이그레이션된 트랙 유형에 대한 시퀀서의 대규모 콘텐츠 평가 오버헤드가 획기적으로 감소하였습니다.

또한, 이런 접근법 덕분에 여러 시퀀스나 위젯 애니메이션에 대한 평가 데이터가 한데 통합되어, 실행되는 전체 애니메이션 세트의 최적화 가능성이 더욱 커졌습니다. 이로 인해 예전보다 더 많은 위젯 애니메이션을 동시 실행하는 것이 가능해졌으며, 필요에 따라 다수의 개별 애니메이션이나 시퀀스를 함께 블렌딩할 수도 있습니다.

파이프라인 예시
모든 트랜스폼 트랙의 평가에 쓰이는 파이프라인 예시를 하나 살펴보겠습니다. 시퀀서의 트랜스폼 트랙은 키프레임 채널 1~9개의 컴포짓 플로트, 즉 X/Y/Z 위치, 롤/피치/요(Yaw) 회전, X/Y/Z 스케일로 구성됩니다. 오브젝트에 트랜스폼을 적용하려면 우선 현재 시점에 이 커브들을 평가한 다음, 그 결과로 'USceneComponent::SetRelativeTransform'을 호출해야 합니다. 4.26 이전에는 이 채널 데이터가 템플릿 오브젝트에 복사되었는데, 템플릿 오브젝트는 최대 9개의 채널과 각 채널을 평가하고 오브젝트에 적용할 로직을 포함했습니다.
Figure 2
[그림 2] 4.26 이전 버전의 트랜스폼 트랙 평가
 
이런 설계에서는 트랙의 수에 따라 가상 함수 호출의 수(다이내믹 디스패치)가 선형적으로 확장되며 이에 따라 캐시 누락 가능성도 생깁니다.

새로운 프레임워크에서는 이 트랙이 컴포짓 플로트 채널에 대한 포인터와 함께 오브젝트에 대해 리졸브될 때 트랜스폼 엔티티가 생성됩니다. 바로 'USceneComponent::SetRelativeTransform'에 대한 함수 포인터이자 해당 엔티티가 트랜스폼 프로퍼티라는 걸 나타내 주는 태그입니다. Figure 3
[그림 3] 4.26 이후 버전의 새로운 트랜스폼 트랙 평가
새로운 접근법은 다음과 같은 이유로 인해 획기적으로 개선되었습니다.
  • 문제, 데이터, 인스트럭션 캐시 집약성이 개선되었으며 스케일에 따라 훨씬 더 빠른 속도를 보여줍니다.
  • 가상 함수 호출의 수가 개별 트랙 수가 아닌, 활성 시스템 유형에 따라 확장됩니다.
  • 전체 데이터 규모가 아니라 컴포넌트 데이터의 조합 수에 비례하여 캐시 누락이 발생합니다.
  • 최적화가 각 트랙에 제한되지 않고 전체 데이터 세트에 걸쳐 발생할 수 있습니다.
  • 로직에 특별한 변화 없이, 파이프라인의 일부가 동시에 수행될 수 있습니다.
예를 들어 위 예시의 ‘플로트 채널 평가’ 시스템은 현재 프레임의 모든 플로트 채널을 병렬적으로 평가할 수 있으며, 여기에 각 플로트 채널이 어떤 프로퍼티에 애니메이션을 부여하는지 또는 어떤 방식으로 조합 또는 적용되었는지는 아무런 상관이 없습니다.

나아가 다수의 트랜스폼을 단일 오브젝트로 블렌딩하는 것처럼 중간 데이터 변형을 도입하는 작업이 훨씬 더 간단하고 세분화되었습니다.

4.26 이전 버전에 이런 기능은 모든 프로퍼티 유형에 대한 모든 입/출력을 저장 및 처리하는 전용 클래스에 구현되어 있었습니다. 하지만 소규모 할당 최적화 및 다이내믹 디스패치의 비용으로 스토리지 및 CPU 오버헤드가 발생하기도 했습니다. 또한, 블렌딩 코드 경로를 고려한 방식으로 프로퍼티 적용을 구현해야 했으며, 이로 인해 블렌딩이 아닌 일반 코드 경로를 더욱 복잡하게 만들고 저하시켰습니다.
Figure 4
[그림 4] 4.26 이전 버전의 트랜스폼 트랙 평가 블렌딩
새로운 파이프라인에서는 이 블렌딩 코드가 자체 시스템에서 고유 ID를 할당받은 입/출력으로 구현됩니다. 그러면 병렬 작업과 데이터 모델의 효율성 개선으로 인해 작업 속도가 향상될 뿐만 아니라, 블렌딩이 필요하지 않을 때는 아예 시스템이 존재하지 않기 때문에 런타임 오버헤드도 전혀 발생하지 않습니다.
Figure 5
[그림 5] 4.26 이후 버전의 트랜스폼 트랙 평가 블렌딩

메모리 레이아웃

시퀀서 메모리에서 평가 데이터가 어떤 모습인지 좀 더 자세히 살펴보겠습니다. 레이아웃 데이터 접근법을 다양하게 시도해 보면서 메모리 크기, 캐시 효율성, 재할당 비용 그리고 동시 액세스 등을 적절히 조율한 끝에 다음과 같은 데이터 모델에 정착하였습니다.

엔티티는 일괄적으로 엔티티 할당으로 그룹화되며, 각 할당에는 최소 하나 이상의 엔티티가 포함됩니다. 결정적으로 할당 내의 모든 엔티티에는 정확히 똑같은 수와 유형의 컴포넌트가 있습니다. 특정 엔티티로부터 컴포넌트가 추가 또는 제거된다면, 이는 다른(또는 새로운) 할당으로 이주됩니다. 할당은 준비된 커패시티에 따라 크기가 유동적으로 변하면서, 메모리 할당(malloc) 호출 없이도 새로운 엔티티가 추가될 수 있도록 합니다(필요한 것은 컴포넌트 데이터의 초기화뿐입니다).
Figure 6
[그림 6] FEntityAllocation 및 FComponentHeader 할당 예시
예를 들어, Float Result 0, Float Channel 0, Eval Time 컴포넌트의 할당은 예시 데이터 및 해당 채널 평가 관련 로직과 함께 아래 표시되어 있습니다.
Figure 7
[그림 7] 엔티티 할당의 예시 데이터
보시다시피 동일한 유형의 모든 컴포넌트는 한 할당 내에서 순차적으로 배치됩니다. 컴포넌트 A, B, C를 포함한 할당에 대한 결과는 AAA..A, BBB..B, CCC..C의 레이아웃으로 나타나며 각 유형은 캐시 라인에 정렬됩니다. 이런 방식으로 데이터를 정리하면 엔티티의 ID에 전혀 영향을 미치지 않고 엔티티 데이터의 위치를 제어할 수 있으며, 각 컴포넌트 배열에 대한 읽기 및 쓰기 액세스도 제어 가능할 뿐 아니라(지금으로선 뮤텍스(mutex) 방식이지만, 나중에 충돌이 문제가 될 경우 특화된 스케줄러로 확장될 수도 있음) 유형 간의 패킹을 잘 유지할 수 있습니다. 시스템에서 컴포넌트 A 및 B에 대한 모든 컴포넌트 데이터가 필요하다면 비트 마스크에 따라 결정되는 할당 유형만 확인하면 됩니다. 이를 통해 시스템은 수천 개가 될 수도 있는 내부 엔티티가 현재 필요한 유형과 일치하는지 즉각적으로 파악할 수 있습니다.

이런 패턴 일치 접근법은 데이터 변형 로직을 데이터의 구성으로부터 완전히 분리하여, 시스템이 스케일의 확장에도 퍼포먼스를 유지하면서 관련 없는 부분과는 상관 없이 다양한 컴포넌트 데이터 조합에도 병렬 작업을 할 수 있게 해 줍니다. 위 예시를 더욱 확장하고자 트랜스폼 원점을 기준으로 트랜스폼 트랙을 만들 수 있는 시스템을 추가하는 일은 굉장히 간단하며 핵심 트랜스폼 시스템에 대한 무리한 변경이 필요하지 않습니다.
Figure 8
[그림 8] 4.26 이후 버전의 트랜스폼 원점을 활용한 트랜스폼 트랙 평가

업데이트 페이즈

시퀀서 시스템은 컨텍스트에 따라 실행되는 여러 페이즈에서 실행 가능하며, 제각기 고유한 지정 사항 및 제한이 있습니다. 이런 제한은 시퀀서에서 보다 엄격한 순서 지정 조건을 적용할 수 있게 해주며, 여전히 모든 프레임을 실행하는 대부분의 시스템에서 비동기 평가 로직이 가능하게 합니다. 이걸 크게 두 가지로 나누어 보자면 Spawn과 Instantiation 페이즈처럼 제한을 넘었거나 바인딩이 무효화되었을 때만 실행되는 시스템과, Evaluation과 Finalization처럼 각 프레임마다 실행되는 시스템으로 나뉩니다.
  • Spawn: 바인딩 리졸브 전후에 일어나야 하는 스포너블 로직 및 이벤트만을 저장합니다. 비동기 작업을 디스패치할 수 없습니다.
  • Instantiation: 엔티티를 생성/소멸, 또는 컴포넌트를 추가/제거하고자 하는 시스템을 전부 포함하고 Linker->EntityManager 태그로 분류합니다. 이 페이즈는 엔티티 매니저 구조가 변경되었을 때나 오브젝트 바인딩이 무효화되었을 때에만 실행됩니다. 비동기 작업을 디스패치할 수 없습니다.
  • Evaluation: 평가 상태를 실현하기 위해 모든 프레임을 실행해야 하는 시스템입니다. 엔티티나 컴포넌트를 추가하거나 제거하는 등 엔티티 매니저의 구조를 바꿀 수 없습니다. 대부분의 시스템은 여기서 실행됩니다.
  • Finalization: 프레임이 끝나는 시점에 실행됩니다.

이처럼 각 페이즈의 구분을 통해 시스템은 보다 비용이 높은 구성/해체 로직을 실질적으로 필요할 때만 실행하면서 일반 코드 경로의 90%를 최대한 간결하게 유지할 수 있습니다.

Spawn 및 Instantiation 페이즈는 엔티티 매니저에서 새로운 섹션이 평가되거나, 섹션이 더 이상 평가되지 않거나, 또는 바인딩이 무효화된다는 등의 구조적 변경이 있을 때만 실행됩니다. 이런 페이즈에서는 보통 프로퍼티 확인, 엔티티 구조 변경 또는 사전 애니메이션된 값 캐싱 등 비용이 높은 작업을 수행합니다. 이런 페이즈에서는 엔티티 매니저를 변경하거나 바꿀 수 있으며, Evaluation 및 Finalization 페이즈에서는 엔티티 매니저가 잠김 상태가 되어 구조적인 변화가 발생할 수 없습니다. 이때 컴포넌트 데이터는 여전히 읽기 또는 쓰기가 가능합니다.

이는 시퀀서 평가의 전형적인 시퀀스 플로입니다. 보시다시피 어떤 시퀀스에서도 제한을 넘지 않으면 오로지 Evaluation 및 Finalization 페이즈만 실행됩니다.Figure 9
[그림 9] 시퀀서 평가 시스템 페이즈 업데이트

스레딩

이제 읽고 쓸 수 있는 컴포넌트의 유형 관련 로직을 정의할 수 있게 되었으니, 컴포넌트 데이터에 대한 업스트림 및 다운스트림 종속성도 정의할 수 있습니다. 이를 통해 이런 데이터 변환을 올바른 비동기 태스크 그래프에 안전하게 자동 디스패치할 수 있게 되었습니다. 다수의 복잡한 키프레임 커브를 가진 콘텐츠처럼 규모가 큰 데이터 세트를 평가할 때, 이런 커브의 평가는 이제 다른 계산과 함께 비동기 실행이 가능하여 플랫폼에서 허용하는 동시성을 활용할 수 있습니다. 이건 컨텍스트 변경이나 스레드 선점의 잠재적 비용이 합리적일 때만 이로운 효과를 볼 수 있으나, 시퀀서의 스레드 세이프 설계는 이런 결정을 내부적으로 내리거나 사용자의 재량에 따라 결정할 수 있게 해 줍니다.

시퀀서로 작업하는 프로그래머를 위한 보다 포괄적인 아키텍처 해설은 앞으로 더 자세하게 공개될 예정입니다.
 

구형 런타임 시스템으로부터 4.26을 향한 비헤이비어 변화

일반적으로는 비헤이비어상의 어떤 변화도 체감되지 않을 것입니다. 스포너블(spawnable), 어태치먼트, 트랜스폼, 그 외 기타 프로퍼티는 전부 이전과 똑같이 작동하게 됩니다. 하지만 아래와 같이 비헤이비어에 아주 미묘한 변경 사항이 있습니다.
  • 주어진 유형의 활성 시퀀스가 이제 전부 동시에 평가됩니다. 4.26 이전에는 두 개의 개별 활성 시퀀스가 동일한 오브젝트에서 동일한 프로퍼티의 애니메이션을 제작한다면 각각 별개로 평가되어야 하기 때문에 프로퍼티의 제어권을 두고 충돌이 일어납니다. 4.26에서는 이런 시퀀스가 함께 평가되면서 서로 자연스럽게 블렌드됩니다. 앞으로는 더욱 확장되어 시퀀스 상호간 블렌드나 오버라이드에 대한 제어도 가능해집니다.
    • 모든 활성 위젯 애니메이션이 이제 함께 평가됩니다.
    • 모든 활성 레벨 시퀀스가 이제 함께 평가됩니다.
  • 시퀀스나 위젯 애니메이션의 수동 재생, 정지 또는 위치 설정은 더 이상 해당 함수의 호출에서 시퀀스를 동시에 재평가하지 않습니다. 그 대신 시퀀스 플레이헤드의 재생 및 이동 요청이 다음 프레임까지 연기될 수 있습니다.
    • 이 기능을 특정 시퀀스에서 비활성화하려면 시퀀스의 비동기 평가 옵션을 비활성화하면 되며, 퍼포먼스 비용이 듭니다. 이 경우 동기 재평가를 강제하면서 앞서 (1)에서 설명했던 블렌딩 비헤이비어가 비활성화됩니다.
Figure 10
[그림 10] 비동기 평가 시퀀스 체크
  • 이징 커브(easing curve)를 가진 절대 블렌드 트랙은 이제 오브젝트의 초기값부터 블렌딩합니다. 4.26 이전, 블렌드 웨이트는 기여 요소가 단 하나라도 있다면 항상 정규화되었습니다. 즉, 상대에서 절대로 변경되는 블렌드에는 두 섹션이 필요하다는 뜻이었습니다.
     
    4.26에서는 상대에서 절대로 변경되는 블렌드가 이제 이즈 인/아웃(ease in/out)이 가능한 단 하나의 절대 섹션으로 표현됩니다. 아래 그림 11에서 이즈 인/아웃할 수 있는 절대 블렌드의 예시를 볼 수 있습니다.

 
[그림 11] 절대 블렌드 예시
 
  • 시퀀스 평가 관련 재진입을 일으키는 이벤트 트랙(타 시퀀스 재생, 재생 상태 변경, 플레이헤드 이동 등)은 이제 사후 평가 위치로 제한됩니다(즉, 더 이상 PreSpawn이나 PostSpawn에서 허용되지 않습니다). 이는 이제 새 이벤트 트랙의 기본 설정입니다. 4.26 이전에는 이벤트 트랙이 기본적으로 PostSpawn으로 설정되었습니다. 기존 트랙은 계속 PostSpawn 설정을 유지하지만, 새 트랙은 이제 PostEval이 기본 설정입니다.
Figure 12[그림 12] 이벤트 트랙 위치를 At End of Evaluation으로 변경

API 변경 사항

UE::MovieScene 네임스페이스
신규 시퀀서 코드베이스 모두 클래스명의 과잉 접두사 필요를 줄이고자 UE::MovieScene 네임스페이스에 포함됩니다. 이번 작업의 일환으로 기존 MovieScene 네임스페이스에 포함되었지만 사용 빈도가 높지 않던 코드는 현재 코딩 표준의 일관성과 지속성을 확보하고자 전부 UE::MovieScene으로 옮겨졌습니다.

드문 경우지만 서드 파티 코드가 지금은 존재하지 않는 MovieScene 네임스페이스, 유형, 함수를 참조하는 경우 UE::MovieScene로 변경되어야 합니다.

UMovieSceneTrack
사용자에게 커스텀 트랙 구현이 있다면, 트랙 템플릿의 컴필레이션 관련 API는 다른 평가 방법으로 구분을 하고자 별개의 인터페이스(IMovieSceneTrackTemplateProducer)로 마이그레이션됩니다. CreateTemplateForSection, CustomCompile, PostCompile 등 더 이상 기본 클래스에 속해 있지 않는 함수를 정의하려면 이 인터페이스를 자신의 UMovieSceneTrack 유형에 추가해야 합니다.

트랙/세그먼트 블렌더
GetRowSegmentBlender GetTrackSegmentBlender는 이제 기능하지 않으며 더 이상 호출되지 않습니다. 트랙 평가 필드는 이제 수정 시 재생성되어 에셋에 저장되므로 더 이상 컴파일 시간에 재계산될 필요가 없습니다.

UMovieSceneTrack::PopulateEvaluationTree는 커스텀 오버랩 비헤이비어를 정의하는 새로운 방식으로, FEvaluationTreePopulationRules에서 사용할 수 있는 내장 알고리듬을 활용합니다.

UMovieSceneSection
UMovieSceneSection::GenerateTemplate IMovieSceneTrackTemplateProducer::CreateTemplateForSection을 통한 템플릿 정의를 위해 제거되었습니다.

ChannelProxy
드문 경우지만 서드 파티 섹션 유형에 다이내믹 채널 레이아웃이 있을 경우(예를 들어 ChannelProxy가 생성자 외부에 재생성된 경우), 그 구조는 새로운 함수인 가상 EMovieSceneChannelProxyType CacheChannelProxy()에서 정의되어야 합니다.

요약

스포너블, 어태치먼트, 이벤트, 2D/3D 변환 및 플로트 프로퍼티만이 새 런타임 시스템으로 포팅되었음에도 콘텐츠 속도가 눈에 띄게 향상되면서 이런 기능들을 적극 활용할 수 있을 것으로 봅니다. 데이터 지향 설계 법칙을 시퀀서의 특정 문제 영역에 적용하면서 전반적인 최적화 개선이라는 목표를 달성했을 뿐만 아니라, 흩어져 있던 런타임 내 다양한 문제도 개선할 수 있었습니다. 이는 또한 높은 퍼포먼스를 유지하면서 키프레임/트랙/서브 시퀀스 파라미터화, 글로벌 블렌딩, 개선된 디버깅 툴을 빌드할 수 있는 기반이 되어 줄 것입니다.

아래 예시는 제각기 수동으로 키잉된 개별 스포츠카 액터 500개가 나란히 달리는 모습을 4.25와 4.26에서 보여줍니다. SetRelativeTransform의 수동 호출 오버헤드는 대략 2.5ms로 측정되어 시퀀서 오버헤드가 약 7.5배 개선되었습니다.
 
[그림 13] SetRelativeTransform 비용의 퍼포먼스 차이 시연
 
이 정보가 재미있으면서도 유익하길 바랍니다. 시퀀서에 대해 더 자세히 알아보려면 툴의 문서 페이지를 확인하세요.
    뉴스
    4월 14일

    메타휴먼 크리에이터 얼리 액세스가 출시되었습니다!

    메타휴먼 크리에이터를 경험하기 위해 기다리셨다면 바로 지금 얼리 액세스를 신청하고, 여러분만의 특별한 메타휴먼을 제작해 보세요!
    뉴스

    메타휴먼 크리에이터 얼리 액세스가 출시되었습니다!

    메타휴먼 크리에이터를 경험하기 위해 기다리셨다면 바로 지금 얼리 액세스를 신청하고, 여러분만의 특별한 메타휴먼을 제작해 보세요!
    뉴스
    12월 3일

    언리얼 엔진 4.26이 출시되었습니다!

    이번 버전에서는 사실적인 리얼타임 환경과 캐릭터를 만들 수 있도록 확장된 새로운 툴, 지속적으로 진보한 버추얼 프로덕션 툴세트, 더 높은 품질의 미디어 출력, 향상된 디자인 리뷰 툴과 그 이상을 만나보실 수 있습니다.
    뉴스

    언리얼 엔진 4.26이 출시되었습니다!

    이번 버전에서는 사실적인 리얼타임 환경과 캐릭터를 만들 수 있도록 확장된 새로운 툴, 지속적으로 진보한 버추얼 프로덕션 툴세트, 더 높은 품질의 미디어 출력, 향상된 디자인 리뷰 툴과 그 이상을 만나보실 수 있습니다.
    뉴스
    5월 13일

    언리얼 엔진 5 최초 공개

    최초로 공개하는 언리얼 엔진 5와 차세대 게임 그 이상의 모든 분야에서 크리에이터들에게 리얼타임 렌더링의 극한까지 구현할 수 있는 자유를 제공하는 새로운 핵심 기술들을 가장 먼저 살펴보세요.
    뉴스

    언리얼 엔진 5 최초 공개

    최초로 공개하는 언리얼 엔진 5와 차세대 게임 그 이상의 모든 분야에서 크리에이터들에게 리얼타임 렌더링의 극한까지 구현할 수 있는 자유를 제공하는 새로운 핵심 기술들을 가장 먼저 살펴보세요.