Guía de Actualización de Unity 3.5 a 4.0

Estado Activo del GameObject

Unity 4.0 cambia cómo el estado actual de los GameObjects se maneja. El estado activo del GameObject ahora es heredado por GameObjects hijos, para que cualquier GameObject que esté inactivo también cause que sus hijos sean inactivos. Nosotros creemos que el nuevo comportamiento tiene más sentido que el viejo, y siempre debió ser así. También, el nuevo sistema GUI que se aproxima depende mucho en el nuevo comportamiento 4.0, y no sería posible sin este. Des-afortunadamente, esto podría requerir algo de trabajo para arreglar los proyectos existentes para que funcionen con el nuevo comportamiento de Unity 4.0, y aquí está el cambio:

El comportamiento viejo:

• Si un GameObject está activo o no fue definido por su propiedad .active
• Esto puede ser consultado y configurado al marcar la propiedad .active
• El estado activo de un GameObject tiene ningún impacto en el estado activo de los GameObjects hijos. Si usted quiere activar o des-activar un GameObject y todos sus hijos, usted necesita llamar GameObject.SetActiveRecursively.
• Cuando utilice SetActiveRecursively en un GameObject, el estado activo previo de cualquier GameObject se perdería. Cuando usted des-activa y luego activa un GameObject y todos sus hijos utilizando SetActiveRecursively, cualquier hijo que estaba inactivo antes de la llamada SetActiveRecursively, se volvería activo, y usted tiene que manualmente mantener un seguimiento del estado activo de los hijos si usted quiere restaurarlo a la manera en que estaba.
• Los prefabs no podían contener cualquier estado, y siempre estaban activos después de la instanciación de un prefab.

El nuevo comportamiento:

• Si un GameObject está activo o no está definido por su propia propiedad .activeSelf, y todo aquellos de sus padres. El GameObject está activo si su propia propiedad .activeSelf y la de todos sus padre es true. Si cualquiera de ellos es false, el GameObject está inactivo.
• Esto se puede consultar utilizando la propiedad .activeInHierarchy.
• El estado .activeSelf de un GameObject puede cambiar al llamar GameObject.SetActive. Cuando se llame SetActive (false) en un GameObject previamente activo, esto va a des-activar el GameObject y todos sus hijos. Cuando llame SetActive (true) en un GameObject previamente inactivo, este va a activar el GameObject, si todos su padres están activos. Los hijos serán activados cuando todos sus padres estén activos (i.e., cuando todos sus padres tienen .activeSelf configurado a true).
• Esto significa que SetActiveRecursively ya no se necesita más, ya que el estado es heredado de sus padres. También significa que, cuando se desactive y se active un parte de la jerarquía al llamar SetActive, el estado activo previo de cualquier GameObject será preservado.
• Los Prefabs pueden contener un estado activo, el cual es preservado en una instaciación de prefab.

Ejemplo:

Usted tiene tres GameObjects, A, B y C, para que B y C son hijos de A.

• Desactive C al llamar C.SetActive(false).
• Ahora, A.activeInHierarchy == true, B.activeInHierarchy == true y C.activeInHierarchy == false.
• Del mismo modo, A.activeSelf == true, B.activeSelf == true y C.activeSelf == false.
• Ahora nosotros des-activamos el padre A al llamar A.SetActive(false).
• Ahora, A.activeInHierarchy == false, B.activeInHierarchy == false y C.activeInHierarchy == false.
• Del mismo modo, A.activeSelf == false, B.activeSelf == true y C.activeSelf == false.
• Ahora nosotros activamos el padre A nuevamente al llamar A.SetActive(true).
• Ahora, nosotros estamos de vuelta a A.activeInHierarchy == true, B.activeInHierarchy == true y C.activeInHierarchy == false.
• Del mismo modo, A.activeSelf == true, B.activeSelf == true y C.activeSelf == false.

El nuevo estado activo en el editor

Para visualizar estos cambios, en el editor de 4.0, cualquier GameObject que es inactivo (ya sea porque su propia .activeSelf es configurada a false, o aquel d uno de sus padres), se volverá gris en la jerarquía, y va a tener un icono en gris en el inspector. La propiedad .activeSelf del GameObject es reflejada por su casilla de verificación active, que puede ser activada/des-activada sin importar del estado del padre (pero solamente va a activar el GameObject si todos los padres están activos).

Cómo esto afecta a proyectos existentes:

• Para que usted esté atento a lugares en su código dónde esto lo podría afectar a usted, la propiedad GameObject.active y la función GameObject.SetActiveRecursively() se han vuelto obsoletas.
• Estas son, sin embargo funcionales. Leer el valor de GameObject.active es equivalente a leer GameObject.activeInHierarchy,, y configurar GameObject.active es equivalente a llamar GameObject.SetActive(). Llamar GameObject.SetActiveRecursively() es equivalente a llamar GameObject.SetActive() en el GameObjects y todos sus hijos.
• salirse de escenas de 3.5 son importadas al configurar la propiedad selfActive de cualquier GameObject en la escena a su propiedad active previa.
• Como resultado, cualquier proyecto importado de versiones previas de Unity debería funcionar como se espera (con advertencias de compilación, sin embargo), siempre y cuando no se base en tener hijos activos de GameObjects inactivos (lo cual ya no es posible en Unity 4.0).
• Si su proyecto depende en tener hijos activos de GameObjects inactivos, usted necesita cambiar su lógica a un modelo que funcione en Unity 4.0.

