Para poder dar un mejor servicio hemos creado un Blog basado en WordPress y así poder dar nuestra opinión y formación en un entorno adecuado.
https://renderflow.wordpress.com/
martes, 29 de diciembre de 2015
miércoles, 25 de marzo de 2015
Lanza Renders por command line para 3dsmax
Render Automáticos
Todos hemos visto las lineas de comando o de código como si estuviéramos viendo Matrix alguna vez en nuestra vida. Esto ocurre por que o no comprendemos su uso o no le vemos utilidad en nuestro día a día.Intentare explicar SUPERFICIALMENTE como se usan y las posibles utilidades que puede tener en las tareas cotidianas de un estudio o un profesional.
lunes, 9 de marzo de 2015
HuevoCartoon confia un largometraje a RenderFlow
La productora mexicana HuevoCartoon ha confiado secuencias de su tercera película en el sistema de Render de RenderFlow.
Esta es la tercera entrega cinematográfica y la primera en 3D. Tradicionalmente efectuada en 2D/Flash se decidieron a dar el salto a la producción 3D de la mano de uno de los motores de render más avanzados (Arnold).
Esta es la tercera entrega cinematográfica y la primera en 3D. Tradicionalmente efectuada en 2D/Flash se decidieron a dar el salto a la producción 3D de la mano de uno de los motores de render más avanzados (Arnold).
Las producciones de HuevoCartoon son muy conocidas desde hace muchos años y en México disponen de una amplia comunidad de seguidores. Con un pipeline basado en Maya y Arnold Render confiaron en RenderFlow para efectuar el procesamiento de un grupo de planos de la producción.
Concretamente las secuencias de mayor complejidad de la producción en las que por la cantidad de personajes con plumas requería de una potencia extra de Render.
Tras un proceso de adaptación al pipeline se les suministra un acceso privado y el uso libre de un sector de 180 nodos de los 1.100 disponibles por RenderFlow. Esta potencia extra de 360 procesadores Xeon E5 2670 han permitido atender la producción.
La empresa SolidAngle aporta el asesoramiento y soporte de Arnold Render para efectuar el servicio.
Auditoria previa
Para poder disponer de toda la información de primera mano se establecieron una serie de reuniones por Skype con todos los directores de las áreas involucradas y nuestro equipo de producción y desarrollo. Tras las primeras reuniones se determinaron las claves de las necesidades y las peculiaridades a resolver:
- Necesidad de Render inmediata
- Pipeline basado en Maya 2013 y Arnold 1
- Entorno de trabajo y almacenamiento Linux en cliente
- Shaders customs de Arnold de la productora en Linux
- Pipeline de Render actual basado en ficheros ASS de Arnold
- Secuencias de Render ultra pesadas con cámaras estéreo creadas por scripts propios.
- Generación de ficheros EXR que deben ser integrados a postproducción en tiempo real
Decisión de pipeline
Puesto que la productora ya esta realizando el render internamente en su granja se nos propone que adoptemos el mismo pipeline que ellos están aplicando. Esta decisión es clave a la hora del éxito del proyecto al existir diferencias entre las dos infraestructuras y que deben ser sincronizadas vía IP.
Inicialmente la productora propone exportar las escenas a ficheros Ass para ser procesados por el motor de Arnold por medio del Kick. Tras un análisis de problemática se les propone a la productora no tener que hacer los procesos de exportación y lanzar las escenas directamente desde Maya. Esta alternativa de conexión permite no tener que generar y transferir los pesados ficheros Ass ni ocupar a su personal en las tareas de exportación. Además, el poder disponer de un plugin interno a Maya, permite que se lancen a proceso todas las Layers y de ambos ojos en un único envió.
La recolección de los assets necesarios para el Render (modelos, texturas y caches) son recolectados por el plugin de Maya y el programa propio Synchro para optimizar los envíos y tener un control de versiones.
Además, puesto que la productora trabaja con Linux, se les proporciona y Synchro para este sistema operativo y se despliegan los shaders de Arnold en granja.
- Plugin personalizado de Maya
- Despliegue de versión exacta de Software por medio de tecnología Docker (Ver Articulo)
- Acceso privado ilimitado
- Credenciales de sFTP de bajo nivel para sincronía y recogida en tiempo real. (Acceso usando un cliente de sFTP como el WinSCP)
- Copia de shaders y tools a granja Linux, desplegados dentro del Docket especifico.
- Desde este momento la productora pudo comenzar a hacer el envío de sus escenas con autonomía.
- Dotación de potencia. Asignación de tres racks de 60 nodos con políticas de encendido automático.
- Proceso BPM automático de alerta estadística para gestión de frames erróneos.
Coordinación
Debido a la diferencia horaria entre España y México, 5 horas, se establecieron jornadas de trabajo solapadas que permitían desarrollar conjuntamente pruebas y la supervisión.
Tras la puesta en marcha de la solución de Render automática por parte de RenderFlow no fueron necesarias tareas de coordinación más allá de las tareas básicas de seguimiento y soporte técnico de granja puesto que los artistas gestionaban ellos mismos los trabajos desde la consola web de control.
Cierre del proyecto
Puesto que el cliente tenía acceso a los ficheros raíz y los frases procesados se aseguró el borrado de todo el material de la producción por medio de los comandos de borrado de las tareas desde la consola de control y el acceso a bajo nivel por sFTP.
Ha sido una experiencia fantástica y solo nos resta desearles lo mejor en el estreno y la comercialización.
Créditos
Rodrigo Medinilla Render Supervisor
Israel Bethencourt Programmer
Marcos Martin Render Supervisor
Miriam Garcia Production Line
Jennifer Hernandez Comunications
Jonatán Felipe García HPC Manager
Carlos I. González Vila HPC Specialist
Alberto Cabrera Pérez HPC Specialist
miércoles, 5 de noviembre de 2014
Docker.io 3D
Yes, I have to admit that I’m a bit envious of all those cloud projects that can virtualize their infrastructure and run whatever they want.
As you may know in a renderfarm we can’t use virtualization because of the loss of performance. So we have to ignore all that kind of fascinating new technologies like elastic infrastructure and autoprovisioning and configure our render nodes with all we could need for the current and future scenes, and hope all of that software, plugins and libraries doesn’t transform your nodes into a complete mess.
In a commercial renderfarm like RenderFlow this scenario is even worse, because we have to support any kind of configurations for Maya, Softimage, Arnold standalone, etc. Also, we have to be able to replicate the workspace of every client in our nodes. That includes plugins, shaders, directory structure and so on.
Our first approximation to solving this problem was configuring our nodes to be able to render any kind of scene no matter what 3D software, render engine or plugin it uses, we should have all things previously configured. As you may guess it is really hard to try to fix/debug problems in a node. Also adding a new feature for a client can break a configuration for the rest of the users.
Docker.io to the rescue
The new revolutionary cloud technology has come to Linux and in a couple of years has become the most massive hype on the IT. But before explaining what docker is I have to explain what a Linux Container is.Linux Containers
A Linux Container is similar to a lightweight virtual machine but running in the same kernel as the host. It doesn’t need a hypervisor and the applications run in the same context as the host but in an isolated way. That means you have all the advantages of virtual machines without the overhead of a hypervisor and a complete SO running into another SO:
- Portability: You can create your containers on your laptop and then run them in the render nodes. The only requisite is a compatible kernel.
- Isolation: Changes on one container don’t affect others. You can configure the live render nodes to accept a new type of render engine even when the node is still rendering.
- Lightweight and minimal overhead: Containers don’t require additional infrastructure, they just use the host kernel.
What is Docker
Docker is a management tool on top of Linux Containers that offers a really useful set of tools. See how easy it is to create a centos image ready to use:docker run -t -i -v /repository:/repository centos:centos6 /bin/bash
This command will download a basic centos6 distribution from the docker site; after that you will get a bash console to start configuring the container. Yes, you don’t have to install the SO from an ISO and configure the services to run and all those boring things. Docker uses its platform (https://registry.hub.docker.com) to download ready-to-use images of any kind of linux flavour on which you can then install whatever you want.
We have to give a special mention to the last part of the above command: /bin/bash This is the init command in your container. That means you don’t need to use the classical sysvinit since you only need to run one single command in your container: the Render command.
This simplifies the render use case since you don’t have to specify a special script to run your render when the Container starts, just specify the render command as the last argument in the docker command and the container will run the command. When the render finishes, the container will be terminated as well.
Distributing containers
Of course as with a virtual machine you can just export the container to a file and then import it in each render node, but Docker offers some other solutions:- Docker registry: You can distribute your containers over the network, uploading the images to a private registry. If you try to execute a container which is not available locally, docker will try to look it up in the registry and it will download it before execution.
- Dockerfile: You can create a script that from a base distribution configures a render node. With this file you can create the render container just executing the script in the render node.
How we use it
We have a Docker registry available from all render nodes. We have uploaded some containers to the registry. Each container has a descriptive name about what it contains. For example we have a maya2015_mtoa_1.1.1.1. Then we use a script to run the render command from a specific container.render.sh 2015_mtoa_1.1.1.1 test.mb username
This is more or less like:
#!/bin/bash
CONTAINER=$1
SCN=$2
USERNAME=$3
docker run -ti --rm -v /storage/$USERNAME:/storage $CONTAINER /usr/autodesk/maya/bin/Render -rd /storage/output $SCN
This command will:
We are discovering new fascinating uses for this technology. For example, we hope in the upcoming versions of our Arnold renderfarm to be able to execute linux containers provided by our clients. This will give you more control over how to render your scenes in RenderFlow: Imagine you can upload the same container you are using to render your scene in your own renderfarm to RenderFlow this will allow us to be able to start rendering your scene without delay and comply with the deadline.
If you want to play a bit with Docker, install it https://docs.docker.com/installation/#installation and enjoy: https://docs.docker.com/userguide/
#!/bin/bash
CONTAINER=$1
SCN=$2
USERNAME=$3
docker run -ti --rm -v /storage/$USERNAME:/storage $CONTAINER /usr/autodesk/maya/bin/Render -rd /storage/output $SCN
This command will:
- Create a new container with the name specified in the first argument.
- Mount in /storage the host directory /storage/<username>. This will give access to the user assets and nothing else.
- Run the maya Render command inside the container and wait until it finalizes.
- When the render is ready then close and remove the current instance. The render result will be stored in the /storage/<username> directory of the host.
- Leave the node prepared for a new job.
We are discovering new fascinating uses for this technology. For example, we hope in the upcoming versions of our Arnold renderfarm to be able to execute linux containers provided by our clients. This will give you more control over how to render your scenes in RenderFlow: Imagine you can upload the same container you are using to render your scene in your own renderfarm to RenderFlow this will allow us to be able to start rendering your scene without delay and comply with the deadline.
If you want to play a bit with Docker, install it https://docs.docker.com/installation/#installation and enjoy: https://docs.docker.com/userguide/
viernes, 18 de mayo de 2012
Cycles + GPU
Desde el pasado 7 de Mayo tenemos en fase de beta pública gratuita el nuevo sistema de procesamiento por GPU para usuarios de Cycles.
Cycles fue introducido en la matriz de Blender desde hace solo un año pero ha cogido una popularidad muy importante entre los usuarios que demandaban un motor de render potente, interactivo y con una libertad de crear shaders importante.
Aunque aun no es totalmente compatible con los parámetros internos de blender al no soportar partículas, pelo o los materiales del internal es de los motores más interesantes que han aparecido en el panorama 3D del momento.
Hay que añadir que la velocidad de desarrollo del motor en las sucesivas versiones del último año lo está situando como una alternativa muy prometedora a otras soluciones anteriores como Yafaray o Luxray que se desarrollan con más lentitud.
La nueva versión 2.63a incorpora nuevos canales de salida para AO y sombras y las versiones de desarrollo ya permiten que las fases de preparación de la geometría, que antes resultaba lenta, se pueda efectuar en múltiples cores por lo que su tiempo se reduce considerablemente.
Continuamos echando en falta opciones de compatibilidad y una capa por encima del editor de nodos para simplificar el trabajo con escenas pesadas o el reciclaje de materiales generando librerías, pero todo se andará.
El tiempo de render es elevado y este es el motivo de nuestra oferta de servicios. Podemos absolver estas tareas de render y que la comunidad de Cycles pueda trabajar en sus proyectos sin tener la limitación de las horas de procesamiento que se requieren para una imagen de gran tamaño o complejidad.
Para estas tareas la granja a dotado de estaciones de 64 procesadores y varias tarjetas cuda en SLI para dar la mayor de las potencias de render en un tiempo mínimo. El siguiente vídeo os muestra todo el proceso desde el registro hasta la descarga del resultado...
Since May 7th we offer in phase free public beta our new system of GPU processing for Cycles users. Cycles was introduced in the Blender matrix only one year ago but it gained strong popularity within the community which demanded a powerful render engine, interactive and with the potential to create important shaders.
Even though it is, by now, not 100% compatible with the internal parameters of Blender, e.g. it does not support particles, hair or the materials of the Internal, it is one of the most interesting render engines which recently appeared in the 3D panorama.
It is to mention that the speed of development of this engine with its numerous version changes along last year has converted it in a promising alternative to other, anterior, solutions like Yafaray or Luxray whose development is much slower.
The ultimate version 2.63a incorporates new output channels for AO and shadows and the versions in development already permit that in phase of preparing geometry, which in the past ran very slow, it can be effectuated in multiple cores which reduces significantly the processing time.
The rendering time is high and this is the motive for our service offer. We can take care of the render tasks and the Cycles users can work in their projects without the time restrictions due to high processing requirements especially for big or complex images.
For these tasks our render farm is equipped with 64 core machines and various CUDA´s in SLI to provide maximum render power in minimum time. The following video shows the whole process from register to downloading the result …
Aunque aun no es totalmente compatible con los parámetros internos de blender al no soportar partículas, pelo o los materiales del internal es de los motores más interesantes que han aparecido en el panorama 3D del momento.
Hay que añadir que la velocidad de desarrollo del motor en las sucesivas versiones del último año lo está situando como una alternativa muy prometedora a otras soluciones anteriores como Yafaray o Luxray que se desarrollan con más lentitud.
La nueva versión 2.63a incorpora nuevos canales de salida para AO y sombras y las versiones de desarrollo ya permiten que las fases de preparación de la geometría, que antes resultaba lenta, se pueda efectuar en múltiples cores por lo que su tiempo se reduce considerablemente.
Continuamos echando en falta opciones de compatibilidad y una capa por encima del editor de nodos para simplificar el trabajo con escenas pesadas o el reciclaje de materiales generando librerías, pero todo se andará.
El tiempo de render es elevado y este es el motivo de nuestra oferta de servicios. Podemos absolver estas tareas de render y que la comunidad de Cycles pueda trabajar en sus proyectos sin tener la limitación de las horas de procesamiento que se requieren para una imagen de gran tamaño o complejidad.
Para estas tareas la granja a dotado de estaciones de 64 procesadores y varias tarjetas cuda en SLI para dar la mayor de las potencias de render en un tiempo mínimo. El siguiente vídeo os muestra todo el proceso desde el registro hasta la descarga del resultado...
Since May 7th we offer in phase free public beta our new system of GPU processing for Cycles users. Cycles was introduced in the Blender matrix only one year ago but it gained strong popularity within the community which demanded a powerful render engine, interactive and with the potential to create important shaders.
Even though it is, by now, not 100% compatible with the internal parameters of Blender, e.g. it does not support particles, hair or the materials of the Internal, it is one of the most interesting render engines which recently appeared in the 3D panorama.
It is to mention that the speed of development of this engine with its numerous version changes along last year has converted it in a promising alternative to other, anterior, solutions like Yafaray or Luxray whose development is much slower.
The ultimate version 2.63a incorporates new output channels for AO and shadows and the versions in development already permit that in phase of preparing geometry, which in the past ran very slow, it can be effectuated in multiple cores which reduces significantly the processing time.
The rendering time is high and this is the motive for our service offer. We can take care of the render tasks and the Cycles users can work in their projects without the time restrictions due to high processing requirements especially for big or complex images.
For these tasks our render farm is equipped with 64 core machines and various CUDA´s in SLI to provide maximum render power in minimum time. The following video shows the whole process from register to downloading the result …
Suscribirse a:
Entradas (Atom)