AS3 – Probador virtual de El Corte Inglés

Introducción:

Por fin es primavera en El Corte Inglés (ECI)! Muchos odiareis este anuncio. No os falta razón, es muy malo.

Dejando a un lado el exquisito gusto que tienen la mayoría de compañías para promocionarse en televisión hoy en día, aprovecharé para comentar a grandes rasgos parte del proyecto que define el probador virtual de ECI, donde mediante una interfaz web se pueden visualizar múltiples combinaciones de ropa del catálogo online que ofrece ECI sobre un maniquí virtual.

Describiré sólo el apartado del renderizador (el encargado de mostrar el modelo y las prendas de ropa) muy por encima y sin entrar en detalle, no hay que olvidar que es un software privativo. Además hay que tener en cuenta que el probador se compone en esencia de un front-end (interfaz gráfica web para los usuarios), un back-end (gestor de contenidos) y finalmente el renderizador. En definitiva, no es más que la punta del iceberg de un proyecto enorme, ambicioso y lo mejor de todo, diseñado y programado por 3 personas.

Este es el resultado final:

Es gracioso cuando me pongo a hacer memoria.

Cuando entré a trabajar en Virtualtwo, hace un año más o menos, me pasaron el proyecto de un renderizador en Flex casi acabado para la temporada primavera / verano e implementado por otra persona ajena a la empresa. Era un completo desastre: 600 KB de archivo swf, código ininteligible, leaks de memoria por doquier, tiempos de carga exagerados, en fin lo que no se debe hacer nunca. Sin embargo debido a los plazos de entrega extremadamente cortos y a la dependencia del anterior front-end con éste, nos vimos obligados a arrastrar esa abominación de renderizador hasta el día de hoy.

Para esta temporada he rehecho el renderizador por completo en AS3 (flash), ahora ocupa 20KBs, el código es modular (está compuesto de 4 clases no de 40), procesa 14 piezas de ropa a la velocidad de 1 pieza en el renderizador anterior, realiza garbage collection, y lo mejor de todo, al anterior swf se le debía pasar la estructura de imágenes montada en cada comunicación, el actual acepta 1 imagen independiente y él mismo se configura su estado, es decir realiza mucho más trabajo en menos cantidad de código. Todo esto en dos semanas, *gracias de nuevo* a las deadlines impuestas por el cliente.

A pesar de que AS3 sigue siendo un desastre en lo que a se refiere a programación multi-thread (no tiene directamente) y que su gestión de eventos es bochornosa, tiene algunos pros a considerar. Por ejemplo, el procesamiento en tareas simples para imágenes responde de una manera aceptable. No obstante el punto decisivo que forzó el desarrollo con dicho lenguaje fue la necesidad de tener un renderizador lo más rápido posible que funcionara en todos los navegadores, desde ie7 hasta Safari. Es decir, consideré la opción de realizarlo en JS con canvas, pero sólo con pensar en la existencia de Internet Explorer volví a poner los pies en el suelo.

El renderizador está estructurado en 4 grandes clases:

  • Renderer: clase principal que inicializa el renderizador, instancia a las demás clases, gestiona los eventos y la comunicación con el front-end.
  • Queue: gestiona las peticiones del usuario y carga todas las imágenes necesarias adjuntas a esas peticiones.
  • Status: contiene el estado en cada momento del renderizador.
  • Render: se encarga de presentar el resultado final y calcular la superposición de prendas de ropa mediante máscaras.

 

Renderer:

Es el core de la aplicación flash, en él se instancian y controlan las clases Queue, Status y Render.

Su constructor inicializa dichas clases y prepara el entorno en base a una estructura de capas, donde cada prenda de ropa tendrá asignada su posición de profundidad mediante la propiedad zOrder de su capa asociada. Así pues, el resultado que se muestra en pantalla será un conjunto de imágenes organizadas por capas que se ordenan en base al zOrder de éstas.

La inicialización además se encarga de preparar la comunicación con el front-end mediante eventos que controlan asíncronamente las siguientes acciones:

  • Vestir / desvestir una pieza de ropa.
  • Cambiar el fondo del probador.
  • Cambiar el modelo del maniquí.
  • Desnudar al maniquí.
  • Zoom.
  • Rotación del modelo.
  • Configuración del modelo (peinados y variación de pies y manos según la prenda que se vista).
  • Screenshots pasados a arrays de bytes para procesarlos con JS.
  • Iluminación de piezas de ropa concretas.

Cada una de estas acciones es cargada y procesada en una instancia de la clase Queue, donde una vez finalizado este proceso es devuelta al Renderer para facilitar el resultado al objeto de la clase Render.

 

Queue / Status:

Queue (pila de instrucciones) es el módulo encargado de interpretar las acciones. Realiza los cambios internos de estado y carga las imágenes asociadas a cada acción si así se requiere.

Cuando una acción entra en la pila, se lanzan las cargas de las imágenes asociadas a ésta. Cuando todas las acciones de la pila están completamente cargadas, lo cual implica que las imágenes asociadas han sido descargadas del servidor, la pila devuelve las acciones con sus datos adjuntos al Renderer.

Status controla en cada momento el estado del programa, almacena los objetos vestidos, la configuración del maniquí, el estado del zoom, de la rotación, etc., provocando que Renderer y Queue actuen en consecuencia.

 

Render:

Una vez Renderer obtiene los resultados de Queue, invoca a los métodos de Render para visualizarlos. Teniendo en cuenta que Renderer se encarga de posicionar correctamente las imágenes en la pila de capas ordenadas por un zOrder, el problema más importante que queda por resolver es la visualización de la superposición entre dos o más prendas de ropa. Es decir, al superponer piezas, hay que tener en cuenta si se encuentran en una capa con zOrder menor y sin embargo poseen más área que las de superior zOrder.

El problema se solucionó con máscaras que se acumulan por zOrder.

Sin embargo a pesar de ser, generalmente, eficaz y rápido, tiene ciertos inconvenientes como el que muestra la imagen anterior. Para ciertas zonas del cuerpo (colisiones de extremidades con cuerpo) és imposible aplicar una máscara. Por ejemplo en la imagen anterior, si se aplicara máscara en la zona señalada, se eliminaría parte de la manga.

Etiquedado como , ,

Deja un comentario

Tu dirección de correo electrónico no será publicada.