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
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.
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
en el Mac o 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.
El Administrador necesita configurar la maquina Cache Server que será anfitriona de los assets en cache.
Usted necesita:
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.
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.
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
.
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.
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 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.
Cuando Unity está apunto de importar un asset, genera un has MD5 de todos los datos fuentes.
Para una textura esto consiste de:
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.
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 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 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.