GLB, USDZ e WebAR: quali formati servono per il 3D sul sito
Asset, visualizzatore e percorso dell’utente: cosa preparare per scheda prodotto, configuratore e realtà aumentata.
Un prodotto da ruotare nella scheda e-commerce, una poltrona da provare nel soggiorno e un configuratore con finiture selezionabili possono partire dallo stesso oggetto. Non hanno però la stessa consegna. Prima di chiedere «mi serve un GLB o un USDZ?», conviene chiarire che cosa deve poter fare la persona che apre la pagina.
La distinzione utile è fra asset, sistema che lo visualizza e percorso dell’utente. Il file contiene il modello; il visualizzatore ne interpreta le caratteristiche; il sito mette a disposizione comandi, informazioni e un passo successivo. Preparare solo il primo elemento lascia irrisolti gli altri due.
GLB, USDZ e WebAR a confronto
| Elemento | Che cosa indica | Decisione pratica |
|---|---|---|
| GLB | La rappresentazione binaria di un asset glTF. | Specificare la scena da consegnare e provarla nel visualizzatore scelto. |
| USDZ | Un pacchetto che raccoglie contenuti USD e risorse consentite. | Prepararlo per la destinazione prevista e verificare la resa. |
| WebAR | Un’esperienza di realtà aumentata avviata attraverso il web, non un’estensione di file. | Definire accesso, dispositivi, interazione e alternativa quando l’AR non parte. |
Khronos descrive glTF come formato per la distribuzione di asset 3D e ne prevede la forma binaria GLB. OpenUSD definisce invece USDZ come pacchetto: le due sigle appartengono a specifiche diverse. Un file GLB non garantisce da solo che ogni risorsa sia incorporata. Khronos, specifica glTF, specifica USDZ.

