Qualquer um pode dizer que o seu software é sólido. Aqui estão as provas.
O Meshory é feito por uma pessoa só, é pago e tem código fechado. É muita coisa para pedir que você aceite na base da confiança, então prefiro não pedir. Esta página traz as provas: o que roda antes de uma versão ser lançada, o que eu medi, o que me recusei a afirmar e o que ainda falta.
Escrito por Petros, que faz o Meshory. Mais sobre a pessoa por trás dele.
Nada é lançado sem antes passar por tudo isto
Toda versão, incluindo as pequenas, passa pela mesma barreira. Sem exceções manuais, porque uma barreira que dá para pular não é uma barreira.
A checagem de tipos precisa passar
O TypeScript compila o app de desktop inteiro sem erros antes de qualquer outra coisa rodar. Um build que não passa na checagem de tipos nunca chega à etapa de testes.
6.987 testes unitários
578 arquivos de teste cobrindo o motor de escaneamento, a camada de banco de dados, a indexação de arquivos compactados, a detecção de duplicatas, o licenciamento e a interface. Outros 52 são pulados em vez de excluídos, e a contagem acima não os inclui.
298 testes de ponta a ponta
O Playwright abre o app empacotado de verdade com uma biblioteca real no disco e o usa como uma pessoa usaria: escaneia uma pasta, pesquisa nela, abre o visualizador 3D, aplica tags, encontra duplicatas, manda arquivos para a lixeira. 63 arquivos de especificação.
Assinado e notarizado no macOS
Todo build para macOS recebe assinatura de código e é enviado à Apple para notarização antes de chegar perto de um link de download. Se a notarização falha, o lançamento para.
O próprio instalador passa por um teste de fumaça
A CI instala o app gerado em uma máquina limpa e o inicia. Uma versão que compila mas não abre é pega aqui, e não por você.
Publicação em duas etapas
Os builds vão primeiro para um armazenamento privado. Nada chega à página de download nem ao atualizador automático de quem já usa o app até que uma etapa separada de promoção seja executada.
Faço os benchmarks com a minha própria biblioteca, não com uma pasta de demonstração
Os benchmarks da biblioteca inteira de agosto, abaixo, comparam a mesma biblioteca no NAS no mesmo computador, antes e depois: 141.696 arquivos indexados em 8.448 pastas, 3,3 TB no momento em que essas execuções foram registradas, em 2 de agosto de 2026. Os resultados brutos são salvos no repositório com data e hora, a versão do app e o hardware em que rodaram, para que uma mudança posterior que deixe algo mais lento sem alarde apareça.
Esse número conta arquivos, não modelos, e por isso é maior que os 118.270 modelos citados em outras partes deste site. 6.997 desses arquivos são ZIPs, e as 100.874 entradas dentro deles são indexadas como itens completos, em vez de ficarem como blobs opacos. O resto da diferença são as imagens, os PDFs e os readmes que ficam junto dos modelos. Os benchmarks contam tudo em que o scanner de fato precisa trabalhar.
Esses dois últimos números vêm de uma execução posterior na mesma biblioteca, em 8 de agosto de 2026, porque as execuções por trás da tabela são anteriores ao contador que os registra. O mesmo conjunto de dados: as duas informam os mesmos 141.696 itens nas mesmas 8.448 pastas. Essa execução também está publicada.
rápido
Na linha do primeiro escaneamento, o cronômetro para quando a biblioteca fica pronta para navegar e buscar. Miniaturas, imagens de capa e o cálculo de hash de duplicatas rodam depois em segundo plano e, nesta biblioteca, continuam por muito tempo depois que o escaneamento termina. Medido em um Apple M4 Pro, 12 núcleos, 48 GB, no mesmo compartilhamento de NAS somente leitura nas duas execuções. Os seus números vão variar conforme o seu hardware e a sua rede. Estes são os que eu posso mostrar. A coluna de ganho de velocidade é calculada a partir das medições brutas, e não dos valores arredondados ao lado, então pode ficar uma fração de ponto percentual diferente do que você obtém dividindo o que aparece na tela. O JSON bruto de cada linha está publicado aqui, com data e hora, versões do app e máquina.
Menos tempo esperando miniaturas
As melhorias mais recentes nas miniaturas reduziram o tempo de processamento em 35,8% em uma amostra de 768 itens da minha biblioteca no NAS com conexão cabeada. Todas as imagens geradas ficaram idênticas byte a byte antes e depois.
O banco de dados de teste manteve todos os 152.955 registros de itens, enquanto a fila de miniaturas cobriu 500 arquivos dentro de arquivos compactados e 268 arquivos soltos. As duas versões já incluíam as otimizações de miniaturas anteriores.
rápido
Mediana de duas execuções por versão, na ordem antes/depois/depois/antes, com os caches do NAS e do sistema operacional já aquecidos, em um Apple M4 Pro, 12 núcleos, 48 GB. O tempo inclui a inicialização dos workers, as leituras, a renderização, a gravação das imagens e as atualizações do banco de dados. Escaneamento, marcação com tags, modelos STEP e a interface ficaram de fora. A biblioteca completa ainda não foi cronometrada com essas mudanças. Leia o registro das medições.
O que eu não me permiti afirmar
O sentido de medir é que às vezes a medição diz não. Esta é uma conclusão literal de um dos meus próprios relatórios de benchmark, sobre um ganho de velocidade que eu queria poder anunciar:
“Directory read aggregate increased substantially even while archive wall time fell, so these runs do not support a directory read speedup claim.”
Nessa mesma rodada, o primeiro escaneamento ficou cerca de 11% mais rápido e o processamento de arquivos compactados ficou cerca de 18% mais rápido, e os dois ganhos são reais. Mas a latência das prévias na amostra piorou, e uma meta que eu tinha definido para mim mesmo não foi demonstrada pelos dados, então também não é demonstrada nesta página. Números que só se movem na direção favorável não são medições, são marketing.
O que ainda não está pronto
A lista que eu gostaria de ler se estivesse decidindo se confio no software de outra pessoa.
Os builds para Windows ainda não têm assinatura de código.
O Windows mostra um aviso do SmartScreen na primeira instalação, e alguns antivírus colocam o instalador direto em quarentena como falso positivo. Só a assinatura de código elimina os dois problemas. Até ela chegar, o SHA-256 de cada build e um relatório do VirusTotal ficam na página de downloads para você mesmo conferir o arquivo. O macOS já é assinado e notarizado hoje.
O código é fechado.
Você não pode ler o código, então o resto desta página mostra como tento fazer disso um acordo razoável, e não um ato de fé.
Arquivos individuais muito grandes ainda podem derrubá-lo.
Um único STL com mais de cerca de um gigabyte pode esgotar a memória durante o cálculo de hash de duplicatas. É um limite conhecido, com um patamar medido, não uma surpresa.
É uma pessoa só.
Se eu estiver dormindo, sua mensagem no Discord espera até de manhã. Não há plantão de 24 horas, e não vou fingir que há.
Você não pode ler o código, então aqui está o que eu devo a você em troca
Ele roda inteiramente no seu computador.
O Meshory nunca envia seus modelos. Sem conta, sem sincronização, sem servidor entre você e seus próprios arquivos. Tire o cabo de rede e ele funciona exatamente igual.
O que você pagou é seu.
Pagamento único, não uma assinatura. A versão que você comprou continua funcionando, e continua funcionando offline.
O registro de alterações é específico.
Cada versão diz o que realmente mudou e por quê, incluindo as correções que foram constrangedoras. Já são 23 desde 8 de julho de 2026
Quem recebe o relato de bug é quem o corrige
Relatos de bugs e pedidos de recursos vão para um Discord onde chegam diretamente a mim, e boa parte deles acaba sendo lançada. O filtro por tags existe porque alguém pediu no Discord. A detecção do fatiador Snapmaker existe porque um usuário me mandou arquivos de exemplo. Metade das notas de versão é ideia de outra pessoa.
Veja na sua própria biblioteca
Baixe, aponte para a sua pior pasta e julgue pelo que ele faz com a sua própria bagunça.