CLÚSTER DE RENDERIZADO PARA LA GENERACIÓN DE MODELOS TRIDIMENSIONALES

CLÚSTER DE RENDERIZADO PARA LA GENERACIÓN DE MODELOS TRIDIMENSIONALES

Omar Ordóñez Toledo (CV)
Universidad TECMilenio

Volver al índice

Propuesta de intervención

La propuesta de solución tentativa para solucionar el problema identificado después de realizar un análisis conceptual con base a los resultados arrojados en el desarrollo del proyecto de investigación, es la creación de un clúster de renderizado el cual va permita mejorar los tiempos de renderizado atacando directamente las variables que fueron consideradas como significativas y que impactan y se relacionan directamente con el problema identificado, las cuales fueron Motor de renderizado (X1), Cantidad de fotogramas (X2) y Técnica de renderizado (X3).
Con la creación del clúster de renderizado se pretende contar con una plataforma tecnológica abierta que sea flexible y escalable que nos permita disminuir los tiempos de renderizado y con esto poder entregar en tiempo y forma los servicios tecnológicos ofertados y que a su vez sirva  para lograr la integración de diversos servicios dentro de la misma plataforma.
A continuación se muestra la investigación realizada de los diferentes tipos de clúster que se encuentran en el mercado.

6.1 Estado de la cuestión

6.1.1. BackBurner renderizado por lotes utilizando 3D´s MAX

Es muy conocido el hecho de que, en 3ds MAX, se puede hacer renders en red, con más de una computadora; fenómeno más conocido como "Net render". Algunos de los beneficios que trae este tipo de rendereo es que se puede trabajar con muchas computadoras rendereando una sola escena o muchos computadores rendereando un solo frame, esto resulta bastante útil cuando se tiene que hacer pruebas en renders que se demoran más de 5 minutos, Backburner divide el proceso de render en tres partes:
Manager: Es el que maneja al resto de las computadoras. Desde él se asignan tareas al resto de los computadores que están en modo server.
Server: Se debe inicializar en cada uno de las computadoras denominadas "obreros", es decir las computadoras que van a renderear. Estos se comunican con el manager y esperan tareas.
Monitor: Es una ventana desde la cual se puede ver y controlar todos los procesos. Desde esta ventana se pueden cancelar las tareas o cambiar prioridades o propiedades. Lo ideal es que este encendida solo en el pc que hace de manager. Lo primero que se debe hacer es encender el manager en la computadora  que va a controlar todo. La primera vez aparecerá una ventana de configuración, donde generalmente la configuración por defecto funciona a la perfección. Si se quiere (no es necesario pero siempre es bueno visualizar lo que se hace), se puede encender el monitor en la misma computadora que tiene la función de manager, para poder ver lo que está en lista de espera y a que computadoras les está enviando trabajos. (Peivem, 2007)
Este proceso de renderizado funciona de la siguiente manera:

  • Todas las computadoras deben estar en red y deben tener 3d studio MAX (la misma versión para todos) y los plugins necesarios instalados.
  • Una de las computadoras debe funcionar como manager, es decir, es el que le manda trabajos al resto de las computadoras a los cuales se les, llama servers.
  • En la computadora denominada manager se abre 3d studio MAX, se setea el render y se manda a renderear.
  • En ese momento, el render que se envió queda en una lista de espera para ser rendereado apenas el manager se contacte con cualquiera de los servers.
  • Después de eso, solo queda esperar el resultado final.

6.1.2. Optimización utilizando computación distribuida.

Si dividimos el problema en otros más pequeños (y cada uno de ellos es resuelto en un procesador diferente), el tiempo necesario para resolver el problema completo debería disminuir. Para obtener una solución óptima al problema todas las computadoras que forman el sistema deberán mantenerse ocupados. Por tanto, es necesario elegir una buena estrategia de distribución de tareas para conseguir este objetivo.

De acuerdo a la forma en la que se ha realizado la división de tareas, podemos distinguir sistemas de granularidad fina, si una imagen se ha dividido en fragmentos más pequeños y éstos han sido enviados a distintos procesadores para que sean ejecutados de forma independiente, o bien, sistemas de granularidad gruesa (en el caso de las animaciones 3D) si cada fotograma de la animación sin fragmentar es enviado a una unidad de procesamiento. Dr. Queue es una herramienta de código abierto diseñada para distribuir fotogramas a través de una granja de computadores interconectados en una red; en concreto, este software multi-plataforma trabaja en un nivel de división de granularidad gruesa. (DrQueue, 2011)

Doctor Queue es un entorno de procesamiento paralelo que comenzó orientado a la renderización pero que ha evolucionado para proporcionar distribución, monitorización y gestión de tareas a través de una red de nodos de procesamiento. Las tareas son distribuidas entre las computadoras y procesadas de manera paralela. La configuración de los trabajos se realiza mediante scripts y también ofrece una API Python que permite extender la funcionalidad. Dr. Queue puede utilizarse en plataformas Windows, MacOs X, Linux, Irix y FreeBSD. Soporta plataformas mixtas en las que incluso pueden coexistir arquitecturas de 32 y 64 bits. (Carabias, 2008)

