Ayer por fin Apple aprobó la actualización de Tres que envié la semana pasada.

Simplemente arregla algunos fallos, mejora el rendimiento y ahora cuando se exporta como imagen lo hace al doble del tamaño de la pantalla (2048×1536).

Para mejorar el rendimiento toqué el algoritmo que genera la triangulación de Delaunay haciéndolo más eficiente.

Tres 1.1

Llevo tiempo sin escribir nada nuevo en el blog, y no es porque no tenga cosas que contar, de hecho tengo varios artículos a la mitad (entre otros “Decálogo para diseñadores, como cuidar a tu desarrollador parte II”), pero he estado dedicado este tiempo a ponerme seriamente a estudiar Objective-C en los huecos en los que el trabajo me lo permitía.

En este artículo pretendo dar una visión general de por qué me metí en este embolao y cómo empecé a aprender lo poco que hoy sé. En próximos artículos espero seguir hablando del cambio de Actionscript a Objective-C a la vez que voy haciendo un recorrido por lo que fue el desarrollo de mi primera aplicación para iPad: Tres

Esto está cambiando

Llevo los últimos 8 años dedicado en exclusiva a la programación en Actionscript (con algo, poco, de php y html) y ha sido una experiencia satisfactoria en general, he aprendido mucho, tanto de programación como de técnicas gráficas, algoritmos y demás, he podido trabajar con gente muy buena y, salvo excepciones (todos hemos hecho banners), en proyectos muy interesantes.

Pero no es ningún secreto que el uso de Flash está cambiando. La tecnología en sí, en mi opinión, no va a morir pronto, ha evolucionado mucho y sigue habiendo una enorme comunidad de desarrolladores, pero sí que cambiarán el tipo de proyectos y es posible que hasta que se asiente su papel, haya menos trabajo. No creo que sea tanto la muerte de Flash, como la muerte de la web tal y como la conocemos. Dejamos atrás el PC para conectarnos con móviles, tabletas y televisores. Eso implica un cambio en la forma de acceder a la información y también un cambio en la tecnología con la que se presenta esa información.

Pero no quiero divagar sobre el tema.

¿Por qué aplicaciones y no html5?

Parece que todo el mundo de mi alrededor que se dedicaba a programar en Actionscript hasta la fecha están cogiendo cada vez más proyectos de html (html5 como le gusta llamarlo a los clientes, html+javascript+php+css al fin y al cabo). Habiéndome dedicado a la web durante tanto tiempo parece que sería el paso lógico. Pero en realidad yo tengo formación de programador puro y duro, tengo una base sólida (aunque algo olvidada) de C++ y odio maquetar. Lo odio y se me da mal. Además me da una pereza horrible enfrentarme al lío de los navegadores (el hecho de que está web sea una plantilla lo deja claro). El javascript tampoco me genera mucha simpatía, viniendo de AS3 es, definitivamente, un paso atrás. No te digo ya comparado con Objective-C, en cuanto a paradigmas de programación orientada a objetos, que es lo que a tipos con protegebolsillos y cinta aislante en las gafas y a mi, nos mola.

¿Por qué iOS y no Android?

Es algo que me preguntan mucho. Bueno, para empezar, simplemente tenía que elegir. Descarté desde el principio usar AIR, para llegar a las dos plataformas, debido a temas de rendimiento, sobretodo, pero también tenía ganas de aprender algo nuevo. También descarté PhoneGap y similares, por las mismas razones y porque además es Javascript (ver punto anterior). Sea como sea, con ningún sistema de los que están saliendo ahora como setas se puede alcanzar el rendimiento de una aplicación nativa. Están muy bien para cosas sencillas multiplataforma, pero si te complicas un poco simplemente no sirven.

En cuanto a iOS vs Android, pues bueno, no quiero ser un fanboy, pero he tenido un móvil Android, he probado tabletas Android y siempre he vuelto a Apple. Que es cerrado, cierto. Que Apple a veces se pasa con sus restricciones, cierto. Pero en mi opinión el iPhone/iPad + iTunes + App Store es un sistema mucho mejor. Además con Apple te quitas el 99% de los problemas de fragmentación que tienes trabajando para Android. Esto sin contar que en el caso de querer vender aplicaciones, donde actualmente se están comprando es en la App Store y no en el Android Market, no tengo cifras, pero existen por ahí.

