Three.js BLOCKS 0.11.0: nuove funzionalità per la gestione
Three.js BLOCKS 0.11.0 è uscito con tre novità che cambiano i calcoli di budget per chi gestisce esperienze 3D in produzione: Baked Motion dimezza la memoria GPU, Gaussian splat entra nella pipeline di rendering, il batching indiretto viene rimosso.
Three.js BLOCKS 0.11.0 è uscito con tre novità che cambiano i calcoli di budget per chi gestisce esperienze 3D in produzione: Baked Motion dimezza la memoria GPU sulle animazioni, Gaussian splat entra nella pipeline di rendering, il batching indiretto viene rimosso senza preavviso pratico.
In sintesi
- Baked Motion fonde ogni pagina dell’atlante di animazione in un’unica texture RGBA (formato che include i canali rosso, verde, blu e trasparenza in un unico blocco di dati), dimezzando la memoria GPU occupata in scenari tipici.
- Il supporto nativo a HEVC (High Efficiency Video Coding, codec video ad alta efficienza) con fallback automatico ad AVC (Advanced Video Coding, il codec H.264 standard) elimina una classe di decisioni manuali per il team tecnico.
- Il batching indiretto (tecnica che raggruppa più oggetti 3D in un’unica chiamata al motore grafico) è stato rimosso: chi lo usava deve pianificare una migrazione prima di aggiornare.
- Gaussian splat (tecnica di rendering che rappresenta scene 3D come nuvole di punti invece di mesh poligonali tradizionali) entra nella pipeline con nuovi nodi SDF (Signed Distance Field, campo di distanza con segno: struttura matematica che descrive forme 3D in modo efficiente per il motore grafico).
- Adottare un layer commerciale sopra Three.js nativo riduce la complessità in certi contesti, ma introduce dipendenze da gestire a ogni aggiornamento del framework sottostante.
Baked Motion: cosa cambia nella gestione della memoria GPU
Baked Motion è una funzionalità esclusiva di Three.js BLOCKS. Non è nel core di Three.js. La distinzione conta subito: chi lavora con Three.js nativo non ha accesso a questo meccanismo, e chi valuta BLOCKS deve sapere che sta adottando un’astrazione proprietaria sopra il framework open source.
Il meccanismo funziona così. Nelle pipeline di animazione tradizionali, ogni pagina dell’atlante di animazione, una sorta di foglio di sprite 3D dove ogni fotogramma occupa una porzione della texture, viene caricata come texture separata. Texture multiple significano overhead multipli: ogni texture porta metadati, intestazioni di allocazione e spazio di allineamento in memoria. Consolidare tutto in un’unica texture RGBA elimina questi overhead ridondanti e produce un layout di memoria contiguo, più efficiente da leggere per la GPU, ovvero la scheda grafica del dispositivo. Il risultato dichiarato nel changelog di BLOCKS è un dimezzamento della memoria GPU in scenari tipici.
Esempio concreto: uno showroom digitale di un produttore di mobili italiano che mostra sedie con animazioni di apertura, chiusura e rotazione su tre varianti di colore. Con la vecchia pipeline, ogni variante animata occupava texture separate. Con Baked Motion, tutto confluisce in un unico blocco. Meno memoria GPU significa poter caricare più varianti nella stessa sessione, oppure abbassare i requisiti minimi del dispositivo target senza degradare la qualità visiva. Un cliente che accede dal telefono con due anni di vita vede la stessa esperienza di chi ha un laptop recente.
L’azione concreta oggi: se stai pianificando un progetto con animazioni complesse su BLOCKS, rivedi il budget di memoria GPU nelle specifiche tecniche usando come riferimento il dimezzamento dichiarato. Se invece usi già Baked Motion in una versione precedente, controlla il changelog per capire se l’aggiornamento richiede modifiche alla configurazione degli atlanti esistenti.
Gaussian splat e nodi SDF: rendering senza mesh tradizionali
Gaussian splat è una tecnica di rendering che negli ultimi due anni ha guadagnato terreno nelle pipeline di visualizzazione architettonica e nella fotogrammetria, ovvero la ricostruzione 3D a partire da fotografie. Invece di costruire una mesh poligonale, la rete di triangoli che compone un oggetto 3D classico, rappresenta la scena come una nuvola di punti gaussiani. Ogni punto ha posizione, colore, opacità e forma ellissoidale. Il risultato visivo su scene catturate da fotocamera è spesso più fedele di una mesh ricostruita, con meno artefatti sui materiali organici e sulle superfici riflettenti.
Non è magia. È geometria probabilistica applicata al rendering in tempo reale.
L’ingresso di Gaussian splat in BLOCKS 0.11.0, affiancato dai nuovi nodi SDF, apre una strada concreta per chi lavora su configuratori di interni, presentazioni immobiliari o prodotti con geometrie complesse. I nodi SDF permettono di descrivere forme attraverso funzioni matematiche invece che attraverso poligoni: utile per oggetti con bordi morbidi, fusioni tra forme o effetti che sarebbero costosi da gestire con mesh tradizionali.
Un esempio che conosco bene: uno studio di architettura che produce tour virtuali di appartamenti in costruzione può usare Gaussian splat per caricare una scansione fotorealistica del cantiere e sovrapporvi elementi configurabili, pavimenti, rivestimenti, arredi, gestiti con nodi SDF. Senza ricostruire manualmente ogni superficie in un software di modellazione 3D. Il risparmio di tempo è misurabile in giorni, non in ore.
L’azione concreta oggi: se il tuo flusso di lavoro include fotogrammetria o scansioni LiDAR (Light Detection And Ranging, tecnologia laser per la misurazione precisa di spazi fisici), valuta se Gaussian splat in BLOCKS può sostituire o affiancare la pipeline di conversione in mesh che usi attualmente.
La rimozione del batching indiretto: chi deve agire ora
Il batching indiretto era una tecnica che permetteva di raggruppare più oggetti 3D in un’unica istruzione al motore grafico, riducendo il numero di chiamate CPU, ovvero il processore centrale del dispositivo, per ogni fotogramma renderizzato. BLOCKS 0.11.0 lo rimuove. Insieme agli esempi di codice che lo illustravano.
Per chi non lo usava, è trasparente. Per chi lo aveva integrato in produzione, è una migrazione obbligata prima di aggiornare.
Il rischio operativo non è tecnico in senso stretto. È di tempistica. Se un configuratore di prodotto live usa batching indiretto e l’aggiornamento viene fatto senza verificare le dipendenze, il comportamento in produzione può cambiare in modo non previsto, con effetti visivi che emergono solo quando un cliente sta usando lo strumento. Non è uno scenario teorico.
L’azione concreta oggi: prima di aggiornare qualsiasi progetto BLOCKS alla 0.11.0, fai un audit delle funzionalità usate e confrontale con il changelog ufficiale. Il batching indiretto non sarà l’ultima rimozione nelle versioni future. Stabilire questo processo di verifica come standard prima di ogni aggiornamento vale più che gestire l’emergenza caso per caso.
La domanda strategica: layer commerciale, pro e contro reali
Conviene adottare un layer come Three.js BLOCKS sopra Three.js nativo, o aggiunge dipendenze che complicano la manutenzione a lungo termine? La risposta ha due facce genuine, e sarebbe disonesto appiattirla.
Il caso in cui BLOCKS riduce davvero la complessità: un team di sviluppo web che deve consegnare un configuratore 3D in sei settimane, senza specialisti di grafica in organico, trova in BLOCKS un insieme di astrazioni già testate. Baked Motion, la gestione automatica dei codec video, i nodi SDF pronti all’uso. Sono settimane di lavoro che non si fanno internamente. Per un’agenzia o uno studio che fattura a progetto, questo ha un valore economico diretto e misurabile.
Il caso in cui le dipendenze pesano: Three.js rilascia aggiornamenti con frequenza, e ogni versione del core può introdurre breaking changes, modifiche che rompono la compatibilità con il codice esistente. BLOCKS deve allinearsi a queste versioni, e il ritardo tra un aggiornamento del core e il suo recepimento nel layer commerciale è un rischio reale. Se Three.js introduce una funzionalità critica per il tuo progetto e BLOCKS non la supporta ancora, sei bloccato. O esci dall’astrazione, perdendo parte del vantaggio per cui l’avevi adottata.
La posizione di Osservatorio avstudio è questa: per progetti con ciclo di vita superiore a due anni e team tecnico interno, la dipendenza da un layer commerciale va valutata con lo stesso rigore con cui si valuta qualsiasi fornitore critico. Per progetti a consegna rapida con team generalisti, il trade-off è spesso favorevole all’adozione. Non esiste una risposta universale, e chi te ne propone una probabilmente non conosce il tuo contesto.
Domande correlate
Baked Motion è disponibile anche in Three.js nativo?
No. Baked Motion è una funzionalità esclusiva di Three.js BLOCKS, il layer commerciale sopra il framework open source. Three.js nativo non include questa ottimizzazione: chi lavora direttamente con Three.js deve gestire la memoria delle texture di animazione con soluzioni proprie.
Cosa succede se aggiorno BLOCKS alla 0.11.0 senza verificare le dipendenze?
Se il progetto usa batching indiretto, rimosso nella 0.11.0, il comportamento in produzione può cambiare in modo non previsto. Prima di aggiornare, verifica il changelog ufficiale e testa in ambiente di staging, ovvero un ambiente separato dall’ambiente live, prima di portare le modifiche in produzione.
Gaussian splat sostituisce le mesh poligonali tradizionali?
Non in tutti i casi. Gaussian splat è efficace su scene catturate da fotocamera, interni, paesaggi, oggetti fisici scansionati, ma non sostituisce le mesh per oggetti che devono essere modificati dinamicamente o configurati dall’utente. I due approcci si usano spesso in combinazione.
Quando conviene adottare BLOCKS invece di Three.js nativo?
Conviene quando il team non ha specialisti di grafica 3D, i tempi di consegna sono stretti e il progetto beneficia delle astrazioni già pronte. Non conviene quando il ciclo di vita del progetto è lungo e la dipendenza da un layer commerciale introduce rischi di allineamento con le versioni future del core.
Fonti:
- Changelog Three.js BLOCKS — accesso maggio 2025
Vuoi capire come applicarlo alla tua azienda?
