Blog FreePhyloTree

Novedades: logo

2011-06-03T07:37:00.000-07:00

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.

Versión v0.7

2011-03-31T03:27:00.000-07:00

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.

Final del premio local del CUSL V

2011-03-23T16:11:00.002-07:00

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,

Versión v0.5

2011-03-15T11:06:00.000-07:00

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.

Versión v0.3

2011-01-14T11:17:00.000-08:00

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.

Versión v0.2

2010-12-29T06:48:00.000-08:00

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 ...

Mi primer blur

2010-11-13T12:23:00.001-08:00

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.

Adios Ogre

2010-11-13T06:49:00.001-08:00

Desde mi última entrada, han ocurrido muchas cosas en mi proyecto, pero qué han tenido muy poca repercusión en su aspecto actual. Como ya adelanté en la presentación, quería que mi proyecto se pareciera al aspecto de Gource por cuestión de elegancia, y todos éstos cambios tienen su origen en la persecución de ésta idea.

Como un grafo, y por tanto un árbol, no es más que nodos y aristas, los modelos 3D con los que hace falta trabajar son muy sencillos. Sumándole ésto a que el tamaño de cada nodo, o de cada arista, puede ir cambiando en tiempo de ejecución, el dibujado, y con ello los modelos también deberían hacerlo. Ésto me llevo directamente a trabajar con el tipo ManualObject de Ogre, que te permite definir los modelos vértice a vértice, definir subobjetos, y cambiarlos en tiempo de ejecución. Es decir, todo lo que necesitaba, aunque precisamente por trabajar con objetos geométricos a bajo nivel veía a Ogre un recurso demasiado disparatado. Ogre está orientado para trabajar con modelos complejos, en escenarios complejos, con cálculos complejos. Yo no necesito muchos efectos gráficos ni de iluminación, y es todo relativamente sencillo. Pero por tal de no empezar a aprender openGL, por cuestión de tiempo, decidí seguir adelante.

La primera idea para simular el efecto de Gource era mediante el uso de una esfera, con una luz en su centro que la reflejara, para que tuviera el aspecto de una estrella brillante. Cómo se nota que era la primera vez que trabajaba en un contexto 3D. Cuándo tienes un objeto, iluminarlo solo cambia la intensidad de la luz en su superficie, en los lugares donde la luz incida, oscureciéndose a medida que la superficie se aleja de la luz, o se hace más innacebile para ella. Una luz no se verá si no hay ningún objeto en el que reflejarla. Y por poner una luz dentro de un objeto, nunca va a tener un aspecto de "bombilla".

Una vez comprendido ésto, cambié de táctica. Relegé la construcción 3D del árbol en un nuevo objeto, usando el patrón estrategia (StrategyMakeTree). Ahora tenía dos construcciones, una mediante esferas (SphereMakeTree), y otra recurriendo al llamado efecto Tyndall (ColloidMakeTree).

El efecto Tyndall es lo que ocurre cuando un rayo de luz entra en una habitación, o cuando el agua se refleja en el mar. El aire de la habitación, o el agua, tienen una serie de impurezas. Cuando un rayo de luz penetra, cada partícula impura refleja la luz que incide en ella, creando una serie de puntos de luz indistinguibles entre sí para el ojo humano, dando la sensación de un continuo iluminado. Luz reflejada en aire o agua pura no es visible en forma de rayo, debido a que no tiene partículas que puedan reflejar la luz incidente en ellas. En la imágen siguiente se ve un láser que atraviesa dos vasos, uno con agua pura, y otro con impurezas, y se observa como el agua pura no muestra al rayo atravesándolo, mientras que las impurezas disueltas en el agua sí que lo permiten.

Un sistema como el aire o el agua con impurezas, son llamados coloides, y mi nueva idea, era, por supuesto, que cada nodo fuera un coloide. Se crearía una nube de puntos con forma esférica, de forma que en su centro hubiera una mayor densidad, y en el límite de su radio poca. Luego, situando una luz en su centro se simularía un coloide, difuminándose la intensidad lumínica a medida que la luz se alejaba de su centro, hasta diluirse con el fondo negro.

Pero por más formas ideadas para implementar un coloide, ninguna tuvo éxito. Para experimentar, comencé construyendo una esfera que tuviera siempre una misma densidad de puntos. Pero si construía una esfera de poca densidad, se veía en vez de un coloide una nube dispersa de puntos. Si la construía con poca densidad. Se veía una esfera sólida en vez de un coloide. Si hacía una esfera de poca densidad, con mucho radio, y alejando mucho la cámara, se volvía a ver una esfera sólida.

