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) redirects to SceneManager.LoadScene[Async](path, false) and Application.LoadLevelAdditive[Async](path) redirects to 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.
El nuevo soporte de de curvas de rotación de Euler de importación, y el soporte de todos los ordenes de rotación de Euler diferentes necesitaron una nueva versión de las funciones de matemáticas QuaternionToEuler y EulerToQuaternion, ambas en las versiones tradicionales y SIMD. Estas nuevas variaciones no se han visto disponibles en el API todavía, y solamente se utilizan internamente por ahora.
Esto debería tener muy poco impacto, pero hay diferencias minutas (menor a 0.01 grados) en los resultados entre la versión previa y la nueva, y solamente cuando se está cerca de las condiciones de gimbal lock. Las pruebas han mostrado que la nueva versión en su mayoría de tiempo es bastante precisa, y el error promedio es menor que al menos un factor de 10.
Las flags JointDriveMode ahora son obsoletas, y por lo tanto han sido quitadas. Sin embargo, en versiones previas de Unity fueron utilizadas incorrectamente para ignorar las configuraciones de stiffness (rigidez) y damping (amortiguación) del Joint Drive del Configurable Joint (articulación configurable). Cuando actualice un proyecto a Unity 5.3 que utiliza Configurable Joints, los usuarios deberían tener en cuenta que estos ajustes podrían estar teniendo un efecto cuando previamente no no lo tenían - porque eran erróneamente ignorados basado en las viejas flags de JointDriveMode.
A partir de 5.3, las Animaciones Legacy, tanto existentes como nuevas, no animará propiedades de Light (luz). Cambios a la estructura de datos subyacente de las lights (luces) han hecho que sean incompatibles con Legacy. Para animar adecuadamente Lights (luces), por favor utilice el componente Animator.=======
La flag sucia de la escena ahora está respetada cuando se guarde escenas. Las extensiones del Editor que no configuren correctamente la flag sucia, podría fallar al momento de guardar datos correctamente. Utilice Undo.RecordObject para grabar que un objeto está a punto de cambiar y actualice la flag sucia de la escena adecuadamente, o EditorSceneManager.MarkSceneDirty para marcar vigorosamente la escena completa como sucia.
La variable shader _CameraDepthTexture ha sido arreglada para que constantemente se refiera a la textura principal de profundidad en la cámara, y no como asía previamente a la última depth texture renderizada por cualquier cámara. Si usted está renderizando una cámara secundaria en un script para e.g obtener la mitad de un depth buffer de resolución y usted necesita enlazarse a su depth texture, ahora debe utilizar la variable _LastCameraDepthTexture que tiene la semántica de referirse a la depth texture de cualquier cámara que haya renderizado de última.
El diseño de los datos de los ComputeBuffers en shaders OpenGL automáticamente convertidos han cambiado para que coincidan con el diseño de los ComputeBuffers de DirectX. Si usted utiliza ComputeBuffers en OpenGL, quite cualquier código que ajuste los datos para que coincidan con las reglas previas de diseño específicas a OpenGL. Por favor mirar Compute Shaders para más información.