Túnel: entrar, o no entrar, esa es la cuestión

El efecto túnel, o similares a este, han sido utilizados durante mucho tiempo en la demoscene. Ya desde el año 1997, el grupo asphyxia tenían algunas demos impresionantes para la tecnología y desarrollo de la época que utilizaban este efecto.

Antes de entrar a tratar el tema, quería dejar aquí dos efectos túnel que creo que son interesantes:

El mejor efecto túnel de la historia (sin discusión posible XD):

JavaScript, lo que terminaremos teniendo todos: http://www.p01.org/releases/256b_tunnex/

Y después de las bromas y festividades, pasemos al tema.

Inferno (Spöntz)

Para la demo de túnel he elegido «Inferno» del grupo  Spöntz por tres razones:

1. No hay muchas demos para mac, y esta es una de ellas, y se merece que se la reconozca por ello.
2. Detrás de esta demo hay una historia de las que no son agradables.
3. Es un grupo patrio, no todo va a estar hecho fuera.

Inferno fue publicada en noviembre de 2002, y fue presentado en la «bcnparty’10» (10 en binario: 2) y tiene un extenso post sobre cómo se hizo y qué técnicas se utilizaron, así como un diario del proceso de programación. La idea de esta demo está integrada en hacer un entorno que le facilite al grupo la creación de otras demos. El por ello que esta demo tiene gran influencia en ese entorno que están diseñando, y la programación del efecto túnel original se encuentra desarrollada aquí.

En su web tienen otras demos realizadas posteriormente que muestran un mayor grado de refinamiento, donde también existen túneles, que se combinan en ocasiones con sistemas de partículas y otros efectos, pero es en esta demo donde se deciden a introducir el efecto túnel en su motor.

Existen dos efectos túnel en la demo: El primero presenta un túnel con llamas en movimiento, y con el final del túnel (la boca) también en movimiento. Como características destacables cabe indicar que las texturas utilizadas dan una sensación de animación independiente del movimiento del propio túnel, pese a que son estáticas. Como principal problema hay que destacar que este efecto no da sensación de profundidad: es como si el túnel fuese muy pequeño, aunque sí da sensación de velocidad, por lo que probablemente la elección de la visualización del mismo se pudiese haber realizado de otro modo.

En el segundo efecto túnel, los desarrolladores han optado por intentar hacer un túnel con protuberancias (bumping), dando la impresión de ser un túnel orgánico (¿un esófago?), de manera que las texturas dan la impresión de que efectivamente tienen relieve. Este efecto túnel lo presentan desde dos ángulos de vista distintos: cayendo por el tunel, y con una vista lateral, con la cara de un dummie a la derecha de la imagen que da la impresión de ir cayendo por el tunel con el viento moviéndole los labios por la velocidad (lo que refuerza la sensación de velocidad percibida).

Los participantes en esta demo fueron:

Programación: merlucin y kolian

Modelos 3D: merlucin

Música y sonidos: merlucin

Gráficos: merlucin, angelss y ximac

Cajón desastre

Y ahora algo que me interesa bastante (mucho/muchísimo/muchisisísimo): ver cómo evoluciona la scene también en el mundo de internet y los navegadores: http://www.dasprinzip.com/pExamples/p121_2.html (Flash, textura procedural, precálculo de distancias y ángulos, sin soporte hardware)

Y este otro con soporte hardware pero tirando de estándares (el navegador tiene que tener WebGL activado): http://cubicvr.org/CubicVR.js/bd3/BeatDetektor4HD.html

Una demo/tutorial muy curiosa es esta otra: http://membres.multimania.fr/amycoders/tutorials/raytunnel.html, donde se hace una demo en 512 bytes, utilizando una técnica de raycasting y programado en ensamblador. La traza de rayos se realiza sobre una malla de 32×32 posiciones, y después se crean bloques más grandes para poder dar una imagen de 256×256 píxels.

Cómo no desperdiciar recursos: BOINC

