Tema: Tecnologías libres para sintesis de imagen digital tridimensional blendiberia 2006

¿Qué pasa en este país?
este artículo recoge una serie de impresiones personales sobre el mundo laboral del programador en España. Las directivas que en el se recogen no son evidentemente aplicables como norma. La intención del texto es la de denunciar una serie de aspectos a mi juicio profundamente perjudiciales para el sector.

Como se menciona en the mythical man-month: recogiendo patatas el individuo más productivo puede tener una relación de 2, como mucho 3 a 1 contra el menos productivo. En el mundo del desarrollo de software, la relación entre el más productivo y el menos productivo puede ser de 10 e incluso 100 a 1. Sin embargo, el más productivo aceptara trabajar sólo por el triple, esta ventaja que en principio tienen los empresarios pasa totalmente desapercibida en este país. Hay ya unos cuantos programadores que pueden ser productivos. También hay unos pocos programadores brillantes que podrían, en el entorno adecuando, generar verdaderas fortunas. Pero el programador no es una persona respetada en el mundo laboral. Ni siquiera se le respeta en la calle, uno se encuentra programadores cobrando menos que los del servicio de limpieza. No es que estos deban cobrar menos, es que los programadores deberían cobrar más. Además, nos da una idea de cómo valora la empresa el papel del programador. Al fin y al cabo, en la industria del software son los programadores los que crean riqueza de la nada. Es difícil entender como pueden tener una valoración tan baja. También es sorprendente que los propios programadores lo consientan, todos sabemos lo que supone reemplazar a un programador en medio de un proyecto. Puede significar un retraso de 6 meses en el mejor de los casos. El atasco completo del proyecto en el peor de ellos. Pero nadie en la dirección de las empresas se da cuenta. Es más, ni siquiera les importa. En España el 90% de las empresas se dedican a vender humo o a hacer proyectos con la administración cuyo buen fin preocupa a muy pocos. No es de extrañar que de aquí no salga ninguna empresa espectacular como Skype, Keyhole, o no digamos ya, google. Debe existir algún motivo.

Trabajando como programador uno se enfrentará a un montón de iluminados visionarios que, sin tener ningún conocimiento, proponen cada día ideas como ¿y si hacemos un sistema de telefonía por internet? Normalmente estos ataques de creatividad ocurren al día siguiente de que salga por la tele la noticia de que alguien ha hecho lo mismo en alguna parte. A los dos años cuando la idea esté ya implantada podrán decir eso se me ocurrió a mí, pero nadie me apoyó, todo este entorno frena a cualquier programador de provecho de hacer nada útil ni revolucionario. A diferencia que en otros países, las empresas de tecnología no están dirigidas por personal técnico. Están dirigidas por gente de mucho dinero o tipos que ganaron algo de dinero haciendo otra cosa y ahora quieren apuntarse al carro. Nunca saldremos del agujero tecnológico hasta que esto cambie, en mi corta experiencia como programador he ido desarrollando fuertes alergias a prácticas comunes. Como ahora están de moda los estatutos, he decidido empezar a redactar un tutorial de los programadores. Para generar polémica, todo estatus tiene que tener un preámbulo incendiario que reclame derechos de nación o algo similar. Como no está el horno para bollos, hemos de maquillarlo un poco para que no suene muy radical.

El preámbulo propuesto es el siguiente:
«el mundo de la programación es una realidad constitucional».

Dicho esto procedemos con el primer y más importante artículo:
artículo 1: toda persona incapaz de realizarlas tendrá, terminantemente prohibido, tener ideas.
Lleva un poco de reflexión darse cuenta de cuanto beneficio haría una norma como ésta. Primero invito a pensar si podría en algún caso hacer daño a la sociedad. ¿ha habido alguna vez una buena idea tecnológica o científica que surgiera de mano de alguien incapaz de desarrollarla?
Aunque así fuera (que no es), la idea se hubiera echado a perder por la mala gestión de la misma. Resulta impensable que el jefe de la oficina de patentes donde Einstein trabajaba se presentara un día en el trabajo diciendo:

Albert, he pensado que quizás la velocidad de la luz es una constante universal no sujeta a la medición relativa que sufren todas las demás mediciones. Las consecuencias pueden ser muy interesantes, podemos llegar incluso a la energía nuclear. Quiero que dediques todos los días un par de horas a desarrollar esto. Tiene que estar listo en seis meses.

Los hitos del proyecto son:
1905 -relatividad especial (un primer boceto de la idea).
1915 -relatividad general (desarrollo matemático y.

Generalización).
1950 -centrales nucleares.

Es mucho más probable que lo que ocurriera fuera algo como:

Albert, el futuro es desarrollar unas nubes tan densas que la gente pueda volar en ellas y viajar prescindiendo del avión, que es un invento obsoleto. En dos años ya se habrá superado y no podemos quedarnos atrás. Así que deja esos papeles que garabateas todos los días y ponte con esto ya.

las ideas son mucho más que una simple frase. En el mundo de la programación no cuenta sólo la idea, sino la idea de cómo llevar a cabo la idea. A los fundadores de Google no se les ocurrió simplemente hacer un buscador. Eso lo hacía todo el mundo por aquel entonces. Se les ocurrieron ideas para hacer uno mucho mejor que el de los demás. Y eso nunca podría habérsele ocurrido a un tipo que reunió unos millones vendiendo camisetas y ahora quiere revolucionar la informática (porque el lo vale), un día el jefe llega y dice vamos a hacer un programa de CAD que desbanque al AutoCAD. Uno se queda esperando por lo que debería venir a continuación. A ver cuáles son esas ideas para un programa de CAD revolucionario. Pero no las hay, eso ya lo hará el programador que contratemos. Al final, si a caso el jefe nos dirá donde colocar los botones de dibujado para que el programa sea bueno de verdad, este tipo de casos tendrían que conllevar incluso penas de cárcel. Es por ello que el artículo 1 es fundamental. Las prácticas como ésta llevan a un total desperdicio de tiempo, dinero, paciencia y todo tipo de recursos, vamos ahora con el segundo artículo de nuestro estatuto:

artículo 2: el uso del PowerPoint y herramientas similares será perseguido y castigado.

Admito que puede parecer demasiado radical. Cierto es que, a la hora de exponer algo a un público, unas transparencias pueden venir bien. Pero en los últimos años, estas herramientas se han convertido en el único objetivo de trabajo de un montón de desorientados. Es uno de los casos donde el medio acaba convirtiéndose en el propio fin. ¿a cuantas presentaciones vacías de contenido hemos de asistir para darnos cuenta?
Una herramienta que permite a cualquiera hacer una presentación consigue implantar la creencia de que todos tienen algo importante que decir, ahora mismo la relación señal/ruido en cuanto a presentaciones es baja en todas partes. Montones de personas en esta industria llegan cada día al trabajo para abrir inmediatamente el PowerPoint y ponerse a hacer la presentación de mañana. Vendemos humo, pero vendemos humo con colorines, animaciones, gráficas dinámicas y sobre todo, mucha negrita e imágenes del catálogo business, nadie que quiera decir algo necesita esa parafernalia. Siempre se han hecho diapositivas, pero se hacían de otra forma, y no se hacía una presentación cada dos días. Lo que estos programas han creado, es una cultura del PowerPoint. El lector puede estar pensando ahora que el hecho de que un cuchillo pueda usarse para matar, no quiere decir que haya que prohibir los cuchillos. Efectivamente, pero si nos fijamos en el artículo 2, nadie bien de prohibir las herramientas. Se trata de perseguir y castigar su uso. ¿cuántas veces hemos querido decir ese gráfico no dice nada, es más, causa confusión, vas a ir a la cárcel chaval? Que ocurra alguna vez es aceptable, pero no que ocurra todos los días, miles de veces, en todas las empresas al mismo tiempo.

Y finalmente vamos con el tercer y último artículo por ahora:

artículo 3: se prohíbe el desarrollo de ningún programa que no sea susceptible de ser programado por una sola persona.

Esto no quiere decir que no puedan trabajar varios en él. Pero un programa que no pueda ser hecho por un sólo programador esta, sencillamente, mal pensado. ¿Qué pasa con los grandes sistemás complejos? Antiguamente se tendía al desarrollo de grandes programas monolíticos que tenían un montón de funcionalidades. Enormes sistemas de gestión que controlaban hospitales enteros, sistemas operativos que lo controlaban todo con el mismo código.

Ahora, la tendencia en el mundo ha cambiado. Esos grandes sistemas se desglosan en pequeños programas. Los sistemas de gestión se componen ahora de muchos servicios distintos que se interconectan usando múltiples protocolos. Los programás complejos de por si se reducen al mínimo de funcionalidades y se dejan puertas a la integración con otros programas que hacen otras cosas, con esta política de desarrollo, sin duda mejor que la otra, se consiguen programas que hacen unas pocas cosas muy bien. Los programas son más pequeños y por tanto más sostenibles. Incluso los sistemas operativos se dividen ahora en módulos totalmente independientes encargados de tareas específicas. Los clientes prefieren también estas soluciones, porque.

Cuando quieren añadir algo nuevo al sistema no tienen que reemplazarlo todo. Pueden comprar el sistema de visualización de esta empresa, la gestión de bases de datos de esta otra y el interfaz web de la de más, allá, pero aquí los empresarios no parecen haberse dado por enterados. Salvo unas pocas muy buenas, la mayoría de pequeñas empresas que quieren crecer se obsesionan con sacar un programa que lo haga todo. Tiene que servir para hablar por teléfono, para grabar CD, para gestionar los clientes, para mandar un mail, etc. Sólo las grandes compañías parecen adaptarse a este nuevo modelo de desarrollo. Pero es que en España, éstas llevan tiempo haciendo meras tareas de fontanería informática. En las pequeñas que se dedican a nuevos proyectos se cometen muchos errores. Incluso, aunque parezca que los productos que se plantean son muy especializados, al final se le pide al programador que implemente todo tipo de funcionalidades que en ese programa no tienen ningún sentido. El resultado son programas que hacen un montón de cosas, pero ninguna bien, hay unos pocos ejemplos de empresas en España que triunfan con productos específicos y de calidad. No sólo por el personal de calidad, además tienen muy claro el objetivo del desarrollo. Por desgracia empresas así no abundan. Pero con pocas que sean, se demuestra que no es imposible, aquí acaba este primer boceto del estatus del programador. Aunque son sólo tres directivas, son cruciales para arreglar el desastre local que sufrimos. Todo el mundo está invitado a intentar completar la lista de artículos en caso de que me haya olvidado de algún aspecto, ahora llegamos a la pregunta final. ¿Qué hacer? Lo primero abandonar ese tipo de empresas y convertirnos en su competencia. Muchos programadores deciden muy acertadamente ponerse a trabajar por cuenta propia. No todo el mundo se atreve debido a diversas razones. Entre ellas hay dos muy comunes.

La primera es el miedo a perder la tranquilidad de que vas a cobrar a final de mes. Pero esta tranquilidad no es más que una ilusión. Si en un momento dado la empresa deja de funcionar dejaras de cobrar. Y el problema es que no puedes hacer nada al respecto. Es decir, es posible, muy posible, que un grupo de inconscientes estrelle la empresa contigo dentro. Cuando sólo dependes de ti mismo o de otros como tú al mismo nivel, sí se puede hacer algo. Depende sólo de que hagas las cosas bien, la segunda es una extraña concepción de la moral. Hay gente que considera incorrecto o desleal irse de una empresa para ir a hacerle la competencia. Hay que deshacerse de esa barrera imaginaria. La empresa no dudaría ni un segundo en prescindir de tus servicios si ya no te necesita. Tampoco veras un céntimo de la riqueza que hayas podido generar más, allá de tu mísero sueldo. No sólo se debe hacer por uno mismo, los programas merecen ser bien hechos, por desgracia uno no puede decirle a su jefe que va a ser 10 veces más productivo y que quiere cobrar por lo tanto diez veces más. Tomo prestada esta frase de Paul Graham. Entre sus ensayos podemos encontrar un montón de consejos a la hora de lanzar iniciativas de empresa. Al contrario que yo, el es un hombre con experiencia en este campo. Su colección de bombazos empieza en el 95 con un sistema de comercio electrónico que vendió a Yahoo y que le hizo inmensamente rico, obviamente no estamos hablando del típico que hizo dinero vendiendo ADSL y que ahora quiere hacer programas. Estamos hablando de un gran programador, la falta de ambición es otro gran problema local. Nadie piensa ni de lejos que puede llegar a hacerse inmensamente rico con un producto. Algunos lo dicen, pero ni ellos ni los que les rodean creen realmente en ello. La gente aspira a ganar un poco de dinero para comprar un BMW y poder presumir en el barrio como hombre de negocios, como advertencia a todo aquél que vaya a salir al mundo laboral de la programación como asalariado, aquí viene lo que encontrara:

salarios bajos. Dependiendo de la región, el sueldo de principiante va desde los 15000 a los 24000 euros al año. Teniendo ya cierta experiencia se puede llegar con suerte a los 30000. A modo de comparación, en Inglaterra, un sueldo de programador raso es de 50000 libras. Unos 80000 euros. Al igual más o menos que el resto de Europa. No mencionamos ya los sueldos de Estados Unidos por no deprimir al lector. La excusa del precio de la vida ya no es valida. Aunque un DVD cueste más que aquí, en Alemania se puede alquilar un piso por 300 euros.

