Perché i modelli 3D sono così pesanti?

Il tuo modello sta ingrassando di nascosto

Esporti un file GLB, 10MB, sembra ok. Lo apri sul telefono e... schermo bianco, lag, o addirittura crash.

Sul PC va benissimo, sul telefono esplode. Non è colpa del codice: i modelli 3D hanno una caratteristica controintuitiva: non occupano lo stesso spazio su disco e in VRAM.

Una foto JPG su disco può pesare solo 200KB. Ma la GPU non conosce i JPG, conosce solo i pixel grezzi. Quindi prima di essere caricata in VRAM, l'immagine viene completamente decompressa. Una texture 2048x2048, una volta decompressa, occupa circa 22MB di VRAM. Se usi 6 texture (albedo, normal, roughness, metallic, AO, emissive), un singolo materiale ti costa 132MB.

Un telefono ha in totale 2-4GB di VRAM: un solo modello con le sue texture occupa il 3-6%. E se nella scena ci sono 10 modelli?

Smontiamolo: dove va a finire lo spazio

Un tipico modello GLB è composto da tre parti principali: dati dei vertici, texture e metadati/animazioni.

Prendiamo un modello PBR reale:

Componente	Contenuto specifico	Percentuale tipica	Note
Texture	albedo, normal, roughness, metallic, AO, ecc.	70-85%	Quasi sempre il peso maggiore
Vertici	posizione, normali, UV, tangenti, colore	10-20%	Dipende dalla complessità
Animazioni	ossa, skinning, keyframe	0-15%	Solo se ci sono animazioni
Altro	definizione materiali, struttura scena, camera	< 2%	Trascurabile

Le texture occupano circa l'80%. Spesso pensi di dover ottimizzare i vertici, ma il vero peso sono le texture.

"Poco su disco" non significa "poco in VRAM"

Questo è forse il punto più importante per capire le performance 3D.

PNG e JPG sono progettati per la trasmissione in rete: piccoli su disco, veloci da scaricare. Ma la GPU non può usarli direttamente: devono prima essere decompressi completamente in pixel grezzi. Il calcolo è:

VRAM occupata = larghezza * altezza * 4 byte (RGBA) * 1.333 (con mipmap)

Una texture RGBA 4096x4096:

Metrica	Valore
Dimensione file PNG	~8MB
Dimensione file JPG	~1.5MB
VRAM occupata (con mipmap)	~87MB

Un JPG da 1.5MB, in VRAM diventa 87MB.

Cosa sono i mipmap? La GPU genera una serie di versioni progressivamente ridotte della texture, dalla dimensione originale fino a 1x1 pixel, ogni livello è la metà del precedente. Questo rende il rendering degli oggetti distanti più veloce e nitido, ma richiede circa il 33% di VRAM in più. Quasi tutte le applicazioni 3D usano i mipmap, quindi questo costo è praticamente standard.

PNG/JPG sono come i sacchetti sottovuoto da viaggio: compressi sono piccoli e facili da trasportare, ma una volta a destinazione devi gonfiarli tutti. Il download è veloce, ma la VRAM non si risparmia affatto.

Cosa succede quando la VRAM non basta

Non appare un messaggio "memoria insufficiente". La realtà è molto peggiore:

• Mobile: schermo bianco, oppure il sistema uccide direttamente la scheda del browser
• Visori VR: frame drop. In VR il lag non è "un po' lento", provoca nausea
• Desktop: texture che sfarfallano, downgrade grafico, rendering più lento

Su Reddit un developer stava costruendo una galleria WebXR e ha caricato 60 foto stereo su un Quest. All'inizio andava bene, poi sempre più instabile fino al crash. Ha passato giorni a cercare nel codice, per poi scoprire che non aveva mai pensato alla VRAM: continuava a caricare JPG nella GPU.

Le due strade della compressione

La compressione dei modelli 3D si divide in due direzioni principali:

Compressione dei vertici — memorizza i dati geometrici (posizioni, normali, UV) in modo più compatto. Ad esempio, passare da float a 32 bit a interi a 16 bit (si chiama quantizzazione). Soluzioni rappresentative: Draco, MeshOpt, KHR_mesh_quantization.

Compressione delle texture — mantiene le texture compresse anche in VRAM. La GPU decodifica i singoli pixel in tempo reale durante il campionamento, con overhead quasi nullo. Soluzioni rappresentative: KTX2 + Basis Universal.

	Compressione vertici	Compressione texture
Cosa riduce	Dati geometrici	Texture
Effetto tipico	-50-90%	Disco -50-70%, VRAM -75%
Con perdita?	Sì, precisione	Sì, qualità visiva
Caso d'uso ideale	Modelli con molti vertici	Quasi tutti i modelli PBR
Approfondimento	Articolo 2	Articoli 3 e 4

Un errore comune: usare Draco per i vertici e pensare di aver risolto tutto. Ma le texture occupano l'80% del modello: se dimezzi i vertici, il totale cala solo del 10%. Bisogna gestire entrambi i fronti.

Non esiste una soluzione unica per tutti

Questo è il punto centrale dell'intera serie:

Piattaforme diverse, dispositivi diversi, casi d'uso diversi richiedono strategie di compressione diverse.

Scenario	Collo di bottiglia principale	Focus principale
Web desktop	Velocità di download	Dimensione file
Browser mobile	VRAM	Compressione texture
Visori VR	VRAM + frame rate	Compressione texture + semplificazione vertici
App ibride (es. mini-program)	Dimensione pacchetto + compatibilità	Soluzioni leggere (MeshOpt)
Scene di grandi dimensioni	VRAM + draw call	Compressione completa + LOD

Nei prossimi articoli non diremo solo "usa X e basta": spiegheremo per cosa è adatto X, quando invece è controproducente, e in quali casi conviene usare Y.

Prossimo passo

Questo articolo ha chiarito il problema. Il prossimo si mette al lavoro: conosciamo i tre strumenti della compressione dei vertici: quantizzazione, MeshOpt e Draco.