Simulaciones físicas

Para la asignatura de Animación Avanzada, realicé varias simulaciones físicas en C++ con Visual Studio, utilizando distintos métodos:

• Masa-muelle y ODEs (ecuaciones diferenciales ordinarias):

• Sólidos articulados:

• Simulador de fluidos:

Shaders

En la entrada anterior expuse algunas imágenes de texturas procedurales programadas en CPU. Hoy pondré varios enlaces de shaders, algunos también de texturas procedurales pero esta vez programadas en GPU.

Todos estos shaders los he hecho con Jessica Mejías para la asignatura de Procesadores Gráficos y Aplicaciones en Tiempo Real.

El primero es un shader que hicimos para San Valentín. Era el primer shader que hacíamos, y lo cierto es que me encantó la experiencia. Estuvimos experimentando con colores hasta que decidimos hacerlo en tonos rojizos/rosados y azulados, para hacer el contraste entre frío y calor. Lo llamamos San Shadertín ;)

Después, tuvimos que hacer un shader que mostrara una esfera con teselas del estilo de Gaudí. Para este trabajo, hicimos varios shaders. En primer lugar, conseguimos crear unas teselas que nos gustaban, que cambian de forma y color con el tiempo:

Después creamos otro con apariencia más "celular", que podríamos utilizar más adelante para otra práctica de otra asignatura para crear la transformación caótica de una vena, cuya idea inicial era una especie de virus totalmente surrealista.

Después, creamos el shader de la esfera con las teselas, metiendo un mar con "teselas" celulares para hacer como cáusticas. Hay que decir que en este vídeo no habíamos conseguido todavía que la textura de la esfera fuera seamless (sin costuras), pero ese mismo día, más tarde, lo conseguimos y nos dio tiempo a entregarlo arreglado!

Por último, creamos un vídeo recopilatorio con los shaders que habíamos hecho, con diferentes colores, diferentes transformaciones, arena en vez de mar, degradados... hasta hicimos algo parecido a un terremoto:

Texturas procedurales (CPU)

Programar texturas procedurales es algo que, sorprendentemente, me ha gustado mucho. Las primeras las programé en CPU, mapas de ruido de Perlin y celular:

Para el mapa de ruido de Perlin, se obtienen varios resultados duplicando varias veces el número de particiones (de 2 a 256) y después se interpolan todos ellos para conseguir el resultado final:

Una vez obtenido el mapa de ruido de Perlin, programar el celular fue bastante simple, y experimentando se pueden obtener curiosos resultados:

Juntando mapa de Perlin con celular:

Todas las texturas obtenidas son seamless (sin costuras).

Las texturas procedurales progamadas en GPU (shaders) las mostraré en la siguiente entrada.

Multirresolución

Olvidaba comentar una de las prácticas que más me ha gustado (y costado) del primer cuatrimestre. El trabajo era totalmente libre, pero tenía que ser algo sobre multirresolución, así que varios alumnos decidimos experimentar con algoritmos de multirresolución. Yo, en particular, con colapso de facetas y de aristas.

• Colapso de facetas:

El algoritmo que desarrollé calcula el área media de todas las facetas de la malla, y colapsa todas aquellas facetas cuya área sea menor que el doble del valor del área media. Pero tiene un gran inconveniente: sólo sirve para mallas en las que sus facetas estén agrupadas de 4 en 4 de la siguiente forma:

Para mallas de este estilo, obtenemos los resultados deseados:

Pero habría que extender el algoritmo para mallas con facetas agrupadas de diferentes formas:

• Colapso de aristas (1):

El algoritmo que desarrollé selecciona la menor arista de la malla, elimina uno de sus vértices, junto con todos los triángulos que lo contienen y retriangula el agujero; todos los triángulos que contenían el vértice eliminado pasan a contener el otro vértice de la arista colapsada:

Crea una segunda malla (malla simplificada que se va construyendo a partir de la original). Encuentra la arista más corta, selecciona el vértice a a eliminar y guarda en una lista todos sus vértices vecinos menos el vértice b que lo va a reemplazar. Elimina los vértices repetidos de la lista y los ordena de forma que cada uno sea vecino del anterior (formando el borde del agujero). Añade los nuevos triángulos (que taparían el agujero), formados por el vértice b y todos los pares de vértices consecutivos de la lista, así como todos los triángulos que no contienen el vértice a eliminado. Añade todos los vértices y elimina los no referenciados (el vértice a).

Da buenos resultados, pero es poco eficiente (tiene alto coste computacional):

• Colapso de aristas (2):

Implementé un segundo algoritmo de colapso de aristas, mucho más eficiente. Funciona para cualquier número de iteraciones y para cualquier malla. Selecciona la arista a colapsar (según el criterio de selección elegido), formada por los vértices a y b. Para cada triángulo t: Si t contiene a a y a b, se elimina el triángulo t. Si t contiene a a pero no a b, sustituye a por b en el triángulo t.

Comparando distintos criterios de selección de arista:

• Colapso de aristas (3):

Por último, desarrollé un tercer algoritmo de colapso de aristas más eficiente (a la tercera va la vencida), que tarda menos tiempo en simplificar una malla. Crea una lista de aristas a colapsar de una sola vez en lugar de colapsar una arista en cada iteración. Calcula el área media de todos los triángulos de la malla, y selecciona para colapsar toda arista que sea la menor de las aristas de cada triángulo que tenga menor área que el área media. Puede simplificar mallas mucho mayores mucho más rápido.

Otras prácticas del primer cuatrimestre