Hay veces en la vida que las cosas salen solas, caen por su propio peso…
Ese es el caso de las aplicaciones masivamente paralelas y la computación de escritorio.

Introducción

Durante muchos años, debido a la manera en la que iba creciendo el rendimiento de los sistemas de cómputo, las aplicaciones masivamente paralelas han estado condenadas a ejecutarse en centros de cálculo relativamente cerrados y que disponían de una capacidad de cómputo limitada (no porque ésta fuese pequeña, sino porque había un límite de presupuesto/máquinas/energía/tecnología o una combinación de estos factores).

Por naturaleza, los problemas altamente paralelizables, debido a su bajo acoplamiento, disfrutan de unas características que les hacen posible ejecutarse en lotes, con pocos o ningún problema de dependencias de datos dentro de cada lote de trabajo.

Habitualmente estos problemas se dividen en tres grandes fases: creación del lote de trabajo, cómputo del lote de trabajo, integración de los resultados del lote para conseguir un resultado global. Cuando estos problemas se pueden diseñar de manera que el cómputo del lote de trabajo sea especialmente importante en cuanto a tiempo de cálculo, estos problemas son especialmente paralelizables y se benefician al máximo de la disponibilidad de unidades de cálculo.

El gran avance de la computación doméstica, con ordenadores tremendamente potentes (cuando empecé a programar tenía un 8088 a 4,77Mhz, con un disco duro de 20Mb, hoy en mi bolsillo llevo un procesador ARM9 de 1000Mhz y una memoria de 16000Mb, y en un ordenador de escritorio hay más, mucho más), que parecen centros de cálculo de hace 20 años, se abre un nuevo mundo de posibilidades para las aplicaciones masivamente paralelas.

El concepto básico aquí es tener un centro de datos donde se realizan principalmente la primera fase de creación de lotes de trabajo y la última fase de integración de resultados, dejando a máquinas más modestas (nuestros PC de sobremesa, la PS3, incluso los teléfonos móviles) el trabajo de procesar los distintos lotes de trabajo y devolver los resultados al centro de datos cuando se complete la tarea asignada.

Siguiendo esta filosofía han aparecido multitud de proyectos, siendo uno de los primeros en adquirir renombre el de la rotura del algoritmo de encriptación DES3. Para romper el algoritmo DES, la EFF desarrolló un ordenador especial llamado DES Cracker. Dado que el algoritmo DES3 aumentaba considerablemente el espacio de claves, DES Cracker se programó para que ordenadores personales de la época (1999) pudiesen ayudarle a procesar posibles claves para romper el algoritmo DES3.

Placa del DES Cracker

El algoritmo se rompió en menos de 24 horas, lo que marcó un hito en este tipo de aplicaciones, ya que se demostró que con muchos pequeños clientes y un ordenador central se podían realizar tareas inmensamente grandes (que antes se pensaba que no se podrían realizar en un tiempo razonable)

De esta manera se empezó a abrir la puerta a este tipo de computación distribuída donde se repartían trabajos de problemas altamente paralelizables sobre multitud de «pequeñas» máquinas (las cuales corrían a cargo del usuario propietario, y no del usuario que plantea el problema a resolver, lo cual también es una ventaja en cuanto a costes)

Y así llegamos a SETI@Home y su salvapantallas:

Y es que no hay nada mejor para vender algo que hacer que entre por los ojos, y eso mismo debieron pensar los chicos de SETI@home, pues el problema para que este tipo de arquitectura funcione es que hay que convencer a los usuarios de que dejen sus ordenadores trabajando para el proyecto cuando no hacen otra cosa (y eso cuesta dinero). Y dado que la computación de lotes de problemas altamente paralelos es muy aburrida, se les ocurrió dar algo a cambio: un sistema de méritos (para interacción social y a mayor gloria del usuario) y algo bonito que ver en pantalla (que parezca que lo que haces es megachipirifláutico).