Y por último porque las herramientas de desarrollo que proporciona Apple son una maravilla, llevan años depurándolas ya que son las mismas que se utilizan para programar para ordenadores Apple. En mi opinión mejores que las alternativas que existen para Android (Eclipse y otros) y están a años luz que todo lo que lleva Adobe vendiéndonos por una pasta (sobretodo si vives en Europa). ¡Ah! y son gratuitas.

Cómo aprendí

Para empezar dejé de coger trabajos. Aprovechando que había facturado bien a principios de año, en junio dejé de contestar a ofertas de freelance. Y empecé a aprender. No estudiaba tanto desde la universidad, y puede que ni entonces.

Me pedí unos cuantos libros a Amazon, en concreto estos:

- Programming in Objective-C
- iOS programming. The big nerd ranch guide.
- iPhone 3D Programming
- OpenGL ES 2.0 Programming Guide
- Cocoa Design Patterns

Los dos primeros son de conocimientos generales de iOS y Objective-C. Estuve bastante tiempo investigando como hacer deformaciones con Delaunay con Objective-C. Como contaré en otra entrada resultó que no conseguía todo lo que pretendía hacer solo con Objective-C, así que, siendo un poco inconsciente de la complicación que tendría, me lié la manta a la cabeza y me dispuse aprender OpenGL. Para eso me compré los dos siguientes libros.

El tercero aún no lo he leído, pero lo haré, todavía me queda muchísimo que aprender.

De todas formas, más allá de estos libros, que están bien como referencia, donde realmente aprendí los entresijos de la programación para iOS fue en los vídeos que hay en iTunes University. Sobretodo los de Paul Hegarty de Stanford, que es un profesor excelente y lo explica todo de una forma clara y sencilla. Pero también los de Brad Larson de Madison Area Technical College que son más avanzados y Brad no es tan claro, se lía, corta frases a la mitad y a veces, para un hispano hablante, es difícil entenderle, pero que toca temas complejos como OpenGL o CoreData en más profundidad.

Y por supuesto también internet, leer mucho, buscar más y preguntar. Recomiendo, cómo no, stackoverflow, que tiene muchísimo movimiento de preguntas relacionadas con iOS.

Hasta aquí esta pequeña introducción. Pronto más sobre este cambio de rumbo.

Un poco a toro pasado, pero aprovecho que tengo nuevo diseño de web para recordar que el pasado 28 de Noviembre di una charla sobre Tres en el HUB Madrid invitado por la gente de The App Date.

Aquí podéis ver un vídeo con un pequeño resumen. Tardo un poco en salir porque fui el último ponente.

Quiero dar las gracias a The App Date por invitarme cuando el proyecto todavía estaba en pañales, creer en él y además, de esa manera, forzarme un poco a acabarlo a tiempo.

Más información aquí.

Se me está quedando cara de triángulo de tanto hablar de Delaunay.

En fin, por si a alguien le puede interesar aquí está la charla de ASNativos: Triangulación de Delaunay y Deformaciones

Tiene un inicio un poco denso, mucha programación, así que para quien quiera saltar directamente a la parte de las aplicaciones que vaya al minuto 24:44

Y para ir directamente al ejemplo del Morphing: 42:00

Ahora mismo estoy trabajando en portar este tema a Objective-C para llevar Metamorpher ™ a la App Store, espero poder dar noticias al respecto pronto (eso sí, seguro que le pongo otro nombre).

Os recuerdo que aquí están las clases, si las usáis para algo me haría ilusión que me lo dijerais.

Gracias a Joseba y ASNativos por organizar esto.

Como prometí en la charla de asnativos, aquí está el código que he usado para calcular la triangulación de Delaunay y posteriormente para mapear los triángulos.

Todo listo para hacer morphings de este tipo:

Pronto estará la presentación online y también la pondré por aquí.

Contenido

El paquete se compone de las siguientes clases:
- TriangulacionDelaunay: Clase estática que contiene el método que a partir de una serie de puntos genera la red de triángulos.
- DTriangulo: ValueObject, contienen los 3 puntos de cada triángulo. Los puntos no son Point, son int, posiciones del Vector de puntos que le pasamos a la triangulación.
- DLado: Almacena los lados para hacer cálculos en la triangulación. Tampoco son puntos reales si no referencias.
- Deformador: Hace el mapeado de los triángulos y pinta el resultado en un Shape.
- Malla: Guarda el vector de puntos y el de triángulos (referencias al de puntos) que conforman la Malla.

