YAML Class ID Reference (Referencia del ID de la clase YAML)
Modificando Assets Fuentes a través del Scripting

Cache Server (Server de Cache) (Licencia de Equipo)

Unity tiene un proceso de control de activos completamente automático. Cuando el archivo original de un asset como el de un archivo ‘.psd’ o el de un archivo ‘.fbx’ es modificado, Unity detectará los cambios y automáticamente lo re-importará. La información importada del archivo es después almacenada por Unity en su propio formato interno.

Ésta característica fue diseñada para hacer que el flujo de trabajo de un usuario sea lo más eficiente y flexible posible. Sin embargo, al trabajar en un proyecto en equipo, es posible que otros usuarios estén constantemente haciendo cambios y actualizaciones a los assets, dichas modificaciones tendrán que ser importadas manualmente. También será necesario re-importar los assets cuando se haga el cambio de una versión de escritorio a una versión móvil, lo que podría tomar un tiempo considerable para proyectos de gran envergadura.

El tiempo que toma la importación de los assets, podría drásticamente verse reducido si la información importada se almacena en la Cache Server.

Cada asset a importar es almacenado en la caché en base a

  • El archivo mismo
  • La configuración de importación
  • La versión del importador de Assets
  • La plataforma actual.

Si cualquiera de los anteriores cambia, el asset es re-importado, de otro modo se descarga de la Caché del Servidor.

Cuando se habilita la caché del servidor en las preferencias, se puede incluso compartir los assets importados en distintos proyectos (es decir, el trabajo de importación puede ser hecho por una máquina y los resultados se pueden compartir con otros).

Nota que una vez que la caché del servidor es configurada, éste proceso es completamente automático, lo que significa que no se requiere trabajo adicional. Simplemente se reduce el tiempo que toma importar los proyectos sin la necesidad que se tenga que intervenir.

Como configurar la Caché del Servidor (usuario)

Configurar la Caché del Servidor no podría ser más fácil. Todo lo que se necesita es hacer clic en la opción Use Cache Server dentro de las preferencias y decirle al Unity Editor donde se encuentra la Cache Server.

Esto puede encontrarse en Unity->Preferences en el Mac o Edit->Preferences en el PC.

Si usted es anfitrión del Cache Server ( Servidor de Cache) en su maquina local, especifique localhost para la dirección del servidor. Sin embargo, debido a las limitaciones de tamaño del disco duro, es recomendado que usted aloje el Cache Server en una maquina diferente.

Como configurar la Caché del Servidor (usuario)

El Administrador necesita configurar la maquina Cache Server que será anfitriona de los assets en cache.

Usted necesita:

  • Comprar Cache Server (parte de Unity Pro) en la tienda en linea.
  • Descargue el Cache Server. Vaya a la página Collaboration y haga click en el botón para Descargar el Cache Server.
  • Descomprima el archivo, después del cual usted debería ver algo así:
  • Dependiendo de su sistema operativo, corra el scrip de comando apropiado.
  • Usted verá una ventana del terminal, indicando que el Cache Server está corriendo en el fondo.