Esta idea ha sido posteriormente adoptada por multitud de proyectos de computación distribuída, con gran éxito.

El sistema de méritos se basa en asignar una serie de unidades (que pueden llamar créditos, dependiendo del sistema, ticks, tickets, etc…) según se completan los lotes asignados. Cada lote a procesar tiene un «tamaño» de cálculo estimado, y cuando se completa el lote, se en base al tamaño estimado y al real computado se asigna la puntuación.

Cada sistema tiene el suyo, y yo me centraré aquí en BOINC.

BOINC

Boinc (Berkeley Open Infraestructure for Network Computing) es una infraestructura con un cliente instalable desarrollada por la universidad de California (más info), que si bien fue desarrollada inicialmente para el proyecto SETI@home, con posterioridad ha sido generalizada y es utilizada actualmente por multitud de proyectos, pudiendo crear proyectos nuevos sin ningún problema.

¿Y cómo de potente es BOINC?

Me alegro de que me haga esa pregunta, caballero: La gran duda en todos los sistemas de computación es hasta qué punto aprovechan sus capacidades (en este caso cálculo pico en FLOPS). En los centros de cálculo se tiene una capacidad más o menos estable durante un tiempo determinado, pero en los entornos como BOINC esa capacidad fluctua debido a las idas y venidas de los usuarios, la heterogeneidad de los ordenadores conectados a la red, la diferencia de carga de los lotes a procesar, etc.

Para poder ver cómo de potente es BOINC primero hay que establecer un estándar de medición. En BOINC ese estándar ha variado (a día de hoy) 3 veces.

El cálculo actual de la capacidad de cómputo para un cliente de BOINC viene dado actualmente por lo siguiente (referencia):

Cada crédito ganado por un usuario se calcula como la 1/200 parte del trabajo que realiza un ordenador de 1000 FLOPS en un día. De esta forma, si nuestro ordenador consigue 200 créditos en 1 día, tendremos un ordenador con una potencia de 1000 FLOPS.

Este cálculo es sencillo, pero teniendo en cuenta que nuestro ordenador puede estar entrando y saliendo de BOINC, que lo apagamos, etc, el cálculo pierde valor. Por ello, desde Boinc se aconseja que para calcular la potencia de nuestro ordenador se utilice en RAC (recent average credit) asignado a nuestra máquina, el cuál se calcula en un determinado espacio de tiempo (normalmente es de 1 día).

Al utilizar el RAC la fórmula de cálculo cambia, y nos queda como GFLOPS = RAC/200.

Hay que remarcar que como la fórmula de cálculo ha sido alterada en varias ocasiones, esta fórmula sólo es válida para datos actuales, para datos actuales qué mejor que  saber cuántos GFLOPS está dando el sistema ahora mismo (siendo estos la suma de todo lo invertido en todos los proyectos disponibles) por paises

¿Y las tarjetas gráficas?

Pues las tarjetas gráficas, como no podía ser de otra manera, se lucen en este tipo de entornos, y para muestra un botón: http://foldingforum.org/viewtopic.php?f=43&t=3193&st=0&sk=t&sd=a&start=420#p38094

En el enlace anterior se puede apreciar el rendimiento de distintas tarjetas nVidia para los distintos proyectos.

En la dirección http://www.gpugrid.net/forum_thread.php?id=1150 se encuentra un resumen con GFLOPS que están rindiendo las GPU en BOINC

Según algunos usuarios, han pasado de generar unos 14 créditos por hora a 180 gracias al uso de una tarjeta gráfica nVidia 8800 GTX

Y además de SETI@home ¿qué otros proyectos se pueden encontrar?

En general cualquier proyecto que incluya la búsqueda de patrones suele ser altamente paralelizable, por lo que en Boinc se puede encontrar multitud de proyectos: de medicina, ingeniería, ciencia pura…

Un proyecto que me ha parecido interesante por el caracter local que tiene es IberCIVIS, si bien el que está despuntando en estos momentos es el proyecto sobre la vía láctea: http://milkyway.cs.rpi.edu/milkyway/

