참고: 이 섹션의 가이드를 릴리스 순서대로 따르십시오. 예를 들어 프로젝트를 2018에서 2020으로 업그레이드해야 하는 경우 2019 업그레이드 가이드를 읽고 변경해야 할 사항이 있는지 확인한 후 2020 업그레이드 가이드를 읽으십시오.
이 페이지에는 Unity 2017 버전에서 업그레이드할 경우 기존 프로젝트에 영향을 미칠 수 있는 Unity 2018 LTS의 변경 사항이 나와 있습니다.
2018 LTS는 2018.4로도 알려져 있습니다.
flex-grow, flex-shrink 및 flex-basis를 나타내는 최대 3개의 파라미터를 허용합니다. flex-shrink 및 flex-basis 파라미터는 선택 사항입니다. 생략할 경우 flex-basis는 0, flex-shrink는 1로 기본값이 각각 지정됩니다.flex: N이 flex N 0 auto와 동등했습니다. 이제는 flex: N 1 0과 동등하도록 만들어 CSS 표준을 따릅니다. 예전 시맨틱을 보전하려면 USS 파일의 모든 flex: N 지시문을 flex: N 0 auto로 교체해야 합니다.물리 행동이 변경되었으며, 일부 프로젝트가 신규 버전과 다르게 동작할 수 있습니다. 다음이 대표적인 예입니다.
Unity 2018.3에는 일부 파티클 버그 수정이 포함되어 있으며, 이는 이전 버전에서 생성된 프로젝트에 영향을 줄 수 있습니다.
2018.3 이전에 Unity 에디터는 모노 C# 컴파일러(mcs)를 사용하여 프로젝트의 C# 파일을 컴파일했습니다. 2018.3 이상에서는 Roslyn C# 컴파일러(csc)가 새로운 스크립팅 런타임(.NET 4.x Equivalent)을 타겟팅하는 프로젝트에 사용됩니다. Roslyn으로 전환하면 다음과 같은 여러 동작을 목격할 수 있습니다.
csc.rsp여야 합니다. PlatformDependentCompilation을 참조하십시오.UnityScript(.js) 및 Boo(.boo) 스크립트 파일은 이제 에디터에서 컴파일할 수 없습니다.
자세한 내용은 2017년 8월 블로그 포스트에서 확인할 수 있으며 unityscript2csharp 툴을 사용하여 UnityScript를 C#으로 전환할 수 있습니다.
애니메이션 창에서 루트 모션 애니메이션을 작성할 때 발생하는 일부 불일치 문제를 수정하기 위해 애니메이터 루트 모션 재생이 약간 변경되었습니다.
| 사례 | 생성되는 루트 모션 | Animator.applyRootMotion | 2018.2 | 2018.3 & 2018.4 (LTS) |
|---|---|---|---|---|
| A | 지원 | 지원 | 루트 모션을 루트 트랜스폼에 점증적으로 적용합니다. | 2018.2와 동일함 |
| B | 지원 안 함 | 지원 안 함 | 애니메이션 클립에서 작성된 대로 포지션, 회전 및 스케일 커브를 적용합니다. | 2018.2와 동일함 |
| C* | 지원 | 지원 안 함 | 루트 트랜스폼 움직임 없음 | 애니메이션 클립에서 작성된 대로 포지션, 회전 및 스케일을 적용합니다. |
| D* | 지원 안 함 | 지원 | 루트 트랜스폼 움직임 없음 | 루트 모션을 루트에 점증적으로 적용합니다. |
C 및 D 사례의 경우 2018.3과 동일한 결과를 얻으려면 OnAnimatorMove를 구현하십시오. 그런 다음 루트 모션을 적용하고 싶지 않으면 Animator.deltaPosition 및 Animator.deltaRotation을 폐기하십시오.
프로젝트가 applyRootMotion을 사용하여 루트 트랜스폼의 포지션, 회전 및 스케일 애니메이션을 “뮤트”한 후 Root Transform 프로퍼티를 수동으로 오버라이드해야 합니다.
이제 UIElements.ContextualMenu 메뉴 액션 콜백이 EventBase 파라미터 대신 ContextualMenu.MenuAction 파라미터를 갖습니다.
ContextualMenu.InsertSeparator는 추가 string 파라미터를 갖습니다.
이 기능은 Unity 5.1에서 지원이 중단되었고 이제는 제거되었습니다. Unity 2018.2에서는 이 기능을 프로젝트에 사용할 수 없습니다.
Unity의 네트워킹에 관한 자세한 내용은 멀티플레이어 및 네트워킹 섹션을 참조하십시오.
실제 투명도가 있는 경우 Photoshop은 픽셀 컬러를 미세 조정하여 매트(백그라운드) 컬러와 혼합합니다. 알파 채널을 올바르게 준비하는 프로세스는 알파 채널 준비 방법 문서에 자세히 나와 있습니다.
이 문서에서 확장은 무시할 수 있습니다. 이 노트의 핵심은 투명도가 아니라 별도의 알파 채널/마스크가 포함된 ‘불투명’ 이미지가 있어야 한다는 점입니다. Unity는 컬러를 미세 조정하여 매트를 ’제거’했지만, 이는 2018.2에서 중지되었습니다. 투명도가 포함된 PSD가 있는 경우 모서리에 흰색이 보일 수 있습니다. 이 문제를 해결하려면 위의 수동 링크를 참조하여 투명도 대신 실제 알파 채널을 만드십시오.
예전에는 게임 오브젝트가 비활성화되거나 삭제되면 해당 자식 MonoBehaviour에서 실행 중인 코루틴이 모두 중지되었습니다. 하지만 특정한 경우 호출된 메서드에서 시작된 코루틴(예: OnBecameInvisible())은 시작될 수 있었고, 이로 인해 컴포넌트 순서별 동작에 크래시가 발생했습니다.
Unity 2018.1에서는 게임 오브젝트가 비활성화되거나 삭제될 때 반환된 코루틴은 더 이상 시작되지 않습니다.
이전에 BuildPipeline API(예: BuildPipeline.BuildPlayer, BuildPipeline.BuildAssetBundles)는 문자열을 반환했습니다. 빌드가 성공하면 비어 있었고, 빌드가 실패하면 오류 메시지가 포함되어 있었습니다.
2018.1에서는 문자열이 새로운 BuildReport 오브젝트로 교체되었습니다. 이 오브젝트에는 빌드 프로세스에 관해 더욱 풍부한 정보가 들어 있습니다.
빌드가 성공했는지 검사하려면 보고 오브젝트의 summary 프로퍼티를 검색해서 가져온 후 해당 result 프로퍼티를 확인하십시오. 빌드가 성공한 경우 BuildResult.Succeeded입니다. 다음 예를 참조하십시오.
var report = BuildPipeline.BuildPlayer(...);
if (report.summary.result != BuildResult.Succeeded)
{
throw new Exception("Build failed");
}
이전에는 Unity 스탠드얼론 플레이어가 종료될 때 MonoBehaviour에 대해 OnApplicationQuit 메서드를 호출하고, 플레이어 종료를 취소하려면 Application.CancelQuit를 호출했습니다.
이제 두 개의 새로운 이벤트, Application.wantsToQuit와 Application.quitting이 도입되었습니다. Unity 스탠드얼론 플레이어가 종료될 때 이 이벤트를 수신하여 알림을 받을 수 있습니다. Application.wantsToQuit는 플레이어가 종료하려는 경우에 호출되며, wantsToQuit의 리스너는 true 또는 false를 반환해야 합니다. 플레이어 종료를 계속하려는 경우 true를 반환하고 종료를 취소하려는 경우 false를 반환합니다. Application.quitting 이벤트는 플레이어 종료가 확실하고 취소할 수 없는 경우에 호출됩니다.
Application.CancelQuit는 지원이 중단되었습니다. 대신에 Application.wantsToQuit를 사용하십시오.
using UnityEngine;
public class PlayerQuitExample
{
static bool WantsToQuit()
{
// Do you want the editor to quit?
return true;
}
static void Quit()
{
Debug.Log("Quitting the Player");
}
[RuntimeInitializeOnLoadMethod]
static void RunOnStart()
{
Application.wantsToQuit += WantsToQuit;
Application.quit += Quit;
}
}
이 변경 사항은 WSAPlayerX86, WSAPlayerX64 및 WSAPlayerARM 런타임 플랫폼에 영향을 미칩니다.
현재 대체 메서드는 제공되지 않습니다.
쿼리를 통해 지원이 중단된 상태와 더 많은 상태를 포함하도록 새로운 TouchScreenKeyboard.status가 제공됩니다.
MonoDevelop 5.9.6은 macOS에서 Visual Studio for Mac으로 교체되었습니다. 이제는 macOS 설치 프로그램에서 번들 C# 스크립트 에디터로 사용됩니다. 현재 Visual Studio 2017 Community는 Windows에 Unity와 함께 설치되는 유일한 C# 스크립트 에디터입니다.
Unity 실행 파일 옆의 기본 위치에 설치되면 Unity는 MonoDevelop를 환경 설정에서 “MonoDevelop(빌트인)” 외부 스크립트 에디터로 인식하지 않습니다. C# 코드 에디터가 설치되지 않고 환경 설정에서 선택되지 않으면 Unity는 시스템 기본 애플리케이션을 사용하여 C#(.cs) 스크립트를 엽니다.
BuildPipeline 콜백 인터페이스인 IPreprocessBuild, IPostprocessBuild, IProcessScene이 변경되어서 이제 BuildReport 오브젝트에 전달해야 합니다. 이는 이전의 빌드 경로/타겟 플랫폼용 파라미터를 대체합니다. 이 인터페이스를 구현하려면 코드를 변경해야 합니다.
빌드 경로와 타겟 플랫폼은 모두 BuildReport 오브젝트를 통해 액세스할 수 있습니다. 이제 빌드 경로는 report.summary.outputPath이고 타겟 플랫폼은 report.summary.platform입니다.
이전에는 플러그인 폴더의 에셋(예: 확장자가 .bundle, .plugin 또는 .folder인 디렉토리)은 특수 임포터를 사용하여 임포트했습니다. 텍스처는 텍스처 임포터를 통해 임포트되고, 오디오 클립은 오디오 임포터를 통해 임포트되는 식이었습니다. 이제 이 모든 에셋은 기본 임포터를 통해 임포트됩니다. 즉, 해당 에셋에는 특수 타입(텍스처, 오디오 클립 등)이 없기 때문에 예전처럼 해당 에셋을 참조할 수 없습니다. 플러그인 폴더는 봉인된 패키지이므로 내부의 에셋을 외부에서 액세스하면 안 됩니다. 단, 플러그인 액세스 방식을 통하는 경우는 예외입니다.
해당 에셋을 계속 사용하려면 플러그인 폴더 밖으로 옮겨야 합니다.
피벗 오프셋을 메시에 적용할 때 사용되는 수학 공식이 잘못되었으며, 빌보드 파티클에 대해 동작하는 방식과 일치하지 않았습니다. 올바른 스케일을 달성하려면 피벗 오프셋에 파티클 크기를 곱해야 합니다. 따라서 피벗 오프셋 1은 파티클의 전체 너비와 같습니다.
메시의 경우 크기를 두 번 곱했습니다. 즉, 피벗 양이 파티클 크기의 제곱에 비례했고, 이로 인해 다양한 크기의 파티클이 포함된 시스템에서 일관성 있는 결과를 얻을 수 없었습니다.
같은 크기의 파티클을 사용하는 시스템에서는 수식을 리버스 엔지니어링하여 조정할 피벗 오프셋 값을 결정함으로써 이러한 동작 변화를 보정할 수 있습니다.
예전 수식: offset = size * size * pivot
새로운 수식: offset = size * size * pivot
따라서 모든 파티클은 동일한 크기를 가집니다.
newOffset = pivot / size
파티클 간 크기가 다른 시스템에서는 문제가 되는 시스템을 육안으로 다시 평가해야 합니다.
2018.1부터 전역 조명(GI)이 Unity의 GPU 인스턴싱 렌더링에서 지원됩니다. 각 GPU 인스턴스는 다른 라이트 프로브 또는 하나의 라이트맵(아틀라스의 다른 영역) 또는 하나의 Light Probe Proxy Volume 컴포넌트(모든 인스턴스가 포함된 공간 볼륨을 위해 베이크됨)에서 비추는 GI를 지원할 수 있습니다. 스탠다드 셰이더와 표면 셰이더에는 이러한 변경 사항이 자동으로 함께 제공되지만, 이러한 기능을 활성화하려면 커스텀 셰이더 코드를 업데이트해야 합니다.
UnityEditor.IMGUI.Controls 네임스페이스의 복잡한 핸들(예: BoxBoundsHandle, CapsuleBoundsHandle, SphereBoundsHandle, ArcHandle, JointAngularLimitHandle)에는 컨트롤 포인트의 형상을 변경하는 데 할당할 수 있는 델리게이트가 있습니다. 이전에는 이러한 델리게이트에 null 값을 할당하면 기본 동작으로 폴백되었습니다. 지금은 null 값을 할당해도 아무런 동작이 발생하지 않으며, 이로 인해 특정 컨트롤 핸들을 쉽게 비활성화할 수 있습니다. 이제 컨트롤 핸들을 기본 동작으로 초기화해야 하는 경우 각 클래스에는 기본 메서드용 공용 API 포인트가 포함됩니다.
‘안전하지 않은’ C# 코드를 컴파일하려면 미리 정의된 어셈블리(예: Assembly-CSharp.dll)의 경우 플레이어 설정에서, 어셈블리 정의 파일 어셈블리의 경우 인스펙터에서 Allow ‘unsafe’ code 옵션을 활성화해야 합니다. 이 옵션을 활성화하면 Unity는 스크립트를 컴파일할 때 ‘안전하지 않은’ 옵션을 C# 컴파일러에 전달합니다.
2017.2 및 2017.3에서 Unity 패키지 관리자는 UnityPackageManager 디렉토리를 도입했습니다. 이 디렉토리는 manifest.json 파일을 저장하는 데 사용되었습니다. 패키지 콘텐츠는 Packages 로 시작하는 가상 상대 경로를 사용하여 스크립트에서 액세스할 수 있습니다.
2018.1에서는 패키징된 에셋의 가상 상대 경로와의 일관성을 위해 UnityPackageManager 디렉토리의 이름이 Packages 로 변경되었습니다. manifest.json 파일은 새 디렉토리로 자동으로 이동되어야 합니다.
그로 인한 결과는 다음과 같습니다.
프로젝트가 Perforce, Git 등의 버전 관리 시스템(VCS)을 사용하는 경우 UnityPackageManager 디렉토리 대신에 Packages 디렉토리를 추적하도록 해당 설정을 업데이트해야 합니다.
프로젝트가 Packages 디렉토리를 사용하도록 만드는 방식으로 Nuget(또는 기타 외부 패키지 관리자)을 사용하는 경우 다른 디렉토리를 사용하도록 해당 설정을 변경해야 합니다. 이렇게 하면 패키지가 Unity 패키지 관리자에서 선택되어 컴파일 오류, 임포트 오류 등 디버그하기 어려운 문제를 일으키는 상황을 피할 수 있습니다.
새로운 디렉토리로 마이그레이션한 후 UnityPackageManager 디렉토리를 안전하게 삭제할 수 있습니다.