Come si esporta un progetto 3D per la realtà aumentata? La procedura step by step che evita problemi di visualizzazione su dispositivi mobili

Hai modellato un oggetto impeccabile, ma sul telefono appare sgranato, pesante o con materiali sbagliati. Succede perché l’AR ha regole sue: scala reale, formati giusti, shader limitati e texture ottimizzate. Qui trovi una procedura concreta, collaudata in automotive e nautica, per uscire dall’app di modellazione con un file che in realtà aumentata si vede bene e gira fluido.

Scegli la destinazione e imposta il formato fin dall’inizio

Prima decidi dove verrà visto il modello. Questa scelta guida tutto: naming, materiali, UV, compressioni.

• iOS e Safari con Quick Look: punta su USDZ. È la via più lineare per ARKit.
• Android e Web: lavora con glTF/GLB, supportato da Scene Viewer e dai principali viewer WebAR.
• Cross-platform: prepara entrambi. La pipeline principale in GLB ti semplifica la conversione a USDZ.

Obiettivo: un asset leggero, PBR standard, in scala metrica e pronto a caricare senza sorprese.

Potrebbe interessarti anche

Come scegliere il software 3D migliore per modellare personaggi complessi? Scopri l’alternativa più intuitiva contro le soluzioni standardWorkflow per la stampa 3D nei software di grafica: la scorciatoia che evita errori comuni nel passaggio dal digitale al realeCome si crea un modello 3D per videogiochi? Scopri le strategie dei professionistiI migliori plugin per la modellazione 3D in Blender: strumenti poco noti che velocizzano ogni progetto

Prepara il modello: pulizia, scala e topologia

Le ottimizzazioni a valle non salvano un modello sporco a monte. Metti ordine prima di toccare l’export.

• Scala reale: lavora in metri. In ARKit e ARCore 1 unità = 1 m. Verifica bounding box: una sedia 0,45 x 0,45 x 0,9 m ha senso; una da 45 m no.
• Orientamento e pivot: Y-up, pivot alla base a contatto del suolo. Eviti asset “mezzo affondato” nella stanza.
• Congela trasformazioni: applica scale/rotate prima dell’export. Niente scale negative.
• Topologia: triangola in export (o in scena se serve coerenza), elimina n-gon e geometrie non manifold. Normali tutte coerenti verso l’esterno.
• Budget poligonale: 30–80k triangoli per singolo asset AR su mobile è sostenibile. Sopra i 150k inizi a pagare in FPS, soprattutto con materiali multipli.
• Draw call: unisci mesh con lo stesso materiale. Meno materiali = meno overhead. Evita decine di shader diversi per viti e guarnizioni.

UV e LOD: semplicità che paga

Le texture fanno la differenza, ma vanno gestite con disciplina.

• UV compatti: niente UDIM. Un UV set 0–1 pulito. Se ti serve Ambient Occlusion dedicata, usa un secondo UV set non sovrapposto.
• Packing: lascia margini generosi (8–16 px a 2K). Gli edge devono reggere il mipmapping.
• Simmetrie: sovrapponi solo dove accetti specularità. Su loghi e lettering, UV unici.
• LOD: crea almeno LOD0/LOD1/LOD2. Riduzione 40–60% a step. In WebAR e app native fa la differenza nei device caldi o con rete lenta.

Materiali PBR per mobile: cosa funziona e cosa no

In AR non c’è spazio per shader esotici. Stai sul PBR metalness-roughness.

• Canali standard: Base Color (sRGB), Normal (tangent space, lineare), Roughness (lineare), Metallic (lineare), AO (lineare). Per GLB puoi usare una ORM map combinando: occlusion R, roughness G, metallic B.
• Gamma corretta: Base Color in sRGB; Normal/Roughness/Metallic/AO in lineare. Un errore qui ti sporca tutto l’asset.
• Riflessi: punta a roughness tra 0,2 e 0,7 per materiali credibili su mobile. Gli specchi perfetti raramente rendono bene senza environment adeguato.
• Trasparenze: usale con parsimonia. Se ti basta “forare” un materiale, preferisci alpha cutoff rispetto al blending.
• Double-sided off: mantenilo disattivo salvo necessità. È costoso e può rompere l’illuminazione.

Texture e compressioni: qualità entro i limiti

La resa dipende da come bilanci risoluzione, formato e peso.