Partire dall’azione, poi scegliere la consegna
Per una scheda prodotto, la domanda può essere: il visitatore deve osservare soltanto la forma oppure confrontare materiali e dimensioni? Nel primo caso è utile definire una vista iniziale e un dettaglio da esplorare. Nel secondo bisogna anche decidere quali scelte sono ammesse, quali informazioni cambiano e come si conserva la configurazione.
Un configuratore di prodotto richiede quindi una specifica delle combinazioni e dei comandi. Il nome del formato non definisce queste regole. Conviene approvare una configurazione rappresentativa prima di preparare l’intero catalogo: permette di discutere un esempio concreto e di correggere il metodo prima di replicarlo.
Se l’obiettivo è collocare il prodotto nell’ambiente dell’utente, il progetto entra nel perimetro delle applicazioni di realtà aumentata. Qui il criterio di accettazione deve comprendere anche scala, posizionamento e comprensibilità dell’avvio.
Un modello sullo schermo non è ancora una prova in AR
Apple documenta Quick Look per mostrare oggetti USDZ e avviare esperienze AR da Safari su iPhone e iPad. Sul percorso Android, Google documenta Scene Viewer con requisiti del dispositivo e dei servizi installati, oltre a destinazioni alternative quando il percorso previsto non è disponibile. Non basta quindi verificare che il modello si apra sul computer. Apple Quick Look, Google Scene Viewer.
Anche i comandi del sito meritano attenzione: gli esempi ufficiali di model-viewer distinguono WebXR, Scene Viewer e Quick Look. L’interfaccia HTML della pagina non viene trasferita automaticamente ai visualizzatori nativi. La documentazione mostra inoltre un asset iOS separato quando la generazione automatica non risulta adeguata. model-viewer: AR.
La scelta operativa è definire in anticipo che cosa deve rimanere disponibile: colore selezionato, istruzioni, scheda tecnica, ritorno al prodotto. Non promettere identiche funzioni su tutti i percorsi prima di averle provate.
Dal CAD all’asset da consegnare
Una preparazione ordinata può seguire cinque passaggi:
- Raccogliere gli input. Versione del prodotto, dimensioni confermate, materiali di riferimento e parti da mostrare. Separare ciò che è definitivo da ciò che deve essere approvato.
- Scegliere una scena campione. Includere un elemento difficile, per esempio una superficie trasparente o un particolare sottile, se rilevante per il prodotto.
- Preparare le versioni per le destinazioni scelte. Registrare geometrie, texture, varianti e animazioni richieste, senza presumere una conversione identica per ogni funzione.
- Provare l’integrazione. Aprire la pagina reale, selezionare una variante, avviare l’eventuale AR e tornare al percorso commerciale.
- Conservare la revisione approvata. Associare file, pagina e risultati del collaudo, così una sostituzione successiva può essere controllata.
Non serve imporre qui un limite universale di megabyte o poligoni. Il budget va concordato sul prodotto, sul dettaglio utile e sui dispositivi previsti, poi misurato sul candidato effettivo. Un modello leggero ma illeggibile non soddisfa lo scopo; un dettaglio non visibile non va mantenuto solo perché presente nel sorgente.
Tre scenari per scrivere un brief migliore
Arredo, esempio ipotetico. Una sedia con più finiture richiede coerenza fra opzione scelta e oggetto mostrato. Il collaudo deve includere la variante effettivamente aperta in AR e la scala percepita nello spazio.
Componente industriale, esempio ipotetico. Se l’obiettivo è spiegare un innesto, scegliere quali parti separare e quali informazioni accompagnano la vista. Un’esplorazione guidata può essere più utile di una rotazione senza indicazioni.
Catalogo, esempio ipotetico. Prima di estendere la produzione a molti articoli, concordare nomi dei file, revisioni, immagini di anteprima e responsabilità sugli aggiornamenti. La consegna comprende anche il modo in cui sarà mantenuta.
Che cosa chiedere nella consegna
Richiedi un elenco di asset e destinazioni, le varianti effettivamente supportate, una pagina campione e i casi di prova concordati. Per ogni problema, conserva dispositivo, versione e passaggio che lo riproduce. Il controllo del file e il collaudo dell’esperienza sono evidenze diverse: nessuno dei due sostituisce l’altro.
Dall’asset al percorso di prodotto
Se devi scegliere fra visualizzazione, configurazione e AR, parti da un oggetto e da un’azione concreta. Possiamo valutare il materiale disponibile e definire la consegna con te: parliamone con Loto Studios.
PARLIAMO DEL PROGETTO
Stai preparando il 3D per sito, configuratore o AR?
Porta un prodotto campione, i file disponibili e le azioni che vuoi offrire. Definiamo con te asset, destinazioni e collaudo.
UN PRIMO CONFRONTO
Prodotto, file e destinazioni prima della produzione.
Partiamo da ciò che vuoi realizzare, dai materiali disponibili e dai tempi del progetto per definire il percorso insieme.
RICHIEDI UN PRIMO CONFRONTO
Raccontaci il tuo progetto.
I campi sotto sono facoltativi e servono a indirizzare meglio la prima risposta.
Sei domande frequenti
GLB e glTF sono due progetti diversi?
GLB è la forma binaria prevista da glTF. Nel brief è utile specificare la consegna richiesta, anziché usare le sigle come sinonimi di un’intera applicazione. Khronos.
Basta rinominare un GLB in USDZ?
No. Il pacchetto USDZ ha una propria struttura. Occorre una preparazione adeguata e una verifica nella destinazione scelta. OpenUSD.
Con un file 3D ho già un configuratore?
Il brief deve ancora definire opzioni, combinazioni, comandi e risultato da conservare. Parti da una configurazione campione approvata, poi estendi il lavoro.
Il pulsante AR funzionerà su qualunque telefono?
Non va promesso senza una matrice di compatibilità verificata. Per Scene Viewer, Google indica requisiti e percorsi alternativi: includili nel collaudo concordato. Google.
Quanto deve pesare il modello?
Concorda un budget sul caso concreto e misura il risultato sul dispositivo previsto. Registra anche ciò che deve restare riconoscibile: la sola dimensione del file non è il criterio di qualità.
Che cosa posso inviare per partire?
Un prodotto campione, file disponibili, dimensioni, finiture, azioni desiderate e pagina di destinazione. Segnala quali materiali sono approvati e chi valida il risultato.
Fonti e perimetro
Documentazione ufficiale Khronos, OpenUSD, Apple, Google e model-viewer consultata a fine ottobre 2026. Gli scenari sono esempi ipotetici, non casi cliente. Le immagini illustrano il tipo di lavoro.



