Novedades: logo

He de decir, que al terminar el concurso local, dejé el proyecto de lado, porque me he dedicado a todas las actividades universitarias que tenía pendientes. Respecto al resultado del proyecto en la fase final del concurso —he de recordar, que el premio era del concurso local de Cádiz, pero el objetivo final era el concurso nacional del CUSL.




En el concurso local no fuí uno de los cinco finalistas, pero obtuve una mención especial, entre otros tres proyector que también fueron menciones espaciales. Mi compañero gaditano, desarrollador de Iber Ogre y Sion Tower —segundo en el concurso local de Cádiz— ha sido el ganador en la categoría de mejor proyecto comunitario. Aquí podeis ver la nota de prensa sobre los ganadores.

Respecto al desarrollo de mi proyecto, quisiera anunciar que ya tengo logo —en realidad es la única noverdad. En la imágen anterior, se ve una captura de pantalla con el logo en blanco y negro como fondo de la aplicación. El logo ha sido creado por mi compañera de universidad y amiga Noelia Sales Montes —a su vez ganadora del mejor proyecto de educación y ocio en el concurso del año pasado.



El logo nació después de unas cuantas semanas de discusión sobre mis «apetencias» respecto al logo, y ella finalmente editó la versión definitiva. Mi más sincero agradecimiento a ella por su trabajo.

Leer más...

Versión v0.7

Desde la versión 0.5, he añadido algunos cambios, a una versión 0.6 que no publiqué aquí en el blog, y ahora una versión 0.7 que es el motivo de esta entrada. Veámos el correspondiente video, como ya viene siendo habitual:

La nueva funcionalidad se describe a continuación:

• Incluido buscador: éste aparece automáticamente al lanzar la aplicación. Puede ocultarse/mostrarse con F4. Con Ctrl+F puedes escribir directamente en el buscador, como en firefox y otros tantos programas. Si el clado ya existe, se selecciona el nodo para ver dónde está. Si no está en el árbol, se lee de wikispecies el clado y se carga en la aplicación un nuevo árbol, de dos niveles de profundidad, con el clado buscado como raíz.
• Menú contextual de ayuda: aparece autómaticamente al lanzar la aplicación. Puede ocultarse/mostrarse con F1.
• Se permiten hacer capturas con Ctrl+S.
• Ctrl+click en un nodo lo selecciona, de modo que el nombre del clado permanezca visible. Otra vez Ctrl+click lo deselecciona.

Eficiencia y diseño

Ha mejorado la eficiencia de la aplicación. El diseño de la aplicación, existente desde la versión v0.4, consiste en una clase base de la mayoria de las clases del juego, llamada Strategy, que tiene una función init y una función step, es decir, la aplicación es, en esencia, una fase de inicialización, y después la secuencia de pasos hasta que la aplicación finalice: un paso es actualizar la cámara, cambiar la posición de los nodos, cambiar la posición del menú contextual de ayuda o del buscador cuando éste se muestra u oculta.

Cada clase hereda de la clase Strategy para definir en qué consisten sus propios pasos. Pero éstas clases tienen cierta dependencia entre los cambios de los demás. El objeto más importante de la aplicación es el propio árbol, y la cámara solo se actualiza cuando el árbol cambia. Aquí podemos ver el diagrama de colaboración de la clase Viewing, la responsable del visionado:




Podemos ver como Viewing contiene un objeto PhyloTree, que es el árbol en sí. Hereda virtualmente de ColorTree y LocTree. El primer contiene una serie de nodos coloreados (ColorNode que hereda virtualmente de Node), y LocTree contiene a los mismos nodos (LocNode que también hereda virtualmente de Node), pero solo centrándose en sus posiciones. Así, ColorTree implementa el algoritmo de coloreado que se actualiza en su función step, y LocTree implementa el algoritmo de posicionado (el algoritmo Spring Embedder) que ya fué explicado. A su vez, tanto la posición como el color es un Smooth, una clase que tiene el propósito de dirigir un vector desde una posición de origen a una posición final a un ritmo controlado de forma paramétrica, y que también se actualiza paso a paso, pues también hereda de la clase Strategy. La clase Smooth es usada tanto para controlar el cambio de los colores y la posición de cada nodo, así como su glow (el radio del brillo que acompaña a cada nodo), la posición del buscador, la del menú contextual de ayuda y la cámara.