Uso

Creación de la red de triángulos.

var puntos:Vector.<Point> = new Vector.<Point>();
//...Rellenamos este vector con los puntos que necesitemos.
var triangulos:Vector.<DTriangulo> = TriangulacionDelaunay.triangulate(puntos);
//admite otro parámetro que ordena el Vector, y así acelera el algoritmo,
//pero no lo podemos usar en un morph porque perdemos la referencia a los puntos

Creación y deformación de la malla de triángulos.

var destino:Shape = new Shape();
var malla:Malla = new Malla(puntos, triangulos);
//bmpd es un BitmapData con la imagen que queremos deformar
var df:Deformador = new Deformador(bmpd, malla, destino);
 
//Aquí podemos mover los puntos del Vector puntos
 
//esta línea es para actualizar la Malla y por lo tanto ver la imagen deformada, debería estar en un bucle os similar
df.morph();
//si además queremos actualiza la imagen.
df.actualizaBitmap(bmpd);

Descarga

Aquí os podéis descargar el código y usarlo para lo que queráis. Eso sí, si hacéis algo que mole, estaría bien que me lo hicierais saber en los comentarios de este post. Por curiosidad solamente.

Por aclararlo, no vayamos a herir sensibilidades. Lo que viene a continuación son consejos desde el punto de vista de un programador, pensados sobre todo para diseñadores que viene de diseño off-line y que no acompañan sus amplios conocimientos de diseño con otros sobre cómo funcionan las cosas en digital. Yo soy un simple programador y nunca me he sentido capacitado para dar consejos de diseño a un diseñador.

En principio todo esto está escrito desde el punto de vista del programador Flash que trabaja en agencias de publicidad, pero probablemente la mayor parte sea extrapolable a otro tipo de programadores en otro tipo de trabajos, siempre que trabajen con diseñadores.

Para muchos el programador no es más que ese ser paliducho que se sienta en una esquina de la agencia, come bolsas de patatas y siempre tiene la pantalla llena de letras extrañas. Pero señores, más allá de ese pelo desordenado, detrás de esa camiseta de heavy metal, dentro de ese cuerpo falto de ejercicio hay un corazón que se siente herido si no se le trata con cariño.

Pero basta de drama, en realidad lo que digo a continuación no solo ayudará a tener al programador contento, si no que además incidirá en una mejora del flujo de trabajo en general, haciendo que haya que dar menos vueltas al ciclo de desarrollo y que por lo tanto se pierda menos tiempo en el proyecto.

Los 10 consejos que describo a continuación en realidad podrían resumirse en uno solo, el más importante de todos: Ten el archivo fuente de diseño tan ordenado como si fuera tu casa justo antes de que tu madre viniera de visita.

1 Software

El 90% de los flasheros suelen trabajar con Photoshop y sí, me acabo de inventar la estadística, pero ¿a que suena creíble?. Este punto es un poco conflictivo, ya que habrá gente que prefiera utilizar Fireworks, otros Ilustrator e incluso habrá algún obsoleto que siga con el Freehand. De todas formas el más común sigue siendo Photoshop y es el software que deberíais utilizar si queréis aseguraos de no fallar. Quizás Ilustrator funcione mejor para algo que luego en flash vaya a ser vectorial, pero para bitmaps nos quedaremos con Photoshop y sus extensas posibilidades de exportación para web.

En cuanto a Fireworks, hay muchos programadores que lo prefieren sobre Photoshop, pero creo que son más del bando de “yo me lo guiso, yo me lo como”, que diseñan y montan la web ellos mismos, normalmente en HTML + CSS, para lo cuál, Fireworks, tiene ciertas ventajas. Tiene muchas herramientas que facilitan el trabajo en web, pero en cuanto a bitmaps es una versión descafeinada de Photoshop. Además las supuestas ventajas de Fireworks desaparecen en el momento en el que el diseñador no tiene en cuenta la metodología de trabajo del mismo en cuanto a ordenación de capas y demás para luego exportar fácilmente a flash.

