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

2.2 Investigaciones Previas

A continuación se presentan algunas investigaciones previas que se han realizado por diversos autores y que tienen relación con el tema de esta investigación, con la finalidad de que se comprenda mejor el tema tratado e este trabajo.

2.2.1 REDAG3D: Renderizado Distribuido de un Ambiente Gráfico 3D

La computación gráfica ha evolucionado en gran medida desde sus orígenes hasta hoy, gracias al aporte de otras líneas de investigación, tales como los sistemas distribuidos y los mecanismos de comunicación. Actualmente existen varias arquitecturas que permiten realizar el renderizado distribuido, generalmente solo usan un mecanismo de comunicación:

Es por ello, que en este artículo se presenta una arquitectura flexible que permite realizar de forma distribuida el renderizado (proceso para generar una imagen 2D a partir de objetos 3D), el cual exige un alto consumo de recursos de procesamiento. La arquitectura permite configurar de manera dinámica tanto la técnica de renderizado como el mecanismo de comunicación.

Para realizar el renderizado distribuido de una escena 3D se deben revisar conceptos relevantes sobre sistemas distribuidos, computación gráfica y las técnicas de renderizado distribuido existentes además de conocer los elementos que incluirá el renderizado es decir movimientos, texturas, luces, etc, con el fin de determinar los requerimientos mínimos de la arquitectura de REDAG3D.

Para probar dicha arquitectura, se debe implementar una aplicación prototipo que ponga en funcionamiento cada una de las características de los componentes definidos. Adicionalmente crear una escena constituida por modelos 3D complejos, que permitan validar las características de desempeño y flexibilidad de la arquitectura. Por otro lado, la aplicación debe tener un diseño consistente que ofrezca ventajas para la implementación, mantenimiento y puesta en marcha.

Las técnicas de renderizado distribuido fueron Sort-First y Sort-Last. Sus principales diferencias radican en la forma como se distribuye la geometría y en qué etapa del proceso de renderizado se hace el ordenamiento (sort). Sort-First implica redistribuir primitivas de espacio de pantalla a cada procesador, en donde se hace una clasificación de éstas antes de la etapa de transformación geométrica.
En Sort-Last, las primitivas se envían a cada procesador sin una previa clasificación y se hace un ordenamiento de píxeles en la etapa de composición de la imagen final. Como mecanismos para la distribución se seleccionaron Sockets y JNDI-RMI. Sockets también fue utilizado como mecanismo de comunicación para el envío y recepción de mensajes entre las máquinas, y JNDI-RMI permitió la publicación de servicios para ser usados por la máquina que administra la aplicación.

La elección de Sockets para el envío y recepción de mensajes se basó en unas pruebas cuyos resultados fueron analizados y arrojaron como conclusión que era el mejor mecanismo para esta labor.

Por otra parte, cuando se hace referencia al renderizado distribuido es necesario contar con escenas 3D que justifiquen la presencia de varias máquinas para realizar dicho proceso, por lo cual, se decidió crear una escena lo suficientemente
compleja. Esta complejidad se mide según el número de mallas que conforman los modelos 3D de la escena, el número de triángulos de las mallas, las texturas asociadas a los modelos y efectos adicionales.
Se definió un plan de pruebas, el cual evalúa los aspectos más relevantes asociados al comportamiento de las técnicas de renderizado, los mecanismos de comunicación, así como el rendimiento y la funcionalidad de los gestores de distribución en la aplicación REDAG3D. (Diana L. REYES, Alfonso BARBOSA, César J. BUSTACARA)

2.2.1.1 Pruebas de Renderizado