A partir de aquí, surge una cadena de dependencias de abajo a arriba. La clase Smooth tiene una variable _changed que indica si el vector ha cambiado de posición o no (cuando el vector llega a la posición final no se producen nuevos cambios). Si no se han producido nuevos cambios en ninguno de los nodos, significa que el árbol ya está en una posición estable. Por tanto, LocTree indicará en éste punto que no hay actualizaciones. Entonces la cámara recibe ésta información y, a su vez, indica que él tampoco ha modificado nada. Con éste control en la política de cambios, se optimiza mucho el código, pues llegada a una posición estable se ahorran la mayoría de los cálculos que realiza la aplicación a cada paso.

Anteriormente no se realizaba bien este control y siempre se realizaban todos los cálculos, es decir, no se detectaba bien la llegada a una posición estable, y ahora se ha depurado éste control para detectarse efectivamente —la variable _changed era global a PhyloTree, LocTree y ColorTree, pués estaba en la clase Strategy, y ahora en Strategy sólo está la función virtual bool changed() y la variable _changed ahora es propia de cada clase, facilitándo mucho éste control.

También había errores en el cálculo del tamaño ocupado por el árbol. La clase LocTree calcula, cada vez que hay posiciones, el rectángulo convexo que contiene al árbol completo, y éste rectángulo es el que toma la cámara para especificar su proyeccion. Como, y en parte por culpa del mal control de cambios, éste rectángulo convexo se calculaba mal, la cámara no enfocaba bien, sobre todo cuando un árbol solo tenía un nodo.

Mejora del analizador léxico

Otro detalle importante en la calidad de la funcionalidad de la aplicación es el analizador léxico incrustado. Cada vez que se hace una consulta a wikispecies, éste devuelve un texto que contiene, entre otra información, los subclados de cada clado. Éstos subclados hay que buscador, y el analizador lexíco es el que se encarga de ello, analizando la salida de la consulta al API. Sucede que la forma en que se presentan los subclados no está del todo formalizado, y hay muchos casos particulares y variantes de éstas salidas que hacían que antes no se reconocieran todos los clados, y el árbol quedaba incompleto. Se han realizado muchas mejoras en ésta búsqueda y ahora el lexer es más potente y se reconocen una mayor cantidad de clados y el árbol es bastante más completo que antes, aunque supongo que seguirá habiendo casos particulares no controlados que tendré que buscar y depurar.

Éstos cambios no son muy complicados de controlar, pero hay que saber cuáles son éstos casos particulares, y ésto es lo complicado. Hay que ir haciendo pruebas y explorando clados aleatorios en busca de fallos, mirándo qué devuelve el API y por qué no se reconoce. Así que, si a alguien le apetece ayudarme en ésto, bienvenida séa su ayuda y/o particupación.

Para finalizar, también indicar que ya está mejorada y ampliada la información necesaria para poder compilar la aplicación. Tanto en el readme como en la documentación se muestran los paquetes concretos que hace falta instalar, y además cmake avisa de si ha encontrado las librerías o no. Antes solo avisada de «algunas» librerías, pero no se controlaban todas.

Leer más...

Final del premio local del CUSL V

Bueno, esta mañana ha sido la final del premio local del CUSL V de la universidad de Cádiz, y bueno, según la opinión de los evaluadores, mi proyecto ha sido el mejor, y he resultado ganador, llevándome un fabuloso mini-portatil. Yo no estoy seguro de mi propia opinión al respecto, aunque agradezco a todos aquellos que, a mi favor, sí que lo tienen claro. Me encanta mi criatura, creo que es una buena idea y tiene mucho futuro, pero Iber Ogre y Sion Tower es un gran proyecto que también se merecería el premio que al final me he llevado yo. Aunque por muy poco —un punto— lo que no está de más recordarlo, tanto a la salud de David Saltares como de la de otros participantes y de la mía propia, que tampoco quiero caer en el círculo del síndrome del impostor. El proyecto Dominous, de Ignacion Palomo Duarte, que fué tercer premio, también quedó a un punto del de David, así que también podría haber sido tan buen ganador como nosotros, aunque no he tenido el placer de ver y ejecutar su proyecto como para dar una opinión, pero me remito a la puntuación como prueba de su calidad.