De todas formas, si existe la posibilidad, lo mejor es preguntar al programador con qué software prefiere que se diseñe la web. Dependiendo del tipo de trabajo puede que sea más conveniente uno u otro. Eso sí, no intentéis hacerlo siempre en el mismo y exportar a otros formatos (por ejemplo, hacerlo en Fireworks y exportar a PSD), porque simplemente no funciona, el exportador creará tal caos en las capas que hace el archivo incomprensible incluso para el propio diseñador.

2 Resolución de pantalla

Sé que esto no hace falta decírselo al común de los mortales, pero el diseñador de papel es un ser fuera de lo normal. Por lo tanto lo digo: La resolución del archivo tiene que ser de 72 puntos por pulgada. Los archivos de 300 puntos por pulgada los dejamos para imprenta.

Si me dieran un euro por cada vez que he recibido un archivo a 300 ppp, ahora tendría… no sé, 3 o 4 euros.

3 Tamaño

Hay una diferencia importante entre el diseño pensado para papel, televisión, etc y el pensado para internet. Y es que en internet no puedes controlar diversos aspectos de cómo el usuario verá tu diseño. El más importante de ellos es el tamaño de pantalla.

A día de hoy se toma como tamaño mínimo 1024×768, es decir, se entiende que todo el mundo tiene esa resolución de pantalla o más. Si a eso le restamos lo que ocupa el navegador en si nos queda que aproximadamente el diseño tiene que andar por los 950×600 para que no salgan las barras de scroll.

Aún así todavía hay gente con resoluciones más pequeñas (portátiles probablemente) y casualmente alguien en el cliente suele tener una resolución más pequeña. Generalmente no pasa nada, se les puede explicar que lo suyo no es lo normal, pero aún así es buena idea no colocar elementos interactivos pegados al borde inferior, ya que, aunque puedas mover el scroll hasta allí, no salen en un primer vistazo.

Es muy común que se diseñe pensando en un tamaño fijo concreto sin darle mucha importancia a cómo se verá en pantallas más grandes o más pequeñas. Esto sobretodo es un problema cuando se hacen diseños que ocupen toda la pantalla del navegador. Creo que esto queda claro con el siguiente ejemplo.

Esto suele ser la captura que hace el diseñador de cómo va a ser la home de una web. Ha puesto la ventana del navegador para que el cliente se haga una idea de cómo quedaría (parece que si no el cliente no se hace una idea, así es… ). Todo muy bonito, el cliente lo aprueba y claro, cuando esté online quiere ver exactamente eso.

Pero ¿qué pasa si la ventana del navegador del usuario tiene un tamaño diferente? ¿se reposicionan los elementos para ajustarse al tamaño nuevo? ¿mantenemos todo en su sitio y ponemos un marco? ¿no dejamos que reescale la ventana? (muy poco recomendable) No es una decisión muy complicada de tomar, pero puede cambiar completamente el look de la página, podemos pasar de una página limpia con muchos espacios en blanco a una con todo apiñado o viceversa si esto no se piensa con antelación. Y el encargado de pensarlo tiene que ser el diseñador.

Veamos qué puede pasar si la pantalla del usuario es más grande. Primero podemos poner un marco para que el contenido se mantenga centrado y conserve las proporciones del original.

Ésta es la solución más sencilla desde el punto de vista del programador, no requiere andar haciendo cálculos ni comprobar si se escala o no la ventana. Desde el diseño, mi impresión es que hacer esto también es más fácil.

Otra opción sería reposicionar los elementos para que se extiendan por toda la pantalla, pero sin escalar nada.

Esta opción requiere algo más tanto para diseño como para programación. El ejemplo que uso es muy sencillo, pero ya se pueden ver algunas cosas que pueden dar lugar a conflictos. Por ejemplo, ¿qué pasa con el pie?, ¿lo dejamos pegado al contenido súper molón o lo pegamos al borde inferior de la ventana?. Lo mismo con el logo, ¿lo ponemos en el borde superior de la ventana o pegado al contenido?

Este tipo de dudas crecen exponencialmente según la complejidad del diseño, no hablemos ya de las animaciones y transiciones entre secciones. Todo eso habría que tenerlo en cuenta.

