Virtual Try-On: de la foto de producto a la prueba en vivo

Un virtual try-on que parte de las imágenes de catálogo ya existentes: ninguna sesión fotográfica dedicada, ningún modelado 3D manual, ninguna app que instalar.

El contexto

Una agencia web partner de Rayo Consulting quería construir un servicio de virtual try-on para incorporarlo a su catálogo de servicios para sus clientes de e-commerce del sector de la moda. La necesidad comercial estaba clara: con una prenda, el cliente quiere ver cómo le queda antes de comprar, y una galería de fotos sobre modelo no basta para despejar esa incertidumbre.

La restricción, sin embargo, era igual de clara. Para que el servicio fuera vendible, tenía que funcionar sobre los catálogos tal y como ya son: ningún cliente de la agencia iba a refotografiar todo su surtido ni a encargar modelado 3D referencia por referencia. Un servicio que exige ese tipo de inversión inicial no se vende.

Nuestra tarea era, por tanto, de ingeniería antes incluso que tecnológica: bajar el coste marginal de cada nueva prenda lo suficiente como para sostener un modelo de negocio repetible.

El problema de la pipeline 3D

Un virtual try-on necesita un asset 3D por cada producto. Las vías tradicionales son dos, y ambas son caras.

La primera: modelado manual. Un artista 3D reconstruye cada referencia. Calidad alta, pero plazos y costes que no escalan en un catálogo de cientos de artículos, y cada nueva colección reabre el problema desde cero.

La segunda: escaneo fotogramétrico. Requiere equipamiento dedicado y la disponibilidad física del producto, a menudo en un momento en que el producto ya está en almacén o todavía no ha llegado.

Ninguna de las dos podía sostener un servicio de catálogo, porque ambas cargan al cliente final con un coste que crece linealmente con el catálogo. El único asset garantizado para cada producto, en cualquier e-commerce, son las imágenes de catálogo: la pipeline tenía que partir de ahí.

La conversión con Tripo3D

Hemos construido la pipeline alrededor de Tripo3D, que genera una malla 3D texturizada a partir de las imágenes del producto ya presentes en el catálogo.

Esto desplaza el coste marginal de cada nueva referencia de "horas de trabajo de un artista 3D" a "una llamada a la pipeline", que es exactamente lo que hace que el servicio sea vendible de forma recurrente. Las imágenes ya presentes en la ficha de producto se convierten en el input del try-on, sin añadir pasos al proceso del cliente final.

Las mallas generadas pasan después por una fase de normalización, porque un asset generado automáticamente no llega ni alineado al sistema de referencia del renderer ni lo bastante ligero para el navegador. La pipeline ejecuta en secuencia:

• Realineación: el eje vertical de la prenda se lleva al eje Y del mundo y el origen se desplaza al punto de anclaje (la línea de los hombros), de modo que la misma transformación valga para todas las referencias.
• Diezmado: de ~180k triángulos a la salida de Tripo3D a ~12k, preservando la silueta y la topología de las mangas, las zonas donde el error más se nota durante el movimiento.
• Bake de las texturas: los mapas generados se recompactan en un atlas PBR 2K (albedo, normal, roughness), para mantener una sola draw call por prenda.
• Compresión: exportación a glTF con Draco en la geometría y KTX2/Basis en las texturas, de modo que el payload por referencia se queda en el orden de los cientos de kB en lugar de los megabytes.

Esta fase está totalmente automatizada: una referencia nueva entra como imágenes de catálogo y sale como asset listo para el try-on, sin pasos manuales.

El tracking: MediaPipe ampliado

El tracking en tiempo real se basa en MediaPipe, que se ejecuta enteramente en el navegador del usuario: ningún frame de vídeo se envía a un servidor, lo que simplifica notablemente el escenario de privacidad respecto a una solución del lado del servidor.