El propósito de las pruebas de renderizado es verificar la eficiencia de cada técnica de renderizado con el mismo mecanismo de comunicación. Para cada máquina renderizadora se tomó el tiempo de inicio y final del renderizado de las mallas asignadas, más el tiempo de envío de cada imagen al servidor administrador y el tiempo de composición de la imagen final. En el imagen 2 se muestran los resultados de estas pruebas.
Como se observa en la Imagen 2, el comportamiento en general de las técnicas de renderizado es similar. Con 2 y 4 máquinas visualizadoras Sort-First es un poco más eficiente; a partir de 8 máquinas mejora el desempeño de Sort-Last. Con pocas máquinas Sort-First tiene un mejor comportamiento debido a que no se generan imágenes completas, por lo cual el envío de éstas a través de la red tarda menos tiempo que con Sort-Last. Cuando el número de máquinas es mayor a 4, el espacio de pantalla está subdividido en un gran número de regiones con Sort-First, por lo que se renderizan más de una vez mallas que ocupan varias regiones (ver Imagen 3), debido a esto se observa un mejor comportamiento con Sort-Last.
También se tuvieron en cuenta tiempos por cada máquina renderizadora de manera que se pudiera observar la distribución de la carga. En las Imágenes 4 y 5 respectivamente, se pueden observar los resultados de estas pruebas para 24 máquinas con las dos técnicas de renderizado distribuido.
Al observar los dos gráficos se puede concluir que la distribución es más uniforme con Sort-First. A las máquinas que demandaron más tiempo de renderizando les fueron asignadas una cantidad mayor de mallas, o mallas con un mayor nivel de complejidad respecto al número de triángulos.

2.2.2. Yafrid: sistema de renderizado basado en Grid

Yafrid es un sistema que aprovecha las ventajas de los sistemas de computación Grid, permitiendo la distribución de una escena a través de Internet para su renderizado. Además, el sistema soporta otras tareas importantes como son la gestión de las unidades de trabajo y el uso controlado del grid.

2.2.2.1. Esquema general de la arquitectura

Los componentes de Yafrid que se encuentran en la capa de más alto nivel de la arquitectura son:

Servidor: Es el núcleo de Yafrid. Su componente básico es el Distribuidor, encargado de recoger los trabajos de una cola y enviarlos a los proveedores.

Proveedor: Esta entidad se encarga de procesar las peticiones de los clientes.

Cliente: Un cliente es una entidad externa que no pertenece al sistema en un sentido estricto. La función principal del cliente es añadir trabajos al sistema grid, para que posteriormente sean completados por los proveedores.

A continuación se describen los tres roles de usuario utilizados en Yafrid:

• Cliente. Este rol permite a un usuario añadir nuevos trabajos al grid. Un cliente también puede crear y gestionar grupos asociados a los proyectos (clientes y proveedores pueden suscribirse a estos grupos). Únicamente los proveedores que pertenecen al mismo grupo pueden participar en el proceso de renderizado del proyecto.

• Administrador. Este usuario es necesario para operar con cualquiera de los componentes que constituye el sistema, y además, posee todos los privilegios para acceder a la información relacionada con cualquier usuario del sistema.
• Proveedor. El proveedor es un usuario que tiene instalado el software necesario para que el grid pueda enviarle trabajos.

Servidor Yafrid. El servidor es el nodo fundamental ya que todo el sistema gira en torno a él. Cada uno de los proveedores se conecta a este nodo para ceder al grid sus ciclos de CPU, con el objetivo de renderizar las escenas que los clientes han añadido.

En la figura se muestran las cuatro capas que forman la arquitectura del servidor Yafrid. Este diseño está basado en la arquitectura de (I. Foster, C. Kesselman, S. Tuecke.). Las capas mencionadas anteriormente son Capa Base (o de Recursos, Capa de Servicio, Servidor Yafrid y Capa de usuario).

Capa de recursos. Ésta es la capa de menor nivel de abstracción. La capa de recursos tiene los siguientes componentes:

• Sistema de base de datos. En las bases de datos de esta capa se encuentran las tablas donde se almacena la información necesaria para el correcto funcionamiento del sistema. Algunas de estas tablas se utilizan para obtener estadísticas de la ejecución del sistema, mientras que otras almacenan datos asociados a usuarios, grupos, proyectos, etc. Los niveles que se encuentran sobre esta capa en la jerarquía pueden acceder a las bases de datos a través del servidor de bases de datos. La implementación actual del sistema utiliza MySQL como servidor para las bases de datos.

• Sistema de archivos. En algunas ocasiones es necesario acceder directamente al sistema de archivos desde las capas superiores. Básicamente el sistema distingue dos tipos de directorios: uno de ellos se utiliza para almacenar las unidades de trabajo de los proyectos creados, y el segundo tipo contiene información relativa a los usuarios y sus proyectos.

• Sistema de red. El módulo dedicado a las comunicaciones, que pertenece a la capa principal, oculta la utilización de los recursos de red de los ordenadores mediante el uso de un middleware.

