R.E.D.:Historia de una demo

r3D

1. INTRODUCCIÓN

Se contaba con la tecnología básica(Epopeia Demosystem) estable para realizar una producción de este estilo, desarrollada en el último año. El sistema gráfico, a cargo de OpenGl, dándonos la posibilidad de hacer la producción multiplataforma, un lenguaje script para la sincronización de eventos en el tiempo con la música(reproducida mediante fmod), un motor 3D para la carga de escenarios complejos, y un mecanismo de plugins mediante dll'sl para la programación de efectos que acompañan a las escenas. El diseño original de la demo se concibió en unos días, tras los cuales se fue modificando(casi por completo) para adaptarse a las limitaciones técnicas del medio y del tiempo con el que contábamos.

 

2. DESARROLLO

La demo, a partir de ahora R.E.D., seguía una pauta bastante sencilla, una sucesión de escenas 3D como base acompañadas de efectos. El motor 3D se encarga de leer escenarios 3D de un fichero .3ds,antiguo formato de 3D STUDIO. A este, le acompaña otro fichero con la descripción y definición de materiales asociados (transparencia, brillo, multitexturado, bump mapping... ). Posteriormente estas escenas 3D se cargan y orquestan mediante el lenguaje script parseado al iniciar la demo y que construye la estructura de datos necesaria para la ejecución y sincronismo correcto de los efectos/plugins. Este sistema script fue desarrollado para facilitar la tarea de diseño, evitando por parte del artista depender del coder continuamente y dando un enfoque más visual y fresco a la tarea de diseño. Su soporte de instancias de efectos, repetición de comandos en bucle y expresiones nos acerca lo mejor de los dos mundos. Cada efecto esta constituido como un objeto solido, encapsulado en una .dll. El propio motor 3d(Fantasy) es considerado por el sistema como un efecto más(y por tanto una dll). La interacción entre distintos efectos, de ser necesaria, se produce mediante el retorno de valores, pudiendo definir tipos nuevos a usar por los efectos, como veremos más adelante.

 

3. LABORATORIO 1

La primera escena diseñada fue la del laboratorio. Se quería conseguir un aspecto limpio y cristalino (asociado comunmnete a los laboratorios), algo difícil de conseguir con los gráficos 3D en tiempo real. Para suavizar la estética de toda la demo y de este escenario en concreto, se optó por aplicar un filtro de postproducción mediante la técnica de render a textura y mip mapping, para dar un efecto de Glow al escenario. Todo el modelado y creación de cámaras se realizó en 3DSMAX. Como el soporte de jerarquías no funciona, hubo que crear un script que pusiera la información correcta de posicion y rotación a los objetos "separados"(en este caso de la centrifugadora de laboratorio) mediante un habil truco. El inconveniente de este método era el engorde del fichero, ya que obligaba literalmente a guardar un fotograma clave para cada objeto en cada frame. Por fortuna,las técnicas de compresión salvaron el obstáculo.

Laboratorio

Algo más complicada de elaborar fue la toma lateral, en la que vemos volar a una cápsula que ha salido disparada de la centrifugadora. Se pretendía dar un toque cinemático a esta cámara, ralentizando la velocidad de la escena y provocando un efecto de desenfoque de campo sobre el fondo del laboratorio. Para conseguir simular este efecto se optó por dividir en dos capas la escena. Por un lado el fondo de laboratorio con un cámara que descendiera parabólicamente y, en primer plano, la capsula rotando aún con el líquido rojo y la cámara quieta. Este líquido rojo fue simulado con una textura dinámica generada con ruido perlin noise animado y una paleta de colores rojos. A la capa de fondo se le aplicó un blur hardware mediante mipmapping. Consiste esencialmente en renderizar a una textura con mipmaps el fondo y mezclarlos con distintos pesos. Al reescalarlos y ser filtrados se generaba esa sensación de desenfoque (no exenta de artefactos no obstante). Una técnica sencilla pero limitada por los artefactos que provoca en la imagen

Capsula y fondo desenfocado