Una tercera opción sería reposicionar algunos elementos y escalar otros.

En muchos casos esto estará bien ya que se podrá ver el contenido a mayor tamaño. Tenemos los mismos retos que en el caso anterior, hay que pensar bien cómo queda todo en el nuevo tamaño. Pero además hay otras cosas a tener en cuenta. En el caso de que el contenido súper molón fuera vídeo o imágenes antes de plantear esta solución habría que pensar si se dispone de ese contenido con una calidad suficiente como para mostrarlo a un tamaño tan grande (y hay que tener en cuenta que todavía habrá gente con pantallas mayores). Sin embargo, si el contenido es 3D (Papervision, Away…) u otra cosa que haga un uso intensivo de la CPU es posible que no vaya igual de fluido a tamaños muy grandes.

Cuidado con esto y sobretodo pregúntale al programador antes de enseñárselo al cliente, no vaya a ser que éste se encapriche por un diseño que luego no se va a poder montar.

4 Nombrar capas y carpetas

Ésta es de cajón, para saber qué hay en cada capa sin tener que andar seleccionándolas y moviéndolas por el documento, encendiendo y apagando otras, lo mejor es que cada una tenga un nombre claro y conciso de lo que contiene.

No solo eso, además ayudará a que el diseño esté estructurado. Nosotros como programadores tenemos el cerebro completamente cuadriculado (lo digo por mantener el mito, aunque algo de verdad hay), para nosotros un logo es un logo y un botón es un botón. Por eso nos resulta bastante lioso cuando, por ejemplo, ese logo está compuesto de varias capas (sombra, brillo, mancha, texto…) que no están colocadas de forma consecutiva en el PSD y sobretodo cuando además alguna de esas capas afecta a otros elementos al mismo tiempo. He visto más de una vez que se dibuja todo el interfaz y luego se le dan tonos o brillos a todo en una capa por encima.

Nombrar las capas y las carpetas del PSD, además de ayudar al programador a entenderlo, ayudará al diseñador a estructurar el contenido de forma que un logo sea un logo y un botón un botón. Si hay alguna capa a la que no sepas qué nombre darle quizás me plantearía si esa capa es realmente necesaria o si realmente va situada donde la estás poniendo. Puede parecer demasiado restrictivo, pero hay que tener en cuenta que no estamos diseñando para papel, esto no se imprime y listo, lo que se haga en Photoshop tiene que ser extraído por partes a Flash, por eso esas partes tienen que estar bien definidas.

Si además de todo esto ponemos colorines al PSD ya es para nota.

Y ahora un ejemplo de lo que NO se debe hacer

El vídeo es real, grabado por mi. En defensa del diseñador diré que en realidad el jaleo en el PSD es el resultado de exportarlo desde Fireworks, pero igualmente, es buen un ejemplo de lo que no se debe hacer jamás.

Y un par de lo que SÍ se debe hacer.

Como anécdota diré, que pedí por twitter y facebook imágenes de PSDs bien ordenados y coloreados como ejemplo para este post y la respuesta más común fue que la existencia de ese tipo de PSDs era una leyenda urbana. Es vuestro deber como diseñadores demostrar que eso no es así.

5 Efectos de capa

Como regla general un solo consejo: no los uses.

Vale, me he pasado, puedes usarlos, pero con moderación. No todos los efectos de capa que hay en Photoshop están disponibles en Flash. Y aunque lo estén no siempre es una buena idea usarlos. Van a cargar más la CPU y además hay que tener en cuenta cómo funcionarán cuando el contenido sea animado.

Por ejemplo, a lo mejor ponemos un logotipo en algún modo de capa para que el fondo sea transparente, pero resulta que en Flash lo que está debajo del logo en algún momento cambia de color o se anima. Puede que el modo de capa deje de funcionar o que el logo cambie de color. Aunque es más trabajo, suele ser mejor idea recortar el logo y exportarlo como PNG.

–
Pronto una segunda parte.

Ya aviso que el juego no es sencillo, tampoco es que gráficamente sea una maravilla, pero está realmente bien pensado. Solo espero que si pinchas sobre el enlace no tengas nada que hacer en la próxima hora.

Yo me he hecho todos los niveles, sin buscar la solución en google, a ver quién lo logra.

¡Jugar!