6.2 Modelo de Propuesta

Cuando se realiza un modelado 3D o un recorrido virtual, es necesario una vez que se construye el modelo, llevar a cabo un proceso que nos permita construir cada fotograma de la animación o película en 3D, por lo que es necesario que el programa empleado para modelar construya una foto de la cámara virtual que está enfocada al escenario. Dicho proceso puede tardar dos o tres minutos en baja calidad, por cada segundo de película animada necesitamos al menos 25 cuadros y si se toma en cuenta que un cortometraje puede durar varios minutos, entonces una sola PC tardaría semanas o meses durante todo el día construyendo los cuadros; para darle una solución tenemos los clúster o granjas de render. (Driemeyer, 2008).
La granja de render es un conjunto de computadoras interconectadas a través de un sistema operativo y un programa control, las cuales realizan una tarea en conjunto, en este caso el calcular la escena de un modelado 3D y crear las imágenes o renders de esta.
Es necesario el empleo de una red con características especificas a gigabit, esto se debe a la gran complejidad de cálculos que necesita realizar una computadora y distribuirla entre las demás computadoras, todo ello se traduce en tiempo de espera para obtener una sola imagen, la cual a la hora de requerir de una animación se puede transformar en muchas horas de renderizado, días e incluso hasta semanas. De aquí la necesidad de utilizar el cómputo paralelo. En la actualidad la mayoría de los motores de renderizado (Scanline, PhotonMaping, Mental Ray, Vray, Brasil, Maxwell, etc.) son complejos sus cálculos y son necesarios en la interpretación del modelo 2D de una imagen 3D, utilizan todo el recurso disponible en dicha labor. De aquí la importancia de contar con equipos de alto rendimiento y capacidad.
La utilización de herramientas comerciales puede ayudar a la construcción de un clúster de render sin mayores problemas, desafortunadamente el costo tan alto que tienen las licencias hacen que muchas empresas busquen otras opciones.
Existe un gran número de herramientas que permiten la construcción de un clúster de renderizado, de las cuales resaltan, como se observa en la tabla 12.
Como se puede observar una de las plataformas más utilizadas para crear clúster es el software ofrecido por la empresa Autodesk, con 3D Max Studio, Maya y su motor VRay, son las herramientas más utilizadas en un clúster de red, desafortunadamente el costo de las licencias por nodo de red es muy alto y difícil de pagar para la mayoría de las Instituciones educativas  en México y algunas organizaciones; la licencia de estas herramientas por nodo tiene un costo aproximado de US$3,900.
La utilización de herramientas de software libre, es una gran alternativa para los diseñadores y desarrolladores de recorridos en 3D, puesto que los costos de licencias pueden ser invertidos en la infraestructura del clúster y así mejorar la eficiencia en el proceso de render de un proyecto.
La alternativa que se propone con este proyecto se basa en la experiencia que se tiene como grupo de trabajo al implementar un conjunto de herramientas de software libre, que permiten mejorar y obtener resultados de proyectos de render de gran tamaño. Sin embargo es necesario probar con otra gama de herramientas emergentes y que permitirán mejorar el proceso de paralelización.
La propuesta de este proyecto es ofrecer una solución basada en software libre y hardware de bajo costo, de tal forma que la integración de una granja de render para las empresas de la región sea una posibilidad y la solución para grandes proyectos de animación generados en la institución educativa.
En nuestro entorno de ejecución, el sistema está compuesto por 5 estaciones de trabajo localizadas en el mismo lugar. Estos computadores son PCs con características iguales. Los requerimientos mínimos que debe tener cada computadora para pertenecer al sistema son una memoria RAM de 1 GB y tener una conexión de al menos 100Mbits/s (todos las computadoras están conectadas a la red utilizando switches de 100Mbits/s). En la siguiente figura se muestran estos requisitos.
Para generar el clúster de renderizado se pretende utilizar Open Mosix como la herramienta base para construir el clúster sobre sistemas Linux con licencia GNU. Este utiliza la estrategia de trabajar como una máquina multiprocesador y permite el balanceo de carga entre todos los nodos que forman el clúster: migra procesos, independientemente de en qué nodo se han originado, al nodo con menos carga de trabajo. Su mayor ventaja es que las aplicaciones que ejecuta no deben estar programadas para Open Mosix ya que trabaja con aplicaciones sin paralelizar; permite al usuario utilizarlo sin conocer su funcionamiento, es transparente. Tiene una limitante: sólo migra procesos que no usen memoria compartida, por lo que no migra procesos multihilo.

6.2.1. Software Open Mosix

