升级到Unity 5.3
全球照明
光照贴图快照已重命名为照明数据资产。在升级到Enlighten 3后，照明数据的内部格式已更改。来自以前版本的Unity的快照不再受支持，应重新进行重新编译。
这也影响具有实时GI的流化场景AssetBundles。将不会加载光照贴图数据，因此也应重建此类绑定。
光探测器和环境照明现在在伽马和线性色彩空间中是一致的。与Unity 5.2相比，环境照明的一些差异是可以预期的。输出匹配Unity 4.x强度现在，但从4.x和我们的光投影代码生成L2系数和Enlighten只输出L1，最终光探针的衰减可能会出现不同。L2支持光探针将出现在将来的版本中。定向非重要灯现在应该匹配4.x. 光探针总是以线性颜色空间传递到着色器，并且最终的伽玛转换发生在GPU上。如果您使用Unity的ShadeSHxxx函数来评估着色器中的球面谐波，则不必更改着色器。在UNITY_STANDARD_SIMPLE着色器中，SH评估不会在像素和顶点着色器之间分割，因此我们将线性到灰度转换限制为仅发生一次，并且只发生在顶点着色器中。在更高级的GPU上，计算在顶点和片段着色器之间分割。
Shuriken
碰撞模块中的粒子大小已被一个新参数替换：半径比例。这个新参数作为实际粒度的乘数。如果您使用旧值来执行除了近似粒子大小之外的任何操作，那么您将需要使用新参数重新配置碰撞边界。
多场景编辑
多场景编辑功能通过EditorSceneManager和SceneManager引入了新的API。这意味着许多API的EditorApplication和Application已被弃用。
EditorApplication.NewScene
EditorApplication.NewEmptyScene
EditorApplication.OpenScene
EditorApplication.OpenSceneAdditive
EditorApplication.SaveScene
EditorApplication.SaveCurrentSceneIfUserWantsTo
EditorApplication.SaveCurrentSceneIfUserWantsToForce
以上都在EditorSceneManager上有相同的API
EditorApplication.currentScene
在内部，这将返回场景管理器中的活动场景的名称，但是要获取所有当前打开的场景使用EditorSceneManager API
EditorApplication.MarkSceneDirty
EditorApplication.isSceneDirty
每个场景现在都有自己的脏标志。通过EditorSceneManager获取场景并检查它们的状态。设置场景脏也通过EditorSceneManager完成。弃用的API仅在活动场景上操作。
Application.LoadLevel
Application.LoadLevelAsync
Application.LoadLevelAdditive
Application.LoadLevelAdditiveAsync
Application.LoadLevel [Async]（path）重定向到SceneManager.LoadScene [Async]（path，false）和Application.LoadLevelAdditive [Async]（path）重定向到SceneManager.LoadScene [Async]
Application.loadedLevel
Application.loadedLevelName
这些分别获得活动场景的构建设置索引和活动场景的名称。您应该使用SceneManager来获取所有加载场景的索引和名称。
还要注意，EditorApplication.OpenSceneAdditive可以在编辑器中播放时调用nolonger。这也意味着它不能从[PostprocessScene]回调中调用。如果在播放期间调用EditorApplication.OpenSceneAdditive，则播放模式将停止。
预编译着色器资产
不再支持预编译的着色器资源 - 这意味着您不能再单击“显示已编译的代码”，并将生成的反汇编复制到新的着色器资源。预编译的旧着色器资源将被标记为不支持。
着色器检查器中的“显示编译代码”仍然可以工作，并且将显示每个平台上的着色器的反汇编。
同样，您仍然可以查看表面着色器生成的代码，修改它，并将其复制到新的着色器资源中 - 因为它只是您要修改的HLSL源。
这将影响以前版本的Unity中构建的AssetBundles - 他们已经根据定义在其中编译了着色器资源。这种捆绑中的任何着色器都需要重新构建。
有关详细信息，你可以看到这个团结的博客文章即将推出的功能弃用。
桌面上的OpenGL 4.x支持
作为一个新功能，OS X编辑器和独立版现在支持新的GL后端，可以使用OpenGL 3.x和4.x功能，如镶嵌和几何着色器。但是，由于苹果将OS X桌面上的OpenGL版本限制为最多4.1，它不支持所有DirectX 11功能（例如无序访问视图或计算着色器）。这意味着所有配置为指向着色器Level 5.0（使用#pragma target 50）的着色器将无法在OS X上加载。
因此，引入了新的着色器目标级别：#pragma target gl4.1。这个目标级别需要至少在桌面上的OpenGL 4.1或DirectX 11.0 Shader Level 5，或者移动设备上的OpenGL ES 3.1 + Android Extension Pack。
资产包
AssetBundle的容器格式已更改，以支持新的LZ4压缩，并有进一步改进的基础。在早期版本（2.x，3.x）中创建的软件包已弃用，不受支持。支持在Unity 4.x，5.0-5.2中创建的软件包，并且可以加载。但是，如果它们已经使用WWW.LoadFromCacheOrDownload方法在用户设备上缓存，则将重新下载它们。还要记住，这种捆绑中的数据可能会改变（见例如全局照明部分）。
GetComponent（s）InChildren
GetComponentsInChildren有一个稍微改变的行为，当你调用一个gameObject的父对象是非活动的。以前，你总是得到一个空数组作为结果。因为这不是你想要的，因为这意味着GetComponentsOnChildren没有在预制工作，这已被改变为忽略目标游戏对象的父母的任何活动状态。此外，单一版本GetComponentInChildren（）现在有一个可选的includeInactive参数。
UI /默认着色器
默认情况下不再支持在非新UI对象上使用默认新UI UI着色器。以前有一个“if”检查，以确定是否应该使用_clipRect，但出于性能原因，此检查被删除。要继续在非新的UI对象上使用新的UI着色器，您需要自己指定一个有效的clipRect。
点和斑点投射光
选择投射阴影的点光源现在有一个工作偏光滑块，以允许调整和平衡阴影伪影（阴影阴影痤疮下）。这意味着任何现有的点光源可能已经在之前的偏光设置之前没有做任何事情现在将开始有效果，这将改变阴影投射行为。
投射阴影的投射灯现在有一个新的滑块，允许您选择近夹子距离。这是到光的距离，在此之下任何物体都不会投射阴影。低值包括近似对象，代价是阴影的精度大大降低。在以前的Unity版本中，这是计算在光的总范围的4％，这可能是太高的大灯。现在它默认为0.2，这应该适用于大多数情况。
四元数学
新的对进口商欧拉旋转曲线的支持，以及所有不同欧拉旋转顺序的支持，需要重写QuaternionToEuler和EulerToQuaternion数学函数，无论是在传统的SIMD版本。这些新版本尚未在API中提供，目前仅供内部使用。
这应该有非常小的影响，但在以前的版本和新的结果之间有微小的差异（<0.01度），并且只有当非常接近万向节锁条件。运行的测试显示新版本在大多数时间更准确，并且平均误差减小至少10倍。
JointDriveMode标志
JointDriveMode标志现在已过时，因此已被删除。然而，在Unity的早期版本中，它们不正确地用于忽略可配置关节的关节驱动刚度和阻尼设置。当将项目升级到使用可配置关节的Unity 5.3时，用户应该意识到这些设置现在可能有效果，以前他们没有 - 因为他们错误地被忽略基于旧的JointDriveMode标志。
遗留光动画
从5.3开始，Legacy Animations（现有的和新的）都不会为Light属性设置动画。对Lights的底层数据结构的更改使它们与Legacy不兼容。要正确地为灯光设置动画，请使用Animator组件。=======
编辑器扩展
保存场景时，场景的脏标志现在受到尊重。未正确设置脏标志的编辑器扩展可能无法正确保存数据。使用Undo.RecordObject记录对象即将更改，并相应地更新场景的脏标志，或使用EditorSceneManager.MarkSceneDirty强制将整个场景标记为脏。
相机深度纹理着色器变量
该_CameraDepthTexture着色器变量已经被固定，总是把主要的深度纹理在相机上，而不是像以前一样由任何相机呈现的最后一个深度纹理。如果你是渲染脚本例如，一个副摄像头获得半分辨率深度缓冲，你需要绑定的深度纹理，你现在应该使用_LastCameraDepthTexture有指取相机上次渲染的深度纹理的语义变量。
ComputeBuffers
ComputeBuffers在自动转换的OpenGL着色器中的数据布局已更改为与DirectX ComputeBuffers的布局匹配。如果你在OpenGL中使用ComputeBuffers，删除任何调整数据的代码，以匹配以前的OpenGL特定的布局规则。请参阅计算着色器的详细信息。
原文地址：https://www.cnblogs.com/kubll/p/10798751.html