régimen de desprecio. Generalmente se apila a los programadores en algún cuarto apartado. Si viene alguien importante, o simplemente, el gerente de otra empresa, en caso de que los llegue a ver será a modo de y estos son los programadores. Igual que si se tratara de una jaula de monos. Muchas veces he querido colocar un cartel de no den de comer a los programadores. Este trato se debe a muchos motivos. Pero de todos ellos, el más sangrante es el miedo. El miedo a que alguien de fuera acabe haciendo una oferta a alguno de los programadores para que se vaya con él.

total anonimato. No tienes derecho a ningún reconocimiento externo por tu trabajo. El producto es de la empresa. Mejor dicho, del presidente de la empresa. Nadie vendrá a felicitarte por lo que has hecho y mucho menos veras un céntimo de los beneficios. En este país hay empresarios que serían capaces de poner a Miguel Ángel a esculpir, hacer millones con sus esculturas y pagarle una miseria de sueldo. Porque al fin y al cabo, el mármol que usa es mío. ¿te gustan las esculturas que hace mi empresa?

si no nos queda otro remedio que trabajar para una de estas empresas porque haya que pagar una hipoteca o cualquier cosa, mi consejo es el siguiente: jamás regalar ni una sola idea a la empresa. Si se te ocurre cualquier forma de hacer mejor las cosas, lo haces en casa. Lo desarrollas por tu cuenta y ya lo venderás, lo darás como código libre o lo que apetezca. Ya que nos tratan como a ganado, actuemos como ganado. No hacer nada que no se ordene explícita y detalladamente, no ha sido mi intención mostrar al programador como un individuo extremadamente valioso ni superior al resto de los mortales. El énfasis no se debe a una especial estima por la profesión sino al profundo agujero en el que se haya hundida. Pero existe el riesgo de que como pasó con otros colectivos marginados, se produzca un efecto rebote hacia la sobrevaloración. Convendría no esperar a que la herida fuera demasiado profunda o que todos hayan emigrado hacia otros países. Este mal no es además exclusivo de la industria del software. Todos conocemos el fenómeno de la fuga de cerebros que sufren todas las disciplinas intelectuales en España. Este caso es sólo uno más de la lista.
referencias.
o ensayos de Paul Graham:
http://www.paulgraham.com/articles.html.
o sobre PowerPoint: http://www.norvig.com/gettysburg/
http://www.unc.edu/~healdric/PowerPoint.html.

Yafray de la y a la y - Reflexiones sobre los proyectos de software libre.

cuando uno oye hablar del software libre por primera vez le asaltan un montón de dudas. ¿quién desarrolla ese software? ¿por qué se llama libre y no gratis? ¿gratis? ¿por qué se desarrolla y cómo? Si los roedores pudieran roerrobles, ¿cuántos robles roería un roedor? Intentaremos contestar a estas preguntas en el presente documento, siguiendo el ciclo de vida del proyecto en el que me he visto involucrado (en el sentido más amplio de la palabra) en los últimos años: Yafray.

Yafray. Bajo este nombre de lavavajillas se esconde yet another free raytracer, un raytracer gratuito y multiplataforma, creado por mi gran amigo Alejandro Conty Estévez. Un raytracer es un programa que se vale de una técnica llamada Raytracing para generar imágenes fotorrealistas con un computador, su desarrollo comenzó en Julio de 2002. Inicialmente se trataba de un raytracer básico para el sistema operativo GNU/Linux. Posteriormente se le fueron añadiendo funcionalidades, una de las más importantes fue el cargador de escenas en un formato propio utilizando xml. De este modo fue posible la exportación de escenas desde programas de modelado para la posterior generación de la imagen utilizando Yafray, este hecho produjo un gran interés en comunidades internacionales relacionadas con el mundo de los gráficos tridimensionales (elysiun -ahora Blender artists, Blender.org, Wings3d.org, entre otras), creándose programas que permitían la exportación de escenas desde los modeladores más importantes dentro del software libre como son Blender y Wings3d, como fruto de ese interés se amplió el desarrollo de Yafray a otros sistemas operativos aparte de GNU/Linux. Primero se llevó a cabo la traducción para sistemas operativos Windows. De manera casi simultanea se desarrollaron versiones para Mac OSX, actualmente, Yafray se basa en un modelo de plugins, en el cual el motor de render esta contenido en una librería separada del cargador xml. De esta manera, es relativamente sencillo construir cargadores o invocarlo desde otros programas. A su vez, el motor de render (librería principal) es el encargado de cargar, en tiempo de ejecución, los plugins relativos a los métodos de iluminación (Shaders, luces, etc). Esta modularidad ha facilitado su integración con Blender, en un principio todo el trabajo de desarrollo recaía sobre Alejandro Conty. A medida que pasaba el tiempo y el interés por Yafray aumentaba, aparecían nuevos desarrolladores y colaboradores. Lo que empezó como un proyecto personal para pasar las horas del verano de 2002, se acabó convirtiendo en un largo proyecto de software libre que involucra a programadores de todo el mundo y con una comunidad de cientos de usuarios, antes de entrar de lleno en el proyecto Yafray, me gustaría sentar las bases del modelo de software libre, sin pretender un análisis exhaustivo sobre el ciclo de vida del mismo. No hablaré aquí sobre herramientas de ingeniería.

O de desarrollo de una manera profunda. El objetivo de este documento, que es el apoyo a la charla del mismo nombre, es introducir al lector en la problemática del software libre, reflexionando sobre las motivaciones de sus desarrolladores, entendiendo el funcionamiento de las comunidades que orbitan alrededor de estos proyectos y sopesando las ventajas e inconvenientes de este modelo, existen multitud de estudios a este respecto mucho más precisos que este, en su mayoría elaborados con rigor científico por personas más capacitadas, pero no dejes de leer aún. Aunque no vayas a encontrar aquí una fuerte base teórica de ingeniería del software (libre), puede que te resulte interesante la experiencia del desarrollo del Yafray, ¿cómo se nutre de aportaciones desinteresadas y sobre todo, ¿cómo esta comunidad de desarrolladores y usuarios se apoya en otras comunidades mayores.

software libre.

Es de suponer que alguien que le sobre la evolución de proyectos de software libre sabe a qué se refiere ese tipo de software. Pero como todos hemos sido lectores despistados en alguna ocasión, hay que comentar una vez más que el software libre, según la definición del proyecto GNU, es aquel software que ofrece al usuario las siguientes libertades:

libertad 0: la libertad de usar el programa, con cualquier propósito.

Libertad 1: la libertad de estudiar cómo funciona el programa, y adaptarlo a tus necesidades. El acceso al código fuente es una condición previa para esto.

Libertad 2: la libertad de distribuir copias, con lo que puedes ayudar a tu vecino.

Libertad 3: la libertad de mejorar el programa y hacer públicas las mejoras a los demás, de modo que toda la comunidad se beneficie. El acceso al código fuente es un requisito previo para esto.

en internet se puede encontrar una inmensa cantidad de literatura, documentación y faq sobre el esta filosofía. El lector que no esté familiarizado con el término debería detenerse en este punto y buscar información al respecto, no sólo para poder seguir con fluidez este documento, sino porque la idea que subyace bajo el concepto es digna de ser meditada. No hay que olvidar que dicha idea se ha convertido para muchos en toda una forma de vida, quizás el software libre parezca una idea actual, una vuelta de tuerca a las protestas contra el sistema. Incluso en EU han llegado a tachar de actitudes comunistas los principios en los que se basa. Pero realmente, aunque estemos acostumbrados al modelo de software propietario (comercial), en los inicios de la informática era imposible concebir el software como un producto aislado, susceptible de ser vendido.

Las licencias por el uso del software y las restricciones para ejecutarlo o copiarlo, sencillamente no existían, en aquellos tiempos los programas y las máquinas que los ejecutaban estaban íntimamente ligados. No existía el concepto de programa como pieza separada que se tiene hoy.

Tampoco había usuarios domésticos, sino que las personas que ejecutaban los programas solían tener muchos conocimientos de programación y por lo general eran científicos e ingenieros, entre estos usuarios expertos, lo normal era intercambiar y mejorar los programas, compartiendo sus modificaciones, que a veces recibían el nombre de hacks (de ahí la palabra hacker, tan mal utilizada en los últimos tiempos), uno de aquellos usuarios expertos era Richard Mathew Stallman (a veces nombrado por el acrónimo RMS, basado en su nombre de usuario en los computadores del mit), un personaje a la vez genial y controvertido, imprescindible para comprender el software libre, este físico, graduado en 1974 en Harvard, trabajaba en el laboratorio de inteligencia artificial del instituto de tecnología de Massachusetts (mit) desde 1971.

En su laboratorio disponían de una impresora que tenía ciertos problemas con la alimentación de papel, de manera que, se atascaba habitualmente y no había otra forma de descubrirlo que desplazarse hasta dónde estaba, Richard se puso en contacto con los fabricantes, con la idea de modificar el software que controlaba la impresora y hacer que enviase una señal al atascarse, de forma que no se perdiese tanto tiempo de trabajo, sin embargo, estos se negaron a facilitarle el código fuente, que son como los planos de un programa y que hace posible modificar su comportamiento.

Este episodio le contrarió mucho e hizo que terminase de consolidarse su idea de que el código fuente de los programas tenía que estar accesible para todo el mundo, movido por este deseo, abandonó el mit en enero de 1984, para iniciar el proyecto GNU.

GNU es un acrónimo recursivo qué significa GNU not Unix, GNU no es Unix, en referencia a que el proyecto busca desarrollar un sistema operativo de tipo Unix, pero libre, en sus comienzos, el proyecto GNU se concentró en desarrollar las herramientas necesarias para construir un sistema operativo, como editores y compiladores y en las utilidades básicas para la gestión del sistema.

Sobre 1985, Richard Stallman creó la licencia GPL (general public license) como mecanismo para proteger el software libre, sustentado sobre el concepto de copyleft. Mediante este concepto, se le da la vuelta a la idea de copyright, definiendo las cuatro libertades mencionadas anteriormente, uno de los conceptos que se suelen mezclar con el software libre (reconozco que me sucede habitualmente) es el de open source (código abierto). Podemos considerarlo como un error justificable, ya que en la práctica el software open source y el software libre comparten las mismas licencias. Aunque la FSF (free software foundation) opina que el movimiento open source es filosóficamente diferente del movimiento del software libre, apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric s. Raymond (autor de la catedral y el bazar y de fetchmail)y Bruce Perens (padre del proyecto Debian), que formaron la open source initiative (OSI). Buscaban darle mayor relevancia a los beneficios prácticos del compartir el código fuente, e interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto.

Estos defensores ven que el término open source evita la ambigüedad del término inglés free en free software, mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando cualquiera puede usar, modificar y redistribuir el código fuente de un programa. Esta es la idea subyacente de la obra de Raymond, la catedral y el bazar, que analizaremos más adelante. El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario Richard se puso en contacto con los fabricantes, con la idea de modificar el software que controlaba la impresora y hacer que enviase una señal al atascarse, de forma que no se perdiese tanto tiempo de trabajo, sin embargo, estos se negaron a facilitarle el código fuente, que son como los planos de un programa y que hace posible modificar su comportamiento. Este episodio le contrarió mucho e hizo que terminase de consolidarse su idea de que el código fuente de los programas tenía que estar accesible para todo el mundo, movido por este deseo, abandonó el mit en enero de 1984, para iniciar el proyecto GNU.

GNU es un acrónimo recursivo qué significa GNU not Unix, GNU no es Unix, en referencia a que el proyecto busca desarrollar un sistema operativo de tipo Unix, pero libre, en sus comienzos, el proyecto GNU se concentró en desarrollar las herramientas necesarias para construir un sistema operativo, como editores y compiladores y en las utilidades básicas para la gestión del sistema. Sobre 1985, Richard Stallman creó la licencia GPL (general public license) como mecanismo para proteger el software libre, sustentado sobre el concepto de copyleft. Mediante este concepto, se le da la vuelta a la idea de copyright, definiendo las cuatro libertades mencionadas anteriormente, uno de los conceptos que se suelen mezclar con el software libre (reconozco que me sucede habitualmente) es el de open source (código abierto).

Podemos considerarlo como un error justificable, ya que en la práctica el software open source y el software libre comparten las mismas licencias. Aunque la FSF (free software foundation) opina que el movimiento open source es filosóficamente diferente del movimiento del software libre, apareció en 1998 con un grupo de personas, entre los que cabe destacar a Eric s. Raymond (autor de la catedral y el bazar y de fetchmail)y Bruce Perens (padre del proyecto Debian), que formaron la open source initiative (OSI). Buscaban darle mayor relevancia a los beneficios prácticos del compartir el código fuente, e interesar a las principales casas de software y otras empresas de la industria de la alta tecnología en el concepto. Estos defensores ven que el término open source evita la ambigüedad del término inglés free en free software, mucha gente reconoce el beneficio cualitativo del proceso de desarrollo de software cuando cualquiera puede usar, modificar y redistribuir el código fuente de un programa.