A medida que se la cápsula se acerca al suelo, la velocidad de la escena aumenta progresivamente, unida al valor de desenfoque de campo. Justo antes del momento de choque, cambiamos de plano, para observar la fragmentación del cristal y el esparcimiento del líquido que lleva consigo. Para conseguir simular la explosión, se siguieron varias etapas. La primera consistió en desarrollar un pequeño script para cortar el objeto capsula y líquido en trozos pseudoaleatorios. La siguiente fase era la simulación en sí misma de la fragmentación. Un proceso delicado por problemas de interprenetración. Se optó por separar la simulación en varias fases.Cristal, líquido y capsula y momento previo y posterior de la fractura. Esto mejoró mucho la simulación, pero no eliminó todos los artefactos, que se tuvieron que solventar animando a mano y jugando con algunos trozos del cristal/liquido. Mientras el liquido se esparce aparece el logo de la demo, junto con un tinte progresivo del fondo a blanco sincronizado con una spline, cuyo funcionamiento será descrito posteriormente.

 

4. TUNEL Y ORGANISMO

Tras esta serie de "flashes", nos adentramos directamente a lo que parece un tunel por el cual la cámara se desplaza. En realidad, la técnica que se siguió fue inversa y la cámara está quieta. Se usaron las llamadas que exponía el motor 3D al Epopeia para la animación de coordenadas UV de un objeto, y se animaron según una spline, proporcionada por otro efecto programado aparte (un efecto cuyo único cometido es evaluar splines generadas con una utilidad propia). Al margen, aparece una especie de organismo con tentáculos deformandose. Este organismo fue modelado en un escenario/archivo aparte. A traves del script se puso en escena por encima del tunel, y se le paso a un plugin deformador de malla el objeto del escenario 3D en cuestión, mediante el mecanismo de devolución de valores del epopeia. Por ejemplo

Deforma.SetMesh(tentaculo.GetScene(), "tent_obj" );

Indica con dos parámetros el método de la escena tentaculo que devuelve un objeto de tipo mundo, y el nombre de la mallaque la instancia del plugin Deforma usará para deformar. Este plugin a su vez dispone de varias funciones expuestas para definir la velocidad de la deformación, la frecuencia con la que sucede ésta etc.... Fueron animados también con un par de splines para provocar una aceleración sucesiva del movimiento de los tentáculos

Tunel y Tentáculo

De aquí pasamos a la siguiente escena mediante una transición circular, creada con una máscara en el Stencil Buffer y gracias al cual sabiamos que escena tocaba pintar en cada punto de la pantalla

 

5. CUEVA 1

Este escenario fue modelado en Lightwave|3D. De geometría y texturado sencillo, las dificultades vinieron de la mano de las pantallas animadas. Originalmente se pensó en simular estas pantallas mediante videos prerenderizados puestos como textura. Finalmente se apostó por usar técnicas de render a textura. Texturas que serían usadas por las pantallas de estos monitores. Así, para renderizar una imagen de este escenario se tenía que poner en pantalla cada escenario (escenas 3D sencillas), hacerle un render a textura, limpiar el Color Buffer, y repetir este proceso sucesivamente para cada escenario. Por último, se ponía en pantalla el escenario de la cueva, con las texturas renderizadas puestas en los planos de los monitores que contaban con estas (algunos simplemente tenían una textura blanca que el efecto glow se encargaba de embellecer). Todo este proceso se ejecutó en el script gracias al uso de un plugin que renderizaba en una textura asociada al subsistema gestor de texturas (a partir de ahora GLT) a través de un nombre identificativo. Este nombre era usado en la descripción de materiales del escenario Cueva en los materiales de los paneles "activos". La unificación del sistema de texturas para todos los procesos/plugins de la demo facilito la tarea de manipulación concurrente de una textura por parte de varios efectos. La escena termina en el interior de una pantalla, que muestra la siguiente escena, recurso explotado hasta la saciedad y que no podiamos plantearnos siquiera no repetir

 

Cueva con las pantallas

 

6. ARAÑA ELECTRÓNICA

