Virtual Try-On: dalla foto prodotto alla prova live
Per una web agency partner di Rayo Consulting abbiamo costruito un virtual try-on per e-commerce: le immagini di catalogo del prodotto vengono convertite in mesh 3D con Tripo3D, poi ancorate in tempo reale sull'utente tramite MediaPipe, esteso con landmark custom per una maggiore precisione, e renderizzate con Three.js direttamente nel browser.
Un virtual try-on che parte dalle immagini di catalogo già esistenti: nessuna sessione fotografica dedicata, nessuna modellazione 3D manuale, nessuna app da installare.
Il contesto
Una web agency partner di Rayo Consulting voleva costruire un servizio di virtual try-on da mettere a listino per i propri clienti e-commerce nel settore abbigliamento. L'esigenza commerciale era chiara: su un capo il cliente vuole vedere come gli sta prima di comprare, e una galleria di foto su modello non basta a colmare quell'incertezza.
Il vincolo, però, era altrettanto chiaro. Perché il servizio fosse vendibile, doveva funzionare sui cataloghi così come sono già: nessun cliente dell'agenzia avrebbe rifotografato l'intero assortimento o commissionato modellazione 3D referenza per referenza. Un servizio che richiede quel tipo di investimento iniziale non si vende.
Il nostro compito era quindi ingegneristico prima ancora che tecnologico: rendere il costo marginale di ogni nuovo capo abbastanza basso da sostenere un modello di business ripetibile.
Il problema della pipeline 3D
Un virtual try-on ha bisogno di un asset 3D per ogni prodotto. Le strade tradizionali sono due, entrambe costose.
La prima: modellazione manuale. Un artista 3D ricostruisce ogni referenza. Qualità alta, ma tempi e costi che non scalano su un catalogo di centinaia di articoli, e ogni nuova collezione riapre il problema da capo.
La seconda: scansione fotogrammetrica. Richiede attrezzatura dedicata e la disponibilità fisica del prodotto, spesso in un momento in cui il prodotto è già in magazzino o non è ancora arrivato.
Nessuna delle due poteva reggere un servizio a listino, perché entrambe caricano sul cliente finale un costo che cresce linearmente col catalogo. L'unico asset garantito per ogni prodotto, in qualsiasi e-commerce, sono le immagini di catalogo: la pipeline doveva partire da lì.
La conversione con Tripo3D
Abbiamo costruito la pipeline attorno a Tripo3D, che genera una mesh 3D texturizzata a partire dalle immagini del prodotto già presenti a catalogo.
Questo sposta il costo marginale di ogni nuova referenza da "ore di lavoro di un artista 3D" a "una chiamata alla pipeline", che è esattamente ciò che rende il servizio vendibile a ricorrenza. Le immagini già presenti sulla scheda prodotto diventano l'input del try-on, senza aggiungere passaggi al processo del cliente finale.
Le mesh generate passano poi per una fase di normalizzazione, perché un asset generato automaticamente non arriva né allineato al sistema di riferimento del renderer né leggero abbastanza per il browser. La pipeline esegue in sequenza:
- Riallineamento: l'asse verticale del capo viene portato sull'asse Y del mondo e l'origine spostata sul punto di ancoraggio (la linea delle spalle), così che la stessa trasformazione valga per tutte le referenze.
- Decimazione: da ~180k triangoli in uscita da Tripo3D a ~12k, preservando la silhouette e la topologia delle maniche, le zone dove l'errore si vede di più durante il movimento.
- Bake delle texture: le mappe generate vengono ricompattate in un atlante PBR 2K (albedo, normal, roughness), per tenere una sola draw call per capo.
- Compressione: export in glTF con Draco sulla geometria e KTX2/Basis sulle texture, così il payload per referenza resta nell'ordine delle centinaia di kB anziché dei megabyte.
Questa fase è interamente automatizzata: una referenza nuova entra come immagini di catalogo ed esce come asset pronto al try-on, senza passaggi manuali.
Il tracking: MediaPipe esteso
Il tracking in tempo reale si basa su MediaPipe, che gira interamente nel browser dell'utente: nessun frame video viene inviato a un server, il che semplifica sensibilmente il quadro privacy rispetto a una soluzione lato server.
MediaPipe da solo, però, non era abbastanza preciso per l'ancoraggio del capo. Il modello di posa standard traccia lo scheletro con pochi punti chiave (spalle, gomiti, polsi, fianchi), ottimizzati per robustezza generale, non per la stabilità sub-pixel nei punti su cui un indumento deve appoggiarsi. Piccole oscillazioni dei landmark si traducono in un capo che "galleggia" sul corpo invece di restare fermo.
Abbiamo quindi sviluppato estensioni custom sul set di landmark. Dai 33 punti nativi ne deriviamo altri 8 (centro spalle, base collo, punto sterno, assi di busto e vita), ottenuti per interpolazione vincolata anziché per inferenza diretta, il che li rende più stabili dei punti da cui nascono.
Sopra questi punti gira un filtro One Euro con cutoff adattivo: aggressivo sullo smoothing quando l'utente è fermo, permissivo quando si muove rapidamente. È la differenza fra un capo che vibra da fermo e uno che resta indietro nei movimenti veloci: un filtro a cutoff fisso costringe a sceglierne uno dei due.
La scala del capo non viene dedotta da un singolo segmento, ma da una stima della corporatura mediata su più distanze inter-landmark, resa robusta agli outlier. Un singolo frame in cui MediaPipe sbaglia un polso non fa più "pulsare" il capo.
Il rendering: Three.js
Il layer di rendering è Three.js, che compone la mesh del capo sopra il feed della webcam e la aggiorna a ogni frame seguendo i landmark tracciati, adattandone la scala alla corporatura rilevata.
Il lavoro qui è stato soprattutto di coerenza visiva e di budget. Sul primo fronte: illuminazione stimata dal feed della webcam e applicata alla mesh, così che un capo chiaro non risulti innaturalmente brillante in una stanza buia; occlusioni gestite con una maschera di segmentazione, in modo che il capo sparisca dietro le braccia quando l'utente le incrocia.
Sul secondo: a 30 FPS il frame budget è di 33 ms, e dentro ci devono stare inferenza dei landmark, filtraggio, aggiornamento dello scheletro e draw call. Abbiamo separato i due carichi: l'inferenza MediaPipe gira in un Web Worker con backend WebGL, il rendering resta sul main thread. Così un picco di latenza dell'inferenza non produce frame droppati nel rendering, ma solo un aggiornamento di posa leggermente più vecchio. Percettivamente è molto meno visibile.
Il risultato è una latenza end-to-end sotto i 40 ms dal frame catturato al capo composto: sotto la soglia in cui il movimento inizia a sembrare disaccoppiato dal proprio corpo.
Stack tecnologico
| Ambito | Tecnologie |
|---|---|
| Generazione 3D | Tripo3D (immagini catalogo → mesh texturizzata) |
| Post-processing mesh | decimazione a ~12k tri, atlante PBR 2K, glTF + Draco + KTX2/Basis |
| Tracking | MediaPipe Pose (33 landmark) + 8 punti derivati custom |
| Filtraggio | One Euro filter a cutoff adattivo, stima scala robusta agli outlier |
| Rendering | Three.js, WebGL, segmentazione per le occlusioni |
| Threading | inferenza in Web Worker, rendering sul main thread |
| Esecuzione | interamente client-side: nessun frame video lascia il dispositivo |
In sintesi
Il risultato è un virtual try-on che si aggancia al catalogo esistente invece di richiedere un flusso di produzione parallelo: le foto che l'e-commerce produce comunque diventano asset 3D, e l'utente prova il capo dal browser senza installare nulla.
Per la web agency partner questo non è un progetto una tantum, ma un servizio a listino: la pipeline è la stessa per ogni cliente, e il costo di attivazione di un nuovo catalogo è basso abbastanza da renderlo un'offerta ripetibile.
Vuoi vedere il virtual try-on in funzione? Prenota una demo e lo mostriamo dal vivo sul tuo catalogo.
Virtual Try-On realizzato da Rayo Consulting per una web agency partner.