Convertire OBJ in GLTF

Quasi tutto ciò che è utile nella moderna pipeline 3D per il web prende glTF come ingresso. gltf-transform lo pota, salda, ricampiona e comprime; il validatore Khronos lo controlla; three.js e Babylon.js lo consumano. Un OBJ è fuori da tutto ciò, e il primo passo per portarlo dentro è una conversione che produca un documento che quegli strumenti accettano.

La ragione per puntare a .gltf piuttosto che a .glb in questa fase è che la forma JSON è quella che potete leggere e cambiare. Un GLB è l’artefatto che producete alla fine della pipeline, dopo che il materiale è giusto e il passaggio di compressione è girato. Questa pagina è per l’inizio di quella pipeline.

Un blocco asset che dichiara la versione 2.0 e Quinvert come generatore, un indice scena 0, una scena che elenca ogni nodo, un nodo per mesh, una mesh per gruppo OBJ, e per mesh una singola primitiva con modalità 4, un attributo POSITION e un accessore indices. Poi gli accessori, le viste buffer e un buffer.

È formattato con indentazione a due spazi, il che lo rende circa un terzo più grande del minificato e leggibile senza un formattatore. Per un documento che state per modificare è il predefinito giusto; farlo passare per un minificatore è un comando, il contrario è un lavoro molto più lungo.

glTF permette tre modi di memorizzare i dati vertice: un file .bin separato, un URI dati base64 nel campo uri del buffer, o il chunk binario di un GLB. Una conversione produce un file, quindi l’URI dati è l’unica opzione che mantiene l’output autonomo, ed è quella scritta.

Due conseguenze. Il file è circa un terzo più grande degli stessi byte memorizzati in binario, perché base64 costa quattro caratteri per tre byte. E ogni strumento che legge glTF lo gestisce: gltf-transform, il validatore e three.js risolvono tutti i buffer incorporati senza configurazione speciale.

Il documento non ha un array materials, perché il file MTL dell’OBJ non viene letto. Aggiungerne uno sono quattro righe: un array materials contenente un oggetto con un blocco pbrMetallicRoughness e un baseColorFactor di quattro numeri, poi una proprietà material sulla primitiva che ne dà l’indice.

Questo dà un modello colorato e correttamente illuminato in qualunque visualizzatore glTF senza toccare la geometria. Le texture sono un lavoro più grande, perché servono immagini, sampler, texture e dati TEXCOORD_0 che questa conversione non ha prodotto.

Ogni riga o o g inizia un nuovo gruppo, e ogni gruppo diventa una mesh nominata. Quel nome è l’unica informazione non geometrica che attraversa la conversione, e in un documento che state per modificare è ciò che fa la differenza tra trovare la parte che intendevate e contare nodi.

Un gruppo senza nome nella sorgente non riceve un nome nemmeno nell’output. Se il glTF verrà letto o modificato a mano dopo, nominate i gruppi nell’OBJ prima — una modifica testuale lì è più facile che riconciliare mesh anonime nel JSON dopo.

L’output è scritto contro le parti della specifica che i validatori applicano davvero. Le viste buffer sono riempite così che ogni offset byte di accessore sia un multiplo della dimensione del suo componente, un requisito piuttosto che una cortesia. Ogni accessore POSITION porta min e max, richiesto e usato dai visualizzatori per inquadrare il modello.

Uno stride di zero viene trattato come strettamente compattato piuttosto che come stride uguale alla dimensione dell’elemento, ciò che dice la specifica. Se fate girare il validatore Khronos sul risultato, l’output interessante non sono errori ma la nota informativa che le mesh non hanno normali — vero, e gestito dalla specifica dicendo ai visualizzatori di calcolarne di piatte.

Le facce con quattro o più angoli sono triangolate a ventaglio dal primo angolo. Corretto per quad e n-gon convessi, che è ciò che questi file contengono in pratica, e può produrre triangoli sovrapposti su una faccia concava.

Gli indici di faccia negativi vengono risolti durante la lettura, poiché contano all’indietro dal vertice più recente. I vertici vengono poi saldati per gruppo a sei cifre decimali, così un gruppo che referenziava dodici vertici di un file da quattromila porta dodici vertici nel glTF.

Inflazione base64 sul buffer, più JSON formattato attorno. Per un modello di sola geometria il buffer domina, quindi aspettatevi circa un terzo di byte in più rispetto allo stesso modello come GLB, prima di qualunque compressione.

È lo scambio corretto in questo punto di una pipeline e quello sbagliato alla fine. La forma usuale del lavoro: convertire in glTF qui, modificarlo o elaborarlo, poi produrre il GLB come artefatto finale — o riconvertendo o facendolo scrivere da gltf-transform, dove appartiene anche la compressione Draco o meshopt.

Se niente accadrà al file tra la conversione e la consegna, andate direttamente al GLB. È più piccolo, è una richiesta sola, e la modificabilità che state pagando con i byte extra non vale nulla se nessuno lo apre.

Scegliete glTF quando c’è un passo successivo: un materiale da aggiungere, un validatore da soddisfare, un passaggio di trasformazione da eseguire, o un repository dove un file testo fa diff e uno binario no. Entrambe le conversioni girano interamente nel vostro browser.