De nuevo ha pasado más de un mes desde la última entrada. Este segundo cuatrimestre está siendo demencial. Si algún futuro alumno del Máster me lee, que no se confíe. No dejan de repetirte que el segundo cuatrimestre está muy sobrecargado de trabajo, pero piensas "no será para tanto", y luego te pasas los fines de semana trabajando, sin dormir. Pero bueno, poco a poco van saliendo cosas chulas, así que merece la pena =D

Todavía hay alguna práctica del primer cuatrimestre que no he comentado aquí:

- Para Realidad Virtual e Interacción, 3 compañeros y yo diseñamos un simulador de escenarios virtuales con Realidad Aumentada y guantes hápticos para que el usuario pudiera visitar lugares ficticios (como los escenarios de sus películas o series favoritas) o reales (como ruinas y otros lugares históricos). Con el simulador, se podría ir a Nueva Zelanda a visitar la Comarca, recorrer un templo romano e incluso dar la mano al mismo Napoleón.

- Para la misma asignatura, también había que hacer un trabajo sobre usabilidad, eligiendo como ejemplo el software que quisiéramos; en mi caso, elegí el videojuego Heroes of the Storm (de Blizzard, que en ese momento estaba en fase alfa (a la que yo tenía acceso), gracias a lo que pude encontrar algún pequeño defecto de usabilidad. Así que busqué unos principios de usabilidad específicos para videojuegos. Pero quise ir más allá, y encontré también unos principios de usabilidad específicos para videojuegos online multijugador (MMO). No voy a comentar aquí más detalles, pero por si alguien quiere echarle un vistazo, los autores de estos principios son David Pinelle, Tadeusz Stach y Carl Gutwin.

- Para Modelado y Comportamiento de Personajes, he realizado cinco pequeños vídeos para mostrar los 12 principios de la animación, con un modelo de personaje bastante peculiar: un monstruo con forma de bola con una gran boca, brazos y patas, y con una antena con un ojo. Cuando tenga más tiempo, haré un pequeño montaje y lo subiré a youtube.

- También realizamos dos compañeras y yo una escena en OpenGL con iluminación de Phong, pero lo que debería ser un cubo rotando, en realidad mostraba un folio. No pudimos arreglarlo a tiempo, así que intentaremos mejorarlo (si nos da tiempo) para Junio.

Estos días, gracias a Rendering Avanzado, me he enganchado a la creación de texturas procedurales. Intentaré poner pronto algunos ejemplos! =D

Juegos de varias asignaturas

Hace más de un mes que no escribo ninguna entrada a causa de los exámenes y los trabajos de clase... pero tanto trabajo ha merecido la pena. He hecho varios juegos para prácticas de algunas asignaturas.

Para la asignatura de Animación por Computador, he hecho un pequeño juego de tipo runner con mi gata Sally como protagonista. Tiene un "modo normal", con un escenario relativamente corto para aprender a jugar, y un "modo infinito" donde los escenarios se van generando de forma aleatoria, y se van eliminando una vez son sobrepasados.

Para Fundamentos Matemáticos y Físicos para Informática Gráfica, he hecho dos prácticas:


1. Tiro parabólico: Aproveché esta práctica para hacer un pequeño minijuego en el que, con una catapulta, hay que lanzar proyectiles a unos orcos en el Abismo de Helm (el Señor de los Anillos). Se pueden cambiar la dirección, el ángulo y la velocidad del lanzamiento.

2. Masa-muelle: Aquí me inspiré en la típica caja sorpresa de la que sale un muelle con un payaso. Se pueden cambiar la posición y velocidad iniciales, la masa del objeto y el coeficiente del muelle.

Para Modelado y Comportamiento de Personajes, mi compañera Jessica y yo hicimos un minijuego en el que unos personajes se persiguen y huyen unos de otros. Para la inteligencia artificial, utilizamos la herramienta RAIN.

PFM: Traducción de Java a C#

Una vez entendido su funcionamiento (y aprovechando las vacaciones), he empezado con la traducción del código, de Java a C#, empezando por la clase EEPEngine. A partir de esa clase, continué de forma fluida, introduciendo las clases (y métodos) que el propio Unity me iba avisando que necesitaban las demás clases. Así, continué hasta que Unity ya no me informó de ningún error, y ya tenía la siguiente jerarquía de clases:

Sin embargo, algunas clases estaban vacías. Así que continué completando todas las clases, y añadiendo más clases que se necesitaban, hasta la jerarquía de clases que tengo ahora mismo:

La traducción de Java a C# fue bastante sencilla. Los cambio más significativos son los siguientes:

• El código original en Java utilizaba ArrayList. Yo en C# he usado List, porque he leído en los foros de Unity que es más útil y más cómodo, sobre todo porque le especificas el tipo de la lista, mientras que con ArrayList (en C#) no. Además, ArrayList en C# también puede generar otros problemas.
• He utilizado float en vez de double (utilizado en el código original), recomendado por mi tutor porque todo el motor de Unity trabaja con float, y al utilizar Mathf (que necesita floats), al hacer cast se pierde precisión.
• El código original utiliza HashMap. Yo he utilizado un equivalente en C#, Dictionary, al que se le especifica el tipo de Key y de Value, al igual que con HashMap (con Hashtable, sin embargo, no). Recorrer una colección de tipo Dictionary, es sencillo, utilizando: foreach (KeyValuePair p in ...).
• La última diferencia es que en C# no hay que declarar las excepciones que lanza un método; las extrae directamente del cuerpo del método.