Los Lightmap Snapshot fuero re-nombrados a Lighting Data asset. El formato interno de los datos de la iluminación fue cambiado después de la actualización a Enlighten 3. Los Snapshots de versiones previas a Unity ya no son soportados y deberían ser re-baked.
Esto también afecta los AssetBundles de la escena streamed con GI (iluminación global) en tiempo real. Los datos del Lightmap no serán cargados y por lo tanto tales bundles deberían ser también re-construidos.
Los light probes y la iluminación ambiental ahora son consistentes en gamma y linear color space. Algunas diferencias en la iluminación ambiente comparado a Unity 5.2 son de esperarse. El Output coincide con la intensidad de Unity 4.x de manera prudente ahora pero ya que 4.x y nuestro código de proyección de luz genera coeficientes L2 y Enlighten solamente da como salida (output) L1, el resultado final de los light probes pueden parecer diferente. Soporte L2 para light probes aparecerá en una versión futura. Las luces direccionales no importantes deberían ahora coincidir con 4.x. Los Light probes siempres son pasados a los shaders en linear color space y la conversión final gamma sucede en la GPU. Si usted está utilizando las funciones ShadeSHxxx de Unity para evaluar los armónicos esféricos en el shader, usted no debería tener que cambiar sus shaders. En los shaders UNITY_STANDARD_SIMPLE la evaluación de los armónicos esféricos no se divide entre el pixel y vertex shaders, por lo que se limita las conversiones lineales a gamma para que solo sucedan una vez y solamente en el vertex shader. En GPUs más avanzadas, los cálculos se dividen entre vertex y fragment shader.
El tamaño de la partícula en el Modulo de Colisión ha sido remplazado por un nuevo parámetro: Radius Scale. Este nuevo parámetro funciona como un multiplicador en el tamaño actual de la partícula. Si usted estuviera utilizando el valor antiguo para hacer cualquier cosa en vez de aproximar los tamaños de la partículas, entonces usted necesitará re-configurar los limites de su colisión utilizando el nuevo parámetro.
La característica de edición multi escena introduce el nuevo API a través de EditorSceneManager y SceneManager. Estos significa que muchos de los API’s de EditorApplication y Application se han vuelto obsoletos.
Todo lo anterior de arriba tiene APIs equivalentes en EditorSceneManager
Internamente esto va a devolver el nombre de la escena activa en el Scene Manager, pero para obtener todas las escenas actuales utilice los APIs del EditorSceneManager.
Cada escena ahora tiene su propia dirty flag. Obtenga las escenas a través del EditorSceneManager y revise su estado. La configuración de escenas dirty (sucias) también se hace a través del EditorSceneManager. Los APIs obsoletos todos operan en la escena activa solamente.
Application.LoadLevel[Async](path) re-direcciona a SceneManager.LoadScene[Async](path, false) y Application.LoadLevelAdditive[Async](path) re-direcciona a SceneManager.LoadScene[Async](path, true)
Esto respectivamente obtiene el Build Setting Index (Indice del ajuste de la construcción) de la escena activa y el nombre de la escena activa. Usted debería utilizar el SceneManager para obtener los indices y nombres de todas las escenas cargadas.
Tenga en cuenta que también que EditorApplication.OpenSceneAdditive ya no se puede llamar durante la reproducción (play) en el Editor. Esto también significa que no puede ser llamada desde un callback [PostprocessScene]. Si EditorApplication.OpenSceneAdditive es llamado durante la reproducción igualmente, entonces el modo de reproducción será detenido.
Los assets de shaders pre-compilados ya no son soportados - esto significa que usted ya no puede hacer click en “show compiled code” y copiar el desembalaje resultante al nuevo asset shader. Los assets shader viejos que están pre-compilados serán marcados como no soportados.
El “show compiled code” en el inspector del shader todavía va a funcionar y va a mostrar el desmontaje del shader en cada plataforma.
Del mismo modo usted todavía puede ver el código generado para el surface shader, modificarlo, y copiarlo a un nuevo asset shader - ya que es solamente la fuente HLSL que usted está modificando.
Esto va a afectar los AssetBundles construidos en versiones previas de Unity - estos tienen assets shader compilados dentro de ellos por definición. Cualquier shader en tales bundles van a necesitar estar re-construidos.
Para información más detallada usted puede ver este blog post de Unity acerca de las características que se volverán obsoletas.
Como una nueva característica, el Editor OS X y Standalone ahora soportan el nuevo backend de GL, el cual habilita el uso de características de OpenGL 3.x y 4.x tal como tessellation (teselación) y shaders de geometría. Sin embargo, ya que Apple restringe la versión OpenGl en desktop OS X a 4.1 como mucho, no va a soportar todas las características de Directx 11 (tal como Unordered Access Views o Compute Shaders). Esto significa que todos los shaders que están configurados para tener un nivel shader de 5.0 (con #pragma en 50) va a fallar en ser cargado en OS X.
Por lo tanto un nuevo nivel objetivo shader es introducido: #pragma target gl4.1. Este nivel objetivo requiere al menos OpenGL 4.1 o un nivel shader Directx 11.0 de 5 en desktop, o OpenGL ES 3.1 + Android Extension Pack en móviles.
El formato contenedor del AssetBundle fue cambiado con el fin de soportar una nueva compresión LZ4 y tener una base para mejoras futuras. Los Bundles creados en versiones previas (2.x, 3.x) son obsoletas y no soportadas. Los Bundles creados en Unity 4.x, 5.0–5.2 están soportados y pueden ser cargados. Pero, si ya estuviera en caché en el dispositivo del usuario utilizando el método WWW.LoadFromCacheOrDownload, esto serían re-descargados. También tenga en cuenta que los datos en dichos bundles podrían estar sujetos a cambio (ver e.g la sección de Global Illumination).
GetComponentsInChildren ha cambiado un poco de comportamiento en el caso dónde usted lo invoque en un gameobject que tiene un padre que está inactivo. Previamente, usted siempre obtendría un arreglo vacío como resultado. Debido a que esto es lo que usted nunca quiere, y debido a que eso significaría que GetComponentsOnChildren no funcionaría en prefabs, esto ha sido cambiado para ignorar cualquier estado activo del gameobject padre objeto. También, la versión singular GetComponentInChildren() ahora tiene un argumento opcional includeInactive.
Utilizar un nuevo shader UI default en objetos UI no nuevos ya no se soporta por el default. Previamente había una revisión ‘if’ para determinar si sí o no el clipRect debería ser utilizado pero por razones de rendimiento esta revisión fue quitada. Para continuar utilizar un nuevo UI shader en objetos UI no nuevos, usted necesitará especificar un clipRect valido usted mismo.
Las point lights que están seleccionadas para emitir sombras ahora tienen un deslizador bias funcionando, para permitir el ajuste y el balanceo de artifacts (problemas) de sombras (under shadowing vs shadow acne). Esto significa que cualquier point lights existente que podrían tener un Bias configurado antes que no estuviera haciendo nada, ahora comenzará a tener un efecto, y esto va a cambiar el comportamiento de emisión de sombras.
Los Spot Lights que emiten sombras ahora tienen un nuevo deslizador que le permite a usted seleccionar la distancia near clip. Esta es la distancia a la luz que si un objeto está debajo de ella no va a emitir sombras. Unos valores bajos incluyen objetos cercanos, al precio de una precisión altamente reducida para las sombras. En versiones previas de Unity esto era calculado en 4% del rango total de la luz, la cual puede ser un poco mayor para luces grandes. Ahora el predeterminado es a 0.2, que debería funcionar en la mayoría de casos.
The new support of importer Euler rotation curves, and the support of all the different Euler rotation orders necessitated a rewrite of the QuaternionToEuler and EulerToQuaternion mathematics functions, both in traditional and SIMD versions. Those new variations have not been made available in the API yet, and are only used internally for now.
This should have very little impact, but there are minute differences (<0.01 degrees) in the results between the previous version and the new one, and only when very close to gimbal lock conditions. Tests run have shown the new version to be more accurate most of the time, and the average error to be smaller by at least a factor of 10.
JointDriveMode flags are now obsolete, and thus have been removed. However, in earlier versions of Unity they were incorrectly being used to ignore the Configurable Joint’s Joint Drive stiffness and damping settings. When upgrading a project to Unity 5.3 which uses Configurable Joints, users should be aware that these settings may now be having an effect when previously they did not - because they were wrongly being ignored based on the old JointDriveMode flags.
As of 5.3, Legacy Animations, both existing and new, will not animate Light properties. Changes to the underlying data structure of the Lights have made them incompatible with Legacy. To properly animate Lights, please use the Animator Component.
The scene’s dirty flag is now respected when saving scenes. Editor extensions that do not correctly set the dirty flag may fail to save data correctly. Use Undo.RecordObject to record that an object is about to change and to update the scene’s dirty flag accordingly, or EditorSceneManager.MarkSceneDirty to forcibly mark the entire scene as dirty.
The _CameraDepthTexture shader variable has been fixed to consistently refer to the primary depth texture on the camera, and not as it did previously to the last depth texture rendered by any camera. If you are rendering a secondary camera in a script to e.g. obtain a half-resolution depth buffer and you need to bind its depth texture, you should now use the _LastCameraDepthTexture variable which has the semantics of referring to the depth texture of whichever camera rendered last.