이 가이드에서는 언리얼 엔진 4 프로젝트를 언리얼 엔진 5(UE5) 로 업그레이드하는 방법을 설명합니다.
언리얼 엔진 5(UE5) 는 언리얼 엔진 4(UE4) 기반 시스템에 여러 가지 변경사항, 업그레이드, 새로운 기능을 도입합니다. 엔진에 많은 변화가 있었지만, 내장 변환 프로세스로 사용자 작업 없이 마이그레이션에 필요한 작업 대부분이 처리됩니다.
먼저 에픽게임즈 런처에서 UE5를 실행합니다. 이미 실행 중인 경우, 메인 메뉴에서 파일(File) > 프로젝트 열기(Open Project) 로 이동합니다. 업그레이드할 프로젝트를 선택하고 열기(Open) 를 클릭합니다.
사본 열기(Open a Copy) 버튼을 클릭하여 별도의 프로젝트 사본을 업그레이드하고, 원본은 그대로 둡니다.

이 다이얼로그에서 추가 옵션(More Options) 을 클릭하면 다음 중에서 선택할 수 있습니다.
- 변환 생략은 프로젝트를 원래의 상태로 엽니다.
- 제자리 변환은 사본을 만들지 않고 기존 프로젝트를 변환합니다.
프로젝트를 UE5로 변환할 때 앞서 설명한 사본 열기(Open a Copy) 워크플로 사용을 권장합니다. 제자리 변환(Convert in-place) 및 변환 생략(Skip conversion) 옵션은 예상과 다르게 작용하여 데이터 손상 및 손실로 이어질 수 있습니다.
프로젝트를 최신 언리얼 엔진 버전으로 업그레이드하면 이전 버전에서는 열 수 없습니다. 열려는 시도는 실패할 것입니다.
변환 프로세스가 완료되면 대부분 프로젝트는 별도의 작업 없이 UE5에서 빌드 및 실행할 준비가 됩니다. 하지만 특정 신기능 또는 업그레이드된 기능을 UE5에서 제대로 작동시키고 완전히 활용하기 위해 수동 업데이트가 필요할 수 있습니다. 나나이트, 루멘, 카오스가 시스템적으로 가장 많이 달라졌습니다. 그래픽 중심의 프로젝트의 경우 UE4에서와 동일한 모습으로 나타내려면 나나이트와 루멘에 작업이 다소 필요하며, 아직 카오스로 전환하지 않은 피직스 기반 프로젝트의 경우 환경설정과 에셋 수정이 필요합니다.
이 페이지에서는 필수 업데이트와 시스템 지원 중단 및 대체 등의 주목할 만한 시스템 변경사항에 대해 설명합니다. 이러한 기능을 사용 중인 경우 필수 업데이트 섹션에서 설명하는 업데이트를 수행하여 UE4 프로젝트를 UE5로 업그레이드해야 합니다. 기타 변경사항 섹션에서 설명하는 업데이트는 프로젝트의 성능에 영향을 미칠 수도, 미치지 않을 수도 있으나 이를 염두에 두는 것이 좋습니다.
버전별 변환 참고 사항
생성된 언리얼 엔진 버전에 따라 프로젝트가 어떻게 변환되는지 이해하려면 아래 표를 참조하세요.
프로젝트 생성 버전 | 변환 참고 사항 |
---|---|
언리얼 엔진 4.0~4.26 | 프로젝트가 생성된 것과 동일한 버전 또는 이후 버전의 언리얼 엔진에서 로드됩니다. 언리얼 엔진 API가 계속 변경되었기 때문에 오래된 버전에서 생성된 일부 프로젝트는 제대로 로드되지 않을 수 있습니다. 예를 들어 4.0에서 저장된 블루프린트는 4.10에서 지원이 중단되고 5.0에서는 더 이상 존재하지 않는 함수를 호출할 수 있습니다. 다만, 프로젝트는 로드되기 때문에 지원 중단되었거나 제거된 레퍼런스를 고칠 수 있습니다. |
언리얼 엔진 4.27 | 프로젝트는 언리얼 엔진 4.27, 5.0 및 이후 버전에서 로드됩니다. 프로젝트는 언리얼 엔진 5.0 얼리 액세스에서 로드되지 않습니다. 이는 언리얼 엔진 5.0 얼리 액세스 호환성 참고 사항에서 알려드렸습니다. |
언리얼 엔진 5.0 | 프로젝트가 언리얼 엔진 5.0 이후 버전에서 로드됩니다. |
언리얼 엔진 5.1 이후 버전 | 프로젝트가 생성된 것과 동일한 버전 또는 이후 버전의 언리얼 엔진에서 로드됩니다. |
에셋 호환성
이전 버전의 언리얼 엔진에서 저장한 에셋은 최신 버전에서 열 수 있습니다. 예를 들어 언리얼 엔진 4.26에서 저장한 에셋은 언리얼 엔진 5.0에서 열 수 있습니다.
최신 버전의 언리얼 엔진에서 저장한 에셋은 이전 버전에서 열 수 없습니다. 예를 들어 언리얼 엔진 5.0에서 저장한 에셋은 언리얼 엔진 4.26에서 열 수 없습니다.
필수 업데이트
다음 섹션에서는 UE5에 가져오기 위해 UE4 프로젝트에서 변경해야 할 수도 있는 사항을 설명합니다. 필수인 사항도 있으며, 권장되는 선택 사항이자 향후 UE5 버전에서는 필수가 될 사항도 있습니다.
개발 플랫폼 변경
Visual Studio에서 C++ 코드를 작성했으며 아직 Visual Studio 2019 버전을 사용하고 있지 않다면 2019로 전환해야 합니다. UE4 최신 버전의 디폴트 Visual Studio IDE도 Visual Studio 2019입니다. UE5는 Visual Studio 2017과 Visual Studio 2015를 지원하지 않습니다.
UE5는 32비트 플랫폼을 지원하지 않으며, 향후에 추가 지원할 계획도 없습니다.
UE5는 대상 플랫폼 이름 을 표준화합니다. 빌드 스크립트를 업데이트해야 하며, 상황에 따라 DeviceProfiles.ini
파일도 업데이트해야 합니다. 이러한 스크립트를 직접 실행하는 경우에 기본적으로 영향을 미칩니다. UAT 를 사용하는 경우에는 변경할 필요가 없습니다.
다음 표에는 변경된 대상 플랫폼 이름 목록이 포함되어 있습니다.
UE4 대상 플랫폼 이름 | UE5 대상 플랫폼 이름 |
---|---|
Windows | WindowsEditor |
WindowsNoEditor | Windows |
MacNoEditor | Mac |
Mac | MacEditor |
LinuxNoEditor | Linux |
Linux | LinuxEditor |
LinuxAArch64NoEditor | LinuxAArch64 |
PhysX 및 카오스 피직스 시스템
UE5는 물리적 시뮬레이션에 대해 카오스 피직스 엔진을 사용하며, 디폴트 값인 PhysX 를 대체합니다. 카오스 피직스의 피직스 시뮬레이션은 PhysX와 다르게 작동하며, 개발자가 일관적인 비헤이비어를 보려면 조정을 수행해야 합니다.
피직스 틱 속도는 기본적으로 새로 생성된 프로젝트에 따라 변경됩니다. 틱 속도 변화는 프로젝트 세팅(메뉴: 편집(Edit) > 프로젝트 세팅(Project Settings) ) 내에 있는 틱 비동기 피직스에서 액세스할 수 있습니다. 이 신기능은 게임 스레드 대신 자체 스레드에서 피직스를 시뮬레이션합니다.
이 변경사항은 고정된 속도에서 물리적 시뮬레이션 업데이트를 실행함으로써 결정론을 향상합니다. 고정된 업데이트 속도로 인해 네트워크 연결된 피직스 시뮬레이션은 동기화를 유지하기가 더욱 쉬워지는데, 이는 클라이언트 및 서버 시스템이 동일한 간격으로 실행되기 때문입니다.
더 이상 게임 스레드에서 실행하지 않는다는 것은 게임 스레드의 피직스 시스템에 대한 입력과 입력에 대한 피직스 시스템의 반응 사이에 딜레이가 생길 수 있다는 뜻입니다. 게임플레이 로직이 피직스 시뮬레이션에 크게 의존하는 프로젝트에서 예측 불가능한 비헤이비어를 방지할 수 있도록 이 딜레이를 염두에 두어야 합니다. 피직스 스레드에서 실행되는 C++ 콜백에서 피직스를 많이 활용하는 게임플레이 코드를 실행하여 이주할 수 있지만, 이 접근 방식을 사용하려면 프로젝트 코드를 수정해야 합니다.
셰이더 디버깅을 위한 콘솔 변수
언리얼 엔진 5가 출시되면서 셰이더 디버깅에 사용되는 콘솔 변수가 변경되었습니다. 아래 표는 이름이 어떻게 변경되었는지 보여줍니다.
프로젝트의 환경설정 파일에서 이러한 변수를 사용하는 경우 셰이더 디버깅을 위해 생성된 데이터를 계속 사용하려면 UE5로 이전할 때 이를 업데이트해야 합니다.
이전 콘솔 변수 이름 | 신규 콘솔 변수 이름 | 설명 |
---|---|---|
r.Shaders.KeepDebugInfo |
r.Shaders.Symbols |
심볼을 생성하고 이를 콘솔용 디스크에 써서 셰이더의 디버깅을 활성화합니다. 데스크톱 심볼은 온라인에 저장됩니다. |
N/A | r.Shaders.ExtraData |
셰이더 이름과 임의의 추가 셰이더 데이터를 생성합니다. |
r.Shaders.PrepareExportedDebugInfo |
r.Shaders.GenerateSymbols |
심볼을 생성하지만 디스크에 쓰지는 않습니다. 심볼은 파생 데이터 캐시(Derived Data Cache, DDC)에 저장됩니다. |
r.Shaders.ExportDebugInfo |
r.Shaders.WriteSymbols |
생성된 심볼을 디스크에 작성합니다. |
r.Shaders.AllowUniqueDebugInfo |
r.Shaders.AllowUniqueSymbols |
셰이더 소스를 기반으로 심볼 연결을 생성합니다. 기본적으로 꺼져 있습니다. |
r.Shaders.ExportDebugInfo.Zip |
r.Shaders.WriteSymbols.Zip |
디스크에 심볼을 쓸 때 단일 ZIP 파일이 생성됩니다. |
콘솔 변수 r.Shaders.KeepDebugInfo
는 2개의 콘솔 변수(r.Shaders.Symbols
및 r.Shaders.ExtraData
)로 나뉘어 심볼만 필요한 변경 런타임 셰이더 데이터의 변경을 제거합니다. 최종 셰이더 데이터를 변경하지 않고 출시 빌드에 대해 심볼이 생성되도록 허용하므로 내보낸 디버그 정보를 지원하는 플랫폼이 유용합니다.
이 프로세스에 대한 자세한 정보는 셰이더 디버깅 페이지를 참조하세요.
기타 변경사항
이 업데이트는 언리얼 엔진 4(UE4) 프로젝트를 언리얼 엔진 5(UE5) 에서 실행하는 데 필요하지는 않지만 향후 버전에서 필요하거나 엔진의 모든 기능을 활용하는 데 도움이 될 수 있습니다.
이 페이지를 자세히 읽고 언리얼 엔진 5(UE5) 의 향후 버전에 대비하고 엔진의 새롭고 업그레이드된 기능을 최대한 활용하는 방법을 알아보세요.
C++ 오브젝트 포인터 프로퍼티
다음 섹션의 내용은 C++ 코드를 사용하는 프로젝트에만 적용됩니다. 블루프린트 비주얼 스크립팅 사용자는 어떠한 작업도 할 필요가 없습니다. C++ 라이선스 사용자의 프로젝트는 원시 오브젝트 포인터를 계속 사용하거나, TObjectPtr
를 선택적으로 사용할 수 있습니다.
UE5는 에디터 빌드의 원시 오브젝트 포인터에 대한 선택적 대체로 템플릿 기반 64비트 포인터 시스템인 TObjectPtr
를 도입합니다. 이 시스템은 에디터 빌드에 다이내믹 해상도와 액세스 트래킹을 추가하면서 비에디터 빌드의 원시 포인터와 동일한 역할을 합니다. TObjectPtr
변수는 또한 함수로 전달되거나 로컬 변수에 저장될 때 자동으로 원시 포인터로 변환됩니다. UPROPERTY
변수에 원시 포인터가 있었던 많은 엔진 클래스에서 이제 TObjectPtr
를 사용합니다. TObjectPtr
타입과의 상호작용 대부분이 묵시적으로 원시 포인터로 변환되지만, 엔진 클래스 멤버 변수와의 직접 상호 작용에서 원시 포인터 시맨틱을 TObjectPtr
시맨틱으로 변환해야 하는 경우가 드물게 있습니다. 예를 들어 UE4에서 AActor
의 RootComponent
프로퍼티는 USceneComponent*
였지만, UE5에서는 TObjectPtr<USceneComponent>
입니다. 드물게 USceneComponent*
반환 타입을 갖는 GetRootComponent
호출이 항상 그대로 유지될 수 있지만, RootComponent
와의 직접 상호작용을 업데이트해야 할 수도 있습니다.
선택 사항이기는 하지만, UObject
포인터 프로퍼티에 대한 T*
와 UCLASS
및 USTRUCT
타입에 있는 컨테이너 클래스를 통해 TObjectPtr<T>
를 사용하는 것이 좋습니다. TObjectPtr
는 비에디터 빌드에 대한 원시 포인터로 변환되므로 출시된 제품의 동작 또는 성능에는 영향을 미치지 않지만, 에디터 빌드에서 개발할 때 경험이 향상될 수 있습니다. 다음의 방식을 따라 여러분의 프로그래밍 스타일을 이 새로운 포인터 시스템에 맞추세요.
-
컨테이너 함수의 ‘Find’ 패밀리를 호출할 때
T**
대신TObjectPtr<T>*
를 사용하여 반환 값을 캡처합니다. -
원시 포인터 컨테이너를 통한 범위 기반 반복작업에서
auto*
를 이터레이터 변수 타입으로 사용했을 수 있습니다. 이를auto&
로 바꿉니다. 또한 새 코드에서auto&
또는const auto&
를 사용하는 것을 권장합니다.TObjectPtr
가 해결된 오브젝트 주소를 캐시하고 이후 액세스 시도에 소요되는 시간을 절약할 수 있습니다. -
원시 포인터가 필요하고 묵시적 변환을 사용할 수 없는 경우
TObjectPtr
에서ToRawPtr
또는Get
을 호출합니다. 일반적인 사례로는const_cast
내부의 3항 연산 및 사용이 있습니다. 함수 델리게이트로 파라미터를 전달할 때 평행 델리게이트 함수를 패스스루로 선언하고, 원시 포인터를TObjectPtr
파라미터로 대체합니다. 다음 예시에서는 패스스루 델리게이트 함수를 보여줍니다.// 대부분의 사례에서 사용할 원시 포인터를 사용하는 원본 함수 시그니처: static bool MyFunction(UObject* FirstParameter); // 드물게 묵시적 변환을 사용할 수 없을 때 이 패스스루 함수를 사용합니다. // TObjectPtr를 사용하는 패스스루 함수 시그니처: static bool MyFunction(TObjectPtr<UObject> FirstParameter); // (소스 파일의) 패스스루 함수 바디: bool UMyClass::MyFunction(TObjectPtr<UObject> FirstParameter) { return ShouldShowResetToDefault(FirstParameter.Get()); }
파라미터를 함수에 전달하거나 로컬 변수에 데이터를 저장하는 등과 같은 대부분의 경우 TObjectPtr
는 자동으로 원시 포인터 타입으로 변환됩니다. 위에 설명한 것과 같이 부 코드 수정을 수행해야 하는 경우가 간혹 있지만 대부분의 프로젝트에는 필요하지 않습니다.
선택적 변환 툴
UE5에는 엔진에서 볼 수 있는 원시 포인터 프로퍼티를 TObjectPtr
시스템으로 자동 변환하는 프로그램인 UnrealObjectPtrTool 이 있습니다. 코드 IDE에 있는 솔루션 계층구조의 UE5/Programs/UnrealObjectPtrTool/
섹션에서 찾을 수 있습니다. 소스 코드는 Engine/Source/Programs/UnrealObjectPtrTool/
에 있습니다. 실행 파일은 Engine/Binaries/Win64
폴더에 있습니다. 운영체제 또는 개발 환경에 따라 실행 파일이 Engine/Binaries/OS 폴더에 있을 수도 있습니다(OS는 사용 중인 운영체제를 의미).
이 선택적 프로그램의 목적은 원시 포인터에서 TObjectPtr
시스템으로 코드를 변환하는 프로세스 속도를 높이는 것입니다. 헤더 파일 내에 있는 클래스와 구조체 정의의 UPROPERTY
변수를 업데이트하지만 위에 설명한 것과 같이 소스 코드를 반드시 모두 변경하지는 않습니다. UnrealObjectPtrTool 사용 전에 수동으로 조정하고 프로젝트가 컴파일되는지 확인해야 합니다.
UnrealObjectPtrTool 을 사용하려면 다음 단계를 따르세요.
-
Engine\Programs\UnrealHeaderTool\Config
디렉터리에 있는DefaultEngine.ini
UHT 환경설정 파일을 찾습니다. -
DefaultEngine.ini 파일 내부에서 다음 스크립트를 수정합니다.
NonEngineNativePointerMemberBehavior=AllowAndLog
-
UHT에서 모든 코드를 파싱하도록 프로젝트를 다시 빌드합니다.
-
프로젝트 컴파일 방식에 따라 Log.txt 또는 UnrealHeaderTool.log 파일에서 UHT 로그 정보를 찾을 수 있습니다. 이 파일은 다음 디렉터리에서 찾아볼 수 있습니다.
C:\Users\USERNAME\AppData\Local\UnrealBuildTool\Log.txt C:\Users\USERNAME\AppData\Local\UnrealHeaderTool\Saved\Logs\UnrealHeaderTool.log Engine\Programs\UnrealBuildTool\Log.txt
-
Visual Studio 솔루션에서 UnrealObjectPtrTool을 컴파일합니다.
이 단계는 소스에서 엔진을 실행하는 경우에만 필요합니다. 그 외의 경우에는 에픽게임즈 런처에서 설치할 때 UnrealObjectPtrTool이 사전 컴파일됩니다.
-
UnrealObjectPtrTool 실행파일 실행:
UnrealObjectPtrTool.exe <UHT_LOG_PATH> -SCCCommand="p4 edit -c UPGRADE_CL {filenames}"
선택적 파라미터 추가 가능: -PREVIEW 또는 -n으로 잠재적 변경사항을 미리 봅니다.
렌더링
다음 기본 세팅이 변경되었으며, 프로젝트의 외형에 영향을 미칠 수 있습니다.
-
스크린 스페이스 글로벌 일루미네이션: 스크린 스페이스 글로벌 일루미네이션(베타) 과 관련 콘솔 변수
r.SSGI.Enable
이 삭제되었고 이전 상태가 손실되었습니다. 스크린 스페이스 글로벌 일루미네이션을 프로젝트의 디폴트 글로벌 일루미네이션 메서드로 다시 활성화하려면 프로젝트 세팅(Project Settings) > (엔진) 렌더링((Engine) Rendering) > 글로벌 일루미네이션 프로퍼티(Global Illumination properties) 로 이동하고 다이내믹 글로벌 일루미네이션 메서드(Dynamic Global Illumination Method) 를 스크린 스페이스(베타)(Screen Space (Beta)) 로 설정합니다. 포스트 프로세스 볼륨에서 스크린 스페이스 글로벌 일루미네이션을 다시 활성화하려면 볼륨의 프로퍼티로 이동하여 글로벌 일루미네이션(Global Illumination) 카테고리에서 메서드(Method) 필드를 스크린 스페이스(베타)(Screen Space (Beta)) 로 설정합니다. -
루멘 하드웨어 레이 트레이싱을 사용한 레이 트레이싱 지원: 독립형 레이 트레이싱 기능은 언리얼 엔진 5에서 지원 중단됩니다. 루멘에서 이러한 라이팅 기능을 담당하므로 라이팅 이펙트를 연산하는 기능은 제거되지 않습니다. 언리얼 엔진 4에서 개발되었던 독립형 레이 트레이싱 시스템이 제거됩니다. 이러한 기능은 대체로 다른 기능과 별개로 작동했기 때문에 엔진의 동일한 기능이 동등하거나 일관되게 지원된다고 보장할 수 없었습니다. 루멘은 리플렉션 및 글로벌 일루미네이션에 대한 레이 트레이싱 기능의 전체적으로 새로운 구현을 하드웨어 레이 트레이싱 패스에 추가합니다. UE5 개발이 진행되면서 루멘의 레이 트레이싱 기능 또한 향상되어 더욱 폭넓은 지원과 엔진의 다른 파트와의 기능 패리티를 제공합니다.
- 레이 트레이싱 리플렉션, 글로벌 일루미네이션 및 섀도가 개별적으로 활성화할 수 있는 자체적인 기능으로 분리되었습니다. 각 기능은 프로젝트 세팅(Project Settings) > 렌더링(Rendering) 에서 찾을 수 있으며 하드웨어 레이 트레이싱 지원(Support Hardware Ray Tracing) 을 활성화해야 사용할 수 있습니다.
글로벌 일루미네이션 섹션에서 선호하는 다이내믹 글로벌 일루미네이션 메서드(Dynamic Global Illumination Method) 를 선택합니다. 리플렉션 섹션에서 선호하는 리플렉션 메서드(Reflection Method) 를 선택합니다. * 하드웨어 레이 트레이싱 섹션에서 사용할 레이 트레이싱 섀도(Ray Tracing Shadows) 박스를 선택합니다.
- 리플렉션과 글로벌 일루미네이션은 글로벌 일루미네이션 및 리플렉션 메서드에서 선택한 포스트 프로세스 볼륨을 사용하여 설정할 수도 있습니다.
-
메시 디스턴스 필드 생성: 루멘의 소프트웨어 레이 트레이싱 기능은 메시 표현에 있어 부호 있는 디스턴스 필드 를 주로 활용합니다. 모든 디스턴스 필드(Distance Fields) 의 디폴트 복셀 밀도(Default Voxel Density) 가 0.1에서 0.2로 증가했습니다. 루멘으로 양호한 소프트웨어 트레이싱 품질을 달성하는 데 필요하지만 디스턴스 필드 메모리 사용량이 크게 증가합니다. 이를 적절히 조정하려면 프로젝트 세팅(Project Settings) > (엔진) 렌더링((Engine) Rendering) 으로 이동하여 메시 디스턴스 필드 생성(Generate Mesh Distance Fields) 체크 박스와 디스턴스 필드 복셀 밀도(Distance Field Voxel Density) 프로퍼티를 찾습니다. 이 설정을 적용하려면 변경 후에 에디터를 재시작해야 할 수 있습니다.
제거
하드웨어 테셀레이션 사용 사례 대부분에서 이제 나나이트 가 사용되지 않습니다. 하드웨어 테셀레이션이 UE5에서 제거되었습니다. 나나이트가 지원하지 않는 사용 사례에서 사용자는 필요한 경우 에셋의 해상도를 높일 수 있습니다.
루멘 은 라이트 전파 볼륨 및 디스턴스-필드 글로벌 일루미네이션(Distance-Field Global Illumination, DFGI) 을 대체합니다.
-
라이트 전파 볼륨과 비교해서 루멘은 추가 기능과 더 높은 품질을 제공하고 현재 개발에 박차를 가하고 있으나, 기본 퍼포먼스 비용이 높습니다.
-
DFGI는 실험단계 기능이었습니다. 개발자는 다이내믹 글로벌 일루미네이션에 대해 DFGI 대신 루멘을 사용해야 합니다.
-
향후 루멘 글로벌 일루미네이션 및 리플렉션은 결과물의 품질이 비슷하거나 더 높은 레이 트레이싱 기능 대다수를 대체합니다.
-
UE4에서 지원 중단되었던 레거시 톤매퍼(Legacy Tonemapper) 가 더는 UE5에 존재하지 않습니다. 개발자는 어떠한 작업도 할 필요가 없습니다.
지원 중단
- 캐스케이드 는 UE 5.0에서 지원이 중단되며, 향후 버전에서 제거될 예정입니다. UE5 개발자는 나이아가라 로 전환해야 합니다. 캐스케이드 데이터를 나이아가라로 업그레이드하는 자동 컨버터가 개발되고 있습니다.
- 일부 레이 트레이싱 기능이 지원 중단되며, 지원이 필요한 독립형 시스템에서 루멘의 하드웨어 레이 트레이싱 시스템에 통합됩니다. 따라서 리플렉션 및 글로벌 일루미네이션은 루멘에 직접 통합될 예정입니다. 이러한 독립형 기능은 지원이 중단되었으며, 엔진 기능의 더욱 폭넓은 지원을 통해 통합 경험을 제공합니다. (자세한 정보는 위에 있는 '렌더링' 섹션을 참조하세요.)
월드 빌딩
지원 중단
월드 파티션(World Partition) 은 UE5에서 큰 스트리밍 월드를 처리하는 데 사용하는 시스템입니다. UE4에서 사용되었던 월드 컴포지션(World Composition) 시스템은 그대로 존재하지만 지원이 중단되며 업그레이드와 수정, 지원을 받지 못합니다. 월드 컴포지션은 향후 UE5 버전에서 제거됩니다.
맵을 월드 파티션 시스템으로 변환하려면 프로젝트에서 WorldPartitionConvertCommandlet
을 사용하고, 변환할 맵의 이름을 한 번에 하나씩 입력합니다. 예를 들어 패키지로 만든 QAGame
프로젝트의 /Game/Maps/Tools/Landscape/TM_WorldComp_P
에 있는 TM_WorldComp_P
맵을 변환하려면 다음의 명령줄 옵션을 사용하여 에디터를 실행합니다.
QAGame -run=WorldPartitionConvertCommandlet TM_WorldComp_P -ConversionSuffix -SCCProvider=None
TM_WorldComp_P
맵이 월드 파티션 시스템으로 변환됩니다. -ConversionSuffix
를 사용하여 원본 맵을 덮어쓰는 대신 변환된 맵을 TM_WorldComp_P_WP
로 저장합니다. -SCCProvider=None
옵션으로 인해 커맨드릿은 프로젝트의 소스 컨트롤 제공자와의 인터랙션 없이 실행됩니다. 이 프로세스는 또한 맵을 변환하는 데 사용되는 세팅이 포함된 TM_WorldComp_P.ini
파일을 생성합니다. 변환 프로세스는 기존 월드 컴포지션 데이터에서 (월드 파티션 시스템에 대한) 런타임 그리드를 빌드하고, 맵의 액터를 해당 그리드에 할당합니다.
C++를 사용하는 개발자는 UWorldPartitionRuntimeSpatialHash::ImportFromWorldComposition
및 UWorldPartitionRuntimeSpatialHash::GetActorRuntimeGrid
를 확인하여 그리드를 생성하고 액터를 그리드에 할당하는 데 사용되는 로직을 검사 또는 수정할 수 있습니다.
툴
제거
새 지오메트리 편집 툴이 실험단계인 레거시 편집가능 메시 플러그인(Legacy Editable Mesh Plugin) 을 대체합니다.
무비 렌더 큐(Movie Render Queue) 가 무비 씬 캡처(Movie Scene Capture) 를 대체합니다.
VR 레벨 편집(VR Level Editing) 은 VR 프리뷰만으로 축소되었지만 UE5는 버추얼 프로덕션 스카우팅을 계속 지원합니다.
테이크 레코더(Take Recorder) 가 시퀀스 레코더(Sequence Recorder) 를 대체합니다. 테이크 레코더에는 시퀀스 레코더의 기능이 전부 포함되어 있습니다.
카메라 애니메이션 시퀀스(Camera Animation Sequence) 가 카메라 애님(Camera Anim) 을 대체합니다.
UE5에서는 제거된 플러그인과 관련된 에디터 기능 팩(Editor Feature Packs) 도 제거됩니다. 이러한 플러그인을 사용한 경우, 프로젝트에서 제거된 콘텐츠를 참조하지 않도록 해야 합니다.
지원 중단
시퀀서(Sequencer) 는 UE5 정식 출시 이후 마티네(Matinee) 를 완전히 대체합니다. 마티네는 지원이 중단되었지만 UE4에 계속 남아 있었습니다.
컨트롤 릭
변경사항
스페이스(Space) 가 Null 로 이름이 변경됩니다.
기즈모(Gizmo) 가 셰이프(Shape) 로 이름이 변경됩니다.
현재에서 초기 트랜스폼 설정(Set Initial Transform from Current) 가 현재에서 트랜스폼 오프셋 설정(Set Offset Transform from Current) 으로 변경됩니다.
지원 중단
컬렉션(Collection) 이 배열(Array) 로 대체됩니다.
트랜스폼 컨스트레인트(Transform Constraint) 노드의 지원이 중단되고 개별 포인트, 로테이션, 부모 컨스트레인트 노드로 대체됩니다.
새로운 부모 컨스트레인트(Parent Constraint) 노드는 새 부모로 투영(Project to New Parent), 트랜스폼 설정(Set Transform) 노드 대신 사용할 수 있습니다.
부모 스위치 컨스트레인트(Parent Switch Constraint) 대신 스페이스 전환(Space Switching) 을 사용할 수 있습니다.
베지어 데이터 타입(Bezier Data Type) 이 스플라인 플러그인(Splines plugin) 으로 대체됩니다.
ControlRigHierarchyModifier 는 이제 Python에 사용되지 않습니다. 릭 엘리먼트 쿼리는 RigHierarchy, 릭 엘리먼트 작성은 RigHierarchyController 로 대체됩니다.
ControlRigBlueprint 에는 이제 이름이 controller 인 프로퍼티가 없습니다. 메인 RigVMController 에 액세스하려면 ControlRigBlueprint.get_controller() 함수를 사용합니다.
매핑은 컨스트럭션 스크립트가 아니라 컨트롤 릭 컴포넌트의 사전 초기화 에서 처리됩니다.
오디오
제거
언리얼 오디오 믹서 가 UE 5.0에서 지원 중단된 레거시 오디오 백엔드 를 대체합니다. 사용자는 어떠한 작업도 할 필요가 없습니다. UE5에서는 기본적으로 언리얼 오디오 믹서와 최신 오디오 백엔드를 활용합니다. 이는 모든 기존 오디오 기능과 호환됩니다.
지원 중단
오디오 볼륨, 사운드 클래스 믹스 및 사운드 큐 는 UE 5.0에서 지원이 중단되며, UE5의 후속 릴리스에서 제거될 계획입니다.
-
사운드 큐는 UE 5.0에서 사용 가능한 메타사운드(MetaSound) 로 대체됩니다.
-
사운드 클래스 믹스는 현재 사용 가능한 모듈레이션(Modulation) 및 서브믹스(Submix) 시스템으로 대체됩니다.
-
오디오 볼륨은 현재 개발 중이며 UE 5.0에서 사용 가능한 새 시스템으로 대체될 예정입니다.
사용자는 가급적 빨리 새 버전으로 이동하는 것이 좋습니다.
게임플레이 프레임워크
제거
블루프린트 네이티브화(Blueprint Nativization) 는 UE5에 없습니다. 이 기능을 활용한 프로젝트에는 변경사항이 없습니다. 성능에 영향을 미칠 수 있으나 적절하게 작동하려면 수정이 필요합니다. 이 경우 개발자는 다른 최적화 접근 방식을 수행해야 합니다.
네트워킹
지원 중단
AES, RSA 및 RSA 키 AES 암호화 핸들러 는 지원 중단되고 제거될 예정입니다.
코어
제거
젠 로더(Zen Loader) 가 이벤트 중심 로더(Event-Driven Loader) 를 대체합니다. 대부분의 사용자는 이벤트 주도형 로더와 직접 접속하지 않으므로 이 변경사항에 따라 프로젝트 마이그레이션 도중 작업을 수행할 필요가 없습니다.
지원 중단
언리얼 인사이트(Unreal Insights) 인스트루먼테이션은 UE 5.0 정식 출시 이후 통계 시스템(Stats System) 을 대체합니다. 통계 시스템은 UE 5.0에 계속 존재하지만 언리얼 인사이트를 위해 제거될 예정입니다.