Converter GLB para PLY

Esta conversão existe por causa de um descompasso entre distribuição e processamento. O GLB venceu como jeito de entregar um modelo: um arquivo só, material embutido, visível num navegador com um elemento só. O PLY venceu dentro do mundo de processamento de geometria décadas antes, e trimesh, Open3D, MeshLab e CloudCompare tratam ele como o formato que não precisa de explicação.

Então uma coleção chega como GLB e a primeira coisa que qualquer pessoa faz é converter. O que importa nesse momento não é fidelidade à origem — ninguém vai renderizar isso —, é saber exatamente o que o leitor vai enxergar: quantos vértices, se a superfície é uma peça só, e se o arquivo vai pesar cinco megabytes ou cinquenta.

O PLY tem um único bloco de vértices e um único bloco de faces. Não existe noção de objeto, grupo ou nome, então um GLB contendo um corpo, uma tampa e uma alça é fundido: as listas de vértices são concatenadas e os índices de face de cada malha são deslocados pelo número de vértices já escritos.

A geometria é idêntica e a estrutura desaparece. Uma análise de componentes conectados ainda encontra as três peças, mas os nomes não voltam, e duas partes que se tocavam agora são regiões adjacentes de uma superfície só, não dois objetos. Se a identidade das peças importa para o seu trabalho, o OBJ é o formato que mantém isso.

O cabeçalho sempre lê `format ascii 1.0`. Não há opção binária nem ajuste para mudar isso, então toda coordenada é escrita em dígitos decimais e toda face é uma linha começando com o número 3. O PLY é definido como texto ou binário, e este conversor só escreve o primeiro.

Na prática isso significa um arquivo várias vezes maior que o equivalente binário: uma coordenada de ponto flutuante ocupa quatro bytes empacotados e de dez a quinze caracteres escritos por extenso. Tudo lê o arquivo, e um `head -20` mostra o cabeçalho direto. Se você precisa da forma binária, o MeshLab e o trimesh escrevem essa variante, e um único salvamento converte.

Algumas origens deste site são soldadas na entrada — um STL guarda três vértices independentes por triângulo e produziria um arquivo quatro vezes maior sem essa etapa. Um GLB não: sua geometria já é um buffer de vértices indexado, então as posições e o índice atravessam como estão.

Isso significa que a contagem de vértices no PLY bate com as contagens da fonte, exatamente o que se quer quando a conversão é um passo dentro de uma medição. Também significa que duplicatas da origem continuam lá — uma costura de UV divide um vértice em duas cópias coincidentes em todo exportador glTF, e essas cópias chegam no PLY. Se um algoritmo posterior precisa de um índice estanque, solde com uma tolerância na biblioteca, não espere que o conversor tenha feito isso.

Nove linhas e nada mais: a palavra mágica, o formato, um comentário de gerador, o elemento de vértice com sua contagem e três propriedades de ponto flutuante, o elemento de face com sua contagem, e `end_header`. Ler as duas contagens no topo do arquivo é o jeito mais rápido de saber o número de triângulos e vértices, e não precisa de biblioteca nenhuma.

O que o cabeçalho não declara é qualquer outra coisa. Sem propriedade de cor, sem normal, sem coordenada de textura, sem comentário carregando unidade ou origem. Um leitor deste arquivo aprende a geometria e nada sobre de onde ela veio, o que é bom para um passo de processamento e ruim para arquivamento — então guarde o GLB.

O PLY é o formato que as pessoas escolhem justamente porque guarda cor por vértice, e é por isso que scanners escrevem nele. Um GLB frequentemente tem cor para dar: um atributo de vértice, ou mais comumente uma textura de cor base com coordenadas UV. Nada disso é lido, e o escritor emite apenas x, y e z.

Então o resultado é geometria sem aparência, e se a aparência é o que você ia analisar, esta é a rota errada, e a resposta é uma biblioteca que lê os dois atributos — o trimesh dá tanto o visual quanto a malha e exporta um PLY colorido direto. Para trabalho puramente geométrico, nada disso importa e o arquivo simples é menor.

O conversor percorre o grafo de cena da cena padrão, compõe a matriz de cada nó com a do pai, e aplica o resultado antes de escrever. Um GLB que posicionou uma malha em quatro lugares produz então quatro conjuntos de vértices em quatro posições, em vez de uma malha e quatro matrizes.

É o comportamento correto, porque o PLY não tem como expressar uma instância, e vale lembrar disso quando os números parecerem estranhos. Uma caixa delimitadora calculada sobre o PLY cobre a cena inteira montada, não a malha de origem, e um modelo cuja raiz de cena o autor deixou deslocada chega longe da origem. Ambos são propriedades do GLB, não da conversão.

Nem GLB nem PLY carrega uma unidade. O glTF é escrito por convenção como se uma unidade fosse um metro; o PLY não faz reivindicação nenhuma, e as ferramentas de escaneamento que o escrevem costumam trabalhar em milímetros. Nada na conversão reconcilia isso, e nada poderia.

Para um fluxo de medição isso é um risco de verdade, não uma nota de rodapé, porque um volume calculado sobre coordenadas sem unidade é um número sem unidade anexada. Estabeleça o fator uma vez, a partir de uma dimensão que você consiga verificar na origem, e registre isso ao lado do conjunto de dados.

Uma pasta converte aqui numa passagem só e volta como um ZIP, o que é razoável para dezenas de arquivos e ruim para milhares. O teto gratuito é 100 MB por arquivo e o trabalho acontece numa aba do navegador, então uma coleção grande é lenta e, mais importante, não repetível — nada dela fica registrado num script.

Para qualquer coisa que você vai rodar duas vezes, uma biblioteca como trimesh lê GLB nativamente e escreve PLY binário em duas linhas. Use esta página para o que ela faz bem: converter três arquivos à mão para ver como a geometria realmente parece antes de decidir como os outros três mil vão ser processados.

Dentro desta aba do navegador. A conversão é JavaScript puro, sem módulo WebAssembly para baixar, nada é enviado, não existe conta e a guia de rede durante uma conversão mostra nada saindo.

Vale conferir em vez de acreditar, e isso importa por dois motivos que se sobrepõem aqui: conjuntos de dados de pesquisa frequentemente vêm com termos de redistribuição, e um modelo escaneado de um objeto real pode ser uma exposição em si mesma. Nenhuma das duas questões existe quando o arquivo nunca sai do lugar.