Converter STL para PLY

Toda outra dupla deste conjunto abre mão de algo. glTF perde os materiais, OBJ perde o MTL, 3MF perde a cor. STL para PLY perde as normais de face, e essas são calculadas a partir da ordem de enrolamento por todo leitor que precisa delas, e costumam estar erradas em arquivos produzidos por exportadores descuidados — motivo de várias fatiadoras ignorarem o valor guardado por completo.

Tudo mais sobrevive porque não havia mais nada. Um STL é uma lista de triângulos sem cor, sem unidade, sem nome, sem peça e sem atributo. Um PLY escrito com x, y e z e uma lista de faces guarda exatamente isso. Os dois formatos concordam sobre o que é um modelo, o que é raro nesta categoria.

CloudCompare, MeshLab, Open3D e trimesh recebem PLY como entrada de primeira classe, porque a Stanford desenhou o formato em 1994 exatamente para esse tipo de trabalho: um cabeçalho autodescritivo listando qualquer propriedade por vértice ou por face que uma ferramenta de pesquisa precise. Escaneamento e fotogrametria se padronizaram nele pelo mesmo motivo.

Também leem STL, e é aí que o problema começa em vez de terminar. Um STL carrega, exibe e parece correto enquanto é topologicamente inútil — veja a próxima seção. Converter não é sobre abrir o arquivo; é sobre conseguir uma malha cuja conectividade os algoritmos possam confiar.

O STL guarda três vértices independentes para cada triângulo. Um cubo são trinta e seis registros de vértice para oito posições. Carregue isso numa ferramenta de malha e pergunte se a superfície está fechada, e ela vai dizer que toda borda é uma borda de fronteira, porque nenhum triângulo compartilha um vértice — mesmo que a forma não tenha buraco nenhum.

A conversão arredonda coordenadas em seis casas decimais, usa isso como chave, e funde todo canto na mesma posição num único vértice compartilhado referenciado por todos os triângulos dele. Seis casas está bem abaixo de qualquer tolerância que uma peça física teria e bem acima do último bit de discordância que dois triângulos vizinhos têm num float. Depois disso, checagens de fechamento, estimativa de normal, curvatura, decimação, suavização e preenchimento de buraco funcionam sobre adjacência real.

O cabeçalho é o conservador: ply, format ascii 1.0, um comentário nomeando quem escreveu, uma declaração de elemento vertex com três linhas de propriedade float para x, y e z, uma declaração de elemento face com uma linha property list uchar int vertex_indices, e end_header. Depois uma linha por vértice e uma por triângulo.

Nada mais é declarado — sem normal, sem cor, sem confiança, sem qualidade, sem propriedade personalizada. É proposital: um cabeçalho que promete uma propriedade que o arquivo não consegue preencher é pior que um curto, e todo leitor que lida com PLY de fato lida com esse dialeto.

Cada registro de triângulo de cinquenta bytes num STL binário começa com doze bytes de normal de face. Esses doze bytes são pulados. A informação que carregam é totalmente determinada pela ordem dos três vértices, então recalcular é exato, não aproximado.

Não é um atalho tomado por conveniência. Normais de STL guardadas discordam da ordem de enrolamento com frequência suficiente para que várias fatiadoras e ferramentas de malha as descartem por política, precisamente porque muitos gravadores erram o sinal ou a normalização. Recalcular a partir da ordem de enrolamento dá uma resposta consistente só.

Toda coordenada é escrita como texto decimal, um vértice por linha, e todo triângulo como um 3 inicial seguido de três índices. Um vértice que eram doze bytes de binário vira vinte a sessenta caracteres. Contra isso, a soldagem já removeu cerca de cinco sextos dos registros de vértice que um STL carregava.

Os dois efeitos parcialmente se cancelam e o resultado depende do modelo. O que é previsível é o lado do STL: exatamente 84 + 50n bytes para n triângulos, então uma malha de dois milhões de triângulos derivada de escaneamento são 100 MB antes de converter e vale a pena decimar primeiro. Se o PLY resultante ficar pesado, salvar de volta do MeshLab como binary_little_endian é uma correção de um passo só.

O motivo mais comum para essa conversão é análise de desvio: uma peça foi impressa ou usinada a partir de um STL, depois escaneada, e alguém precisa da diferença. A distância cloud-to-mesh do CloudCompare quer a referência como uma malha com faces, que é o que isto produz, e o escaneamento como pontos, que é o que o scanner produziu.

Duas questões práticas. Os dois conjuntos de dados precisam ser alinhados primeiro — um pareamento grosseiro de pontos seguido de ICP é a rota padrão — e precisam compartilhar uma escala, que nenhum dos dois formatos declara. Se o escaneamento está em milímetros e o STL foi exportado em polegadas, o alinhamento vai convergir em algo plausível e errado.

O PLY é o formato em que escaneamentos 3D chegam porque carrega cor por vértice, e é isso que faz uma malha de fotogrametria parecer o objeto de onde veio. Nada disso aparece aqui, porque um STL não tinha cor para dar.

A exceção não oficial vale nomear: um punhado de ferramentas codifica uma cor de quinze bits nos dois bytes de atributo no fim de cada registro de triângulo STL, em duas convenções mutuamente incompatíveis. Esses bytes não são lidos. Não há como saber qual convenção um arquivo usou, e chutar colocaria cores erradas numa malha que alguém está prestes a medir.

Se o destino é uma fatiadora ou uma gráfica de impressão 3D, não converta — eles querem STL ou 3MF, e o suporte a PLY nesse mundo é irregular. Se o destino é um visualizador de navegador, glTF é o alvo certo e PLY é o errado.

Converta quando o próximo passo é um algoritmo: um cálculo de distância, uma decimação, um remesh, um preenchimento de buraco, um volume ou área de superfície, um alinhamento contra dado escaneado. Todo o valor do passo é a soldagem e o formato que a ferramenta espera, e roda inteiramente no seu navegador sem envio.