El Cache Server necesita estar en una maquina fiable con un almacenamiento muy grande (más grande que el tamaño del proyecto en sí, ya que habrá múltiples versiones de los recursos importados almacenados. Si el disco duro se llena el Cache Server puede llevarse acabo lentamente.

Instalando el Cache Server como un servicio

Los scripts proporcionados .sh y .cmd deberían estar configurados como un servicio en el servidor. El cache server (servidor de cache) puede ser matado de manera segura y re-iniciado en cualquier momento, debido a que utiliza operaciones de archivo atómicas.

Configuración del Cache Server

si usted simplemente empieza al hacer doble click en el script, éste será ejecutado con el Cacher Server antiguo (legacy) en el puerto 8125 y el nuevo Cache Server en el puerto 8126. También va a crear los directorios “cache” y “cache5.0” alado del script, y va a mantener la información ahí. Los directorios en cache están permitidos crecer hasta 50 GB por defecto. Usted puede configurar el tamaño y la ubicación de la información utilizando las opciones de la linea de comando, así:

./RunOSX.command --path ~/mycachePath --size 2000000000

o

./RunOSX.command --path ~/mycachePath --port 8199 -nolegacy

Usted puede configurar el cache server al utilizar las siguientes opciones de la linea de comandos:

--port le permite especificar el puerto del servidor, solo aplica al nuevo cache server, el valor por defecto es 8126.

--path le permite a usted especificar la ruta de la ubicación en cache, solo aplica al nuevo cache server, el valor por defecto es ./cache5.0.

--legacypath le permite a usted especificar la ruta de la ubicación del cache, solo aplica al cache server antiguo (legacy), el valor por defecto es ./cache.

--size le permite a usted especificar el tamaño en cache máximo en bytes para ambos los cache servers. Los archivos que no han sido utilizados recientemente serán automáticamente descartados cuando el tamaño de cache sea excedido.

--nolegacy si se especifica, no va a comenzar el cache server anterior (legacy), de lo contrario el el cache server antiguo comienza en el puerto 8125.

Requerimientos para la maquina alojando el Cache Server

Para un mejor rendimiento debe haber suficiente RAM para mantener una carpeta de proyecto importada entera. En adición, es mejor tener una maquina con un disco duro rápido, y una conexión rápida Ethernet. El disco duro debería también tener suficiente espacio libre. En la otra mano, el Cache Server tiene un uso muy bajo de CPU.

Una de las distinciones principales entre el Cache Server y el control de versiones es que la información en cache puede ser siempre re-construida localmente. Es simplemente una herramienta para mejorar el rendimiento. Por esta razón, no tiene sentido utilizar un Cache Server en Internet. Si usted tiene un equipo distribuido, usted debería colocar un cache server diferente en cada ubicación.

El cache server debería correr en una maquina Linux o Mac OS X. El sistema de archivos de Windows en particular no es bien optimizado para cómo el Asset Cache Server almacena información y problemas con el bloqueo de archivos en Windows pueden causar problemas que no ocurren en Linux o Mac OS X.

Cache Server FAQ (Preguntas Frecuentes)

Será que el tamaño de la base de datos de mi Cache Server puede crecer indefinidamente a medida que más y más recursos son importados y almacenados?

El Cache Server quita assets que no han sido utilizados por un periodo de tiempo automáticamente (obviamente si esos assets son necesitados nuevamente, estos tendrán que ser re-creados durante el siguiente uso).

El cache server funciona solamente con el asset server?

El cache server está diseñado para ser transparente a los sistemas de control de versiones/fuentes y usted no está restringido a utilizar el asset server de Unity.

Qué cambios van a causar que el archivo importado sea re-generado?

Cuando Unity está apunto de importar un asset, genera un has MD5 de todos los datos fuentes.

Para una textura esto consiste de:

  • El asset fuente: archivo “myTexture.psd”
  • El archivo meta: “myTexture.psd.meta” (almacena todos los ajustes del importador)
  • El número de la versión interna del importador de textura
  • Un hash de números de versiones de todos los AssetPostprocessors

Si ese has es diferente de lo que está almacenado en el Cache Server, el asset será re-importado, de lo contrario, la versión en cache será descargada. El editor cliente de Unity solo va a sacar assets del servidor a medida que sean necesitados - los assets no son empujados a cada proyecto a medida que cambien.

Cómo trabajo con Asset dependencies?

El Cache Server no necesita manejar dependencias. El pipeline del asset de Unity no maneja el concepto de dependencias. Está construido de tal manera para evitar dependencias entre assets. AssetPostprocessors son una técnica en común utilizada para personalizar el importador de assets para que encaje con sus necesidades. Por ejemplo, usted podría querer agregar un MeshColliders a algunos GameObjects en el archivo fbx basándose en su nombre o tag (etiqueta).

También es fácil utilizar los AssetPostprocessors para introducir dependencias. Por ejemplo usted podría utilizar información de un archivo texto alado del asset para agregar componentes adicionales a los game objects importados. Esto no es soportado en el cache Server. Si usted quiere utilizar el Cache Server, usted tendrá que quitar las dependencias en otros assets en la carpeta del proyecto. Debido a que el Cache Server no sabe nada acerca de la dependencia en su post-processor (post–procesador), no sabra que cualquier cosa ha cambiado por lo tanto utilice el versión en cache vieja de su asset.

En práctica hay muchas maneras que usted puede hacer asset postprocessing (post-procesamiento) par que funcione bien con el cache server (servidor de cache). Usted puede utilizar:

  • La ruta del asset importado
  • Cualquier ajuste de importación del asset
  • El asset fuente en sí o cualquier información generada de este pasado a usted en el asset post-processor.

Hay algunos problemas cuando se trabaje con materiales?

La modificación de los materiales que ya existen podrían causar problemas. Cuando se utilice el Cache Server, Unity valida que las referencias a los materiales son mantenidas. Pero debido a que ninguna llamada de post-processing (post-procesamiento) será invocada, el contenido del material no puede cambiar cuando un modelo es importado a través del Cache Server. Por lo tanto, usted podría obtener diferentes resultados cuando importe con o sin el Cache Server. Es mejor nunca modificar los materiales que ya existen en el disco.

Hay algunos tipos de assets que no serán puestos en cache por el servidor?

Hay algunos tipos de información de assets que el servidor no da en cache. En realidad no hay nada para ganar al cachear archivos scripts y por lo tanto el servidor las va a ignorar. También, los archivos nativos utilizado por software de modelado 3D (Maya, 3D Max, etc) están convertidos al FBX utilizando la aplicación en sí. Actualmente, el asset server caches ni el archivo nativo ni el archivo intermediario FBX generado en el proceso de importación. Sin embargo, es posible beneficiarse del servidor al exportar archivos como FBX del software de modelado y agregando estos al proyecto de Unity.

YAML Class ID Reference (Referencia del ID de la clase YAML)
Modificando Assets Fuentes a través del Scripting