이 페이지에서는 이전 Unity 버전에서 2017.2로 업그레이드할 때 기존 프로젝트에 영향을 미칠 수 있는 변경 사항을 설명합니다.
예:
데이터 포맷이 변경되어 다시 베이크해야 할 수 있음
기존 함수, 파라미터, 컴포넌트 값의 의미 또는 동작이 변경됨
일부 함수와 기능이 지원 중단됨(대체 기능 제안)
** 이제 에디터에서 MonoBehaviour를 게임 오브젝트에 추가하면 MonoBehaviour.OnValidate가 호출됨**
게임 오브젝트가 중복되거나 인스펙터에서 값이 변경되면 씬이 로드될 때 MonoBehaviour.OnValidate가 호출됩니다. 이제는 에디터에서 MonoBehaviour를 게임 오브젝트에 추가하는 경우에도 호출됩니다.
스크립팅: 이제 InitializeOnLoad 콜백이 역직렬화 후에 호출됨
InitializeOnLoad의 콜백 타이밍이 변경되었습니다. 전에는 Unity API를 호출할 때 기존의 직렬화된 오브젝트의 오브젝트 상태가 잘못될 수 있는 시점에 InitializeOnLoad가 호출되었습니다. 이제는 직렬화 후에, 그리고 모든 오브젝트가 생성된 후에 InitializeOnLoad가 호출됩니다. 오브젝트를 생성하는 과정의 일부로 기본 생성자를 호출해야 합니다. 과거에는 InitializeOnLoad가 일부 오브젝트 생성자보다 먼저 호출되었지만, 이제는 이 변경 사항으로 인해 오브젝트 생성자가 InitializeOnLoad 정적 생성자보다 먼저 호출됩니다.
예:
[System.Serializable]
public class SomeClass
{
public SomeClass()
{
Debug.Log("SomeClass constructor");
}
}
public class SomeMonoBehaviour : MonoBehaviour
{
public SomeClass SomeClass;
}
[InitializeOnLoad]
public class SomeStaticClass
{
static SomeStaticClass()
{
Debug.Log("SomeStaticClass static constructor");
}
}
이 예제의 결과는 이전에는 다음과 같았습니다.
SomeStaticClass static constructor (InitializeOnLoad)
SomeClass constructor (오브젝트 생성자)
변경 사항이 적용된 후에는 다음과 같아집니다.
SomeClass constructor (오브젝트 생성자)
SomeStaticClass static constructor (InitializeOnLoad)
BC5 포맷을 지원하는 새 노멀 맵 타입
지금까지 Unity 에디터는 RGB 노멀 맵 또는 압축 포맷이 다른 배열이 바뀐 AG 노멀 맵(x가 알파 채널에 있고 y가 녹색 채널에 있는 노멀 맵) 중 하나를 지원했습니다. 이제는 RG 노멀 맵(x가 빨간색 채널에 있고 y가 녹색 채널에 있는 노멀 맵)도 지원합니다. UnpackNormal 셰이더 함수는 셰이더 배리언트를 추가하지 않고 RGB, AG, RG 노멀 맵을 사용할 수 있도록 업그레이드되었습니다. 이렇게 할 수 있기 위해, UnpackNormal 함수는 노멀 맵의 미사용 채널이 1로 설정되어 있어야 올바르게 작동합니다. 즉, 배열이 바뀐 AG 노멀 맵은 (1, y, 1, x)로 인코딩되어야 하고, RG는 (x, y, 0, 1)로 인코딩되어야 합니다. Unity 노멀 맵 인코더가 이렇게 적용합니다.
Unity를 따로 수정하지 않고 사용하고 있다면 수행해야 할 업그레이드 작업이 없었습니다. 하지만 자체 노멀 맵 셰이더 또는 자체 인코딩을 사용하고 있다면 배열이 바뀐 AG 노멀 맵을 (1, y, 1, x)로 인코딩해야 할지도 모릅니다. 노멀 맵을 언패킹하기 전에 배열이 바뀐 AG에 노멀 맵을 혼합했다면 UnpackNormal 대신 UnpackNormalDXT5nm을 사용해야 할 수 있습니다.
에디터를 실행할 때 항상 미리 컴파일된 관리되는 어셈블리(.dll)와 어셈블리 정의 파일 어셈블리 로드
다른 스크립트에 컴파일 오류가 있어도 에디터를 실행할 때 미리 컴파일된 관리되는 어셈블리(.dll)와 어셈블리 정의 파일 어셈블리를 로드합니다. 에디터를 실행할 때 프로젝트의 다른 스크립트 컴파일 오류에 관계없이 항상 로드되어야 하는 에디터 확장 프로그램 어셈블리에 유용합니다.
HDR 이미션
미리 계산된 실시간 GI나 베이크된 GI를 사용하는 경우 이제 범위 상한이 더 이상 제한되지 않기 때문에, 이전 Unity 버전에서 설정한 강렬한 발광 머티리얼이 더 강렬하게 보일 수 있습니다. 과거에 사용했던 RGBM 인코딩의 유효 범위는 감마 공간의 경우 97이었고, 선형 색 공간의 경우 8이었습니다. HDR 컬러 피커의 최대 범위는 99였으므로 일부 머티리얼은 전보다 더 강렬하게 보일 수 있습니다. 업그레이드 후에 이미션 컬러는 트루 HDR 16비트 부동 소수점 값으로 GI 시스템에 전달됩니다. 범위는 이제 64K입니다. 실시간 GI 시스템은 이처럼 강렬한 값을 나타낼 수 있는 rgb9e5 공유 지수 포맷을 내부적으로 사용하지만, 베이크된 라이트맵은 RGBM 인코딩에 의해 제한됩니다. 베이크된 라이트맵용 HDR은 이후 릴리스에 추가될 예정입니다.
VR을 XR로 이름 변경
UnityEngine.VR.* 네임스페이스 이름이 UnityEngine.XR.*로 변경되었습니다. 이름에 VR이 포함된 모든 타입도 XR 버전으로 이름이 변경되었습니다. 예를 들어 UnityEngine.VR.VRSettings는 이제 UnityEngine.XR.XRSettings가 되었습니다.
API 업데이터는 기존 스크립트와 어셈블리를 자동으로 새 타입 이름과 네임스페이스로 업데이트하도록 설정되어 있습니다. API 업데이터를 사용하고 싶지 않다면 네임스페이스와 타입을 수동으로 업데이트할 수도 있습니다.
네임스페이스 변경:
UnityEngine.VR 타입 변경:
모든 VR.* 프로파일러 항목도 XR.*로 변경되었습니다.
UnityEngine.dll은 이제 각 UnityEngine 모듈마다 별도의 dll로 분할됨
(모든 공용 스크립팅 API가 포함된) UnityEngine.dll은 이제 엔진의 여러 서브시스템에 해당하는 코드 모듈로 분리되었습니다. 이로 인해 Unity 코드 베이스가 더 깔끔한 내부 종속성으로 더 잘 정리되었고, 내부 작업에 효과적이게 되었으며, 코드 베이스를 스트리핑하기가 더 쉬워졌습니다. 분리된 모듈의 예를 들자면, 이제 UnityEngine.PhysicsModule.dll에 있는 UnityEngine.Collider와 UnityEngine.TextRendering.dll에 있는 UnityEngine.Font 등이 있습니다.
이 변경 사항은 일반적으로 기존 프로젝트에 영향을 미치지 않고, 스크립트가 올바른 어셈블리에 자동으로 컴파일됩니다. 이제 Unity 에디터는 파일을 새 위치로 재전송하여 역호환성을 보장하는 DLL을 레퍼런스하는 모든 미리 컴파일된 어셈블리에 대한 모든 UnityEngine 타입의 타입 포워더가 들어있는 UnityEngine.dll 어셈블리 파일을 포함합니다.
하지만 이 변경 사항으로 인해 기존 코드가 올바르게 실행되지 않는 경우가 하나 있습니다. 코드에서 반사를 사용하여 UnityEngine 타입을 가져오고 모든 타입이 같은 어셈블리에 있을 때 그렇습니다. 콜라이더와 폰트는 이제 서로 다른 어셈블리에 있으므로 이런 코드는 실행되지 않습니다.
System.Type colliderType = typeof(Collider);
System.Type fontType = colliderType.Assembly.GetType("Font");
타입 포워더를 다음과 같이 처리하면 “UnityEngine” 어셈블리에서 콜라이더나 폰트 타입을 계속 가져올 수 있습니다.
System.Type.GetType("UnityEngine.Collider, UnityEngine")
Unity 에디터는 여전히 Unity 에디터의 Managed/UnityEngine.dll 폴더에 있는 모든 UnityEngine API이 포함된 완전 일체형 UnityEngine.dll을 번들로 제공합니다. 따라서 UnityEngine.dll을 레퍼런스하는 기존 Visual Studio/MonoDevelop 솔루션은 새 모듈식 어셈블리를 레퍼런스하도록 업데이트하지 않더라도 아무런 문제없이 계속 빌드되도록 보장됩니다. 내부 모듈 분할은 변경될 수 있으므로 커스텀 솔루션에서 이 어셈블리를 계속 사용하여 UnityEngine API를 레퍼런스해야 합니다.
스탠다드 셰이더의 머티리얼 평활도
스탠다드 셰이더의 GGX 버전을 사용하는 순수 평활 머티리얼은 이제 해당 머티리얼의 사실감을 높이는 스페큘러 하이라이트를 받습니다.