En total, el resto de premios han sido: el de David Saltares Márquez, Iber Ogre y Sion Tower, como mejor proyecto de Ocio, Ezequiel Vázquez de la Calle como mejor proyecto de comunidad con WiiPang, el proyecto Dominous de Ignacio Palomo Duarte como mejor proyecto de innovación, Sebastían Guerrero Selma como mejor proyecto de seguridad por Security Leaks, y Ballon Breakers como mejor proyecto de ocio, de Jesús González Rodríguez. Éstos tres últimos participantes, lamentablemente, no pudieron asistir a la presentación de ésta mañana y Manuel Palomo Duarte (el coordinador) hizo de sustituto, presentándo sus proyectos brevemente entre nuestras presentaciones.

Una mañana entretenida, donde nervios y expectación jugaban juntos en un partido la mar de interesante. Luego nos fuimos a comer a la pizzería «la bella italia» para celebrarlo, aunque no pudimos rematar la faena con heladitos al no haber ninguna heladería abierta por la ciudad, pero por lo general fue un buen día acompañado de un agradable sol.

Pero la vida sigue, y al acabar la mañana todos volvimos a nuestras rutinas diarias de trabajos y clases para la universidad, que es lo único que queda cuando lo demás se va, y lo que habrá hasta que, si Dios quiere, los gaditanos nos volvamos a colar en la final y a vernos en Granada.

Así que mucha suerte a todos los participantes para la nacional, que no decaigan los ánimos de los que se queden a las puertas, a seguir trabajando en nuestros proyectos y, sobre todo, ¡a disfrutar!

Saludos,

Leer más...

Versión v0.5

Versión v0.5. Me da miedo ponerle un nombre de versión mayor. Pero la verdad es que ahora la aplicación «da' gusto», ya que , por fin, se construye el árbol de forma dinámica extrayendo datos de la web. ¿De qué web?. Pues lo mejor que tenemos ahora, que yo sepa y que sea público, es Wikispecies. De ahí se va generando el cladograma que se visualiza en la aplicación. Pero luego entraremos en más detalles, ahora, a disfrutar un poco durante los cinco minutos y algo que dura el video:

Los nuevos cambios más importantes añadidos son los siguientes:

• Cambio importante de diseño, a destacar: clase Strategy, de la que heredan la mayoría de las clases del juego, clase Smooth, para suavizado de movimientos y desacoplado de las distintas funcionalidades del árbol, es decir, clases Tree vs LocTree vs ColorTree.
  
• Procesado automático del cladograma: cada taxón/clado tiene su correspondiente artículo en Wikispecies. Éste consta de una primera sección en donde residen los subclados. Con la librería libcurl hacemos consultas al MediaWiki-API de Wikispecies, y con flex la analizamos para extraer cada subclado.

Y la nueva funcionalidad:

• Exploración del cladograma de wikispecies: haciendo doble click izquierdo en una clado hoja del árbol se expanden sus subclados.
  
• Visualización del artículo del clado en wikipedia:haciendo doble click derecho en el nodo correpondiente.
• Contracción del árbol: haciendo doble click izquierdo en un clado que no sea hoja, el clado se constrae, ésto es, desaparecen sus subclados. Para constraer el árbol «por arriba», en vez de por abajo, es decir, eliminar padres y hermanos que no interesen, hay que hacer Ctrl+doble click izquierdo en el nodo deseado, ese nodo se convierte en nuestra nueva raíz, desapareciendo el resto del árbol.
• Las teclas →, ↑, ← y ↓ sirven para mover la cámara, y si se mueve el ratón mientras se mantiene pulsado el botón izquierdo del ratón, la cámara también se mueve pero en dirección contraria.

Algunas cosas a corregir/mejorar:

• La cámara no siempre está centrada, y hay que moverla manualmente.
• Disminuir la sobrecarga cuando el árbol es muy grande.
• Construir subespecies (solo se construyen clados y especies).
• Indicar la categoría taxonómica del clado (filo, órden, etcétera).
• Búsqueda de clados.
• Construcción del clado, «hacia arriba»: solo se puede expandir el árbol en dirección padre-hijo.
• Indicar cuál es la raíz del árbol u, opcionalmente, indicar la dirección padre-hijo en el árbol, ya que con árboles grandes es difícil saber «donde estás».
  