• Capa de Servicio. Esta capa contiene los servidores que permiten a los módulos de las capas superiores acceder a los recursos que pertenecen a las capas inferiores. Los servidores que actúan en esta capa son los siguientes:

• Servidor HTTP. El módulo web de Yafrid trabaja sobre este servidor. Como este módulo ha sido implementado con lenguajes de programación que permiten la construcción de páginas dinámicas (la implementación actual está escrita en lenguaje PHP), el servidor web debe proporcionar soporte para este tipo de lenguajes. También, es necesario tener soporte para la composición dinámica de gráficos y el acceso a la base de datos.

• Servidor de bases de datos. Este servidor es utilizado por los módulos de Yafrid para acceder a los datos que son  indispensables para el correcto funcionamiento del sistema.

• Servidor SFTP. Los proveedores utilizan este servicio para obtener los archivos necesarios para el renderizado de las unidades de trabajo. Una vez que el proceso de renderizado ha finalizado, se utilizará el servidor SFTP (Simple File Transfer Protocol) para enviar al servidor de Yafrid la imagen resultante.

• Capa Yafrid. Esta es la capa principal del servidor y está compuesta de dos módulos diferentes (Yafrid-WEB y Yafrid-CORE) que trabajan independientemente el uno del otro. Yafrid-WEB es el módulo interactivo del servidor y ha sido implementado mediante un conjunto de páginas dinámicas. Yafrid CORE es la parte no interactiva del servidor. Este módulo ha sido principalmente desarrollado utilizando el lenguaje Python. Además, Yafrid-CORE está compuesto por tres submódulos; Distribuidor, Identificador  Estadísticas.

• El Distribuidor es la parte activa del servidor encargado de realizar las siguientes tareas indispensables: generación de unidades de trabajo, asignación de las unidades de trabajo a los proveedores, control del Timeout, finalización de proyectos y composición de resultados. A partir de los resultados generados por los proveedores, el distribuidor compone la imagen final. Este proceso no es trivial ya que se pueden distinguir pequeñas diferencias entre los fragmentos obtenidos de diferentes computadores, debido a la componente aleatoria de los métodos basados en Monte Carlo. Por esta razón es necesario suavizar la zona de unión entre los fragmentos mediante una máscara de interpolación lineal.
• La parte pasiva de Yafrid-CORE se denomina módulo Identificador cuya misión principal consiste en establecer las comunicaciones de los proveedores. La primera vez que el proveedor intenta conectar con el servidor Yafrid, el Identificador genera un objeto (controlador del proveedor) y le devuelve un proxy. Es importante destacar que cada proveedor tiene su propio objeto controlador.

• Proveedor. El proveedor es el software que un usuario debe instalar en su ordenador para que el sistema grid pueda utilizar sus ciclos de CPU ociosos. La primera tarea que debe llevar a cabo un proveedor es establecer la conexión con el grid. Una vez activado, el proveedor espera hasta que el servidor le envía una unidad de trabajo para procesarla. Cuando finaliza el proceso de renderizado, el proveedor envía el archivo vía SFTP e informa al controlador que el trabajo ha finalizado. (I. Foster, C. Kesselman, S. Tuecke.)

Un sistema difuso para la optimización del renderizado

La gran cantidad de tiempo empleado en el proceso de renderizado implica que todas las optimizaciones relacionadas persigan la reducción del tiempo final requerido. Estas optimizaciones se pueden clasificar en tres tipos generales (o en una mezcla de los mismos) (Debattista, K., Longhurst, P., Chalmers, A., and Troscianko, T. , 2005)

• Optimizaciones relacionadas con el uso de elementos de procesamiento potentes (optimizaciones de hardware).
• Optimizaciones vinculadas al uso de sistemas distribuidos (optimizaciones paralelas y distribuidas).
• Optimizaciones asociadas al uso de sistemas multiagente.

El primer tipo de optimización está relacionado con el uso de potentes elementos de procesamiento. De esta forma, algunos investigadores utilizan GPUs (Graphics Processing Units) programables con el objetivo de que estos procesadores potentes ejecuten ciertas porciones de código del algoritmo de renderizado. El principal problema de este enfoque es el bajo nivel de abstracción empleado, es decir, los algoritmos han de estar específicamente diseñados para cada arquitectura hardware.