La siguiente escena planteaba un par de puntos de dificultad. En el momento del desarrollo de la escena no se contaba de ningún plugin perfectamente encapsulado que manejara un sistema de partículas como tal, al menos no como era deseado. Se pretendía generar un sistema que envolviera en cierto modo al “objeto con garras”. A causa de la límitación de tiempo de los coders se tuvo que programar un script que exportase la información de un sistema de partículas generado en 3DS MAX. Esta solución, análoga a la del punto 3, provocó un aumento considerable de información. Para controlarlo, se le pasó al sistema de particulas con la información de animación ya guardada un key reducer para disminuir el número de muestras necesarias por cada partícula en el tiempo. Aparte, se redujo el número de partículas. Para intentar dar la ilusión de un número mayor de ellas, se aplicó un desenfoque de movimiento (motion blur) para que dieran una sensación más uniforme y compacta. La técnica usada para el motion blur consistía aproximadamente en poner encima del color buffer el frame anterior con determinada transparencia. Esto impedía limitar el efecto solo al sistema de partículas. Para salvar este bache, hubo que renderizar, de forma similar al punto 3, la escena en varias partes. Se renderizaba a una textura el sistema de partículas, se le aplicaba motion blur y se pegaba encima de la escena en modo additivo como textura. Esto permitó además añadir multiples copias con pequeñas variantes en la escala, para dara mas variedad al sistema a coste 0. El efecto del brillo(intento de "subsurface scattering") que avanza hasta el centro del objeto se obtuvo animando las coordenadas de mapeo de un objeto con la forma adecuada y la textura precisa. La velocidad de avance del mapeado uv está determinada por una función lineal en función del tiempo

Araña electrónica

 

7. CRÉDITOS

La parte más sencilla en apariencia de la R.E.D.. La imagen, pintada en photoshop, esta proyectada en un plano con varios segmentos horizontales y verticales a los que se le aplica una deformación sencilla de fluidos. Está deformación, sincronizada con la música, esta pregenerada mediante un programa propio que graba interactivamente las acciones(clicks y movimiento) del ratón sobre una imagen a determinadas muestras por segundo. El plugin posteriormente reproduce el fichero e interpreta las acciones en tiempo real. Para los créditos, se usaron texturas a las que se aplicó un blur por software, acelerado via MMX. La transición final está realizada a semejanza del tunel del punto 4, con otro patrón de máscara. De hecho, los distintos patrones de transición están engoblados en el mismo efecto/plugin

Créditos R.E.D.

 

9. CUEVA 2

 Volvemos a la cueva, nexo de las distintas partes de la demo. En esta ocasión se puede apreciar un “cerebro” en el centro de la cueva agitándose según una deformación turbulence. Los Halos que suben del cerebro son dos objetos con mapeado uv animado en distintas direcciones y una deformación aplicada a cada uno de los objetos para añadir algo de variabilidad a la textura. Inicialmente se quería hacer uso de una textura animada pero el tiempo se echó encima y la opción quedó descartada.Se repiten las mismas técnicas de render a textura para las pantallas que no requieren más explicación, y se pasa a la siguiente escena acercándose la cámara nuevamente a un monitor que nos la muestra

Cerebro

10. CALEIDOSCOPIO ORGANICO  

De una escena de prueba tecnológica, pasa a ser usada como parte de la demo por problemas de tiempo. El fondo, que simula de forma muy limitada el comportamiento de un caleidoscopio, esta creado mediante el uso de distintos planos con ejes de rotación equidistantes y dispuestos en varios planos radialmente y en capas, que se van mostrando sucesivamente. Esto consigue el efecto de variación cromática (cada capa posee un color distinto). Por otra parte, en primer plano contamos con un objeto que intenta parecerse a algún tipo de estructura organica. Se intentó simular cierta reflexión con el uso de mapas cúbicos aplicados al objeto, unido a una capa externa ("membrana") con transparencia añadida y deformación turbulence, muy similar a la del cerebro del punto 9

 

Caleidoscopio luminoso

 

11. GREETINGS

La zona de saludos se consiguió llevando a la última expresión la técnica ya comentada del render a textura. Cada escenario 3D constaba de dos palabras, capturadas en movimiento y puestas en cada monitor.

Greetings

 

12. REGRESIÓN

Un pasillo “infinito”, con iluminación global pregenerada e insertada en las texturas de las paredes, suelo y techo. El efecto que se trató de sugerir era el de regresión de un sueño o experiencia vivida. Para ello se usó la tecnica del radial blur(renderizar a textura el escenario, escalarlo a cierto tamaño, ponerlo en pantalla a cierta opacidad y repetir el proceso en cada frame). Algunos parametros clave de este efecto se sincronizaron con expresiones sinusoidales en script, para crear la sensación de borrosidad creciente y decreciente. Por encima, se aplico una deformación de onda a toda la imagen con la idea de potenciar la sensación de sueño. El escenario va perdiendo opacidad con el tiempo gracias a una función expuesta del motor 3D al epopeia y se deja entrever el fondo de imagen blanco

