Converter OBJ para GLTF

Quase tudo útil no pipeline 3D moderno para web recebe glTF como entrada. O gltf-transform poda, solda, reamostra e comprime; o validador da Khronos confere; three.js e Babylon.js consomem; todo serviço de otimização de recurso assume isso. Um OBJ fica de fora disso tudo, e o primeiro passo para trazer um para dentro é uma conversão que produz um documento que essas ferramentas aceitam.

O motivo de mirar em .gltf em vez de .glb nesta etapa é que a forma JSON é a que dá para ler e mudar. Um GLB é o artefato que se produz no fim do pipeline, depois que o material está certo e a passagem de compressão já rodou. Esta página é para o começo desse pipeline, onde conseguir abrir o arquivo num editor vale mais que conseguir servir ele numa requisição só.

Um bloco asset declarando versão 2.0 e Quinvert como gerador, um índice de cena 0, uma cena listando cada nó, um nó por malha, uma malha por grupo do OBJ, e por malha uma única primitiva com modo 4, um atributo POSITION e um acessor de índices. Depois os acessores, as visões de buffer e um buffer.

É formatado com dois espaços de indentação, o que deixa cerca de um terço maior que minificado e legível sem formatador. Para um documento que você está prestes a editar, esse é o padrão certo; passar por um minificador é um comando, e reverter um JSON de 40 mil linhas sem formatação não é.

O glTF aceita três jeitos de guardar dado de vértice: um arquivo .bin separado, uma URI de dado base64 no campo uri do buffer, ou o bloco binário de um GLB. Uma conversão produz um arquivo só, então a URI de dado é a única opção que mantém a saída autocontida, e é o que é escrito.

Duas consequências seguem disso. O arquivo fica cerca de um terço maior que os mesmos bytes guardados em binário, porque base64 custa quatro caracteres a cada três bytes — aceitável para um documento de trabalho e desperdício para entrega. E toda ferramenta que lê glTF lida com isso: gltf-transform, o validador e o three.js resolvem buffer embutido sem configuração especial.

O documento não tem lista de materiais, porque o arquivo MTL do OBJ não é lido. Acrescentar um é quatro linhas: uma lista materials contendo um objeto com um bloco pbrMetallicRoughness e um baseColorFactor de quatro números, depois uma propriedade material na primitiva dando o índice dele.

Isso dá um modelo colorido e iluminado corretamente em qualquer visualizador de glTF sem tocar na geometria. Textura é um trabalho maior, porque precisa de imagem, amostrador, textura e — o crítico — dado TEXCOORD_0 que esta conversão não produziu. Se o seu OBJ tinha UV e você precisa deles, o caminho honesto é o Blender, não uma edição manual.

Toda linha o ou g inicia um grupo novo, e cada grupo vira uma malha nomeada. Esse nome é a única informação não geométrica que atravessa a conversão, e num documento que você vai editar é o que faz a diferença entre achar a parte certa e contar nós.

Um grupo sem nome na origem também não ganha nome na saída. A malha é escrita sem propriedade de nome, e o nó que referencia ela carrega só o índice da malha, então qualquer coisa depois precisa inventar um rótulo. Se o glTF vai ser lido ou editado à mão depois, nomeie os grupos no OBJ primeiro — uma edição de texto ali é mais fácil que reconciliar malhas anônimas no JSON depois.

A saída é escrita respeitando as partes da especificação que os validadores de fato cobram. As visões de buffer são preenchidas para que todo deslocamento de byte de acessor seja múltiplo do tamanho do componente, o que é uma exigência, não uma cortesia, e uma causa comum de erro de validador em geradores feitos à mão. Todo acessor POSITION carrega min e max, o que é obrigatório e o que os visualizadores usam para enquadrar o modelo.

Um stride igual a zero é tratado como compactado ao invés de um stride igual ao tamanho do elemento, que é o que a especificação diz e o que vários leitores entendem errado na direção contrária. Se você rodar o Validador glTF da Khronos sobre o resultado, a saída interessante não é erro, é a nota de nível informativo dizendo que as malhas não têm normal — o que é verdade, e que a especificação resolve dizendo ao visualizador para calcular normais planas.

Face com quatro ou mais cantos é triangulada em leque a partir do primeiro canto. Isso é correto para quadrilátero convexo e n-ágono, que é o que esses arquivos contêm na prática, e pode produzir triângulo sobreposto numa face côncava — uma limitação que vale saber se o seu OBJ veio de uma ferramenta que gera polígonos complexos.

Índice de face negativo é resolvido durante a leitura, já que conta de trás para frente a partir do vértice mais recente e não dá para interpretar fora de ordem. Os vértices são então soldados por grupo com seis casas decimais, então um grupo que referenciava doze de um arquivo de quatro mil vértices carrega doze vértices no glTF, não quatro mil.

Inflação de base64 no buffer, mais o JSON formatado em volta. Para um modelo só de geometria o buffer domina, então espere cerca de um terço a mais de bytes que o mesmo modelo como GLB, antes de qualquer compressão.

Essa é a troca certa nesta etapa do pipeline e a errada no fim dele. O formato comum do trabalho é: converta para glTF aqui, edite ou processe, depois produza o GLB como artefato final — convertendo de volta ou deixando o gltf-transform escrever, que também é onde a compressão Draco ou meshopt entra.

Se nada vai acontecer com o arquivo entre a conversão e a entrega, vá direto para GLB. É menor, é uma requisição, e a editabilidade que você paga com os bytes extras não vale nada se ninguém abre o arquivo.

Escolha glTF quando existe um próximo passo: um material a acrescentar, um validador a satisfazer, uma passagem de transformação a rodar, ou um repositório onde um arquivo de texto mostra diferença e um binário não. As duas conversões rodam inteiramente no seu navegador, sem motor para baixar, então a escolha não custa nada além da extensão.