Esta es la idea subyacente de la obra de Raymond, la catedral y el bazar, que analizaremos más adelante. El movimiento del software libre hace especial énfasis en los aspectos morales o éticos del software, viendo la excelencia técnica como un producto secundario deseable de su estándar ético. El movimiento open source ve la excelencia técnica como el objetivo prioritario, siendo el compartir el código fuente un medio para dicho fin. Por dicho motivo, la FSF se distancia tanto del movimiento open source como del propio término.

ingeniería del software.

La ingeniería de software es la rama de la ingeniería que crea y mantiene las aplicaciones de software aplicando tecnologías y prácticas de las ciencias computacionales, manejo de proyectos, ingeniería, el ámbito de la aplicación, y otros campos, este término es relativamente nuevo, ya que no apareció hasta finales de los 60, cuando ya existían grandes compañías informáticas. En aquella época, una serie de estudios sobre desarrollo de software llegaron a la conclusión de que existía una crisis del software. Esta crisis tiene los siguientes síntomas:

el software no es fiable y necesita de un mantenimiento permanente.

El software se entrega muy a menudo con retrasos y con unos costes superiores a los presupuestopuestados.

A menudo el software es imposible de mantener, carece de transparencia y no se puede modificar ni mejorar.

Como solución a esta crisis surge la idea de aplicar un proceso de ingeniería para el desarrollo de software. Según la definición del explorer, la ingeniería del software es un enfoque sistemático y cuantificable al desarrollo, operación (funcionamiento) y mantenimiento del software: es decir, la aplicación de la ingeniera del software, la ingeniería, no sólo la del software, pretende aplicar con criterio el conocimiento matemático y científico obtenido a través del estudio, la experiencia, y la práctica. En la mayor parte de las ramas de la ingeniería es posible cuantificar con exactitud plazos, recursos humanos, costes y técnicas que lleven a cabo un determinado producto. Pero cuando ese producto se trata de software surgen los problemas, ya que aún no se han encontrado métodos de desarrollo y técnicas que permitan producir software de gran calidad con unos recursos limitados, a pesar de que la ingeniería del software ha conseguido notables éxitos, no es menos cierto que no ha sido capaz de superar la crisis del software. Hay quien piensa que más que de una crisis, estamos hablando de una enfermedad crónica. Es una reflexión plausible, más aun viendo como en los últimos años se han retomado viejos caminos bajo nuevas fórmulas de ingeniería. Quién sabe, quizás sean los nuevos modelos de desarrollos que permitan al software librarse de esta crisis, hasta hoy irresoluble.

ingeniería del software tradicional: software propietario.

Dentro del modelo propietario, la propia forma de desarrollar software ha sido quien ha llevado a la ingeniería del software a la crisis. No es una afirmación a la ligera ya que, como afirma Gregorio robles, el formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser verificados sistemáticamente por equipos de investigación independientes, es paradójico ver cómo el propio modelo de desarrollo destinado a evitar que un software robusto y potente pueda ser aprovechado por la competencia, impide la consecución del objetivo primordial: conseguir un software robusto y potente.

ingeniería del software libre.

No hay que entender al software libre como un competidor directo sobre el software propietario. Hay diferencias de base, como las razones motivacionales, casi filosóficas, de los desarrolladores. Tampoco se puede comparar a nivel económico, ya que el software libre sigue sus propias pautas de mercado y desde luego, no suele coincidir con el software propietario en la forma de obtener beneficios. Y lo que es más importante, la forma de producir software es totalmente diferente, la ingeniería del software no es ajena a todo esto y desde hace unos cinco años viene estudiando este nuevo modelo de desarrollo. En un principio podemos pensar que la propia naturaleza del desarrollo de software libre va a hacer fracasar cualquier intento de aplicación de ingeniería. Por ejemplo, si en el caso propietario la medición de costes es difícilmente cuantificable, en el caso del software libre tendremos que acudir a magos y hechiceros para que nos resuelvan la papeleta. Sin embargo, la transparencia en todos los procesos, la disponibilidad del código y en la mayor parte de los casos de todas las versiones de desarrollo, permiten que podamos analizar profundamente cualquier proyecto.

Enfermedad crónica. Es una reflexión plausible, más aun viendo como en los últimos años se han retomado viejos caminos bajo nuevas fórmulas de ingeniería. Quién sabe, quizás sean los nuevos modelos de desarrollos que permitan al software librarse de esta crisis, hasta hoy irresoluble, ingeniería del software tradicional: software.

Propietario.

Dentro del modelo propietario, la propia forma de desarrollar software ha sido quien ha llevado a la ingeniería del software a la crisis. No es una afirmación a la ligera ya que, como afirma Gregorio robles, el formato binario del software, la opacidad en los modelos de negocios, los secretos y barreras comerciales se encuentran entre las principales causas que han imposibilitado estudios cuantitativos y cualitativos a gran escala del software cuyos resultados pudieran ser verificados sistemáticamente por equipos de investigación independientes, es paradójico ver cómo el propio modelo de desarrollo destinado a evitar que un software robusto y potente pueda ser aprovechado por la competencia, impide la consecución del objetivo primordial: conseguir un software robusto y potente, ingeniería del software libre.

No hay que entender al software libre como un competidor directo sobre el software propietario. Hay diferencias de base, como las razones motivacionales, casi filosóficas, de los desarrolladores. Tampoco se puede comparar a nivel económico, ya que el software libre sigue sus propias pautas de mercado y desde luego, no suele coincidir con el software propietario en la forma de obtener beneficios. Y lo que es más importante, la forma de producir software es totalmente diferente, la ingeniería del software no es ajena a todo esto y desde hace unos cinco años viene estudiando este nuevo modelo de desarrollo. En un principio podemos pensar que la propia naturaleza del desarrollo de software libre va a hacer fracasar cualquier intento de aplicación de ingeniería. Por ejemplo, si en el caso propietario la medición de costes es difícilmente cuantificable, en el caso del software libre tendremos que acudir a magos y hechiceros para que nos resuelvan la papeleta. Sin embargo, la transparencia en todos los procesos, la disponibilidad del código y en la mayor parte de los casos de todas las versiones de desarrollo, permiten que podamos analizar profundamente cualquier proyecto.

Pero. ¿quienes son los miembros de las comunidades? Al hablar de comunidades de software libre nos suele venir a la cabeza un grupo de frikis discutiendo sobre Star Wars y las posibles consecuencias de enfrentar a Batman ya la masa. Es una injusticia que a las personas que amamos el software libre se nos encasille de esta manera, así que, es hora de desmitificar la leyenda. De todos modos, espero que quede claro que la masa patearía el culo a Batman, las comunidades de software libre son actualmente el objetivo de estudio de economistas, psicólogos y sociólogos. Se trata de una nueva forma de comunidad virtual, con reglas y jerarquías propias, y en muchos aspectos totalmente diferentes a las que conocemos en la sociedad tradicional. Saber quién forma parte de estas comunidades y cuáles son sus motivaciones es determinante para entender este movimiento.

En el caso de los desarrolladores las incógnitas son aún mayores, debido a que en una sociedad de consumo es difícil entender por que las personas dedican su tiempo libre a una actividad, aparentemente costos a y con beneficios directos prácticamente nulos, hay una gran cantidad de recientes estudios científicos que intentan definir el perfil del desarrollador de software libre. En el documento introducción al software libre de la UOC podemos leer:

«los desarrolladores de software libre son generalmente personas jóvenes. La media de edad está situada en torno a los 27 años. La varianza de la edad es muy grande, ya que el grupo predominante se encuentra en una horquilla que va desde los 21 a los 24 años, siendo la mediana - El valor que aparece con mayor frecuencia - Los 23 años.

Es interesante observar cómo la edad de incorporación al movimiento de software libre tiene sus máximos entre los 18 y 25 años, siendo especialmente pronunciada entre los 21 y 23 años, lo que equivaldría a la edad universitaria. Esta evidencia contrasta con la afirmación de que el software libre es cosa principalmente de adolescentes, aunque su presencia es evidente (alrededor de un 20% de los desarrolladores tiene menos de 20 años). En definitiva, podemos ver cómo los desarrolladores suelen ser mayoritariamente veinteañeros (un 60%), mientras que los menores de 20 y los mayores de 30 se reparten apartes iguales el 40% restante.»

en el mismo texto se hace referencia a otros estudios, en los que se llega a la conclusión de que la mayor parte de los desarrolladores, el 60%, tienen pareja e incluso un 16% tiene hijos. Con esto se acaba de desmoronar el mito del desarrollador de software libre como una persona adolescente y aislada, sin más conocimientos ni relación con el mundo exterior que los que llegan a través de su ordenador. El hecho de que el perfil del desarrollador coincida con el del universitario medio no debería chocarnos, a fin de cuentas, el movimiento del software libre tiene sus orígenes en ambientes universitarios. Richard Stallman recuerda su trabajo en el artificial intelligence lab del mit en los años setenta, cuando el software compartido se consideraba parte fundamental del proceso:

«a nuestro software no lo llamábamos software libre, porque ese término aún no existía, pero es exactamente lo que era. Cuando gente de otra universidad o una empresa querían un programa para hacerlo compatible y utilizarlo, se lo prestábamos con mucho gusto. Si veías a alguien usar un programa desconocido que te interesaba, siempre podías pedir que te dejaran ver el código fuente para así poder leerlo, cambiarlo o desmontarlo para crear un nuevo programa.»

sin embargo, otro de los grandes mitos se torna real en las encuestas. El software libre es desarrollado en su mayor parte por varones. La presencia de las mujeres en las comunidades varían entre el 1% y un 3%, compitiendo duramente por el protagonismo en las gráficas estadísticas con el error de muestreo, mientras que es relativamente sencillo saber la distribución de los desarrolladores según su edad, sexo y estatus social, averiguar las motivaciones por las cuales se emplea tiempo y, en ocasiones, dinero, resulta una tarea mucho más complicada. A veces los propios desarrolladores no tienen demasiado claras las motivaciones o, lo que es muy habitual, existe una conjunción de varios factores.

Desde luego las encuestas nos sirven para eliminar posibles causas de participación, la primera causa en ser descartada es la económica porque, aunque es totalmente factible obtener beneficios económicos con el software libre, estos beneficios nunca se podrán obtener de una forma directa por la venta de licencias, como en el caso del software propietario. Aun así, el 50% de los desarrolladores encuestados afirman haber obtenido recompensa económica como causa de su implicación en un proyecto de software libre. Sin embargo, hay muchos que no lo ven tan claro. El propio Richard Stallman, ante la pregunta de que debe hacer un desarrollador de software libre para ganar dinero, suele responder: puede trabajar de camarero. Personalmente opino que quitando la palabra libre a la pregunta, la respuesta no varía, al ser preguntados por su ocupación profesional, los desarrolladores se definen como ingenieros software (33%), estudiantes (21%), programadores (11%), consultores (10%), profesores de universidad (7%), etc. Es interesante observar cómo, a pesar de que en el software libre no se aplican técnicas clásicas de ingeniería del software, hay tres veces más de personas que se definen a sí mismos como ingenieros de software antes que programadores.

Una vez descartada la motivación económica se suele recurrir al ego de los desarrolladores. Si el lector estaba pensando en desarrollar software libre buscando la fama, puede ir olvidando la idea. En el documento: free/libre and open source software-ware: survey and study -part IV de Ghosh, Glatt, Krieger y robles (2002) se incluyó una pregunta, dirigida a los desarrolladores, para que indicaran a que colegas de una lista dada conocían, no necesariamente de manera personal. Los resultados fueron determinantes, la mayor parte de las personas conocían a pesos pesados del desarrollo, personas como Stallman, Icaza (Gnome)o Torvalds (Linux), eran conocidas por la práctica totalidad de los encuestados. Ni.

Que decir tiene que son personas que se dedican a algo más que al desarrollo y que tienen grandes connotaciones filosófico-históricas dentro del mundo del software libre. Lo curioso es que otros grandes desarrolladores que venían en la lista, como Jörg Schilling (Cdrecord), Marco Pressenti Gritti (Galeón), Guenther Bartsch (Xine)o Bryan Andrews (apache Toolbox) tenían el mismo grado de popularidad que Martín Hofstede o Ángelo Roulini, personas inexistentes y hábilmente añadidas por los encuestadores para averiguar el margen de error de las encuestas, así que, amigo lector, olvide el desarrollo del software libre como vehículo para obtener fama y fortuna.

A menos, claro está, que sea realmente bueno sirviendo copas y que su aspiración sea obtener la misma fama que las personas que no existen, aunque no sé han realizado estudios rigurosos, podemos afirmar que el proyecto Yafray encaja en los valores medios comentados anteriormente. Comparte una parte de su comunidad con Blender. Martine Albers de la Ámsterdam university realizó un estudio sociológico entre 746 personas de la comunidad de desarrolladores y usuarios de Blender, entre los que nos encontramos gran parte de los miembros del proyecto Yafray, se refrendaron algunos datos anteriormente comentados, como la baja participación femenina. No obstante, en el caso de Blender, la horquilla de edad es mayor (un 85% entre 15 y 35 años), sin duda debido a que existe una gran cantidad de usuarios adolescentes. Sin embargo, sólo un 21% de los encuestados reconocían haber desarrollado parte del software, un dato interesante es que el 91% de los encuestados se consideraban usuarios de Blender, lo cual supone que los desarrolladores son, además, usuarios del producto final, en cuanto a las motivaciones que llevan a las personas a formar parte de la comunidad de Blender, la respuesta obtenida fue la siguiente (ordenada de mayor a menor motivación):

