Tenemos una asignatura en el máster cuyo objetivo es la realización de un juego completo. Si esto ya de por si parece difícil, además lo tenemos que tener listo y jugable antes del 13 de abril, ahí es na.
Parece que hemos empezado con fuerza y buen pie, con muchas ganas y un montón de ideas. Ya os hablaré en más detalle del desarrollo del juego que estamos llevando a cabo. Pretendo utilizar este blog para contar nuestras aventuras y desventuras a lo largo del duro proceso de parir el primer videojuego de nuestras vidas.
De momento, damas y caballeros, os presento a Wild Vector Games!
Como trabajo para la asignatura de Rendering Avanzado del máster nos han propuesto encontrar una demo con un efecto túnel y comentarla en profundidad. Cuando uno piensa un poco en la demoscene y los concursos de demos se imagina a los jóvenes de los años 90 exprimiendo al máximo sus equipos para obtener efectos sonoros y visuales muy sorprendentes, todo ello en ficheros de 64k.
Sin embargo, si uno echa un vistazo a las demo parties actuales descubrirá que en esencia se sigue haciendo lo mismo, pero casi 20 años después con equipos tremendamente más potentes (y en la mayoría de los casos con ficheros de más de 64k). Un ejemplo de ello son las demos presentadas en Breakpoint, importante demo party que durante 8 años consecutivos ha tenido lugar en Alemania. Por desgracia el Breakpoint 2010 ha sido el último de su historia, dejando el testigo para que lo recoja una nueva generación.
Pero, ¿De qué es capaz la gente de la demoscene con las máquinas de nuestros tiempos?
La demo escogida para analizar es PC-04 Partycle, segunda demo desarrollada por Panda Cube y que obtuvo el tercer puesto en la categoría PC Demo del Breakpoint 2010, en abril del año pasado. Según indican en el “readme” adjunto, el desarrollo se realizó en 4 semanas. Se puede obtener aquí y tiene un tamaño total de 125MB, una vez descomprimido. Si tienes un Windows y DirectX 10, puedes ejecutarlo.
Panda Cube es un equipo de desarrollo de demos alemán, cuyo principal contribuidor es Gregor Ehrenstein. Como indica en su web personal su carrera profesional empezó en Spinor, desarrolladores del motor Shark 3D, utilizado uno de mis juegos de PC favoritos Dreamfall: The Longest Journey. Actualmente trabaja en Massive Entertainment , creadores de World in Conflict. He re reconocer que la elección de esta demo para analizar es más por cuestiones sentimentales que técnicas.
Tal y como se indica en el enlace, la máquina tulizada para obtener los FPS que se muestra en la esquina superior derecha es un Core i7 860 con una Radeon 5840. La demo hace uso de DirectX 10 y el entorno de desarrollo utilizado es Visual Studio 2008.
En el minuto 0:43 tenemos el comienzo del primer efecto túnel. En lugar de tratarse de un túnel cerrado, el efecto se compone de un entramado de raíces en un espacio abierto. La cámara se mueve a través de este entramado acompañada de un foco de luz que produce diferentes efectos de sombreado sobre las raíces. En el ambiente también flotan distintas partículas y cubos.
A partir del minuto 1:16 da comienzo otro efecto túnel (con un sospechoso parecido a cierta práctica que ciertos alumnos tienen que llevar acabo). Las paredes del túnel están texturizadas asemejando el interior de una mina, con partes metálicas y partes de roca. Una vez más el viaje de la cámara está acompañado por un foco de luz que se proyecta sobre el las paredes del tune (asi como los cubos que siguen en el ambiente).
Urgando entre los distintos elementos que acompañan el ejecutable, sobre todo en lo referente a los efectos túneles presentes, nos podemos encontrar:
Los caminos de las cámaras a lo largo de la escena: Definidos mediante ficheros de texto .cam y .int. Por lo que se puede ver la interpolación entre las posiciones de la cámara se realizan con un B-Spline cúbico. La interpolación del camino del FOV se hace de forma lineal y finalmente la orientación se interpola mediante cuaternios.
Todos los elementos de la escena están definidos mediante ficheros Wavefront obj. La parte más grande de túnel tiene un total de 13306 polígonos. Las rocas que se aprecian en el túnel son otro modelo con 604 polígonos.
En el apartado de texturas se utiliza un mapa de normales para las paredes del túnel, en forma de png de tamaño 4096x2048. También hay otro png que parece un mapa especular y distintos ficheros dds que contienen información sobre texturas para DirectX que pueden ser mapas de entorno, de iluminación, mipmaps, etc.
Existe otra carpeta con numerosos shaders, en formato fxo ya preparados para DirectX, que dan lugar a los efectos visuales como por ejemplo el glowing de la parte final de la demo.
Quizás no sea la demo más espectacular que se puede encontrar, pero resulta muy interesante para ser el segundo intento de este grupo, y desde luego un tercer premio es un gran logro para ser un desarrollo de 4 semanas.
Por curiosidad he probado a ejecutar la demo en mi portátil, con una Mobile Intel 965 Express, es decir, una GPU de nulas prestaciones. En primer lugar me ha sorprendido que arranque y en segundo lugar que se mueva a unos 10 FPS.
Desde luego no es de extrañar que la gente de la demoscene acabe en buenos puestos de las empresas más prestigiosas de gráficos 3D y videojuegos.
Hace poco hemos empezado a ver en la asignatura de PGATR del Master de Informática Gráfica, Juegos y Realidad Virtual como hoy en días es más que posible utilizar GPUs para aplicaciones de propósito general. A raíz de ello se ha propuesto un pequeño trabajo de investigación sobre arquitecturas paralelas y GPUs. Trasteando un poco por la red he dado con los servicios AWS de Amazon, que dan acceso por un módico precio a grandes capacidades de cálculo, lo que me ha llevado a escribir las siguientes reflexiones.
¿Merece la pena usar GPGPUs en las arquitecturas masivamente paralelas?
En la carrera de la supercomputación, se ha llegado a un punto en el que es imposible concebir una mayor capacidad de cálculo sin estructuras altamente paralelizables. Tanto los elementos hardware, como los elementos software se piensan de tal forma que hagan uso del paradigma de parallel computing. La prueba evidente de ello es que desde el 2005 no se ha creado ningún nuevo supercomputador que no tenga una arquitectura de procesamiento masivamente paralelo. El diseño de las nuevas GPGPU, diseñadas especialmente pará ser de propósito general y no solo para resolver de forma eficiente aplicaciones que ataquen al cauce gráfico, favorecen este tipo de estructuras paralelas.
Si echamos un vistazo en el top500existen tres supercomputadores entre los 10 primeros que implementan una arquitectura basada en GPGPUs, dos de ellos en China (Tianhe-1A (1º) y Nebulae(3º)) y otro en Japon (Tsubame 2.0 (4º)). El más reciente de ellos, Tianhe-1A, entró en servicio en octubre de 2010 como una revisión de una arquitectura anterior y hasta hoy en día permanece como la supercomputadora más rápida del mundo, con una capacidad de 2,5 petaflops (y picos de hasta 5 petaflops). Su arquitectura se base en un conjunto de 14336 CPU servidores Xeon X5670 y 7168 GPGPUs Nvidia Tesla M2050. El coste de semejante criatura asciende a 88 millones de dólares, además de un mantenimiento de otros 20 millones, debido principalmente a la factura de la luz ( su consumo alcanza la cifra de 4,04 megawatts).
Tianhe-1A,National Supercomputer Center, Tianjin
Parece evidente que la potencia de las arquitecutas basadas en una combinación de CPUs y GPUs resulta superior a las meramente basadas en CPUs. Esto no se debe exclusivamente al uso de procesadores más pontentes, sino a la mejora que se obtiene en rendimiento, introduciendo el consumo en la ecuación. Nvidia clama al cielo que una arquitectura basada en sus tarjetas gráficas como Tianhhe-1A es capaz de reducir el cunsumo de una máquina de 2,5 petaflops basada solo en CPUs de 12 megawatts a los 4,04 megawatts de Tianhe-1A.
Por desgracia, debido al alto coste de estos supercomputadores (en instalación, hardware y sobre todo consumo), esta gran potencia de cálculo resulta inaccesible para la mayoría de desarrolladores. ¿Qué podemos hacer si necesitamos grandes capacidades de computo?
Amazon Elastic Compute Cloud (EC2)
En la década de los 70, cuando un alumno de una carrera informática necesitaba acceso al ordenador de la universidad para realizar algún cómputo, debía solicitar acceso y tenía un tiempo asignado para ejecutar sus programas. Todo esto desapareció un poco con la introducción de los ordenadores personales en la década de los 80 y su boom en los 90s. A medida que aumentaban en potencia estos PCs, disminuía la necesidad de acceder a grandes máquinas para ejecutar los desarrollos.
Hoy en día los desarrolladores manejan en muchos casos aplicaciones que requieren una gran potencia de cálculo, sobre todo en el mundo de la informática gráfica. A parte de las grandes corporaciones (como las farmacéuticas) que si tienen acceso a los grandes supercomputadores y que en muchos casos también son patronos de sus desarrollos, existen incontables pequeños desarrolladores que quizás no requieran de tanta potencia de cálculo pero que no disponen de las arquitecturas adecuadas para ejecutar sus aplicaciones.
Por suerte, existen iniciativas que ponen al alcance de todos grandes capacidades de cómputo. Un buen ejemplo de ello son los servicios Elastic Compute Cloud de Amazon. La idea es simple: utilizar el concepto de nube para poner al servicio del usuario la capacidad exacta de cómputo que desee.
Recientemente Amazon ha actualizado este servicio para incluir en sus arquitecturas HPC clusters con GPGPUs. Cada cluster GPU instance, como Amazon lo llama, se compone los siguientes elementos:
22 GB de memoria
33.5 EC2 Compute Units (2 x Intel Xeon X5570, quad-core “Nehalem” architecture)
2xNvidia Tesla “Fermi” M2050 (tal y como estais pensando, como las del Tianhe-1A)
1690 GB de almacenamiento local
Plataforma 64-bits
10 Gigabit Ethernet
Lo más característico de la forma en la que Amazon define sus clusters quizás sea el concepto de unidad de cálculo o compute unit. Una unidad de cálculo es el equivalente a un Opteron o Xeon de 1.0-1.2 Ghz de 2007. De esta forma se puede mantener la capacidad de las CPUs de sus clústeres con independencia del hardware utilizado.
Amazon estima que la capacidad de sus clústeres GPGPU puede llegar a 1 teraflop. Lo increíble de este sistema es que el acceso a un clúster de estas características cuesta 2,10$ por hora, más que asequible para cualquier desarrollador que necesite semejantes capacidades de cálculo. En caso de requerir menos potencia, existen otras soluciones de menor coste. En teoría, alquilar 32 de estos nodos nos metería en el top500 por un coste de 67,2$ por hora (siempre que Amazon cuente con la infrastructura adecuada claro).
Hagamos ahora un pequeño ejercicio comparativo:
El coste de una máquina como Tianhe-1 es de 80 millones de dolares con un coste adicional de 20 millones al año, y una potencia de 2,5 petaflops. Supongamos que la vida de esta máquina pueda ser de 50 años. Haciendo unos pocos de cálculos podemos sacar que el coste por hora y por teraflop (como el de un cluster de Amazon) de esta máquina es de 1,16$.
Evidentemente es una aproximación muy grosera, pues no tiene en cuenta los costes y perdidas por escalabilidad de la arquitectura (por no mencionar que Amazon no tiene una red tan potente como Tianhe-1), pero nos da una idea de la relación entre los costes de ambas arquitecturas por hora y teraflop. Es lógico que comprar toda la arquitectura resulta más económico a largo plazo, pero desde luego no se ajusta a nuestras necesidades la mayoría de las veces. En España se suele decir que “alquilar es tirar el dinero”, pero a mí me gusta más pensar en que es pagar por lo que realmente se necesita.
Si alguno se quiere aventurar en el maravilloso mundo de los Amazon Web Services, su blog oficial es un buen punto de inicio. Para ir empezando, aquí tenéis un video de cómo montar un HPC en sus servidores:
Siempre he pensado que existen dos tipos de personas el mundo: Los que tiene iniciativa y los que se dejan llevar, o como un amigo me dijo hace tiempo los pastores y los borregos.
La mala noticia es que la inmensa mayoría forma parte del grupo de los borregos. La buena es que cualquier borrego se puede convertir en pastor con un poco de empeño. Hasta hace poco yo me contaba en lo grupo de los borregos, pero he decido pegar el salto y ver que se cuece cuando eres un pastor.
Para empezar, lo primero que tienes que hacer, es no esperar a que nadie te diga lo que tienes que hacer y lanzarte a la piscina con tus propias ideas y proyectos. Esto es más difícil de lo que parece: como nadie te dice lo que tienes que hacer tampoco tienes seguridad y garantía de éxito. La ventaja de ser borrego es precisamente que si tienes esa seguridad. La desventaja: que es aburrido.
En segundo lugar debes buscar algo que realmente te guste y aferrarte a ello llueva, nieve o te caigan rayos en la cabeza. Otro buen amigo (por suerte de estos no me faltan) me dijo que la mejor forma de ser bueno en algo es dedicarte a ello en cuerpo y alma. En mi caso el mundo en el que he descubierto que me encuentro muy cómodo es la informática gráfica y sus derivados. Llego algo tarde, pero creo que me puedo poner a buen nivel con algo de esfuerzo.
Pues bien, el inicio de este blog es la conclusión lógica (o no) de estos dos pensamientos. Pretendo que sea un lugar en el que pueda reflejar todas las locuras que se me ocurran durante mi formación y vida laboral, sobre todo en lo que se refiere a la informática gráfica.
Espero que también le resulte entretenido o incluso útil a otras personas.
