Etiqueta : python

Blender

Logo

En este post, he decidido hablaros de una herramienta llamada Blender, la cual ha sido el instrumento principal en la realización de mi PFC en la Universidad Politécnica de Madrid. El proyecto consistía en la simulación de efectos meteorológicos, tales como avalanchas o incendios, y a pesar de que en un principio la utilización de la herramienta es compleja y necesita mucho tiempo de investigación, finalmente me ayudo a conseguir un resultado óptimo.

Es un programa multiplataforma para modelar, animar y crear gráficos tridimensionales. Es de distribución libre y pese a que su interfaz es complicada y poco intuitiva, el programa tiene muchas ventajas sobre otros programas con la misma dedicación.

Interfaz

Entre las características mas relevantes tenemos:

* Tamaño de origen realmente pequeño comparado con otros paquetes de 3D.
* Gran variedad de primitivas geométricas, incluyendo curvas, mallas poligonales, vacíos, NURBS, metaballs.
* Incluye cinemática inversa, deformaciones por armadura o cuadrícula, vértices de carga y partículas estáticas y dinámicas.
* Edición de audio y sincronización de vídeo.
* Características interactivas para juegos.
* Renderizado interno versátil e integración externa con potentes trazadores de rayos.
* Lenguaje Python para automatizar o controlar varias tareas.
* Blender acepta formatos gráficos como TGA, JPG, Iris, SGI, o TIFF.
* Motor de juegos 3D integrado.
* Simulaciones dinámicas para softbodies, partículas y fluidos.

Actualmente, blender va por la versión 2.54 Beta, ha sido la principal herramienta usada en el largometraje “Plumíferos”, el cual es el primero realizado íntegramente con software libre, y fue usado en la producción de “Spider man 2” para la previsualización de escenas.

Gracias.

Mercurial, explicado para usuarios de Subversion

Debido a que los repositorios de Openbravo son de Mercurial, en los últimos meses me he tenido que acostumbrar con ese sistema de control de versiones (SCV).

Para alguien que sólo ha trabajado con Subversion (o anteriores), esto significa un importante cambio de filosofía, puesto que Mercurial se engloba dentro de los más modernos sistemas de control de versiones distribuidos (como Git, Bazaar y otros). Lo que voy a contar es específico de Mercurial, pero estos cambios vienen motivados por su característica de distribuido.

El principal cambio es respecto a la redifinición de los conceptos de cliente y servidor. En SVN, la separación está muy clara: el servidor aloja las versiones y se encarga de su gestión. Por otro lado, los distintos clientes se bajan copias del servidor, realizan cambios, y envían esos cambios al servidor.

SCV tradicional

En toda esta relación está claro quién es quién. En nuestra máquina local tenemos el cliente, y en el servidor el repositorio. Con Mercurial la cosa cambia mucho, porque cada copia del repositorios es a la vez cliente y servidor. En lugar de hacer checkout, para hacerte con un repositorio cliente del servidor, haces clone, con lo que creas un nuevo repositorio cliente-servidor copia del anterior. Las operaciones de commit y update funcionan en local, mientras que se introducen nuevas operaciones (pull y push) para intercambiar cambios entre repositorios. Todo junto quedaría en el siguiente esquema:

SCV distribuido

Esta estructura es bastante más compleja que un SCV tradicional, pero ofrece una serie de ventajas que compensan el aprendizaje inicial. Se suele decir que las principales ventajas son relativas a proyectos grandes, con un montón de colaboradores y varias personas validando grupos de estos colaboradores. Sin embargo, mi experiencia es que incluso cuando hay un único desarrollador, hay beneficios importantes.

Una ventaja que puede parecer secundaria, pero que a mí me encanta, es la capacidad de realizar commits locales. Esto permite trabajar con el control de versiones aún cuando no tienes acceso al servidor princiapl (circunstancia muy frecuente). Esto permite que los desarrolladores incomunicados puedan hacer commits con cambios pequeños y atómicos, en lugar de realizar un envío masivo donde todos los cambios van a tropel y hacen inmanejables logs, control de cambios y vueltas atrás.

Hablando de vueltas atrás, con Mercurial también es posible revertir cualquier fichero a cualquier revisión sin necesidad de conexión con el servidor. Los programadores que se han visto en estas situaciones adversas (como proxies) durante largos periodos pueden valorar estas ventas.

Pero quizá la ventaja más importante está en el prácticamente nulo esfuerzo requerido para clonar repositorios. Por ejemplo, cada vez que un cliente nuevo requiere una personalización de Openbravo POS, se le puede crear un nuevo repositorio simplemente clonándolo. Luego cada desarrollador clonaría de este nuevo repositorio y compartirían los cambios a partir de él.

Si es el caso de OpenTPV, la versión de Opensistemas de Openbravo POS para negocios de restauración, la estructura sería Openbravo POS -> OpenTPV -> versión del cliente . Si hay cambios en el repositorio principal de Openbravo POS, es trivial irla bajando a OpenTPV y a sus modificaciones. Si arreglamos un bug, dependiendo de la raíz del problema, podemos corregir Openbravo POS, OpenTPV o la versión del cliente, y luego difundir esos cambios a los que corresponda.

La única desventaja que le encuentro a Mercurial es que requiere algo más de control y pensar bien cómo organizar estos repositorios. En otras entradas planeo contar un poco más de esto ya que, por si no se ha notado, Mercurial me ha encantado.

Por todo esto, yo recomendaría su uso, o al menos probarlo. Quizá algún día merezca implantarlo a nivel oficial en la empresa, como alternativa al madurito Subversion.