MediaPipe por sí solo, sin embargo, no era lo bastante preciso para el anclaje de la prenda. El modelo de pose estándar rastrea el esqueleto con pocos puntos clave (hombros, codos, muñecas, caderas), optimizados para robustez general, no para la estabilidad subpíxel en los puntos sobre los que una prenda tiene que apoyarse. Pequeñas oscilaciones de los landmarks se traducen en una prenda que "flota" sobre el cuerpo en lugar de quedarse quieta.

Por eso desarrollamos extensiones a medida sobre el conjunto de landmarks. De los 33 puntos nativos derivamos otros 8 (centro de hombros, base del cuello, punto del esternón, ejes de torso y cintura), obtenidos por interpolación restringida en lugar de por inferencia directa, lo que los hace más estables que los puntos de los que nacen.

Sobre estos puntos se ejecuta un filtro One Euro con cutoff adaptativo: agresivo en el suavizado cuando el usuario está quieto, permisivo cuando se mueve rápido. Es la diferencia entre una prenda que vibra en reposo y una que se queda atrás en los movimientos rápidos: un filtro de cutoff fijo obliga a elegir uno de los dos.

La escala de la prenda no se deduce de un único segmento, sino de una estimación de la complexión promediada sobre varias distancias entre landmarks, hecha robusta frente a los outliers. Un único frame en el que MediaPipe se equivoca con una muñeca ya no hace "pulsar" la prenda.

El rendering: Three.js

La capa de rendering es Three.js, que compone la malla de la prenda sobre el feed de la webcam y la actualiza en cada frame siguiendo los landmarks rastreados, adaptando su escala a la complexión detectada.

El trabajo aquí ha sido sobre todo de coherencia visual y de presupuesto. En el primer frente: iluminación estimada a partir del feed de la webcam y aplicada a la malla, para que una prenda clara no resulte antinaturalmente brillante en una habitación oscura; oclusiones gestionadas con una máscara de segmentación, de modo que la prenda desaparezca detrás de los brazos cuando el usuario los cruza.

En el segundo: a 30 FPS el frame budget es de 33 ms, y ahí dentro tienen que caber la inferencia de los landmarks, el filtrado, la actualización del esqueleto y las draw calls. Hemos separado las dos cargas: la inferencia de MediaPipe se ejecuta en un Web Worker con backend WebGL, el rendering se queda en el main thread. Así, un pico de latencia de la inferencia no produce frames perdidos en el rendering, sino solo una actualización de pose ligeramente más antigua. Perceptivamente es mucho menos visible.

El resultado es una latencia end-to-end por debajo de los 40 ms desde el frame capturado hasta la prenda compuesta: por debajo del umbral en el que el movimiento empieza a parecer desacoplado del propio cuerpo.

Stack tecnológico

Ámbito	Tecnologías
Generación 3D	Tripo3D (imágenes de catálogo → malla texturizada)
Post-procesado de la malla	diezmado a ~12k tri, atlas PBR 2K, glTF + Draco + KTX2/Basis
Tracking	MediaPipe Pose (33 landmarks) + 8 puntos derivados a medida
Filtrado	filtro One Euro de cutoff adaptativo, estimación de escala robusta frente a outliers
Rendering	Three.js, WebGL, segmentación para las oclusiones
Threading	inferencia en Web Worker, rendering en el main thread
Ejecución	enteramente del lado del cliente: ningún frame de vídeo sale del dispositivo

En resumen

El resultado es un virtual try-on que se engancha al catálogo existente en lugar de exigir un flujo de producción paralelo: las fotos que el e-commerce produce de todos modos se convierten en assets 3D, y el usuario prueba la prenda desde el navegador sin instalar nada.

Para la agencia web partner esto no es un proyecto puntual, sino un servicio de catálogo: la pipeline es la misma para cada cliente, y el coste de activación de un nuevo catálogo es lo bastante bajo como para convertirlo en una oferta repetible.

---

¿Quieres ver el virtual try-on en funcionamiento? Reserva una demo y te lo enseñamos en directo sobre tu catálogo.

Virtual Try-On realizado por Rayo Consulting para una agencia web partner.