entretenimiento. Participar por diversión.

Altruismo. Querer ayudar a la gente sin obtener nada a cambio.

Ayuda a la comunidad. Participar porque estás comprometido con la comunidad.

Reciprocidad. Querer ayudar a la gente y esperar recibir algo a cambio.

Reputación. Participar para labrarse una reputación.

Mejoras en el software. Participar por querer o necesitar mejoras en el software.

Recompensa económica. Participar para ganar dinero.

Como se ve, las motivaciones que se pueden considerar más egoístas son las que están menos presentes. De hecho, en el propio estudio se resalta la inesperada posición del altruismo entre las motivaciones.


La catedral y el bazar.

En 1997 Eric s. Raymond escribió el primer documento que trataba de describir las características de los modelos de desarrollo de software libre, comparándolas con el modelo propietario. El artículo, como hemos mencionado antes, se titula la catedral y el bazar y se ha convertido en uno de los más conocidos y criticados del mundo del software libre, hasta el punto que para algunos supone el comienzo de la ingeniería del software libre, Raymond establece una analogía entre el modo de construir las catedrales medievales y la forma de clásica de producir software. En ambos casos existe una distribución de tareas diferenciada, en la que el diseñador está por encima de todo, controlando el desarrollo de la actividad. También la planificación está totalmente detallada desde el principio, marcando las funciones de cada uno de los participantes y las técnicas que han de utilizar para llevar a cabo su labor, dentro de esta idea de catedral no sólo esta incluido el desarrollo clásico de software propietario. Raymond encuentra que proyectos de software libre como GNU o NetBSD están fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Si una persona quiere entrar a formar parte del equipo de desarrollo, los supervisores del proyecto le asignan un rol y una tarea. Además, este tipo de proyectos tiene unas entregas del software releases espaciadas en el tiempo siguiendo una planificación bastante estricta.

En contraposición al modelo de la catedral esta, según Raymond, el modelo del bazar. En un bazar no existe una autoridad que controle todos los procesos que se están desarrollando ni que realice una planificación de lo que ha de suceder. Los roles de los participantes son difusos, ya que los vendedores se pueden convertir en clientes, y viceversa, sin indicación externa, al contrario que en el modelo de la catedral, en el bazar hay entregas tempranas del software (reléase early). En el caso de Yafray, ¿cómo se ha dicho, se liberó desde prácticamente el primer momento. Esto suele motivar que aparezcan rápidamente personas que tenían el mismo problema (en el caso de Yafray, que querían desarrollar un raytracer)o que puedan estar interesadas en la solución (que necesitan lo que Yafray les puede ofrecer), las pruebas son, ¿cómo se ha comentado, una de las labores más pesadas en el desarrollo de software. Afortunadamente son un proceso altamente paralelizable. La reléase early de Yafray permitió que muchas personas se pusieran a probar el software simultáneamente, llevando así a cabo la fase de pruebas. Su uso aumentó drásticamente cuando Andrea carbone realizó la primera versión de Yable, un exportador de escenas desde Blender programado en Python. De este modo Andrea, usuario de Blender, se convirtió en desarrollador de parte del proyecto dentro del bazar Yafray, este tipo de relación en que todo el mundo puede aportar algo es altamente productiva. Los usuarios encuentran motivación en encontrar, notificar y corregir errores, ya que saben que su petición va a ser atendida casi inmediatamente. Además, existe cierta satisfacción personal por haber aportado algo, algo, así como un yo también he puesto mi granito de arena de cara al reconocimiento de la comunidad. De hecho, algunas comunidades se apoyan en una meritocracia, es decir, las decisiones más importantes las toman las personas que más aportan a la comunidad, el modelo del bazar, con frecuentes entregas del software, puede asustar a usuarios que buscan la estabilidad. Algunos proyectos, como Blender, mantienen ramas diferentes de desarrollo. Una más estable, en la que las nuevas funcionalidades sólo se añaden después de muchas pruebas, asegurándose que no repercuten en la estabilidad del producto final. Y otras experimentales como Tuhopou, The Evil Tree o la reciente rama orange, creada específicamente durante el desarrollo del corto Elephant dreams, pero el bazar no es solo aplicable a los desarrolladores. En ocasiones la vorágine del bazar intimida a nuevos usuarios, lo cuales pueden llegar a encontrar bruscos algunos comportamientos de los usuarios más antiguos. Este recelo de los veteranos de la comunidad suele ser debido a la repetición sistemática de los mismos errores por parte de los nuevos miembros.

Como ejemplo de esto, en la tristemente extinta comunidad de usuarios de Blender hispanos, nicodigital, los nuevos usuarios realizaban las mismas preguntas de novato una y otra vez. Los usuarios más veteranos se cansaban de repetir las mismas respuestas continuamente. Se llegó a hacer famosa la frase ¡usa el buscador, en relación al poco uso que daban los novatos al buscador del foro para encontrar posibles respuestas a sus preguntas. Con el doble fin de evitar preguntas innecesarias por parte de los nuevos y motivar a los veteranos a contestar, el administrador del foro (Nicolás morenas, alias Caronte) creó un sistema de créditos. Los créditos se obtenían, entre otras formas, por visitar la web y contestar preguntas, mientras que se perdían por realizarlas. A los pocos meses se creó toda una sociedad basada en el intercambio de créditos. Es una lástima no haber podido seguir la evolución de este experimento, ya que la imposibilidad de mantenerse económicamente, junto con una serie de desavenencias, precipitaron el cierre de la comunidad, a pesar de la buenas intenciones en el modelo del bazar, las decisiones tienen que estar controladas. Raymond supone que todo proyecto de software libre ha de contar con un dictador benevolente, una especie de líder que generalmente coincide con el fundador del proyecto, para guiarlo reservándose siempre la última palabra en la toma de decisiones. Sobre el papel, esa persona ha de saber motivar y coordinar un proyecto, entender a los usuarios y desarrolladores, buscar consensos e integrar a todo aquel que pueda aportar algo al proyecto. Pero la realidad es que esa persona, ¿cómo queda dicho, suele ser el propulsor original de la idea. Por tanto es un desarrollador al que le apasiona producir software, pero que, habitualmente, se preocupa poco por los usuarios y las relaciones dentro de la comunidad. Este tipo de desarrolladores suele ver cómo una perdida de tiempo las labores de ingeniería social organizativa.

Yafray: de la catedral al bazar organizado.
Yafray ha seguido desde un principio el modelo de procesos en el software libre. Surge como un proyecto personal y la persona que lanza el desarrollo es la que realiza las labores de dictador, considerado por todos benevolente porque si no, nos pegara, inicialmente, en la primera etapa de liberación del código (versión 0.0.1), la página web de Yafray era un simple documento html de fondo blanco con letras negras. Contenía una explicación del proyecto, un par de imágenes y un enlace al código. Si Yafray hubiese sido una empresa, esta presentación tan pobre habría desencadenado un suicidio colectivo del departamento de marketing. Desafortunadamente, Yafray no pudo hacer este favor a la humanidad ya que era un proyecto de un estudiante de informática. Aprovecho la ocasión para saludar a los chicos de marketing de mi empresa.

A pesar de esta puesta en escena tan austera, el proyecto tomó gran interés por parte de los usuarios de Blender, que, por aquel entonces no contaba con un motor de render de calidad. Este interés obligó a mejorar aquella web, incluyendo documentación extra y un foro para que los usuarios pudieran solventar sus dudas. Deberíamos reflexionar cómo una buena idea, en el momento adecuando, crece por si misma sin necesidad de envolverla en una nube de Bullshit dentro de extensas presentaciones de PowerPoint, ya hemos dado el primer paso de la catedral al bazar casi sin darnos cuenta. La necesidad de crear un foro de usuarios surge de la imposibilidad de Jandro para contestar a todos los correos de los usuarios, que emocionados con el nuevo raytracer no paraban de hacer preguntas. El arquitecto de la catedral pierde más tiempo en resolver dudas sobre el proyecto que en su desarrollo. La solución esta clara, permitir que la comunidad se comunique para que los usuarios más experimentados puedan ayudar a los nuevos, de manera casi simultanea al anuncio del proyecto, el hola Alfredo de Gref comenzó a aportar código, convirtiéndose en uno de los grandes impulsores del proyecto haciéndose responsable de la integración con Blender. Otros vinieron después, casi todas fueron pequeñas, pero importantes aportaciones. En poco más de un año Yafray contaba con una comunidad de usuarios grande, teniendo en cuenta el reducido ámbito del proyecto, en 2004, durante las jornadas boingboingblend, tuve la oportunidad de realizar una ponencia similar a esta. Entonces la situación de Yafray era bastante delicada. El proyecto estaba en crisis. Alejandro no tenía tiempo para dedicar al desarrollo, Alfredo estaba volcado en otros proyectos y no aparecían nuevos programadores. Por otra parte, la poca documentación que existía estaba desfasada y la web lleva años sin cambiar de aspecto. Mis conclusiones de entonces eran bastante pesimistas. El proyecto estaba en una situación de interbloqueo. Las pocas personas interesadas en colaborar, bien desarrollando código o documentando, no sabían cómo hacerlo porque la poca documentación existente era de mala calidad. Toda la información estaba en la cabeza de los desarrolladores, que precisamente carecían de tiempo para documentar. La pescadilla que se muerde la cola, el código no estaba libre de problemas. El diseño inicial, pensado para un pequeño raytracer ya no soportaba más parches para introducir las nuevas funcionalidades que los usuarios requerían. Eso llevó a Alejandro a pensar en empezar un nuevo diseño desde cero, mejor estructurado y con algoritmos de raytracer más avanzados. Para un programador interesado en colaborar era muy complicado ampliar el viejo código y el nuevo no era más que un esbozo.

Con este panorama, las pocas personas que intentaban ayudar, al poco tiempo escapaban del desastre organizativo que era el proyecto. Necesitábamos más compromiso y para ello optamos por un arma infalible: la vergüenza pública. Durante aquellas jornadas de Barcelona, en mitad de la ponencia pedimos a ciertas personas que colaborasen con el proyecto y que se comprometieran allí mismo, cara a cara con otros miembros de la comunidad. La jugada no salió mal: apenas recibimos amenazas de muerte y conseguimos que Javier galán diseñase una nueva imagen para Yafray y su web, mucho más profesional, en mi opinión aquello fue clave para el estado actual de Yafray. Dos años después, la documentación esta creciendo gracias al ingente trabajo de Álvaro luna. Mathias Wein ha tomado las riendas del proyecto, introduciendo grandes mejoras al código original, mientras el nuevo rediseño (llamado Fryrender) va madurando. Quiero agradecer desde aquí a estas personas y a tantas otras que con su trabajo, sus mensajes en los foros y sus trabajos artísticos de calidad profesional están consiguiendo que Yafray crezca cada día más.

desarrollo libre para el software libre.

Hemos hablado de la cooperación de las comunidades en el desarrollo de proyectos de software libre, pero ¿cómo se comunican sus miembros? ¿Qué herramientas se utilizan para coordinar los esfuerzos? Afortunadamente la comunidad de software libre se retroalimenta y existen multitud de herramientas libres útiles para el desarrollo de software y la cooperación entre personas de todo el mundo, los foros y las listas de correo son el epicentro de las comunidades. De hecho, son la parte visible de la comunidad. Ambas herramientas permiten la comunicación y las dos comparten la idea de facilitar el envío de mensajes a todos los miembros. Su diferencia fundamental el sentido en el que viaja la información. En las listas de correo la información llega pasivamente a los usuarios, los mensajes enviados a la lista llegan a toda la comunidad. Sin embargo, en los foros son los usuarios los que se acercan a la información. Por esto, las listas se deberían utilizar para intercambiar información útil para todos sus destinatarios. Un ejemplo clásico es una lista para los desarrolladores, donde cada miembro envía un registro de sus modificaciones, en los foros, sin embargo, el usuario es el que decide leer o no un mensaje. Se dividen en secciones y cada usuario le sólo la que le interesa. La información esta ahí, sólo hay que ir a buscarla. Son una herramienta útil tanto para usuarios como para desarrolladores. No sólo se utilizan para resolver dudas sobre el uso de un software, sino que sirven para poner en contacto a los desarrolladores y los usuarios, una de las herramientas que está invadiendo la escena del software libre es el wiki. Del hawaiano wiki wiki, rápido, es una forma de sitio web en donde se acepta que usuarios creen, editen, borren o modifiquen el contenido de una página web, de una forma interactiva, fácil y rápida. Dichas facilidades lo convierten una herramienta efectiva para la escritura colaborativa. En el proyecto Yafray, la instalación de un wiki (una wiki para algunos (algunas para algunos/as)) le ha permitido salir de la penosa situación documental que se encontraba durante el último año. Se está redondeando una documentación completa y actualizada. Además, la wiki ha permitido que los usuarios pudieran traducir por sí mismos la documentación a otros idiomas, como el español, portugués o chino, en cuanto al desarrollo en sí, hay que decir que Yafray empezó siendo desarrollado con herramientas libres, desde el compilador GNU hasta el VIM con el que Jandro tecleó las primeras líneas. Actualmente el único software propietario que se utiliza es el compilador visual c Toolkit (la versión gratuita del compilador de Microsoft para Windows). Aunque inicialmente se utilizó el Cygwin como herramienta de compilación para Windows, la idea se abandono ya que la integración con Blender, usando Yafray como plugin, requería el uso del compilador de los de Redmond, en el momento en el que más de una persona aportaba código al proyecto se hizo necesario el uso de una herramienta para el control de versiones, cvs en el caso de Yafray. El cvs (concurrent versións system), implementa un sistema de control de versiones: mantiene el registro de todo el trabajo y los cambios en la desarrollo de un proyecto (de programa) y permite que distintos programadores colaboren. La mayor parte de los proyectos de software libre utilizan esta herramienta o la más avanzada subversión, para terminar este pequeño repaso por las herramientas de desarrollo quiero hacer una mención a las utilidades de tipo BugTracker, literalmente rastreador de errores. Se trata de una especie de foro (en muchas ocasiones se utiliza como tal) en el que los usuarios dejan constancia de los fallos que van encontrando en el software, permitiendo en muchos casos añadir sugerencias sobre nuevas funcionalidades (feature requests). El BugTracker permite asignar programadores al problema, que serán los encargados de investigar las causas del error y subsanarlo. Es una herramienta muy potente y que recomiendo a todos aquellos proyectos que empiecen a tomar cierta relevancia.