También tenemos una rama de trabajo, llamada 3ddevelopment (de la versión v0.3, no de la última) en la que hay una visualización en 3D del árbol. Pero no la he querido mergear con la rama principal por que todavía no veo claro cuál será su uso. La visualización y exploración es menos cómoda y la sobrecarga de la máquina es considerable. Es más bonito, pero menos útil «en la práctica». Quiero agradacer eternamente a mi compañero Pepe cullera por su colaboración, que es el que ha desarrollado al completo dicha rama 3D y espero algún dia encontrar alguna justificación al uso del 3D en la aplicación y trasladar el contenido a la rama principal, al menos como opción de visualización, para los que lo deseen.

Leer más...

Versión v0.3

Ya tenemos nueva versión. ¿Qué lo hace distinto de la anterior?, pues principalmente, que ya se integra con un mini-explorador que permite visualizar los distintos clados en wikipedia. Es algo cutre puesto que se usa el nombre del nodo con el nombre del artículo de wikipedia. Si éste no existe, aparecerá la página de wikipedia que te propone crear un nuevo artículo.

He aquí un video:

Para conseguir integrar el explorador, sencillamente he hecho uso del módulo de Qt WebKit. Sí, habeis leido bien, he migrado el proyecto a Qt, y la verdad es que estoy muy satisfecho, casi todo lo que te imagines Qt te lo ofrece: te ahorra el trabajo de controlar los dobleclicks, te permite crear señales entre funciones puesto que contiene un mecanismo interno de signal and slots, búsqueda de contenidos en el código HTML, widgets de openGL, etcétera. Además, está perfectamente documentado. Vamos, toda una delicia de librería.

Por ejemplo, para controlar la animación, tengo un reloj que da pulsos cada 40 milisegundos —y así tenemos 25 fotogramas por segundo—, y ese reloj está conectado con el slot PhyloTree::animate(), de modo que cada pulso es una señal, y la función animate es un callback que la recibe, aunque todo ese proceso es controlado por Qt. El siguiente paso importante a dar es que el software interactúe con el API de wikipedia para obtener la información deseada de forma robusta.

Otra característica de la que me estoy preocupando en mantener es el «smootheado» de todos los elementos animables posibles, así, si el usuario mueve la cámara con el ratón, la posición no cambia inmediatamente, sino de forma suave hasta su posición final. Lo mismo ocurre si cambiamos el tamaño de la ventana, que tanto el viewport como el miniexplorador integrado se mueve a la nueva posición y tamaño de forma progresiva.

Por último, hay un desarrollador y ahora colega que va a experimentar en una nueva rama de git con el paso a 3D del árbol, al que incluso añadirá efectos de desenfoque, y también la posibilidad de ver el árbol con profundidad mediante el uso de gafas cromáticas; todo un lujo.

Leer más...

Versión v0.2

Después de un mes con el proyecto dejado de lado, he aprovechado las navidades para trabajar en él un poco, y la verdad es que los resultados son satisfactorios, por ahora.

Los cambios son sencillos, he programado un algoritmo basado en fuerzas para imprimir el árbol, la cámara se mueve si se mantiene pulsado el ratón, y también hay programado un algoritmo de coloreado inventado por mí. Además, se ven los nombres de los clados que representan los nodos cuando se coloca el ratón encima.

He aquí un video de ejemplo:

Mas técnicamente, los dos algoritmos principales son los siguientes:


Algoritmo basado en resortes

Es el algoritmo usado para calcular la posición de los nodos del árbol. Es un algoritmo de la familia de los algoritmos basados en fuerzas, conocido popularmente como Spring Embedder (resortes embebidos). Este algoritmo consiste en lo siguiente: cada arista es, en realidad, un resorte, —es decir, un muelle— que tiene una longitud dada. Cada pareja de nodos no conectados, se unirán con una arista ficticia que también modelará a un resorte. Las aristas verdaderas serán resortes de atracción, y las aristas ficticias serán resortes de repulsión.