Puede parecer una cuestión trivial, pero lo cierto es que no hay ningún método en la API de dibujo de flash que permita crear todas esas formas. Como mucho podemos crear círculos y arcos y a partir de ahí ir haciendo apaños.

Para un proyecto, aún en desarrollo, necesité crear varios círculos superpuestos, en ocasiones semicirculos y también con un radio interior (coronas circulares).

Así que decidí crear mi propia clase círculo. Un Shape que expone las siguientes propiedades mediante getters/setters:

• radio_interior
• radio_exterior
• angulo_inicial
• angulo_final
• color

Al exponerlas en el interfaz nos permite acceder a ellas fácilmente desde fuera de esa clase y como el círculo se redibuja cada vez que una de esas propiedad cambia, es muy sencillo animarlo. Como se ve en el siguiente ejemplo en el que lo animo aleatoriamente con la clase TweenMax:

Aquí está el código de este ejemplo.

package 
{
	import com.greensock.TweenMax;
	import com.greensock.easing.Quad;
	import com.theso3.graficos.Circulo;
 
	import flash.display.Sprite;
 
	[SWF(width=800, height=600, frameRate=30, backgroundColor=0xFFFFFF)]
	public class Main extends Sprite {
 
		public var c:Circulo;
 
		public function Main() {
			init();
		}
 
		private function init():void {		
			c = new Circulo();
			c.x = 400;
			c.y = 300;
			addChild(c);
 
			anima();
		}
 
		private function anima():void {
			c.color = Math.random()*0xFFFFFF;
			TweenMax.to(c, Math.random()*2+1, {
				radio_exterior:Math.random()*200+100, 
				radio_interior:Math.random()*100,
				angulo_inicial:Math.random()*180,
				angulo_final:Math.random()*180+180,
				ease:Quad.easeInOut,
				onComplete:function():void {
					anima();
				}});
		}
	}
}

La geometría aplicada está sacada de internet (no recuerdo de dónde), lamentablemente no atendí lo suficiente en esas clases de la carrera como para desarrollar algo así desde cero. Lo que hice fue coger una clase que creaba un arco en tramos y ampliarla para que creara dos arcos  completos que luego se unen con dos líneas rectas, al rellenarlas de un color da como resultado la forma que buscamos.

El número de miniarcos que forman los arcos grandes varía automáticamente dependiendo del alcance del ángulo del arco grande. Esto se puede ver en el siguiente ejemplo en el que dibujo los puntos de control y los anclajes de los miniarcos.

Por eso en realidad los círculos no son perfectos, y si superpones dos con el mismo radio, pero diferentes ángulos y diferentes colores verás que no encajan perfectamente. Aún así es una solución rápida en términos de consumo de CPU y para casi todo, suficientemente perfectos.

Aquí está el código, por si alguien necesita crear círculos a tutiplén:

package com.theso3.graficos {
 
	import flash.display.Shape;
 
	public class Circulo extends Shape {
 
		private var _radio_exterior:Number;
		private var _radio_interior:Number;
		private var _angulo_inicial:Number;
		private var _angulo_final:Number;
		private var _color:Number;
 
		public function Circulo(radio_exterior:Number = 200, radio_interior:Number = 50, angulo_inicial:Number = 30, angulo_final:Number = 330, color:Number = 0xaaaaaa):void {
			this._radio_exterior = radio_exterior;
			this._radio_interior = radio_interior;
			this._angulo_inicial = angulo_inicial;
			this._angulo_final = angulo_final;
			this._color = color;
 
			dibuja();
		}
 
		private function dibuja():void {
			graphics.clear();
 
			graphics.lineStyle(0, 0, 0);
			graphics.beginFill(_color);
			graphics.moveTo(_radio_interior, 0);
 
			var a1:Number = -_angulo_inicial*Math.PI /180;
			var a2:Number = -_angulo_final*Math.PI /180;
 
			var diff:Number = Math.abs(a2-a1);
 
			var dir:Number = 1;
			if(a2<a1)
				dir = -1;
 
			var divs:Number = Math.floor(diff/(Math.PI/4))+1;
			var span:Number = dir * diff/(2*divs);
 
			var rc:Number = _radio_exterior / Math.cos(span);
 
			graphics.moveTo(Math.cos(a1)*_radio_exterior , Math.sin(a1)*_radio_exterior);
 
			for (var i:int=0; i<divs; ++i) {
				a2 = a1+span;
				a1 = a2+span;
 
				graphics.curveTo(Math.cos(a2)*rc, Math.sin(a2)*rc, Math.cos(a1)*_radio_exterior , Math.sin(a1)*_radio_exterior);
	     	}
 
	     	rc = _radio_interior/Math.cos(span);
	     	graphics.lineTo(Math.cos(a1)*_radio_interior, Math.sin(a1)*_radio_interior);
 
			for (i=divs; i>0; --i) {
				a2 = a1-span;
				a1 = a2-span;
				graphics.curveTo(Math.cos(a2)*rc, Math.sin(a2)*rc, Math.cos(a1)*_radio_interior, Math.sin(a1)*_radio_interior);
	     	}			
 
			graphics.endFill();			
		}
 
		public function set radio_interior(r:Number):void {
			_radio_interior = r;
			dibuja();
		}
		public function set radio_exterior(r:Number):void {
			_radio_exterior = r;
			dibuja();
		}
		public function set angulo_inicial(a:Number):void {
			_angulo_inicial = a;
			dibuja();
		}
		public function set angulo_final(a:Number):void {
			_angulo_final = a;
			dibuja();
		}
		public function set color(c:Number):void {
			_color = c;
			dibuja();				
		}
 
		public function get radio_interior():Number {return _radio_interior;}
		public function get radio_exterior():Number {return _radio_exterior;}
		public function get angulo_inicial():Number {return _angulo_inicial;}
		public function get angulo_final():Number {return _angulo_final;}
		public function get color():Number {return _color;}
	}
}

Y digo “drag blando” por llamarlo de alguna manera.

Simplemente utilizando el método descrito anteriormente, creamos una malla de triángulos.

Al mover la imagen la sustituimos por la malla y hacemos que los puntos se muevan con cierto retardo según lo lejos que estén del ratón.

Y … ¡tachán!

Aquí el código fuente.

Cliente: Volkswagen
Agencia: Tribal DDB

Esta vez se quería algo bastante ambicioso, un proyecto pensado para internacional. Esto quiere decir que todos los textos tienen que ser dinámicos, y los campos tienen que variar de tamaño para adaptarse a las diferentes lenguas (malditos alemanes, no tienen palabras cortas, ¿o qué?). Además se tiene que proporcionar la posibilidad de que editando un xml se puedan deshabilitar determinadas partes del site. Con la dificultad añadida de que los Xmls se tenían que adaptar a una estructura prefijada para que funcionaran correctamente con la herramienta de localización de Volkswagen.

Por si esto fuera poco el proyecto ya de por si no era nada trivial. Consistió en hacer un configurador para el nuevo Volkswagen Polo. Todo en 3D, con Papervision, que permitiera ajustar diferentes parámetros y elementos visuales del coche, que hubiera una galería, que se pudiera conducir, compartir en redes sociales y como colofón que fuera un concurso cuyo premio final fuera el coche tal y cómo el usuario ganador lo había diseñado.

Afortunadamente conté con la ayuda de Pablo Martín (para la parte de producto), Javier Fernández (para la galería y el registro) y Elena Sánchez (para el backend). En este artículo hablaré del resto, es decir, de lo que hice yo.

Desafortunadamente el proyecto fue un infierno de principio a fin, y no, no fue por casi nada de lo que digo arriba.

Cómo se hizo

Ya que íbamos a ser 3 programadores trabajando en diferentes partes del site al mismo tiempo, por primera vez decidí utilizar Gaia Framework. Fue de gran ayuda a la hora de organizarnos. Pero bueno, a estas alturas no voy a decir nada de Gaia que no se haya dicho ya.

El modelo del coche

El excelente modelo del Polo en low poly me lo pasó la gente de Aparenta. Consiguieron que con una geometría sencilla y unas cuantas texturas bien puestas el coche diera el pego a pesar de las limitaciones (en cuanto a recursos y CPU) de Flash + Papervision 3D.

Hubo que pasar dicho modelo por Blender para mover algunos objetos de sitio y renombrar la geometría. Por ejemplo, las ruedas las moví al centro de la escena (0,0,0) para que su propio centro geométrico fuera también su centro de rotación. Luego por programación las volvía a situar en su sitio y en el caso de las delanteras las metía dentro de otro objeto que hacía de eje para que giraran en Y, además de rotar.