conclusiones.

El ámbito de aplicación y desarrollo del software propietario suele (o debe) estar definido de antemano. Se puede realizar una predicción, más o menos acertada, sobre la envergadura del proyecto, así como del número y perfil de los usuarios finales, pero el software libre es totalmente impredecible. Un proyecto inicialmente pequeño, comenzado desde cero por una única persona puede volverse muy grande en muy poco tiempo, el desarrollador que empezó por diversión empieza a ver qué los usuarios demandan su ayuda y piden nuevas funcionalidades al software. Aparecen los primeros bugs que hay que resolver, lo que genera nuevas peticiones de los usuarios. Todo empieza a dejar de ser divertido. Usuarios curiosos inundan la cuenta de correo del programador. Aparecen nuevas personas intentando colaborar. En este caos organizativo el desarrollador debe asumir que su proyecto es de interés para la comunidad, utilizando parte de su tiempo en la organización de la comunidad que se ha formado alrededor de su software. Muchos lo verán como una perdida de tiempo, pero es necesario, ya que una buena planificación a tiempo favorecerá un desarrollo más fluido del proyecto, los desarrolladores han de tener en cuenta que afortunadamente no están solo, ya que existen una amplia gama de herramientas libres que permiten crear comunidades organizadas. Sabiendo el potencial de estas herramientas se podrá poner en las manos de los usuarios la oportunidad de colaborar. Conociendo las alternativas y eligiendo los instrumentos adecuados se puede formar una comunidad que se automantenga, haciendo que sean los usuarios los que contesten sus dudas y escriban la documentación, uno de los principales errores de Yafray fue descuidar estos aspectos y ha costado mucho levantar el vuelo. Si tú, amigo lector, estas empezando a desarrollar software libre ten en cuenta que deberás dedicar parte de tu tiempo al cuidado de las personas que se agrupan alrededor de tu proyecto. Si por el contrario lo tuyo no es programar y el menú del vídeo es todo un misterio para ti, no te preocupes. Hay mucha labor que hacer en el proyecto de tu software favorito. Cualquier aportación, como ayudar a los usuarios más inexpertos, puede hacer mejorar el software, no quiero terminar sin agradecer a Alejandro Conty la oportunidad de participar en un proyecto como Yafray. Mil gracias también a Alfredo de Gref, Javier galán, Mathias Wein, Álvaro luna y a toda la comunidad hispana e internacional de usuarios de Yafray, con especial cariño a los de Blender.

Llegados a este punto sólo queda contestar a una pregunta: ¿cuántos robles roería un roedor, si los roedores royesen robles? Bien, un roedor no roería robles, ya que los roedores no roen robles, pero si un roedor pudiera roer y royera alguna cantidad de robles, ¿cuántos robles roería un roedor? Aunque un roedor pudiera roer robles y, aunque un roedor royera robles, ¿debe un roedor roer robles? Un roedor debería roer si un roedor pudiera roer robles, siempre que el roedor royera robles.

Referencias[/SIZE]

o Gregorio robles. ingeniería del software libre. Una visión alternativa a la ingeniería del software tradicional. 2002.
o Jesús González Barahona, Joaquín Seoane, Gregorio robles. introducción al software libre. 2003
o Eric s. Raymond. la catedral y el bazar. 1997
o Martine Albers, motivation for participating in an online open source software community. 2004
o https://pulsar, unizar.es/gluz/manual-sl/c35.html
o https://es.wikipediaorg

¿la retrocomputación está de moda?
Javier Belanche Alonso.
xbelanch@gmail.com:


¿la retrocomputación está de moda? Es evidente que sí. El sentimiento de nostalgia por la tecnología del ordenador personal, consolas y máquinas recreativas (no puedo encontrar un nombre mejor) de la época comprendida entre mediados de los 70 y 80, ha ido tomando mayor fuerza y visibilidad en el momento actual.

Esta charla tratara de describir las diferentes manifestaciones de la retrocomputación y, en particular, de la necesidad para muchos de volver a repetir el embargo emocional que representa jugar, programar, construir y coleccionar la informática de 8 bits.

Un poco de historia.

El punto de partida es la aparición del primer videojuego comercial en Estados Unidos en 1974. Pong, idea y diseño de Nolan Bushnell y formalizado por el ingeniero de al Alcorn, inaugura el festival del ocio informático popular como la industria que, a excepción de un tiempo de crisis a mediados de la década de los 80, en la actualidad factura un volumen de ingresos superior a la del cine.

De la primera máquina recreativa surge la idea, poco más tarde, de Nolan Bushnell de trasladar la experiencia de las máquinas recreativas al entorno doméstico, reinventa un proyecto tan fallido como visionario, la consola Magnavox Odyssey. La edición home del pong fue un éxito de ventas de las navidades del 75. Es la época de confrontación entre Atari y Colecovisión por dominar el mercado de máquinas recreativas y consolas domésticas. Frente a la producción masiva de Colecovisión, la atari de Nolan Bushnell determinara, mediante el acto de la innovación, un tercer paso hacia la definición contemporánea de la consola: la invención del cartucho o la posibilidad de intercambiar juegos en la misma consola. Seguirán años de creatividad e innovación en cuanto al diseño y producción de juegos para dos mundos que conviven inevitablemente, el de las máquina recreativas, superior en calidad gráfica al segundo, y el de las consolas domésticas. Space Invaders, Pacman, Donkey Kong, Asteroids.



Se convertirán rápidamente en la primera colección de clásicos de la historia de los videojuegos. No sorprende, por lo tanto, que serán objeto de variaciones, con mejor o peor gusto hasta nuestros días y que tendrán representación en soportes y medios tan diferentes como singulares.