Mi siguiente paso fue ver como lo hacía Gource. Me llevé un tiempo estudiando su código fuente, lo que me llevó a aprender bastantes cosas de openGL para comprenderlo. Explorándo el código descubrí, entre otras cosas, que el efecto de destellos de luz cuando se creaba una rama nueva se llama bloom. El desenfocado que buscaba, blur (blur no es más que borroso en inglés). También descubrí que existe una rama de la teoría de grafos que se llama visualización de grafos, y Gource usa un algoritmo de visualización basado en fuerzas, esto es, que el grafo funciona como un sistema gravitatorio, donde cada nodo afecta a la posición de los restantes nodos, hasta alcanzar una posición de equilibrio, que es la posición final de visualización.

Otro detalle interesante es que, como el árbol está cambiando de posición y orientación constantemente, las aristas están curvadas de modo que incrementen la sensación de movimiento, curvándose la aristas en un sentido semejante al sentido de giro del árbol. Para construir estás aristas curvadas, se hace uso de splines.

La forma que tiene gource de dibujar el blur (el desenfoque), es mediante el uso de texturas. Se especifican las coordenadas de un cuadro, se coloca encima una imágen que contiene un círculo difunado que hace las veces de desenfoque, y encima se coloca otra imágen con el nodo en cuestión. El color de la textura de desenfoque se mezcla con el del nodo, y con eso finalmente parece que es el propio nodo el que brilla.

Intenté hacer lo propio con Ogre, creando la clase GourceianMakeTree. Y empezaron los problemas. Por más vueltas que le daba, no conseguía que la textura se renderizara bien. Sobre el funcionamiento interno de ManualObject existe poca documentación, en la lista de correo de la forja tampoco hubo nadie que me pudiera ayudar de forma totalmente satisfactoria. Incluso un desarrollador con el que mantengo contacto por correo, muy familiarizado con Ogre y openGL, con el que aprendí muchísimo, tampoco supo como resolver mi problema. Todo ello demuestra el poco conocimiento, uso o divulgación, de los ManualObject, lo que me convenció más aún que Ogre no estaba hecho para trabajar de esa forma (ya que nadie más lo hacía).

Así que decidí dejar Ogre, y con ello OIS, y cambiarme a openGL, con Glut primero, y con SDL después. Este paso de glut a SDL fue debido a que, aunque glut sea orientado a eventos -cosa que hace más elegante el diseño para este tipo de aplicaciones-, su sintaxis me obligaba a hacer cosas poco elegantes, como tratar con atributos externos o trabajar con referencias a funciones miembro, con sintaxis prefijada, y sin tener control total sobre la función MainLoop, que es la función de Glut que lleva el control de toda la aplicación.

Una vez perdidos unos cuantos dias aprendiendo openGL, pude finalmente reescribir mi aplicación. El diseño prácticamente no ha cambiado. Las clases se organizan de la misma forma, solo que las funciones miembro sí que son distintas y hacen cosas distintas.

Un detalle curioso (que tuve que descrubir yo, y nunca se advierte cuando se habla de SDL + openGL), entre Glut y SDL es que, mientras Glut toma el sistema de coordenadas del escenario centrado en la pantalla, SDL toma el centro del escenario en la coordenada (0, 0) de la pantalla, es decir, la esquina superior izquierda. Además, la pantalla se convierte en el primer cuadrante invertido, ya que la coordenada y de la pantalla crece desplazándose hacia abajo, como de costumbre en SDL. Es decir, que hay que tener en cuenta que SDL no cambia su comportamiento sea una ventana openGL o una pantalla "clásica".

Y respecto al aspecto actual del proyecto, pocas novedades. Todavía no tengo programado el desenfoque, solo pinto un cuadro blanco por cada clado, conectados por aristas. En la siguiente imágen se muestra una captura.

No hay ningún algoritmo "propio" de impresión del árbol. Sencillamente, los hijos los imprimo en columna, con un desplazamiento x constante, por tanto, los hijos de padres distintos podrían solaparse.

¿git-svn?, quizás otro día.

2010-10-25T17:19:00.000-07:00

Me he llevado día y pico quebrándome la cabeza intentando aclararme sobre como interactuar entre git y svn, sin tener dos repositorios independientes almacenados de forma local. Así que intenté entender el comportamiento de git-svn a fin de usar dicho comando para actualizar svn desde mi repo git.

