O que é um arquivo PLY?

PLY é um formato binário, que só significa alguma coisa para um programa que o conhece. Ele guarda formas e coordenadas em vez de pixels, então continua nítido em qualquer tamanho — uma logomarca levada ao tamanho de um outdoor não perde nada. Ele é usado para a digitalização e mover dados entre programas.

A extensão é .ply e o nome por extenso é Polygon File Format. Os dois importam menos do que aquilo que o arquivo consegue carregar, e é disso que trata o resto desta página.

A Stanford University publicou o formato em 1994.

A um formato que se manteve legível por tanto tempo dá para confiar algo que você quer de volta daqui a dez anos.

Ela está publicada por inteiro, então dá para implementá-la a partir do documento em vez de por observação — é por isso que o formato aparece em tantos programas e por isso que arquivos escritos há vinte anos ainda abrem. Especificação publicada não é o mesmo que livre de royalties: quando o formato embrulha um codec, o licenciamento das patentes é uma questão à parte, que a norma não resolve.

PLY guarda o conteúdo exatamente. Salvar de novo não muda nada, então dá para abrir, editar e salvar quantas vezes você quiser sem acumular estrago — e é isso que faz dele um formato de trabalho e não de entrega.

MeshLab, Blender e CloudCompare leem esse formato, e a maioria dos programas do mesmo tipo também.

Quando um arquivo não abre, o formato raramente é o problema — mais comum é o programa ser mais antigo que ele. Converter para algo mais antigo é o caminho confiável, e é para isso que serve o resto deste site.

Nenhum navegador lê o formato.

Esse é de longe o motivo mais comum para convertê-lo: não que o formato seja ruim, mas que o lugar onde você quer mostrar o arquivo não consegue lê-lo.

PLY foi feito para ser aberto e alterado. Mantenha o arquivo nesse formato enquanto o trabalho estiver em andamento e exporte a partir dele sempre que precisar de uma cópia pronta.

O PLY foi escrito em Stanford em meados dos anos 1990 para dado de scanner de alcance, e é isso que ele ainda majoritariamente carrega. Software de fotogrametria, scanners portáteis e de luz estruturada, ferramentas de lidar e os próprios modelos de Stanford falam esse formato, porque foi desenhado exatamente para a coisa incômoda que scanners produzem: milhões de pontos medidos, cada um carregando propriedades que o scanner registrou.

O desenho que fez ele durar é que as propriedades são declaradas em vez de fixas. O cabeçalho lista o que cada vértice carrega — posição, cor, normal, confiança, intensidade, o que quer que um instrumento específico meça — e leitores pegam o que entendem. Um formato de 1994, portanto, consegue carregar dado de um instrumento construído no ano passado.

O OBJ pinta uma superfície com uma imagem de textura mapeada sobre ela. O PLY normalmente faz algo mais simples: todo vértice carrega sua própria cor, medida naquele ponto.

Para um scan, isso é exatamente certo, porque o scanner mediu cor por amostra, e não existe uma superfície desdobrada para mapear uma imagem sobre ela de qualquer forma. Também significa que a resolução de cor é a resolução da geometria — uma malha grosseira tem cor grosseira, e detalhe só pode ser adicionado adicionando pontos. Essa é a troca contra texturas, onde um modelo de baixo polígono consegue carregar uma imagem muito detalhada.

Isso causa confusão real. Um PLY pode ser uma lista de pontos sem conexão nenhuma — uma nuvem — ou uma malha de verdade com faces conectando eles. Os dois são válidos, os dois têm a mesma extensão, e um programa esperando um vai fazer algo inútil com o outro.

Uma nuvem aberta num programa que quer uma malha aparece como uma poeira fraca de pontos, ou como nada de todo. Não está corrompida; simplesmente não há faces para desenhar. Transformar uma nuvem numa superfície é reconstrução — Poisson ou ball-pivoting no MeshLab ou CloudCompare — e é uma etapa de processamento com parâmetros para escolher, não uma conversão de formato.

Como no STL, o cabeçalho declara qual codificação vem a seguir. ASCII é legível e aproximadamente quatro vezes maior; binário é o que qualquer scanner de verdade grava.

Mesmo em binário, esses arquivos são grandes, porque as contagens são grandes. Um scan de fotogrametria de celular de um objeto rotineiramente produz de dois a cinco milhões de pontos, e uma varredura lidar de uma sala produz dezenas de milhões. A cerca de quinze bytes por ponto com cor, um levantamento de cem milhões de pontos é um gigabyte e meio antes de qualquer reconstrução acontecer. Isso é normal para o formato, não um sinal de uma exportação ruim.

A saída crua nunca está pronta. Há fundo — a mesa, o chão, o cômodo — que precisa ser recortado. Há pontos fora da curva, pontos soltos flutuando onde o scanner interpretou mal um reflexo ou uma borda. Há buracos onde o instrumento não conseguiu ver, embaixo do objeto e atrás de todo saliência.

Depois decimação, porque uma malha de cinco milhões de pontos é inutilizável em qualquer coisa adiante, e preenchimento de buracos, e só então uma malha que vale texturizar ou imprimir. MeshLab e CloudCompare são as ferramentas gratuitas para tudo isso. O scanner produz medições; transformar medições num modelo é um trabalho separado e o maior dos dois.

Converter PLY para STL é o último passo comum, e ele descarta a cor — o STL não tem nenhuma — mantendo a forma. Isso geralmente é aceitável, já que uma impressora de material único não conseguiria usar a cor de qualquer forma.

A falha a prever é a estanqueidade. Scans são cheios de buracos por natureza: nada foi medido embaixo do objeto, e detalhe está faltando onde quer que o instrumento não tinha linha de visão. Um fatiador precisa de um sólido inequívoco, então os buracos precisam ser preenchidos e a malha conferida antes de o STL ser gravado. Pular isso produz um arquivo que o fatiador recusa ou, pior, um que ele aceita e interpreta do próprio jeito.

Se o modelo vai para um motor de jogo ou um visualizador web, converta para glTF: carrega texturas, materiais e uma cena, e é construído para entrega, não captura. Se vai para um programa de modelagem para ser editado, o OBJ é mais universalmente aceito. Se vai para uma impressora, STL.

O PLY conquista seu lugar no extremo de captura do pipeline, onde propriedades por vértice e um cabeçalho extensível são exatamente o que se precisa. Guarde ele como o arquivamento do que foi realmente medido, e gere os formatos de entrega a partir dele — o inverso, reconstruir medições a partir de uma malha decimada, não é possível.