Convertire PLY in OBJ

Il PLY è dove vivono le scansioni e l’OBJ è dove avviene la modellazione. Ogni pacchetto di scultura e animazione legge l’OBJ senza pensarci; il supporto al PLY va da buono, in Blender e MeshLab, ad assente, in un buon numero degli strumenti che una pipeline di studio contiene davvero. Quando una scansione deve essere ritopologizzata, decimata a mano, scolpita o usata come mesh base, il primo passo è di solito un cambio di formato.

La conversione è piccola perché i due formati sono vicini nell’ambizione. Entrambi descrivono una superficie come lista di vertici e lista di poligoni sopra di essi, entrambi sono testo, ed entrambi abbastanza vecchi che tutto li legge. Ciò che l’OBJ aggiunge è raggruppamento e un riferimento materiale; ciò che il PLY aggiunge sono proprietà arbitrarie per vertice.

Una scansione fotogrammetrica o a luce strutturata memorizza il suo aspetto come rosso, verde e blu su ogni vertice. Non c’è texture, nessun layout UV e nessun file immagine — il colore è una proprietà della geometria, che è l’intera ragione per cui il PLY è diventato il formato di scansione.

L’OBJ scritto da questo convertitore ha righe v e f e nient’altro: nessuna coordinata vt, nessun riferimento mtllib, nessun .mtl allegato. Anche un file materiale scritto a mano non potrebbe contenere colore per vertice, perché i materiali OBJ si applicano per gruppo di facce. Il flusso di lavoro pratico è tenere entrambi i file — fate il lavoro geometrico dall’OBJ, e prendete il colore dal PLY dopo.

Un file PLY descrive un elemento vertice e un elemento faccia. Non c’è nozione di oggetto, gruppo o parte, e nessun nome da nessuna parte nell’intestazione per la superficie stessa. Quindi il convertitore produce esattamente un gruppo o, e poiché non c’è nome da portare, ne scrive uno generato: mesh_1.

In Blender o Maya è quello che appare nell’outliner. Su una singola scansione è innocuo; su un progetto dove sei scansioni vengono combinate è un vero fastidio, perché ogni importazione produce un oggetto con lo stesso nome. Rinominate all’importazione, oppure rinominate la singola riga o dell’OBJ in un editor di testo prima di importare.

Questa è una differenza genuina fra questa coppia e la maggior parte delle altre qui. Quando un STL o un OBJ vengono letti, i vertici coincidenti vengono saldati a sei cifre decimali, perché quei formati arrivano di routine con duplicati. Quando un PLY viene letto, il suo array di vertici e i suoi indici di faccia vengono presi esattamente come scritti.

È il comportamento giusto per dati scansionati, che sono già stati mesh-ati da software che ha preso decisioni deliberate sulla connettività. Significa anche che la conversione non può ripulire nulla: se la scansione porta vertici duplicati, vertici non referenziati o giunture divise, arrivano nell’OBJ invariati.

Un PLY contenente vertici e nessuna faccia viene rifiutato con un messaggio che spiega perché. Quel file è una nuvola di punti, ciò che uno scanner produce prima che qualcosa lo trasformi in mesh, e trasformare punti in una superficie è ricostruzione piuttosto che conversione — un’operazione con parametri, un’anteprima e un risultato che qualcuno deve approvare.

Fatelo dove appartiene. MeshLab e CloudCompare offrono entrambi ricostruzione di superficie Poisson e ball-pivoting; Open3D espone entrambi da Python; il software di ogni scanner ha un passaggio di meshing. Convertite l’uscita mesh-ata dopo.

Le liste di facce PLY possono contenere qualsiasi numero di indici, e gli strumenti di meshing a volte emettono quadrilateri. Ogni faccia con più di tre angoli viene triangolata a ventaglio dal primo indice prima di essere scritta, corretto per poligoni convessi e capace di comportarsi male su quelli concavi.

Le mesh di scansione sono in stragrande maggioranza già triangoli, quindi questo raramente si applica. Dove si applica, notate che l’OBJ che ne esce è solo triangoli — lo scrittore emette tre indici per riga f e non ricostruisce mai i quadrilateri.

Un PLY binario memorizza una coordinata float32 in quattro byte. Lo stesso numero scritto in un OBJ richiede otto-diciotto caratteri più separatori, quindi un OBJ testuale di una scansione densa è diverse volte la dimensione del file da cui proviene, e una mesh fotogrammetrica grezza di diversi milioni di triangoli produce un file di testo che farà faticare un editor.

Decimare prima è quasi sempre la mossa giusta, ed è una decisione migliore presa in MeshLab contro il PLY che nella vostra applicazione di modellazione contro l’OBJ, perché il collasso quadrico di MeshLab può essere istruito a preservare bordi e topologia.

Aspettatevi una superficie sfaccettata. Non vengono scritte righe vn, quindi le normali piatte delle facce vengono calcolate all’importazione; applicate ombreggiatura liscia o un angolo di auto-smooth e la scansione torna a sembrare sé stessa. Aspettatevi nessun materiale, e assegnatene uno prima di ogni altra cosa così la mesh è visibile contro il viewport.

Poi il lavoro di scansione usuale: rimuovere le isole estranee che lo scanner ha catturato dallo sfondo, riempire i buchi dove non poteva vedere, e ritopologizzare se la mesh deve essere animata o suddivisa. Niente di tutto ciò è lavoro di conversione.

L’OBJ è un file derivato. Ha la forma e niente del colore, niente dei valori di confidenza o qualità per vertice che uno scanner scrive, e niente delle normali se il PLY le portava. Ognuno di questi è irrecuperabile dall’OBJ.

Il modello che funziona è trattare il PLY come master e l’OBJ come copia di lavoro: modellate contro l’OBJ, e tornate al PLY ogni volta che serve l’aspetto o i metadati dello scanner. Entrambi i file restano sulla vostra macchina comunque — questa conversione gira nel browser senza alcun caricamento.