TimeXtended!! Volvemos al juego!!

Disclaimer: los nombres son inventados, cualquier parecido con la realidad es pura coincidencia.

Había una vez un personaje llamado Peputxi que le encantaba el chocolate y jugar. Como lo de hacer chocolate no se le daba bien del todo, aunque comerlo se le daba de maravilla, decidió que lo mejor sería meterse a hacer juegos, ya que jugarlos no se le daba tan bien, a ver si se invertía la tendencia:

LHX Attack Chopper (1990)

F29 Retaliator (1989)

Y un buen día, en medio de un descanso en la clase de primero de universidad, se dedicó a diseñar un juego de estrategia con su amigo Patxi. Tanto Patxi como Peputxi ya tenían experiencia diseñando juegos de mesa, así que las reglas no fueron un problema a la hora de diseñar el juego, tampoco lo sería el nombre (HexaCombat), y tampoco lo sería realizar una estrategia comercial (había contactos para esas gestiones).

Lo que sí que fue un problema era cómo dibujar en pantalla las ideas que estos dos amigos tenían en la cabeza, y ahí, en un mal día, comenzó la obsesión por los gráficos de Peputxi. Ni corto ni perezoso empezó a bucear por internet, y con la ayuda de dos colegas, llegó a los tutoriales de un grupo de la demo scene llamado Asphyxia, y empezó a «competir» por ser el más rápido en escribir un píxel a la memoria de video (la época del OpenGL a nivel de PC aun no había llegado, y las transformadas 3D te las hacías tú a manita). Empezaron las primeras minidemos, y cuando todo parecía ir encarrilandose, la terca realidad apareció con cara de mala leche:

Realidad: ¿Qué haces perdiendo el tiempo, Peputxi?

Peputxi: Que no estoy perdiendo el tiempo, que esto es interesante y tiene futuro.

Realidad: Anda, anda, déjate de tontadas y ponte a trabajar en algo.

Peputxi: Pero hombre, que esto va bien, que me salen cosas chulas, que tengo ideas, a lo mejor hasta me monto mi propia empresa.

Realidad: Ya, como las .COM, para explotar cual burbuja de jabón… Ponte a trabajar y a acabar la carrera que en casa se necesita pasta, y urgentemente…

Peputxi: Cagontóloquesemenea… venga, me voy a currar.

Y así Peputxi abandonó un camino interesante y gratificante, por otro, que si bien no fue malo, si que tuvo algunos sinsabores y sacrificios de no muy buen gusto. Durante más de 10 años trabajó en todo tipo de proyectos, la mayor parte de ellos relacionados con las tecnologías de internet (y es por eso que este blog está en wordpress, porque uno ya se cansa), hizo un muy buen grupo de amigos que eran gente especialmente competente, y un buen día, coincidiendo con una época de hastío y cambios traumáticos, decidió que ya estaba bien de seguir el camino de otros: había algo latente, algo que nunca le había abandonado y que le hacía seguir al día sobre todo lo que oliese a gráficos.

La decisión estaba tomada: Peputxi retomaría las viejas costumbres y volvería a empezar en aquel campo que tan buen sabor de boca le dejó, y no estaría sólo.

Pero esta vez, a diferencia de aquellos comienzos vacilantes, había dos objetivos claros:

• Buscar un buen tema de investigación (para hacer una tesis)
• Hacer un juego, desde cero, donde aprendiese los procesos y pasos que no pudo dar en su momento, para volver a reunirse con Patxi y quién sabe si montar su propia empresa, o sólo para plantar el germen de una mayor, ahora que contaba con gente realmente buena y de confianza.

Y así es como Peputxi acabó haciendo un Máster en Informática Gráfica, Juegos y Realidad Virtual en la Universidad Rey Juan Carlos, en Madrid.

Y ahora, timeXtended, volvemos al juego!!!