La segunda parte de esta historia la ocupa el ordenador doméstico. Tres años después del éxito de pong, Steve Jobs y Steve Wozniak presentan en 1977 el Apple ][, con el procesador 6502 de la casa y que tendrá un enorme eco comercial, en parte por su cualidad técnica y en gran medida por la aplicación de ofimática visual, la primera hoja de cálculo de la historia.

Pero el principal interés que nos trae aquí la obra de Wozniak y jobs es por un motivo clave para la evolución del videojuego: gracias al intérprete de basic, los usuarios podían desarrollar y programar sus propios juegos, almacenarlos y, finalmente compartirlos o venderlos. De nuevo, como fue en el caso de atari, la empresa Apple descubre una doble industria (la del software y la del hardware) que, en poco años, se inundará de un largo número de ordenadores domésticos, de los que destacamos la producción del Commodore 64, Sinclair ZX Spectrum 48k, MSX y CPC 464 de Amstrad. Durante los primeros cinco años de los 80, la explosión de creación de videojuegos para los modelos antes mencionados se verá reforzada por el desarrollo, entre profesional y el amateur, de muchos jóvenes que, aprenden a programar ensamblador para dos micros, el Z80 y el 6502, en sus habitaciones, aspirando a poder vivir de sus propios trabajos. No resulta extraño que, desde la perspectiva actual, se considera ese momento como la edad de oro del software español. Edad que vio su punto más álgido con la obra maestra del programador Paco Menéndez, la abadía del crimen.



Punto final a esta historia lo pondrá Nintendo o, por que no, del encuentro entre Yamauchi y Shigeru Miyamoto. En 1985 aparece la consola Nes de Nintendo y su juego estrella, super Mario Bros, y que culmina dos años más tarde con the Legend of Zelda.

Intenciones.

He clasificado el contenido de esta ponencia en función de unos pocos conceptos que engloban la gran totalidad de proyectos que han girado alrededor de la informática de 8 bits.

Coleccionismo.

Lowprogramming/hardwiring.

Emulación/recreación.

Reinterpretación/reinvención.

La mayor parte de manifestaciones o acciones retro puede referirse a estos cuatro apartados básicos, y que, si bien se pueden tomar por apartados independientes, la estrecha relación entre ellas se hará evidente a lo largo de la explicación de este texto. Empezaremos con el más pasivo de los cuatro, coleccionar, y acabaremos por el que más se aleja de la retroinformatica y sí se aproxima al medio de la práctica del arte actual.

Coleccionismo.

Coleccionar, reunir o agrupar objetos de una misma índole o tema, que despiertan un sentimiento entre nostalgia, pasión y deseo, es probablemente la categoría más pasiva de las cuatro. La acumulación de ordenadores domésticos de 8 bits, consolas, calculadoras no es diferente de la de coleccionar sellos, sin ocuparnos ahora si hay sospechas de un futuro fórum retroinformático. En España contamos con algunos de las colecciones privadas de retroinformatica más importante a escala internacional.

Sin duda, el componente de interés del coleccionismo es el encuentro con lo diferente, la excepción o la singularidad y, por lo tanto, con el objeto más preciado. Quiero destacar varias piezas, explicar su excepcionalidad como la magia y encanto que han suscitado desde su desaparición en el mercado informático. Es probable que la elección no sea la correcta, la mejor o la más representativa, pero cada vez que aparecen en subasta, los precios finales rebasan habitualmente los seiscientos euros.



En primer lugar, Júpiter hace de cantab, ordenador británico que, literalmente, nació muerto a principios de los 80. Creado por Richard Altwasser y Steven Vickers, parte escindida del equipo original del desarrollo del ZX Spectrum, el Júpiter ace heredaba del ZX81 su fisonomía, pero de superficie blanca. Micro Z80 a 3.21 Mhz con 3que de Ram ampliables a un máximo de 48 y una resolución gráfica de 24x32 caracteres en blanco y negro, el Júpiter ace se fundamentó en la estandarización de sus componentes digitales. El ace, a diferencia de las ULA (unidad aritmético lógica) de la línea Sinclair, se diseñó bajo el paraguas de la lógica transistor-transistor y, por lo tanto, con chips de serie. Quizá, su peculiaridad mayor fue el intérprete de Forth en lugar del habitual basic. El ace contenía una rom de 8que con el so y el intérprete de Forth. Aunque la velocidad de ejecución era superior al resto de intérpretes de basic del momento, el Júpiter ace se encontraba en desventaja frente a otras máquinas debido a su insuficiente capacidad gráfica como de sonido, limitando las ventas del ace hasta el punto de su desaparición tres años más tarde.



En segundo lugar, el Sam coupé, también británico, hace su aparición en 1989, cuando el mercado de los ordenadores domésticos de 8 bits ha entrado en caída libre. La empresa responsable fue miles Gordon technology. Al igual que el Júpiter ace, el Sam coupé tenía el Z80 de Zilog por microprocesador, a 1 Mhz de reloj, 256kb de Ram ampliables a 512 Kb. Una característica que luego se convirtió en motivo de confusión fue la posibilidad de ejecutar juegos de la gama Sinclair gracias al chip ASIC, compatible con el ULA del ZX Spectrum 48k. Confusión que llevó a entenderse el Sam coupé como un clónico ampliado del ZX Spectrum. Lamentablemente, después de tres cambios de propietarios, la producción del Sam coupé finaliza en 1992, tras 16000 unidades vendidas y con el imparable mercado del PC compatible como fondo.



Finalmente, el rainbow-i fue un ordenador de 8 bits que apareció en 1989 en la localidad de Manchester, bajo el diseño de los hermanos Ian y Stephen Smith, dos jóvenes apasionados de la electrónica digital, la informática, la música de Madcheter, la literatura y arte decadente inglés del siglo XIX y las drogas. El rainbow-i nunca superó las 100 unidades: la caja era de madera de cerezo, con grabados de ornamentación en gran parte de su superficie, se vendía a petición personal o se regalaba a colegas. Más en la línea del romanticismo del homebrew computer que de la producción comercial, el rainbow-i tuvo un cierto eco en revistas especializadas debido al uso de dos micros Z80 en paralelo, mejorando considerablemente la profundidad de color. Un año más tarde, Ian Smith se suicidó destruyendo toda la información y el poco stock disponible de los rainbow-i. De muy vez en cuando, aparece como artículo de subasta de Ebay, en particular de la región del Reino Unido, algún prototipo del rainbow-i, superando los 2500 euros.



Emulación/recreación.

Hablar de la vida de estas máquinas nos lleva a la segunda categoría, la emulación/recreación. La emulación es la solución pobre de una experiencia real, pero si sumamos la recreación, la sensación es mayor y más próxima al sentimiento original. La retro-emulación es un extraño virus: se extiende con suma facilidad a todas los dispositivos digitales actuales, desde relojes hasta las consolas de última generación, pasando por todas. El interés de la emulación es doble: la satisfacción que produce el reproducir el comportamiento de una vieja máquina, una cierta necrofilia digital y, una línea quizá menos habitual, pero no por ello menos atractiva y enriquecedora, la programación de emuladores de máquinas de 8 bits.

El principio que subyace la emulación en el campo de la informática es la compatibilidad. Que el software de un primer ordenador sea compatible con un segundo es posible sí, gracias si está disponible el código fuente y podamos compilar el binario en la segunda máquina. Tarea esta última difícil si entre las dos máquina la arquitectura es diferente. Un camino alternativo es la ilusión de poder emular el comportamiento del primer ordenador en el segundo. De esta manera podríamos ejecutar el software del primer ordenador sin dificultad en el segundo.

Los primeros emuladores de máquinas viejas de 8 bits aparecen a principios de los 90, con la desventaja de la todavía precaria velocidad del micro para ejecutar con suavidad el sistema emulado, como un emulador del Commodore 64 para amiga.

Con el rápido incremento de la velocidad de los microprocesadores para los PC compatible, la aparición a mediados de los 90 de una emuscene se cristalizó en los primeros emuladores de la serie de máquinas de 8 bits de principios de los 80, Sinclair ZX Spectrum, MSX, Commodore 64, amiga e incluso Apple ][, pero también las primeras consolas como la Nes, la super Nes o la Sega master system. La ventaja en cuanto a implementación y programación de estos emuladores es que todas estas máquinas guardan similitudes técnicas y de diseño muy parecidas, muchos compartían micros de 8 bits, Intel 8080, Motorola 6809, Zilog Z80 o MOS 6502. Las diferencias venían por los dispositivos externos (teclado, cintas o disco de almacenamiento) o el chip gráfico (la ULA famosa del ZX Spectrum) o del sonido.

Contrariamente a lo que podamos pensar, la documentación alrededor del diseño y programación de emuladores es bastante limitada y dispersa si la comparamos con el volumen de comunidades, proyectos y usuarios interesados en la emulación desde su arista más lúdica. En general, la motivación que hay detrás de la programación de emuladores es variada: aprender más sobre computación y la arquitectura de los ordenadores y consolas de 8 bits, saber cómo funcionaban los videojuegos de antes y que había detrás de ellos -pregunta muy razonable cuando éramos niños-y, desde un lado más humano, preservar la memoria de nuestra infancia.

Acorde al movimiento de la emuscene y del sentimiento de preservación del pasado de 8 bits, el 5 de febrero de 1997 Nicola Salmoria publica la versión 0.1 de mame, acrónimo de multi arcade Machine Emulator, siguiendo una filosofía estricta de la emulación a nivel de registros e instrucciones, contrariamente a la técnicas high level de emulación. La velocidad de la emulación no es tan importante como el grado de realismo de la emulación, por lo que mame dependerá siempre de velocidades de reloj enormemente elevadas para una emulación fluida.

Mame representa en la actualidad un gigante centro de gravedad en lo que se refiere al universo de la emulación de videojuegos: el número de juegos que alcanza emular está en los 10000, aunque también se sabe que alrededor de 600 se encuentran fuera de los límites de su emulación por mame. Al mismo tiempo, mame representa un quebradero legal: en cuanto a emulador, la pertenencia y distribución de mame es legal, su venta es ilegal. Respecto las rom, la mayoría están sujetas en la actualidad al copyright de la empresa o autores propietarios y, por lo tanto, imposible su venta y distribución. Esta situación se vuelve surrealista en función de la situación legal de cada país, en el hecho de que las Roms dejaron de ser objeto de mercado hace tiempo o que, rozando el ridículo, algunas empresas propietarias de las Roms dejaron de existir. Estas Roms pasan a ser consideradas huérfanas, pero mantienen paradójicamente su copyright, sin que por ello beneficie económicamente a nadie. Lawrence Lessig, padre del Creative Commons, debate y denuncia en la actualidad la irregularidad del copyright de los juegos huérfanos y defiende el traspaso al dominio público.

He mencionado más arriba la técnica de emulación high level, en contraposición de la filosofía seguida por los desarrolladores de mame. Dos años después de la primera versión pública de mame, se anuncia un nuevo emulador, ultrahle, que difiere en cuanto a metodología de emulación y, por tanto, el enfoque conceptual de emulación. A diferencia de mame, que representa la técnica lle (low level emulation) y concentra sus esfuerzos en emular a bajo nivel todo los componentes del sistema emulado, con especial atención en la CPU, ultrahle intenta adivinar que necesita el juego en cada momento y emula la petición con gran rapidez. De hecho, ultrahle se hizo enormemente popular en muy poco tiempo. Fue el primer emulador con éxito de la Nintendo 64, de juegos imposibles de emular como super Mario 64 y Zelda: ocarina of the time.

Ultrahle murió de éxito repentino. Pocas horas después de su publicación, los desarrolladores abandonaron el proyecto, aunque poco después, realityman, uno de los desarrolladores, volvió a la carga para sucumbir debido a las sugerencias de Nintendo para olvidar el proyecto, incluso la emulación.

Recreación.

La recreación es bicéfala: busca obtener una experiencia más rica al dotar a la emulación de un soporte físico específico y próximo al original. Las retromacas ilustran a la perfección esta idea. La lástima es que está recreación se limita a la habitación del retrogek. La recreación perfecta, casi como siempre, es colectiva y en este sentido la experiencia original se debería completar en una sala llena de humo de tabaco negro, ceniceros quemados y llenos de nicotina, el estar a punto de conseguir una bandera 10 en el galaxian mientras una multitud anónima y silenciosa admira tus movimientos y, ¿cómo no, un jubilado con mono azul y riñonera llena de monedas de 25 de las viejas pesetas.



La aparición de mame, su capacidad técnica para emular fielmente los videojuegos clásicos, lo convirtieron en el software ideal para la recreación de una máquina recreativa, o maca. La construcción/obtención/compra de una maca se ha convertido en sí mismo en fenómeno unido a la experiencia de la retro emulación. Podemos comprarla de segunda mano, readaptarla, recuperarla del cementerio de recreativas, podemos construirla desde cero (from scratch) y ser nosotros quienes definamos el diseño, entre el clásico y el cocktail, o estilo mesa. El mercado de kits de construcción de macas es cada vez mayor, se venden accesorios como los monederos clásicos, las arcade controls y tarjetas gráficas de frecuencias de refresco inferiores a los 60Hz, j-pac.



Hago un alto. He de hablar de la GP2x, sucesora de la malograda GP32. Tras una tortuosa gestación y sin llegar al año de vida en el mercado virtual (la consola oficialmente sólo se distribuye a través de internet), la GP2x ha sabido encontrar un público fiel y adepto a la retroinformatica. Gran parte de la atención recibida se debe a su orientación de desarrollo libre de videojuegos, aplicaciones y emuladores. Sin pasar del límite de los 170 euros, la GP2x contiene un firmware -finalmente-libre (basado en GNU/Linux) sobre un procesador arm9 de doble núcleo, velocidad reloj de 200 Mhz, almacenamiento en tarjetas SD, 64 Mb de Ram y resolución de pantalla de 320 por 240 (QVGA). Dispone de un SDK oficial igualmente bajo licencia GNU, aunque la mayoría de programadores prefieren usar SDL nativas de la GP2x.



Destacar la importancia de la escena española concentrada en la comunidad GP32spain, liderada por Franxis.

Al basar su sistema operativo en GNU/Linux, no ha sido raro que la consola se beneficiara rápidamente de las comunidades. Destacar que es la primera consola de mano que tiene un intérprete de Python (Pygame) y Ruby para el desarrollo rápido de videojuegos y aplicaciones.

Hardware emulation.

La máxima expresión de la emulación/recreación corresponde al uso de chips FPGA que traspasan la frontera misma de la emulación por software. Identificamos la clonación perfecta mediante la emulación por hardware al uso de la recreación de máquinas y consolas de 8 bits antiguas. Los chips de altera y Xilinx, el lenguaje VHDL y un enorme conocimiento de la máquina a emular (y tiempo, mucho tiempo) se suman para aparecer en forma de viejas máquinas recreativas y antiguos ordenadores domésticos. Quizá, del conjunto de proyectos basados en FPGA orientados a la retro experiencia, señalar sin duda el de Jeri Ellsworth, autodidacta en la programación de chips FPGA, el c-one.



C-one representa una iniciativa de Jeri Ellsworth por mejorar el Commodore 64 original, pero que finalmente derivó en una placa base que permitiera la clonación de cualquier máquina de 8 bits. C-one es una suerte de multi-hardware (en lugar de multiplataforma) que, mediante el uso de FPGA y una expansión modular de la CPU (que por defecto incorpora el 65c186 del Commodore 64) se logra implementar la emulación por hardware de cualquier máquina de 8 bits y que, por su naturaleza abierta y modular, permite nuevos diseños personalizados.

Hardwiring/low programming.

El año pasado, André Lamothe, autor especializado en la publicación de libros sobre diseño, creación y programación de videojuegos (cuenta con casi una veintena de libros), da un giro radical de contenidos y celebra una vuelta radical al pasado: crear videojuegos desde una perspectiva lowlevel: electrónica, diseño digital, programación en ensamblador, conocimiento del conjunto de instrucciones del micro. Esta vez el libro no es un simple recetario de algoritmos, ejemplos y código para nuestro enésimo proyecto de videojuego fallido en DirectX. En su lugar, el libro es una mezcla de curso de electrónica y justificación de la elección del diseño de la Xgamestation, una consola basada en el microcontrolador SX52 y de la que los usuarios pueden aprender a programarla -en ensamblador, por supuesto-o ampliar.



¿es la Xgamestation un caso aislado? Dentro del libro, Andre Lamothe explica el desarrollo de una edición mínima del Xgamestation, el pico edition. Un protoboard, el SX52 y un set de resistencias y algún condensador proporciona una infraestructura mínima en el que podemos jugar a nivel de montaje (hardwiring) y de programación del SX52 (lowprogramming), el pico edition no es novedad y André Lamothe debe su iniciativa a un anterior proyecto personal de un estudiante sueco de electrónica, Rickard Gune, al utilizar microcontroladores de la familia pic y SX para diseñar sistemas de videojuegos amateur. La sensibilidad homebrew console es evidente y trascienden el simple acto recreativo al puro cacharrismo make (revista actual dedicada al hardware y tecnología amateur): nuevos proyectos de homebrew computers (incluso con intérpretes de basic.) y homebrew games.

Homebrew games representa un paso final que nace desde el interés de la emulación de retro videojuegos, pasando por el estudio de cómo estos juegos se programaron entonces y finalmente programando un juego que probaremos en nuestro emulador favorito y que, una vez conseguido, desearemos transformar el juego en un cartucho.

La escena de los homebrew games es todavía muy incipiente. Programar en ensamblador en estos días parece un acto de excentricidad y de frikismo. Añadir la dificultad que ello comporta en cuanto al aprendizaje como el de un suficiente control para poder desplegar sprites y la animación de estos por la pantalla. El último reto, superado lo anterior, pasa por la fabricación del cartucho. De nuevo el puente entre el lowprogramming.

Al hardwiring o viceversa. Habitualmente, los pocos creadores de homebrew games tienen dos opciones: cambiar la rom de un viejo cartucho y reemplazarla por la nueva rom o, el más difícil todavía, crear tu propio circuito impreso (PCB) y el packaging del cartucho. Un ejemplo magistral de lo que hablo son las tiradas limitadas del juego I, ciborg, de George Peloni, para la mítica consola Vectrex.



La retroinformatica y el arte actual:la deconstrucción como reinvención de los clásicos.

He querido dedicar el último apartado de esta charla a las relaciones que, desde el 2000, se han ido estableciendo entre los videojuegos y el arte actual y que, tal como ya dije al principio, es la cara de la otra moneda del sentimiento del retrocoleccionista. Gran parte de la exploración del artista en la iconografía de los videojuegos remite a clásicos de los 70-80 como Arkanaoid, Asteroids, space Invaders, pong o Pac-Man. Generalmente, la finalidad de estas intervenciones es desvirtuar el propósito original del juego (matar marcianos, vencer a tu contrincante, ganar a la máquina o tomar todas las pastillas en un lugar oscuro bajo música electrónica.) y presentar un discurso diferente, contrario o inmerso en la ironía.

Si un estudio detallado de la relación entre el arte actual y los videojuegos escapa a los límites de esta charla, no pierdo la oportunidad de mencionar unos pocos, en particular dos: el proyecto Spaceinvaders y la Painstation.

Spaceinvaders es un proyecto personal del francés Invaders de intervención urbana: la invasión del espacio cristalizada en forma de pequeños mosaicos que, no es hola la elección del soporte, reivindican el píxel como unidad de medida gráfica. Sus mosaicos de Invaders están repartidos por toda la geografía del primer mundo, en especial Europa y Estados Unidos.



Painstation es una maca especial del tipo mesa. Los jugadores compiten en el clásico terreno del pong, a diferencia que, el jugador que pierde un tanto de partida recibe una descarga eléctrica.



Para saber un poco más.

Forster, Winnie, game. Machines, the encyclopedía of consoles, Handhelds & home computers 1972-2005, 2005, Gameplan.

Moya del barrio, Víctor, study of the techniques for emulation programming (by a bored and boring guy), 2001, UPC.

Kohler, Chris, retro gaming hacks, tips & tools for playing the classics, 2005, Oreilly.

Lamothe, André, the black art of video game console design, 2006, Sams.

Martínez, David de super Mario a Lara Croft, la historia oculta de los videojuegos, 2003, Dolmen editorial.

psicofisiología de la percepción.

Fernando arroba rubio.
gnotxor@gmail.com :

Cuando hablamos de percepción solemos tender a pensar inmediatamente en la percepción visual. Como sistema perceptivo dominante es el que analizaremos a continuación, tanto desde un punto de vista funcional como psicológico.

El ojo es una esfera que cumple con la estructura de una cámara oscura. Sus funciones son tanto ópticas como sensoriales. En su funcionalidad óptica se comportaría como una cámara fotográfica: su cometido es recibir la luz, a través del iris (diafragma) y enfocarla con su sistema de lentes compuesta de córnea y cristalino, ajustando los rayos luminosos sobre la retina (película sensible).

El sistema visual.

La esclera o esclerótida correspondería con la caja o cuerpo de la cámara. (hay que ver lo original que soy haciendo estas analogías). Aunque en realidad la analogía mejor no es la cámara fotográfica sino la de video.

Atravesamos las estructuras en la misma dirección que lo haría la luz y veremos su funcionalidad de manera rápida.

El ojo esta estructurado en tres capas: la superficial o fibrosa, que comprende la esclera y la córnea, la túnica vascular, tracto uveal o úvea, que comprende la coroidea, el cuerpo ciliar y el iris, y la túnica interior o retina, que incluye la porción fotosensible de la pared posterior del ojo.

La primera estructura que nos encontramos es la córnea. Tras atravesarla nos encontramos en la cámara ocular, un espacio lleno de líquido entre la córnea y el cuerpo vítreo. Este espacio se encuentra dividido en dos (cámara anterior y cámara posterior) por el iris. El humor acuoso que lo llena es el resultado de un ultrarrefinado de la sangre y su función es aportar nutrientes y oxígeno a la lente y a la córnea, que son avasculares.



Figura 1. Corte transversal del ojo, vista sagital.

Por último, en la parte posterior nos encontramos la retina. Es el elemento fotosensible. Podemos distinguir en la retina varias formas o estructuras especiales. Destacando el dico óptico y la macula. El primero es el punto ciego de la retina y la segunda presenta una fosa que es la zona más sensible a la luz.

Aspectos funcionales de la retina.

Podemos considerar la retina como la parte móvil del cerebro. Es una estructura del sistema nervioso central que se mueve con el ojo. No entraremos en las subestructuras que la componen sino en la funcionalidad de la misma, comenzando con los fotorreceptores, los conos y los bastones.

Bastones y conos.

Tanto los conos como los bastones son células receptoras alargadas. Ambos tipos de células difieren anatómicamente según se encuentren en el centro de la retina o en la periferia. Los bastones pueden medir 2 de diámetro en la zona central de la retina y llegar en las periféricas. Los conos de la fosa miden 1,5 mientras que los de las zonas que la rodean alcanzan de 5 a 8.

La rodopsina es el fotopigmento de los bastones. Los conos, por su parte, pueden contener tres fotopigmentos diferentes, sensibles a los 435 nm (azul) cianolabe, 535 nm (verde) clorolabe y 565 nm (rojo) eritrolabe.

La cantidad de energía radiante y las longitudes de onda son los factores físicos de la luz esenciales para el proceso visual. La cantidad de energía radiante se interpreta como brillantez mientras que las longitudes de onda son la base para la discriminación del color.

Los bastones son los sensores ligados a la percepción del blanco, gris y negro, respondiendo a todas las radiaciones del espectro visual e incluso a las de la banda ultravioleta. A diferencia de los bastones, los conos sólo son sensibles a diferentes longitudes de onda de manera selectiva.

La visión en color depende de dos procesos. El primero es la actividad receptora de tres tipos de conos. El segundo el procesamiento dentro del sistema nervioso central. Del primer proceso se sabe mucho y está bien estudiado, sin embargo, del segundo se desconoce prácticamente todo.

Teoría Dual de la visión.

La teoría Dual de la visión se basa en la concepción de la retina como si fuera un mosaico de cuatro tipo de receptores (los bastones y los tres tipos de conos). Los bastones son sensibles a la luz de baja intensidad y los conos se especializan en la visión en color y en el registro de detalles finos.

Las modernas variante de esta teoría no hacen hincapié en la distinta funcionalidad de conos y bastones, sino más bien en la interacción entre conos, bastones y otras neuronas retinianas.

Sin embargo, el nombre de esta teoría evoca otra dualidad curiosa. La dualidad de la luz, como partícula y como onda. Parecería que los bastones son sensibles a los fotones como partículas mientras que los conos lo serían como ondas.

Campos receptores de la retina.

En la retina de cada ojo existen unos 120 millones de bastones, 7 millones de conos y algo más de un millón de células gaglionares cuyas fibras forman el nervio óptico. La desigualdad entre el número de receptores y de células transportadoras evidencia el fenómeno de convergencia que opera en la retina. Esta convergencia es lo que conocemos como campos receptores. Un campo receptor es la superficie que cubren los receptores que estimulan al mismo neurocito ganglionar.

La fosa o macula carece de bastones y contiene entorno a los 4.000 conos y la misma cantidad de neurocitos. En ella, el campo receptor se corresponde con los 2 aproximadamente, lo que corresponde con un ángulo córneal de sólo unos pocos minutos. Esta zona es la región de mayor discriminación de la retina y la parte del objeto percibido con más detalle es el que se proyecta sobre esta zona.

En la retina periférica un campo receptor puede tener hasta $1mm$ de diámetro, lo que corresponde con un arco de 3º en el campo visual (que abarca 160º).

Estos campos receptores extrafoveales con sensores mezclados (conos y bastones) no son muy precisos, pero a cambio pueden trabajar con estimulaciones y umbrales más bajos.

Aspectos funcionales de la visión.

Para nosotros es imposible mantener los ojos quietos un solo instante, ni aun cuando concentramos nuestra mirada en algo, siempre se producen pequeños movimientos. Esta especie de barrido de alta frecuencia es esencial para mantener una imagen visual. Cuando experimentalmente se consigue mantener la proyección de una imagen sobre la retina de forma estática, la misma tiende a desvanecerse, a disminuir su coloración y a que sus contornos se desvanezcan, ¿cómo se puede advertir en la figura 2.



Figura 2. Si fijamos la vista en el punto central la corola parece difuminarse.



Figura 3. El efecto de inhibir los bordes tiene como resultado la aparición de puntos negros fantasmas.

agudeza de contornos y contraste.

En la percepción de los contornos se encuentra implicado un fenómeno perceptivo que se conoce como inhibición lateral. El fenómeno es un mecanismo de interacción entre las neuronas para enfatizar los límites. Por ejemplo, si colocamos un folio blanco sobre una zona negra. Los efectos de esta peculiaridad se pueden apreciar en la figura 3.

La percepción de los contornos, del color y del contraste, es por tanto, una apreciación distorsionada desde la misma recepción del estímulo. Algunos efectos son llamativos como el del ejemplo de Edward h. Adelson, que se puede apreciar en la figura 4. En dicha figura los cuadros a y b son exactamente el mismo tono de gris, sin embargo, el entorno y los contrastes con las zonas adyacentes hacen que se interpreten como cromatismos diferentes.

Adaptación, agudeza visual y visión cromática.

El ojo no es sensible siempre a la misma cantidad de luz. Un ojo adaptado a la oscuridad puede ser estimulado con una diezmilésima parte de la energía que estimularía al mismo ojo adaptado a la luz. Sin embargo, la velocidad a la que se adapta el ojo es variable. Se considera que se tarda una media hora en que el ojo se adapte a la oscuridad, mientras que la adaptación a la luz se realiza en pocos segundos.



Figura 4. Los cuadros marcados con la a y la b presentan el mismo matiz de gris sin embargo, son percibidos de manera distinta por el ojo.

La capacidad que tiene el ojo para adaptarse a la oscuridad no depende sólo de la cantidad de luz. Se ha comprobado que determinados estados de ánimo, la cantidad de oxígeno en sangre y otros factores influyen en la adaptación de la pupila.

La agudeza visual del ojo es la medida en que puede distinguir detalles. Dicho de otro modo: la agudeza visual la podemos medir como la distancia mínima entre dos puntos para que sean percibidos como tales y no como una sola forma. Por supuesto la zona de mayor agudeza de la retina es la fóbea.

Clínicamente la agudeza visual se mide con una fracción cuyo numerador es siempre 20. Ese número representa el número de pies (6 metros aproximadamente) que se toma por referencia. Es decir, una persona con una agudeza visual normal tendría un valor 20/20, es decir a veinte pies puede distinguir letras que se distinguen a 20 pies. Si tiene una agudeza visual de 20/100 quiere decir que está distinguiendo a 100 pies las letras que una persona normal distinguiría a 20. Si la agudeza visual es de 20/15 quiere decir que distingue las letras a tan sólo 15 pies.

La visión cromática es la interpretación que hace el cerebro de la recepción de distintas longitudes de onda y es por tanto una experiencia subjetiva. La interpretación de la luz amarilla cuando se estimulan simultáneamente receptores rojos y verdes se considera que es consecuencia del procesamiento cortical. La percepción del color es algo limitado a algunos vertebrados diurnos. Parece que durante la filogenia la percepción del color evolucionó de forma independiente muchas veces.

El tono de un color es la medida de la longitud de onda que se percibe, el rojo, verde, azul y amarillo son tonos diferentes.

El brillo de un color es la sensación subjetiva determinada por la cantidad de negro en el color. El más negro es el menos brillante, es decir, a mayor cantidad de negro se absorbe una mayor cantidad de luz y por tanto se refleja una cantidad menor.

La saturación o pureza de un color es la sensación subjetiva determinada por la cantidad de blanco dentro del mismo. El blanco altera el tono debido a que está compuesto por colores. Cuanto menos blanco tenga se dice que el color esta más saturado o es más puro su matiz.

El efecto Purkinje.

El efecto Purkinje debe su nombre a dicho experimentador que observó que había diferencias de percepción cromática en situaciones de poca intensidad lumínica. Observó que las flores ligeramente azules lo eran más a la caída de la tarde, mientras que en el crepúsculo las flores rojas parecían prácticamente negras. De hecho, esa es la explicación para la abundancia del color rojo en el fondo marino, muchos peces, corales y animales presentan dicho color para camuflarse en la oscuridad.

El ojo adaptado a la oscuridad es más sensible al verde, mientras que el adaptado a la luz lo es más al amarillo.

Postimágenes.

Las postimágenes son sensaciones ópticas que persisten después de presentado el estímulo y pueden ser de dos tipos: las postimágenes negativas y las postimágenes positivas.

Las postimágenes negativas se producen cuando miramos un estímulo durante unos 10 segundos y después fijamos la mirada en una superficie blanca. La imagen que se produce es complementaria al estímulo original. Tenemos un ejemplo en la figura 5.

La postimagen positiva se produce cuando un estímulo iluminado intensamente se presenta durante 2 o 3 segundos y después se cierran los ojos. Esta postimagen se parece al estímulo original en color y forma, aunque no en intensidad.



Figura 5. Mirar fijamente a la cruz durante unos 10 segundos y después fijar la mirada en la cruz de la derecha, la postimagen formada debería corresponder con los colores de la bandera española1.

Aspectos psicológicos de la percepción.

Uno de los factores que más influyen en la percepción es la atención. Todos conocemos la diferencia de actitud que hay entre ver y mirar o entre escuchar y oír. La atención es pues uno de los primeros factores psicológicos que van a modificar la percepción.

La atención dista bastante de ser una forma de información pasiva. Al contrario, consiste en modificar el estado de vigilancia sobre determinados estímulos, de forma que aumenta el nivel de alerta que producen los mismos. La cantidad de estímulos a los que puede atender el cerebro humano de forma simultanea esta limitada a un rango de 6 a 11, según los casos. Esta limitación se ve compensada por la concurrencia de otras características o propiedades funcionales.

Esta limitación de amplitud exige que se haga una selección de estímulos juzgando la relevancia de unos y otros. En esencia, sirven para establecer esta relevancia factores como el contraste, el tamaño, la intensidad y el movimiento de los objetos o estímulos.

Leyes de la percepción.

Las llamadas leyes de la percepción fueron formuladas en su mayoría por los llamados psicólogos de la forma o Gestalt. El gran número de éstas podemos reducirlo a tres grupos fundamentales: las que se refieren a la separación entre figura y fondo, las que aluden a las propiedades de las totalidades figurables y las que precisan las condiciones por las que se agrupan estímulos en figuras.

Por ejemplo, Helson definió cinco principios:
1. Ley de la primacía, en virtud de la cual los todos son primarios y aparecen con prioridad a las partes.
2. Percibir todos es más natural que percibir partes. Ley de la pregnancia.
3. Los todos (figuras) tienden a articularse de la forma más completa, simétrica, sencilla y perfecta posible. Ley de la buena figura.
4. La ley de la autonomía que los todos tienden a ser regulados por factores intrínsecos, más que por factores externos a ellos.
5. Finalmente, las partes derivan sus propiedades de su posición, o función en el todo. De ahí la posibilidad de que un mismo estímulo sirva de base a la percepción de figuras diferentes, como en el caso de las figuras reversibles. Ley de la flexibilidad del contorno.

Las leyes que rigen la agrupación de los estímulos mencionan los siguientes factores:
1. Proximidad: a igualdad de circunstancias, los estímulos más próximos tienden a percibirse como formando parte de un mismo objeto.
2. Semejanza: a igualdad de circunstancias, los estímulos más semejantes tienden a percibirse como formando parte de un mismo objeto.
3. Continuidad: a igualdad de circunstancias, tendemos a percibir como formando parte de una misma figura los estímulos que guardan entre sí una continuidad de forma.
4. Simetría: la tendencia a organizar los estímulos en una forma simétrica, puede competir con alguna de las anteriores leyes, por ejemplo, con la de la semejanza, y configurar unitariamente estímulos heterogéneos.
5. Constancia: la tendencia a percibir los objetos exteriores de una manera estable. Por ejemplo, si observamos un objeto a un metro de distancia y nos separamos de él, su imagen en nuestra retina se hace más pequeña, sin embargo, seguimos percibiendo sus dimensiones de manera constate.




Figura 6. Algunas figuras que ejemplifican las leyes de la percepción.

El número de las leyes de la percepción excede con mucho las expuestas aquí. Sería imposible en este espacio de tiempo hablar de todas ellas. Éstas, las expuestas por la Gestalt, junto con algunas otras como la de la constancia perceptiva, constituyen el cuerpo básico de las leyes de la percepción siendo las demás meros derivados o incluso redundancias de las mismas.

.

Técnicas de animación en Blender
Carlos López Yrigaray.
[email=Klópes@unizar.eKlópes@unizar, es[/email] :


el arte ha encontrado en la infografía su última forma de expresión, y la generalización de esta ha llevado a la aparición de un sinnúmero de artistas que, a su vez, han sabido transmitir su obra a través de la red. Recíprocamente, la popularidad de los programas gráficos, y en particular los que favorecen la creación de personajes y su animación, han impulsado la creación de programas de licencia libre como Blender y la mejora constante del software disponible en todos los ámbitos.

Estas mejoras se hacen especialmente patentes en cuanto a la facilidad de uso de las utilidades, permitiendo la creación de escenas expresivas con un esfuerzo menor, sin menoscabo de la capacidad artística, que se ve por el contrario más libre en cuanto a las limitaciones del programa.

Como el proceso de modelado, que ha pasado a dividirse en varios tipos (desde la creación de estructuras malladas polígono a polígono hasta la escultura virtual usando herramientas adecuadas), o la creación de materiales y entonación de la luz (que van pasando por sucesivas fases de calidad, refinándose para acercarse cada vez más a la realidad de una fotografía, o haciéndose tan manejables como para modelar el ambiente de forma creativa), el de la animación ha evolucionado hacia el modulado de la composición de acciones en una línea de tiempo, o la implementación de sistemas de toma de decisiones de los propios personajes mediante algoritmos de inteligencia artificial.

En esta exposición se pretende comentar el estado del arte en el momento de escribir estas líneas, en cuanto a la animación en Blender 3d, desde el movimiento de un objeto hasta las posibilidades de animar un personaje.

Moviendo Blender
El movimiento de un objeto lo definiremos tal cómo se usa en su sentido matemático, es decir: su desplazamiento por el espacio 3d, junto con sus giros y sus cambios de escala en los tres ejes de referencia, esto es: la modificación de su matriz característica.



A cualquier otro cambio aparente del objeto (cambios en su geometría, deformación esquelética o por curvatura del espacio, roturas, color, material.) lo llamaremos, en general, animación, y ya está.

Inicialmente, un movimiento se describe mediante curvas que indican el valor del parámetro en el tiempo, ya sean valores coordenados, ángulos, intensidades. Si un objeto sólo va a dar botes por la escena sin moverse del sitio, sólo habrá que definir una curva en el canal locz (figura superior).




Estas curvas se agrupan en objetos de la llamada clase IPO, y sus curvas son las curvas ipo. Podemos ver copias del objeto animado en cada uno de sus puntos de cambio (nodos, keys) para hacernos una idea de su evolución.

Los objetos también pueden estar animados simplemente por restricciones, cambiando su posición, orientación y aspecto por la acción de otros elementos, como el conservar la orientación hacia un objetivo, clonar sus coordenadas u orientación, recorrer una curva, estas restricciones también están controladas a su vez por una curva ipo que las puede desactivar cuando su valor es 0. También podemos generar animación con modificadores: enganchando vértices a otro objeto (hooks), pasando a través de una rejilla deformada (lattice), construyendo un esqueleto.




Python
evidentemente, existiendo un entorno de programación dentro del propio Blender (un Api para lenguaje Python), estamos capacitados para crear curvas ipo mediante un programa, explícitamente o en base a un interfaz controlado por el usuario. El movimiento, entonces, estaría calculado previamente en el momento de uso del script. Pero también podemos evitar el paso de crear curvas modificando directamente las características del objeto en cada fotograma. Para ello hacemos uso de los script links, enlaces directos desde una entidad de Blender (un objeto3d, cámara, material, o una escena completa) a programas que se ejecutaran en cada cambio de cuadro.

Dirigiendo el movimiento externamente: drivers
Otra de las últimas herramientas añadidas en Blender son los drivers, que controlan curvas ipo individualmente por medio de otra curva, o bien con una línea o un programa escrito en Python (pydrivers). A grandes rasgos, nos permite crear animaciones que dependen de otras animaciones o de movimientos de objetos.

Como era de esperar, todas las curvas ipo de todo tipo pueden ser controladas por drivers, también las que cambian los parámetros de los materiales, luces y cámaras, y las que controlan los gestos en las RVKS (ver más abajo).



aprovechando el game-engine
Otra de las utilidades recientemente implementadas es la generación de movimientos generados por el motor de juegos de Blender, lo que nos da la posibilidad de añadir complejidad física a la escena con colisiones y comportamiento realista de los objetos.



Esqueletos en Blender
El más potente modificador, casi imprescindible, para la creación de personajes animados, es el uso de esqueletos, en Blender llamados armatures, que constan de segmentos (huesos, Bones) que pueden emparentarse formando una estructura móvil que se puede animar.

A la preparación de un esqueleto completo, adecuando al objeto que pretende deformar, con sus controles para usar de manera cómoda, se le llama rigging.

Acciones
El movimiento de los huesos responde a Ipos de un tipo especial, actions, que permite desplazamiento, rotación y escalado de estos individualmente. Hay que hacer notar que las rotaciones utilizan 4 parámetros, según el método de orientación de los cuaternios de Hamilton (w, x y, z) en lugar de los ángulos de Euler (x y, z) que usan los objetos 3d, para aumentar la velocidad de cálculo y evitar los ejes privilegiados y puntos nodales.




La situación de los huesos de un esqueleto en un instante forma una pose, y una secuencia de posturas genera una acción. Así que podemos crear una secuencia completa animando un esqueleto en una acción única con posturas sucesivas, si bien podemos pensar que ciertas partes de la acción pueden repetirse, en esta u otras acciones (menear la cabeza, aplaudir, dar un paso), con lo que lo ideal es descomponer la animación en acciones sucesivas, que pueden mezclarse unas con otras, más cuando en una acción no tienen por qué intervenir todos los huesos, así que, podemos crear acciones para los pies, acciones para los brazos, para los dedos, la cabeza, la cola.

En las últimas versiones de Blender no sólo podemos incluir secuencias de posturas de esqueletos, sino que podemos combinarlas con movimientos de objetos o de la propia armature como objeto en sí mismo. Esto adquiere sentido si tenemos objetos conectados al esqueleto o al modelo que los están controlando, como complementos de la ropa que se mueven al caminar, objetos de control que tiran de los ojos hacia adelante en una acción de sorpresa, etc.

Deformación de mallas | esqueletos
A estos esqueletos podemos asociar una malla para que se deforme con el movimiento de los huesos, aunque también podemos usarlos emparentando objetos directamente a los huesos, como componentes rígidos robóticos. La deformación de una malla asociada a un esqueleto (llamada skinning) se puede producir de varias maneras, ya sea mediante grupos de vértices que, siguen a determinados huesos, por asignación automática de cercanía a estos (envolventes), o una combinación de ambas técnicas.

Vertex keys
Esta herramienta es la más importante para dar expresividad a nuestros personajes, pues es la manera más cómoda de modificar las mallas en una secuencia para que cambien su apariencia con el tiempo. Consiste en crear copias modificadas de la malla original (gestos, shapes), de manera que, podemos conseguir una colección de gestos para mezclarlos y combinarlos en la animación. Si bien existe una forma básica de usar las vertex keys, de forma absoluta, haciendo uso de ellas una tras otra linealmente, la opción más interesante es usarlas de forma relativa (RVKS). Esto significa que en cada momento, estamos sumando los gestos de una cara que nos interesan, para conseguir que un personaje pueda hablar, parpadear y mover las cejas a la vez. El mecanismo es simple de entender, y ahora muy fácil de gestionar gracias a los botones de la ventana de acciones: cada gesto está controlado por una curva IPO, que indica con cuanta intensidad se realiza: con 0 no tiene lugar, con 1 vemos el gesto tal cual, y con valores superiores podemos incluso exagerarlo. Gracias a la posibilidad ya comentada de introducir animaciones de objetos dentro de acciones, también podemos añadir secuencias de RVKS dentro de estas, consiguiendo sumar la expresividad de la malla a los movimientos de los huesos.




animación facial y sincronización labial
Como apartado especial quedan estas actividades, imprescindibles para dar expresividad y lenguaje a nuestros personajes y que por sí mismas constituyen una ocupación en la organización de un proyecto animado. La expresividad es responsabilidad del animador y de su capacidad artística, y la sincronización labial (lipsync) exige un esfuerzo a veces impredecible, y conocimientos del bien y la fonación en el idioma en el que bien el personaje. Supondría material para una charla que, por otra parte ya se impartió en otro encuentro, así que, en este apartado nos limitaremos a comentar lo que ofrece Blender para cambiar la expresión de la cara de un personaje. En general, podemos usar las dos técnicas comentadas de forma no excluyente.

Un rigging facial es adecuando para los motores de tiempo real (MTR), esto es: juegos y aplicaciones interactivas. En la actualidad, raramente un MTR permite combinaciones de mallas para crear expresividad o bien, por lo que todas las deformaciones deben hacerse con esqueletos. Esta tarea no suele ser complicada porque normalmente no se exige una interpretación dramática del actor, pero si fuera necesario, el método consiste en crear un sistema de huesos análogo a la musculatura de la cara, de manera que, al asociar los vértices, estos se muevan como la piel que hay sobre ellos. La aproximación es bastante buena, pero no es un método adecuando para expresividad sutil.






La manera habitual de dar expresiones a una cara es modelarlas mediante copias de la malla, separadas en mitades si es necesario (ceja derecha arriba ceja izquierda arriba). Estas mallas, en realidad se guardan internamente como desplazamientos relativos de los vértices con respecto a la malla base, de manera que, el programa sólo tiene que sumar, por cada vértice, un Vector por cada expresión activa, este Vector estará previamente multiplicado por la intensidad con que se realiza esa expresión, usualmente un número entre 0 y 1. Esta intensidad es, precisamente, la que nos dan las curvas ipo que se definen en las RVKS.

La comodidad para insertar nuevos gestos en la animación es muy importante para un trabajo fluido. Esencialmente, toda la potencia para generar animación por RVKS estaba implementada desde hace años en Blender, pero gracias a los nuevos paneles de shapes, su inclusión con deslizadores en la ventana de acciones, la asignación de nombres a cada expresión y otros detalles que poco a poco se han ido añadiendo, es cada vez más rápido conseguir lo mismo y con más control.


creación de GUI personalizados con drivers.

La implementación de drivers que controlen el movimiento a abierto un sinfín de posibilidades para la animación, y el más inmediato parece ser el control manual mediante creación de botones (sliders) en el propio espacio 3d. Así, el desplazamiento de un objeto puede generar animación en todos los objetos que tengan un ipo con drivers asociados a él. Johnny Matthews (Guitargek), un experto usuario de Blender, creó un pequeño script que inmediatamente fue añadido a la versión oficial. Genera controles de diversas formas que se usan para enlazar a drivers de una malla con RVKS, de manera que, podemos fabricar una cara esquemática con pequeños objetos que, al moverlos, nos mueven pequeños rasgos directamente sin tocar para nada el sistema clásico de animación.