El segundo tipo de optimización está basada en el principio de divide y vencerás. Si se adapta este principio al problema específico del renderizado, se pueden utilizar varias unidades de cómputo para reducir el tiempo final de cálculo. Existen diversos enfoques asociados a esta línea de investigación, como el trabajo realizado por Fernández-Sorribes, que hace uso de una arquitectura grid para gestionar el renderizado distribuido. Sin embargo, la mayoría de estos enfoques no logran un balanceado eficiente de la carga de trabajo y, por lo tanto, el tiempo final requerido está siempre condicionado por la tarea de mayor complejidad.

El tercer tipo de optimización está basado en el uso de sistemas multiagente. En este campo se han propuesto diferentes alternativas, como el trabajo presentado por Rangel-Kuoppa. Sin embargo, este enfoque no hace uso de la tecnología de agentes propiamente dicha, ya que no existen mecanismos de interacción entre los agentes. Otro trabajo relacionado es el propuesto por Schlechtweg, el cual hace uso de un sistema multiagente para renderizar diversos estilos artísticos.

El enfoque descrito en este artículo está basado en un sistema difuso. De este modo, se puede representar el conocimiento experto cualitativo empleando un conjunto de reglas lingüísticas, las cuales permiten a cada unidad computacional ajustar un determinado número de parámetros vinculados directamente al proceso de renderizado. A través de estos ajustes, los tiempos finales de renderizado se reducen, resolviendo el problema relacionado a la tendencia del usuario a utilizar valores de los parámetros del renderizado que no son óptimos, debido a que estos ajustes incrementan el tiempo final sin obtener beneficios importantes de calidad.

Este sistema ha sido usado satisfactoriamente en MAgArRO (Multi-Agent Architecture for Rendering Optimizations). Este sistema multi-agente (diseñado bajo los principios del conjunto de estándares de FIPA (FIPA, 2002) está compuesto por un número indeterminado de agentes especializados, los cuales compiten por la adquisición de unidades de trabajo que componen el trabajo completo. Una unidad de trabajo se puede interpretar como una parte de una escena o como un fotograma en una animación.

El enfoque utilizado en este trabajo implica ciertas mejoras con respecto a otras líneas de investigación:

• Proporciona un alto nivel de abstracción debido al uso de un sistema difuso.
• El poder descriptivo del sistema difuso empleado permite que el experto modele el conocimiento relativo al renderizado de una forma sencilla (Tanaka, 1998)
• El uso de un sistema difuso combinado con un sistema multi-agente permite que cada agente utilice diferentes modelos de conocimiento experto. De esta forma, se podrían emplear distintos agentes especializados manejando diferentes conjuntos de reglas.
• Complementa el uso de conocimiento experto en alternativas basadas en hardware o en renderizado paralelo.

Optimización mediante Hardware

Una alternativa para reducir el tiempo de renderizado consiste en realizar optimizaciones particulares mediante hardware. En esta línea de investigación existen diferentes aproximaciones; algunos métodos utilizan GPUs (Graphics Processing Units) programables como sistemas de paralelización masiva. De esta forma se dispone de potentes procesadores para la ejecución en paralelo de diferentes fragmentos de código de un trazador de rayos.

El uso de GPUs programables superan a las CPUs (Central Processing Unit) de una estación de trabajo estándar en un factor de siete (I. Buck, T. Foley, D. Horn, J. Sugerman, K.Fatahalian, M. Houston, P. Hanrahan., 2004). El uso de la CPU en  conjunción con la GPU requiere nuevos paradigmas y alternativas a las (R. Ra jagopalan, D. Goswami, S.P. Mudur., 2005) muestra el uso de un GPU para renderizar imágenes en tiempo real a partir de conjuntos de datos complejos, los cuales requieren tareas de cómputo de gran complejidad.
Existen algunos motores de render diseñados específicamente para ser utilizados con aceleración GPU, tales como Parthenon Renderer, el cual es un sistema de render de iluminación global que hace uso de la potencia de cálculo conjunto de las CPUs y GPUs instaladas. (Hachisuka., 2005) o el motor de render Gelato® que trabaja con tarjetas gráficas NVIDIA®, es un renderizador offline (no de tiempo real) acelerado por la GPU que se diseñó inicialmente para crear efectos visuales y de animación 3D para películas, pero también constituye una potente herramienta para numerosos sectores industriales, entre ellos, los del cine y la televisión, el diseño CAD, la arquitectura o las artes gráficas. (NVIDIA, 2011).