Open Mosix es una herramienta diseñada para realizar balanceo de cargas en un clúster de forma totalmente transparente a tal grado de que los  nodos del clúster se comportan como si fuera solamente una maquina y de esta manera incrementar el aprovechamiento de cada uno de los nodos.
El núcleo de la herramienta Open Mosix está formado por un conjunto de algoritmos diseñados para responder dinámicamente a las variaciones de carga entre los nodos que forman el clúster, migrando los procesos de un nodo a otro, con el fin de mejorar el desempeño.
Los usuarios pueden correr aplicaciones paralelas inicializando múltiples procesos en un nodo, entonces la tarea de Open Mosix es asignar estos procesos a los nodos con mejores recursos disponibles (procesador más rápido, más memoria RAM, mayor tamaño en disco duro, etc). Los algoritmos de Open Mosix están diseñados para monitorear constantemente los nodos, para asignar y reasignar procesos, esto es fundamentalmente importante porque da un uso eficiente de todos los recursos con los que cuenta cada nodo.
La propiedad más notable de la ejecución e aplicaciones en Mosix son las políticas de distribución de procesos y la flexibilidad de configuración de los nodos del clúster. Estas aplicaciones pueden ser ejecutadas creando muchos procesos de tal forma que parezca ante el usuario como si fuera solamente un nodo el que ejecuta todos los procesos.

6.2.2. Características de Open Mosix

Las características de Open Mosix que se muestran a continuación están implementadas a nivel del Kernel del sistema operativo de Linux.

  • Algoritmo de dispersión de información probabilística, mediante estos algoritmos se tiene conocimiento suficiente de los recursos con que cuenta cada nodo. Además todos los nodos envían en cada determinado tiempo información acerca de sus recursos disponibles en ese instante, para que de esta forma el nodo principal les pueda asignar o reasignar procesos, al mismo tiempo cada nodo mantiene un buffer con información enviada a éste.
  • Migración de procesos preventivos, esto significa que un usuario puede migrar procesos de forma manual a un nodo disponible ya que la otra forma  mediante la asignación automática.
  • Balanceo de carga dinámica, continuamente se intenta balancero y reducir la carga entre pares de nodos, es decir, cada vez que un nodo tiene un exceso de carga siempre se busca otro nodo que esté ociosos para asignarle trabajo, este mismo algoritmo es asignado por cada uno de los nodos del clúster Open Mosix.
  • Acomodo de memoria, es un algoritmo que se activa cuando un nodo no tiene la memoria suficiente para ejecutar los procesos que se le han asignado. En estos casos se activa también el algoritmo de balanceo de carga dinámica para asignar los procesos a otros nodos.
  • Comunicación eficiente de Kernel, esta característica fue especialmente diseñada para reducir la sobrecarga de comunicación entre los diferentes  núcleos del clúster, con esta característica la asignación de intercomunicación de procesos se hace más eficiente.

6.2.3. Componentes necesarios para construir el clúster son:

  • Parche para Open Mosix sobre el kernel Linux
  • Instalación y configuración de MFS; sistema de archivos compartido
  • Configuración del demonio omdiscd para localizar los nodos en el clúster
  • Instalación y configuraron las herramientas de administración para el usuario desde línea de coman-dos Open Mosix-User y Open MosixView
  • Obtención de pruebas de stress para verificar el correcto funcionamiento del clúster

Después de verificar el funcionamiento del clúster, ahora se instala y configura el Blender y su alternativa de render POV-Ray; una de las ventajas es que Blender se ejecuta como un único proceso y Open Mosix puede paralelizarlo en una forma eficiente; se ejecutan varios programas Blender en el clúster y esto permite aumentar la rapidez del renderizado de un proyecto. El proceso de generación de un proyecto de render sigue los pasos siguientes:

  • Se obtienen los archivos .blend de una escena o proyecto; adicionalmente es posible con Blender cargar un proyecto de otras herramientas como 3D Max Stu-dio o Maya (.3ds) y convertirlos a este formato.
  • Se divide el proyecto entre los nodos del clúster utilizando un conjunto de scripts disponibles en Open Mosix.
  • Se generan los archivos del render y se reúnen en un único archivo utilizando la herramienta mencoder; la cual puede generar archivos .avi y .mpg
  • Si se desea utilizar un render para texturas y posiciones de cámara se utiliza el KpovModeler y otras bibliotecas de POV-Ray para generar escenarios de recorridos virtuales.

6.3 Inversión y periodo de recuperación

Se estima que para la puesta en marcha del proyecto se haría una inversión inicial de $24,977.00 contando con los requerimientos de hardware y software para la creación del clúster de renderizado, el material necesario para la construcción del clúster y sus costos se muestra en la siguiente tabla.
Referente a la mano de obra para la implementación y mantenimiento del sistema se hará cargo la persona encargada del laboratorio de multimedia con el apoyo de estudiantes de estancia estadía y de alumnos interesados en el proyecto.
La capacitación que se requiere tanto para alumnos como profesores la realizarán las personas involucradas en el proyecto, es decir el encargado de laboratorio y los profesores encargados del proyecto sin ningún costo adicional, puesto que son parte de sus funciones dentro de la Universidad.
Si consideramos el costo de implementación del clúster contra el costo de las penalizaciones por la no entrega a tiempo del producto final que equivale a un 20% del precio convenido sobre la elaboración del modelado tridimensional, podemos ver claramente, que si se invirtiera en la puesta en marcha del clúster el costo de recuperación sería de forma  inmediata.