Cambios al pipeline de procesamiento de assets.

Durante el desarrollo de 4.0 nuestro pipeline de importación de assets ha cambiado en unas maneras significantes de manera interna con el fin de mejorar el rendimiento, uso de memoria y determinación. Para la mayoría de veces, estos cambios no tienen un impacto en el usuario con una excepción: Los Ojbectos en assets no están hechos persistentes hasta el final del pipeline de importación y cualquier versión importada previamente de un asset será remplazada completamente.

La primera parte significa que durante el post-procesamiento usted no puede obtener las referencias correctas a objetos en el asset y la segunda parte significa si usted utiliza las referencias a una versión previamente importada del asset durante el post-procesamiento, por favor almacene la modificaciones ya que estas modificaciones serán perdidas.

Ejemplo de una referencia siendo perdida ya que no son persistentes todavía

Considere este pequeño ejemplo:

public class ModelPostprocessor : AssetPostprocessor
{
    public void OnPostprocessModel(GameObject go)
    {
        PrefabUtility.CreatePrefab("Prefabs/" + go.name, go);
    }
}

En Unity 3.5 esto va a crear un prefab con todas las referencias correctas a los meshes y así ya que todos los meshes ya estarían hechos persistentes, pero debido a que este no es el caso en Unity 4.0 el mismo post procesador va a crear un prefab dónde todas las referencias a los meshes desaparecen, simplemente porque Unity 4.0 no sabe todavía cómo resolver las referencias a los objetos en el prefab del modelo original. Para copiar correctamente un modelprefab a un prefab usted debería utilizar OnPostProcessAllAssets para ir a través de todos los assets importados, encuentre el modelprefab y cree el nuevo prefab como se hace arriba.

Ejemplo de una referencia a unos assets previamente importados siento descartados

El segundo ejemplo es un poco más complejo pero en verdad es un caso de uso que nosotros hemos visto en 3.5 que se rompió en 4.0. Aquí hay un simple ScriptableObject con una referencias al mesh.

public class Referencer : ScriptableObject
{
    public Mesh myMesh; 
}

Nosotros utilizamos este ScriptableObject para crear un asset con referencias a un mesh dentro de un modelo, entonces en nuestro post procesador nosotros tomamos esa referencia y le damos un nombre diferente, el resultado final siendo que cuando nosotros hemos re-importado el modelo el nombre del mesh será lo que el post procesador determine.

public class Postprocess : AssetPostprocessor
{
    public void OnPostprocessModel(GameObject go)
    {
        Referencer myRef = (Referencer)AssetDatabase.LoadAssetAtPath("Assets/MyRef.asset", typeof(Referencer));
        myRef.myMesh.name = "AwesomeMesh";
    }
}

Esto funciono bien en Unity 3.5 pero en Unity 4.0 el modelo que ya estuvo importado será completamente remplazado, por lo que cambiar el nombre de un mesh de una importación previa no tendrá efecto. La solución aquí es encontrar el mesh por otros medios y cambiar su nombre. Lo que es más importante para tener en cuenta es que en Unity 4.0 usted debería SOLAMENTE modificar el input dado del post procesador y no debe depende en la versión previamente importada del mismo asset.

Opción de Lectura/Escritura del Mesh

Unity 4.0 agrega una opción “Read/Write Enabled” en los ajustes de importación Mesh. cuando esta opción se apaga, guarda memoria ya que Unity puede descargar una copia de datos mesh en el juego.

Sin embargo, si usted está escalando o instanciando meshes en tiempo de ejecución con una escala no-uniforme, usted puede tener que activar “Read/Write Enabled” en sus ajustes de importación. La razón es que la escala no-uniforme requiere los datos mesh en ser mantenidos en memoria. Normalmente nosotros detectamos esto en el tiempo de construcción pero cuando los meshes son escalados o instanciados en tiempo de ejecución usted necesita configurar esto manualmente. De lo contrario no podrían ser renderizado en las construcciones del juego correctamente.

Optimización de Mesh

El Importador de Modelo en Unity 4.0 se ha vuelto mejor en las optimizaciones mesh. La casilla de verificación “Mesh Optimization” en el importador del modelo en Unity 4.0 está activado por defecto. Usted puede que tenga algo de código de post-procesamiento o effectos en su proyecto que dependen en el orden del vértice de sus meshes, y estos podrían estar rotos por este cambio. En ese caso, apague “Mesh Optimization” en el importador de Mesh. Especialmente, si usted está utilizando el componente SkinnedCloth, la optimización mesh va a causar que el mappeo del peso de vértice cambie. Por lo que is usted está utilizando SkinnedCloth en un proyecto importado de 3.5, usted necesita apagar “Mesh Optimization” para los meshes afectados, o re-configurar sus pesos del vértice para que coincidan el nuevo orden de vértices.

Input Móvil

Con Unity 4.0, el input del sensor móvil tiene un mejor alineamiento entre plataformas, que significa que usted puede escribir menos código cuando maneje un input típico en plataformas móviles. Ahora el input de aceleración y de gyro va a seguir la orientación de la pantalla de la misma manera que en plataformas iOS y Android. Para tomar ventaja de este cambio usted debería re-factorizar el código de input y quitar código especifico de la plataforma y orientación de pantalla cuando se maneje el input de aceleración y gyro. Usted todavía puede obtener una vieja versión en IOS al configurar Input.compensateSensors a falso.