Las posiciones de los nodos se inicializan aleatoriamente, y se unirán con muelles de la forma indicada. Cada resorte intentará volver a su posición inicial, generándose un sistema de fuerzas que buscará una situación de equilibrio. Es como si forzaramos una serie de puntos unidos con muelles, algunos estirados y otros comprimidos, y luego tiraramos el conjunto al aire. El gráfico anterior ilustra bastante bien su comportamiento, dando finalmente una visualización elegante del árbol.


Algoritmo basado en intervalos de colores

Este algoritmo es invención mía, y funciona de la siguiente forma: a cada nodo se le asigna un intervalo de colores, y se colorea con el centro de dicho intervalo. Dicho intervalo se parte en tantos subintervalos como hijos tenga el nodo, y, análogamente, se colorea con su centro. Se procede recursivamente para todo el árbol, siendo el intervalo de la raíz del árbol el propio cubo RGB (y por tanto, la raíz del árbol será de color gris, pues es el centro del cubo).

La forma de partir cada intervalo es el siguiente. Partiendo del cubo RGB asignado a la raíz, primero se elige para particionar la dimensión R —es decir, la del color rojo—. Así, si la raíz tiene n hijos, el cubo se partirá en n rectángulos 3D, donde el ancho en la dimensión R de cada rectángulo 3D será el ancho del nodo raíz dividido entre 'n'. Para el siguiente nivel, cada cubo se partirá en la dimensión G, luego en la B, luego nuevamente en la R, y así sucesivamente.

La idea de éste algoritmo es que cada nodo sea dueño de una región, del cubo RGB de la que ninguno de sus hijos podrá escapar. Así, aunque en los primeros niveles haya saltos en la gama de colores —sobre todo si cada nodo tiene pocos hijos—, a medida que se incrementa la profundidad la gama de colores de nodos relacionados será mas homogénea, y el propio coloreado será un indicador gráfico de la cercanía entre nodos.

Aspectos por cambiar o mejorar

Hay todavía muchas cosas importantes por mejorar en la aplicación. El más importante por ahora es que la aplicación no cuenta con ninguna base de datos externa. El árbol está creado nodo a nodo en el fichero program.cpp, es decir, embebido en el propio código. Este es quizás el siguiente aspecto crucial de la aplicación, tener una base de datos externa, y crear la visualización del árbol leyendo los datos a partir de dicha base de datos. Seguramente usaré posgreeSQL.

Otros aspectos menores son referidos, por ejemplo, al peso de las aristas. Por ahora, cada arista tiene el mismo peso, que viene indicado en el propio algoritmo basado en resortes —en realidad, no existe aún ninguna clase arista que tenga un atributo peso, sencillamente es una pareja de nodos—. Habrá que asignar un peso a cada arista, usando algún criterio relacionado con el árbol filogenético —por ejemplo, proporcional al número de nietos que tenga un hijo—, y adaptar el algoritmo de resortes para que éste cambio no produzca efectos indeseables en la visualización.

Otro aspecto a cambiar es el posicionado del árbol. El árbol entero es movido según el sistema de fuerzas que provoquen los resortes, y habrá que cambiar el algoritmo para que, al menos la raíz, quede fija en un punto dado, porque a veces el árbol se mueve demasiado hacia un extremo y hay que mover la cámara para volver a centrarlo.

Hasta otra ...

Leer más...

Mi primer blur

Bueno, tan pronto como traducí mi aplicación a openGL, ya le añadí el blur. Por ahora el resultado es pobre porque solo me queda perfilar los efectos, pero la dinámica de trabajo, que es lo que me interesaba, ya la conozco. Este es el resultado final:




La visualización es pobre por dos motivos: no hago cálculos de qué color corresponde a cada nodo, ya que todavía estoy viendo como pintar árboles, no cuál es el contenido del árbol, cosa de la que depende el color asignado (y cuestión todavía que tengo que definir). Y las aristas tampoco tienen blur aún (y tampoco se han colocado sombras).

Estos aspectos se definirán ya muy a posteriori, mi siguiente prioridad ahora es programar el algoritmo de visualización del grafo (es decir, el que coloca cada nodo en un lugar adecuado para una estética visualización), y luego, pelearme con la impresión de texto.

Leer más...