이 페이지에는 이전 Unity 버전에서 2018.1로 업그레이드할 경우 기존 프로젝트에 영향을 미칠 수 있는 변경 사항이 나열됩니다.
예전에는 게임 오브젝트가 비활성화되거나 삭제되면 해당 자식 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 디렉토리를 안전하게 삭제할 수 있습니다.
2018.1의 새로운 기능과 업그레이드 노트에 관한 자세한 내용은 2018.1 릴리스 노트를 참조하십시오.