Sé que eso trae muchos problemas con las ramas del proyecto, que es quizás el aspecto de arquitectura que más dificulta la tarea de su sincronización. Pero partía de una premisa: nunca habrá cambios "nuevos" en el repositorio svn que no haya sido subidos por mí, es decir, nunca voy a necesitar hacer el clásico pull desde svn (que en git-svn, es git svn rebase).

Pero eso no fue suficiente. Para empezar, no conseguí usar el repo de svn como un repo remoto sin más. Primero hay que bajarse el repo svn (con git svn clone), luego usar git de forma normal, sincronizándolo con tu repo git de la web también de forma normal, y todo de forma normal, y cuándo lo desees, con git svn dcommit subes tus cambios a svn. Ésto es aceptable, aunque desearía no verme obligado a hacer un svn clone cuando el repo svn está completamente vacío, estándo el de git con contenido incluido. Sencillamente no me gusta o no me fío del todo.

Pero además, los dcommit de git-svn modifican la información de los commits de git puro, para adaptarlo. No quiero que svn ensucie a git. Además, ésto provoca una "pega" adicional: si realizas un commit, creas una nueva rama, vuelves a la master y realizas un dcommit, cuando intentes mergear la nueva rama no encuentra su punto de anclaje al haber sido modificado por dcommit, lo que produce conflictos.

Ese es un detalle que no me gustaba nada, y que me hacía temer errores en un futuro. No quiero partirme la cabeza con una herramienta, porque las herramientas significan exáctamente lo contrario: ahorrarte trabajo, no producirtelo. Si no veo las cosas claras o no me convencen, las reniego. Y después de tanto, todavía no me llegó a quedar claro como se sincronizaban las ramas y los tags (en general, la jerarquía de directorios de svn) entre git y svn.

Así que, al final, tendré dos copias locales. Cuando quiera actualizar svn, copio los archivos y santas pascuas, cosa que ya me habían aconsejado en la lista de correo del CUSL5.

Cámaras... ¡Acción!

2010-10-25T16:48:00.000-07:00

Ya me han confirmado la aceptación en la forja del proyecto. Era obvio que me lo aceptarían, ya que me lo aceptaron en el cusl5 (no creo que se peleen entre ellos), pero había que esperar, y la verdad es que no ha sido tanta la espera. Y ahora tengo todas las herramientas necesarias y todo el contexto para poder empezar a trabajar.

Así que, con todo, ésto son los "cuerpos oficiales" del proyecto:

Página del proyecto en gitorious (se aloja el repo git): http://gitorious.org/freephylotree
Página del proyecto en forja.rediris (se aloja el repo svn): https://forja.rediris.es/projects/cusl5-freephylo/
Blog del proyecto: http://freephylotree.blogspot.com/

Y por ahora ésto es todo. A la derecha del blog, hay un gadget llamado "Sitios del proyecto y su autor" con éstas referencias. A medida que vaya configurando y/o añadiendo más sitios se irán comentando en éste blog y se colocará en dicho gadget. Por ejemplo, cuando active la página web principal del proyecto (que seguramente estará basado en la wiki que genera doxygen), se informará y se colocará en dicho gadget. O cuando disponga de documentación, o si activo la lista de correo (cosa que creo innecesaria por ahora), etc. En todo éstos casos, las "noticias" tendrán la etiqueta "Metaproyecto" -cómo ésta entrada-.

Meta es un prefijo que procede del griego y que se usa para indicar que vamos a elevarnos un grado de abstracción. En éste caso, las entradas etiquetadas con metaproyecto indican entradas que hablan sobre cosas del proyecto a gran escala o "desde fuera", como los sitios relacionados con el proyecto, el uso dado a los repositorios, las presentaciones realizadas del mismo, etc; y nunca de detalles sobre implementación, resolución de problemas, confección de ideas para nuevas funcionalidades y demás cuestiones relacionadas con el desarrollo.

Creo que tener bien identificado éste tipo de meta-información es muy necesario, ya es que la que mejor permiten orientar a los "seguidores", y mucho más aún, a los nuevos visitantes. A medida que se vayan colocando nuevas etiquetas con fines especificos o importantes, también se comentarán en entradas de "metaproyecto".