Pasillo Regresión

 

13. LABORATORIO 2

El escenario blanco desemboca en una toma cercana de la capsula inicial, ya completamente destruida y con el líquido (rojo) esparcido a lo largo del suelo. La disposición de los componentes de la capsula fue realizada de forma manual, a pesar de que las dinámicas del inicio de la demo de la fragmentación de la cápsula fueran reales, para dar un toque más personal a la escena. Para simular el material del líquido de la sangre, se recurrió a mezclar varias capas de textura (una de ellas un ruido perlin animado) con transparencia variable para dar la sensación de transparencia y densidad adecuadas sobre el suelo ajedrezado del laboratorio. La camara se eleva hasta mostrar todo el frontal del laboratorio y...

Laboratorio Final

 

14. LOGO rgba

La última escena se quería realizar mediante código en tiempo real, pero de nuevo por problemas de tiempo se tuvo que descartar. Animar los centenares de objetos a mano era una tarea inhumana. Se hizo imprescindible por tanto programar otro script que realizara el trabajo. Constaba de varias fases. En la primera etapa se indicaba la geometría del objeto a usar y se "voxelizaba" para construir la estructura tridimensional correcta y la creación de objetos(en este caso cubos) a lo largo de este espacio, cuidando de dejar huecos suficientes por los que se pudieran mover más adelante. Una vez concluida esta fase, mediante un automata finito se generaba la animación de los distintos cubos con distintos comportamientos segun los cuales realizaban distintos movimientos para crear la suficiente variabilidad en el sistema. Se implementó además la lógica necesaria para evitar los choques entre objetos. Tras muchas pruebas, se dió con un movimiento relativamente natural de las cajas, y se exportó la animación generada (al igual que en las sucesivas veces que se realizó este tipo de proceso, el resultado fue de gran tamaño y la compresión salvó de nuevo el pellejo). Una vez la cámara se aleja y muestra el logo formado por las cajas, tras un fade a negro la demo termina junto una voz distorsionada mediante vocoder

 

15. MÚSICA

El apartado musical, abiertamente criticado por las masas :), fue creado antes de que la demo tuviera base real en psycle. Está basada en el diseño original de la demo, y tras la modificación de este(el mismo domingo 27 de Julio) apenas fue modificada. Se pensó en reconstruir desde 0 la base musical, ya con reason, pero se optó por no cambiar de forma tan radical la demo.

 

16. CONCLUSIONES

La finalización de la demo fue bastante tediosa. El proceso de coordinación del proyecto fue complicado, en gran parte por la distancia que separa a los miembros. No obstante, gracias a la experiencia de todo el grupo, se resolvieron todas las dificultades técnicas y logísticas, "terminandose" justo a tiempo y presentándose en la BCN PARTY donde consiguió el primer puesto en su categoría.

En perspectiva, lo que inicialmente surgio un mes antes de la euskal party 11 como una demo rápida se convirtió en un proyecto "interminable",complejo, y que difería bastante de la idea inicial y de la imagen que se quería dar. Tras fracasar la idea original de demo para la euskal, se rediseño la demo con la idea de terminarla en las 2 semanas siguientes. Del mismo modo, por distintos motivos, esta "deadline" también fracasó y la demo quedo en un punto muerto. Se empezaba a temer por la finalización de la demo. Cercanas las fechas de la Bcn, y viendo que se podría conseguir después de todo presentar algo cercano al guión modificado, se hizo el esfuerzo de retomar el trabajo y poco a poco se llevó el script a un punto cercano. Los días previos a la celebración de la party fueron cruciales. Después de todo se presentó, con algunos problemas que la versión final intenta arreglar, muchos meses después. El resultado final resultó ser menos pretencioso que el guión modificado, el cual consideraba la explosión del cerebro, o la inclusión de un organismo andante en el pasillo final, entre otros...

Podeis insertar comentarios,insultos, en el foro(no es necesario registro):

No fueron dañados animales en el desarrollo de esta demo