Este es el código para las ruedas de la parte izquierda:

eje_izq = new DisplayObject3D();
model.addChild(eje_izq);
//referencia a la rueda frontal izquierda en el modelo 3ds
var left_tyre : DisplayObject3D = model.getChildByName("frnttyrel");
model.removeChild(left_tyre);
eje_izq.addChild(left_tyre);
eje_izq.x = -250;
eje_izq.y = 70;
eje_izq.z = 130;
 
//referencia a la rueda trasera izquierda en el modelo 3ds
model.getChildByName("bktyrel").x = 230;
model.getChildByName("bktyrel").y = 60;
model.getChildByName("bktyrel").z = 130;

Costó varias horas de rompederos de cabeza, pero finalmente llegué a la conclusión de que el exportador de Blender a 3ds es una auténtica bazofia (porque no sé si queda muy profesional decir “mierda” en un blog). Cambia los nombres de los objetos sin una regla fija aparente, así que me vi obligado a hacer trazas en flash hasta que descubría cómo le había dado a mi amigo Blender por llamarlos esta vez.

Debido a esto el siguiente proyecto en el que hubo que hacer algo así fue directamente hecho con Maya.

Materiales interactivos

Como se ve en el vídeo, las diferentes partes del coche cambian de material cuando pasas el ratón sobre ellas. Te indican que estás sobre ellas con un color rojo. Esto debería ser sencillo utilizando un material interactivo de Papervision 3D, bueno pues… no lo es.

El problema es que cuando se trata de un modelo cargado de un archivo externo, con relativa complejidad, por algún motivo que desconozco, no detecta bien las zonas activas y solo dependiendo del ángulo con respecto a la cámara hará bien el rollOver o no. Finalmente la solución consistió en crear un modelo proxy mediante programación que imitara una geometría similar a la de las diferentes partes del coche pero simplificada. Esto es: un cubo para una puerta, otro para otra, etc.

De esta forma el modelo proxy detecta el ratón y le pasa al evento al coche que se encarga de cambiar el material de la parte correspondiente.

Los materiales son MovieMaterials compuestos por varios Sprites de la siguiente forma:

Las dos capas superiores añaden detalle a la geometría mediante relieve y brillos. Así las superficies más o menos planas pueden parecer deformadas según la textura que usemos. La capa de brillos es un png transparente y la capa de relieve es un jpg en escala de grises que al poner en modo multiplicar da el efecto de que las partes negras se hunden.

Finalmente el vinilo es también un png transparente que aparece sobre el color o la imagen en patrón, según lo que hayamos seleccionado.

Además hay otro Sprite situado en una capa superior al resto, de color rojo y opacidad a 50% que es el que indica, al mostrarse, cuando estamos haciendo rollOver sobre alguna parte del coche.

La conducción

Para que el usuario pudiera conducir el coche y, sin complicarme demasiado la vida, tuviera un poco de realismo lo que hice fue coger la entrada de teclado y a partir de la misma actualizar unos valores: steer (izquierda y derecha) y speed (arriba y abajo).

Además utilicé la velocidad del coche para simular una ligera suspensión:

private function update():void {
	//rotación de los ejes delanteros según dirección del coche
	eje_der.rotationY = steer;
	eje_izq.rotationY = steer;
 
	//rotación de todas las ruedas según velocidad
	var roll:Number = speed*.4;
	eje_der.getChildByName("frnttyrer").yaw( -roll );
	eje_izq.getChildByName("frnttyrel").yaw( -roll );
	model.getChildByName("bktyrer").yaw( -roll );
	model.getChildByName("bktyrel").yaw( -roll );
 
	//simula una ligera suspensión
	car_parts.rotationX = -(Math.abs(speed)*steer)/800;
	car_parts.rotationZ += (-acceleration*8-car_parts.rotationZ)/2;
 
	// Gira y mueve el coche
	this.yaw( speed * steer / 625 );
	this.moveLeft( speed );
}

Y eso es todo, o más bien, eso es una pequeña parte de lo que creo que merece la pena contar de un proyecto que duró varios meses de trabajo intenso.