Para no crear complejidad innecesaria que confunda al personal, en la forja de rediris he desactivado todas las opciones que no uso, así, en la página del proyecto de la forja de rediris están desactivadas las opciones de documentación, de foros, de lista de correos, etc; y la visión del contenido del proyecto es mucho más clara: si no encuentras la lista de correo es que no se usa, y todos contentos. Para eso está este blog, y si llegara a tener mucha participación, entonces habilitaré la lista.

Presentación

2010-10-24T08:04:00.000-07:00

Me acaban de confirmar la aceptación de mi nuevo proyecto, FreePhyloTree, en el CUSL5, y aquí inauguro éste blog para ir informando de mi progreso, mis ideas, mis peleas con las librerías, los intentos de suicidio a los que sobreviva y demás florituras que acaezcan en el desarrollo de éste proyecto.

Antes que nada (y por tercera vez, tanto en el CUSL5, como en la forja), explicaré en qué consiste el proyecto. Se llama FreePhyloTree, y es una herramienta de visualización 3D de árboles filogenéticos, también llamados filogramas. ¿Qué es un filograma?, pues un árbol que refleja las relaciones evolutivas entre especies.

Por ejemplo, éste es un filograma bonito y decorado:

Este árbol refleja, por ejemplo, como nosotros estamos más emparentados con los roedores que con las gallinas, ya que el ancestro común con los roedores es posterior al ancestro común con las gallinas, que está más cerca de la raíz. Y también refleja que existe un ancestro común a todos: la raíz del árbol. Para más información sobre la clasificación de las especies y los árboles filogenéticos, pueden visitar éste artículo de mi otro blog: clasificación de los seres vivos. Existen muchas maneras de representar árboles filogenéticos, y aquí se muestran otros ejemplos:

Por mi parte, quiero crear árboles filogenéticos con una apariencia como ésta:

Esta imagen tan bonita y elegante no es ni más ni menos que Gource, una herramienta hecha por google para visualizar el historial de cambios de un proyecto bajo git. Cada nodo de ese árbol es un directorio, y cada hoja, un fichero del proyecto. Gource crea una animación que va modificando ese árbol a la par que se van modificando los ficheros del proyecto (es decir, a medidas que se suceden las versiones del repositorio).

Cuando conocí dicho software, sencillamente me encantó. Unido ésto a que me interesa el campo de la evolución biológica y que además no conocía ningún software que ayudara a su estudio, cuando decidí inscribirme al CUSL5 no se me ocurrió otra cosa que fusionar ambas ideas.

Visualizadores de árboles filogenéticos, existen muchos. Libres menos, pero también los hay, y en realidad hay bastantes. En 3D, también. Pero ninguno es una herramienta didáctica, es sencillamente eso, un visualizador. En FreePhyloTree se pretende camuflar una especie de enciclopedia sobre evolución biológica dentro de un visualizador de árboles filogenéticos: visualizando el árbol, se conocen las relaciones evolutivas, y seleccionando cierto clado, se obtiene la información textual que ayuda a entender su historia y contexto evolutivo: historia de los descubrimientos, época geológica, contexto ecológico, etc. Llevar el seguimiento de la historia evolutiva de una especie se hace, así, mucho más fácil.

Todavía no tengo planificado de qué naturaleza será dicha "enciclopedia": si cada clado se anexará a una página wiki integrada con el sistema, si existirá una línea temporal, con qué tipos de árboles contaremos (filogramas o cronogramas, o una fusión de ambos), o de qué forma se interactuará con la base de datos.

Normalmente, diversos autores tienen diversas ideas sobre la historia evolutiva de un grupo de organismos, lo que provoca una obvia confusión en los estudiantes: es muy complicado entender la filogenia de una especie si en cada referencia se muestra una historia evolutiva distinta; así que también se pretenderá crear una visualización cómoda y comprensible de los distintos posibles árboles que relacionan a un mismo grupo de organismos.

El blog del proyecto, será el blog que estás leyendo. El repositorio principal está alojado en gitorious, y el repositorio secundario, y necesario para el CUSL5, estará alojado en la forja de rediris (pendiente de confirmación). En este último (ya que va con svn, -y ya va siendo hora de permitir git-) guardaré solo los commits importantes, los que añadan alguna funcionalidad nueva y así se facilite el seguimiento del repositorio (y de paso no ensuciamos el historial de commits y no volvemos loco a los evaluadores ;) ). La página principal del proyecto también es la ofrecida por la forja (pendiente de confirmación primero, y de construcción después).