• Risoluzioni: 1024 px per asset piccoli; 2048 px per eroi di scena. Raramente serve 4K su mobile.
• Formati: PNG per maschere/trasparenze; JPEG per albedo fotografiche; KTX2 (BasisU) se pubblichi su Web/GLB per una compressione robusta.
• Mipmaps sempre: evita shimmering e aliasing.
• Palette ridotte: limita il numero di texture set. Meglio una 2K ben packata che tre 1K sparse.

Procedura di export, passo per passo

1. Duplica la scena a “_AR_export” per lavorare non distruttivo.
2. Controlla unità in metri e dimensioni reali del bounding box.
3. Applica trasformazioni e posiziona il pivot alla base, Y-up.
4. Triangola in export; se il software non è affidabile, triangola in scena.
5. Rigenera normali e tangenti. Tangent space coerente per le normal map.
6. Verifica UV: 0–1, margini corretti, niente UDIM.
7. Consolida materiali PBR in metalness-roughness. Converti eventuali spec-gloss.
8. Pack texture: BaseColor (sRGB), Normal (lin), ORM o canali separati (lin). Riduci a 1–2K.
9. Prepara LOD e naming chiaro: asset_LOD0, asset_LOD1…
10. Esporta per Web/Android: GLB con compressione Draco per mesh e KTX2 per texture se supportate. Includi animazioni bakeate.
11. Esporta per iOS: USDZ tramite exporter nativo o Reality Converter. Verifica unità in metri e che le texture siano incorporate.
12. Valida i file: usa un viewer glTF o Quick Look per un check veloce. Cerca errori di gamma e scala.

Test su dispositivo: la prova che conta

Non fidarti solo del viewer desktop. Apri l’asset su due/tre smartphone rappresentativi.

• iOS: Quick Look. Verifica scala nell’ambiente, feed AR stabile, coerenza dei materiali.
• Android: Scene Viewer. Controlla performance e resa al variare della luce reale.
• WebAR: un viewer basato su glTF per vedere compressioni, mipmaps e LOD in rete cellulare.

Se il modello è “pesante” su Android più economici, riduci materiali e texture prima dei poligoni. L’overhead di draw call è spesso il vero collo di bottiglia.

Debug rapido dei problemi più comuni

• Asset troppo grande/piccolo: unità errate. Ricalibra su metri e riesporta.
• Materiali neri o lucidi a specchio: shader non PBR o canali in gamma sbagliata. Torna a metalness-roughness, sRGB solo per BaseColor.
• Texture sfocate: niente mipmap o risoluzioni troppo basse. Porta a 2K e verifica il filtraggio.
• Normal invertite: superfici invisibili. Ripara normali, evita double-sided come toppa.
• AO “stampata”: AO troppo forte in ambienti luminosi. Tienila sottile (0,2–0,4) e corretta nel canale.
• Scattosità: troppi materiali e mesh. Unisci per materiale, attiva Draco, riduci draw call.

Se fossi al posto tuo, cosa sceglierei

Per copertura massima e meno rischi, imposterei la pipeline primaria su GLB: PBR standard, compressione Draco/KTX2, test in WebAR e Scene Viewer. Poi convertirei in USDZ per Quick Look, verificando solo coerenza dei canali e della scala. Se l’obiettivo è una demo premium solo iOS, dedicherei più tempo a un USDZ con texture 2K pulite e AO calibrata: resa al top, peso ancora sostenibile.

In ogni caso, metterei una regola ferrea: non superare i 10–12 MB per asset “eroe” e 4–6 MB per asset secondari. Oltre, la curva di abbandono su rete mobile si impenna.

Checklist operativa finale

• Scala reale in metri, Y-up, pivot alla base.
• Triangoli puliti, normali e tangenti rigenerate.
• UV 0–1 senza UDIM, margini 8–16 px a 2K.
• PBR metalness-roughness: BaseColor sRGB; Normal/Roughness/Metallic/AO lineari.
• Texture 1–2K, mipmaps attive; PNG/JPEG o KTX2.
• Niente double-sided salvo necessità; trasparenza moderata.
• Materiali minimizzati, mesh accorpate per ridurre draw call.
• LOD 0/1/2 con riduzioni progressive.
• Export GLB con Draco e, se possibile, KTX2; export USDZ con unità in metri e texture embed.
• Test su iOS, Android e WebAR in rete cellulare. Se zoppica, riduci materiali prima dei poligoni.

Seguendo questi passi arrivi a un asset AR affidabile: leggibile, leggero e coerente su dispositivi mobili. È il tipo di rigore che evita sorprese in demo con clienti e l’unico modo per far rendere davvero il tuo design fuori dal monitor.