Three.js: GLTFExporter GLB compatível com visualizador do Facebook

/ ping @zellski

Ei! Sim, aquele cheque RGBA deve acabar em duas semanas. Não contorne isso. :)

Estou tentando converter WaltHead.obj em glb. Estou carregando em https://threejs.org/editor/ e exportando para o GLB de lá (que já deve ter os patches mais recentes).

Aqui está WaltHead.glb e isto é o que estou recebendo no validador do Facebook:

Your GLB File has the following errors: The 3D model could not be posted: The JSON portion of this model file is invalid.

🤔

É um JSON sintaticamente válido, mas os nulos neste snippet de WaltHead.gltf não estão em conformidade com o esquema de tipo:

    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 48480,
      "max": [
        null,
        null
      ],
      "min": [
        null,
        null
      ],
      "type": "VEC2"
    }

A ferramenta validadora Khronos glTF também lista cerca de 10.000 ocorrências de algum outro erro no arquivo, todos na ordem de:

        /accessors/2: Accessor element at index 28922 is NaN or Infinity.

Portanto, parece que um acessador está sendo gerado durante a exportação do glTF, para ser preenchido com índices, mas na verdade nunca recebe nenhum?

UVs são NaN: 🙃

@mrdoob @donmccurdy corrigido! https://github.com/mrdoob/three.js/pull/13400
Embora ainda não possamos mostrar esse exemplo por causa de

[msg] => Mesh primitives without indices are (temporary) unsupported.

(adicionado à lista de tarefas)

@zellski , você tem alguma estimativa sobre esse recurso? ;)

@fernandojsg Este é um pouco mais complicado. Vai ser consertado, mas pode demorar um pouco mais. tl; dr Talvez um mês?

Explicação mais longa: o problema é semelhante à cor do vértice acima, no sentido de que são as nossas implementações de cliente que estão ficando para trás, e meu validador no backend está apenas protegendo-os de modelos com os quais eles ainda não conseguem lidar.

Obviamente, temos que suportar geometria não indexada, quanto mais cedo melhor. Idealmente nos clientes, mas também nessa altura devo ter o meu código de back-end com a potência máxima da Estrela da Morte, onde transformamos todos os arquivos .gltf carregados preguiçosamente / sob demanda, dependendo da necessidade de cada cliente. Nesse ponto, podemos fazer coisas interessantes como criar geometria indexada no servidor para a conveniência de nossos clientes.

Presumo que o erro acima ocorre quando three.js está tentando exportar primitivas que são naturalmente não indexadas em sua representação de tempo de execução.

Presumo que o erro acima ocorre quando three.js está tentando exportar primitivas que são naturalmente não indexadas em sua representação de tempo de execução.

@zellski é isso! Alguns primitivos ou objetos carregados em três não são indexados. O primeiro caso de uso que pensei para o carregador glb do Facebook foi incluir desenhos de nosso aplicativo A-Painter (mais informações: https://blog.mozvr.com/tag/a-painter/) e usamos geometria não indexada lá também, então seria ótimo ter suporte para isso;)
Eu só queria saber se isso estava no roteiro, então saber que é isso e poderíamos tê-lo em cerca de um mês, é mais do que razoável;) obrigado por compartilhar essa informação!

Podemos ter que adicionar um atributo de índice burro enquanto isso (como em 0, 1, 2, 3, 4, 5, 6, 7, 8, ...) 😕

@mrdoob , você quer dizer ter algum método para converter não indexado em indexado como quiser ou adicionar o hack diretamente no exportador?

Sim, adicione um hack temporário no exportador ...

Eu não sei, eu só quero que as coisas funcionem e não tenha que dizer às pessoas, "oh? Seu modelo não funciona no Facebook? É porque ... você sabe o que são geometrias indexadas? Sim, você não deveria, mas ... "

É, eu entendi! Ok, vou dar uma olhada para ver se posso adicionar algum hack não tão sujo :)

@zellski para contexto ...

Eu adicionei um Export GLB em http://threejs.org/editor/ que usa este GLTFExporter .

Vídeo: como exportar modelo como glTF no Editor Three.js: D

https://twitter.com/superhoge/status/966689549803053056

Acredite em mim, eu entendo a relutância em adicionar hacks. É uma grande luta manter uma perspectiva paciente agora que lançamos ...

Você poderia fazer o hack do GLTFExporter em um fork que é usado em http://threejs.org/editor/, mas não em outro lugar? Espero que já tenhamos corrigido essa falha quando o r91 for lançado, então parece um pouco inútil para vocês escreverem um código cuidadoso e responsável para ele.

Você poderia fazer o hack do GLTFExporter em um fork que é usado em http://threejs.org/editor/, mas não em outro lugar?

Sim, não se preocupe!

Espero que já tenhamos corrigido essa falha quando o r91 for lançado

Oh, estou planejando lançar em 1º de março. Ciclo de lançamento alterado para o início do mês para ter lançamentos mensais adequados.

Parece que ainda temos mais recursos a adicionar antes de promover isso de qualquer maneira. Não acho que estejamos exportando mapas de rugosidade, metálicos, normais ou alfa.

Teste mais recente, usando 2 mapas difusos, nuvens sendo um deles um PNG transparente:
https://www.facebook.com/fakemrdoob/posts/950266411809572

Não tenho certeza de onde o aparente alphaTest: 0.5 está vindo ...

Apenas usando a solução alternativa para índices :)
https://www.facebook.com/fernandojsg/posts/10156405595122044

Lá vamos nós https://github.com/mrdoob/three.js/pull/13410

@mrdoob , você se importa em adicionar os recursos ausentes que encontrar e que não estão relacionados aos requisitos do Facebook sobre este problema: https://github.com/mrdoob/three.js/issues/11951
Embora eu precise atualizar o status lá 😇

Soa bem. Vou testar exportando e arrastando de volta para o editor.
Devemos fechar este?

@mrdoob Eu deixaria aberto até que o problema de RGB vs RGBA para cores de vértice seja resolvido no lado do Facebook, então se as pessoas vierem aqui em busca de ajuda podem ler sobre isso em vez de abrir outro problema.

A propósito, acabei de encontrar este link com algumas informações úteis: https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Aparentemente, as texturas precisam ter potência de 2 ...
https://twitter.com/drupalati/status/967486854630055936

O Three.js não converte automaticamente a imagem de não potência de dois em potência de dois?

Sim, desculpe. Os clientes móveis ainda não são redimensionados, então temos que rejeitá-los durante a validação por um tempo. Provavelmente faremos o redimensionamento no servidor, pois temos total controle sobre o pipeline de entrega. Espero que essa restrição também seja suspensa em 2 a 3 semanas.

@takahirox Sim, three.js será redimensionado instantaneamente. Mas os clientes nativos do Facebook não usam three.js.

A lista completa de recursos do glTF para os quais o Facebook ainda não oferece suporte, em ordem aproximada de ETA:

• Sem cores de vértice RGB; deve ser RGBA.
• Sem texturas NPOT para certas combinações de fixação / filtro
• Apenas geometria triangular indexada.
• Sem animações (ignorado silenciosamente)
• Sem acessores esparsos (falha na validação)
• Sem alvos de metamorfose (se alguma malha tiver uma propriedade 'alvo', o modelo falha na validação)
• Sem câmeras (silenciosamente ignorado) (por enquanto)

Também:

• Tamanho máximo do arquivo 3 MB
• Nenhuma dimensão de textura maior que 4096
• Nenhuma extensão diferente de KHR_material_unlit (por enquanto)

Eu acho que é isso.

Fiz PR # 13424 para textura force POT porque acho que valeria não só para FB.

Ao usar o GLTFExporter para exportar uma malha de vários materiais (uma matriz de material), recebo este erro:

GLTFExporter.js:623 Uncaught TypeError: Cannot read property 'toArray' of undefined
    at processMaterial (GLTFExporter.js:623)

@ Ben-Mack Esse é um problema conhecido e estou trabalhando nisso agora. (Mas demoraria um pouco).

@zellski algum plano para suporte draco no fb? Posso baixar minhas malhas de 40 MB para 5 MB, mas o último par de MB não cai.

@ webprofusion-chrisc (cara que é longo @ para um teclado de telefone) sim, Draco está definitivamente no roteiro. É necessário um bom trabalho de engenharia, portanto, faltam pelo menos um mês, mas - de muitas maneiras, construímos nossas suposições em torno disso - como você diz, para muitos modelos o limite de 3 MB é simplesmente insustentável. (Ainda não tenho certeza do que podemos fazer para ajudar com as texturas.)

(Ainda não tenho certeza do que podemos fazer para ajudar com as texturas.)

@donmccurdy está obtendo algum progresso nessa frente: https://github.com/mrdoob/three.js/pull/12877 😀

Podemos esperar texturas 25-30% menores do GLTFExporter com o # 12877.

A longo prazo, a Binomial está trabalhando com Khronos para criar uma extensão para texturas compactadas de plataforma cruzada em glTF: https://www.khronos.org/blog/call-for-participation-gltf-creating-a-compressed-texture-extension .

Ok ... Depois de # 12877 e # 13451, uma exportação GLB que costumava ter 3,3 MB agora é 480 KB 😊

Legal! # 13451 significa que o tamanho do arquivo de imagem será maior se convertermos jpg para png?

Legal! # 13451 significa que o tamanho do arquivo de imagem será maior se convertermos jpg para png?

sim. # 13451 é um pouco problemático devido ao fato de que o editor não permite alterar o formato de uma textura no momento. Mas fazemos a mesma coisa na biblioteca de qualquer maneira ...

https://github.com/mrdoob/three.js/blob/dev/src/loaders/TextureLoader.js#L34

Mas sim, GLTFExpoter atualmente salva como jpg quando texture.format === THREE.RGBFormat .

https://github.com/mrdoob/three.js/blob/dev/examples/js/exporters/GLTFExporter.js#L493

O que não é ideal, porque estamos recomprimindo um jpg ... Mas melhor do que as exportações de grandes dimensões, eu acho?

Tive que adicionar código ao FBX2glTF que realmente inspeciona os valores alfa de até mesmo imagens RGBA, porque as pessoas (ou, mais precisamente, as ferramentas de pessoas) as criam por padrão e, muitas vezes, é totalmente desnecessário mantê-las como PNGs. Mesmo depois de tentar os mais brutais crunchers PNG habilitados para GPU e não linearmente otimizado que existe, parece que o JPEG realmente manda no poleiro ... a diferença de tamanho é incrível!

Estou um pouco preocupado com o sangramento entre canais para coisas como a textura ORM (oclusão / aspereza / metal), onde cada componente carrega dados que são totalmente independentes dos dados dos outros componentes ... mas na prática parece funcionar bem.

O exportador também pode tornar o nível de qualidade opcional ao usar canvas.toDataURL (mimeType) - minhas texturas são geradas em tempo de execução a partir de imagens compostas, o que também ajudaria.

@zellski para pipeline / viewer do fb Estou supondo que você poderia fazer como sketchfab e servir uma versão de textura de baixa resolução, em seguida, transmitir as texturas de alta / resolução total e substituí-las no modelo à medida que carregam. Não é um trabalho pequeno, mas é possível.

@ webprofusion-chrisc Sim, podemos acabar fazendo isso. No momento, usamos .glb como a entidade transmitida, o que é difícil de combinar com streaming do tipo LOD seletivo (já que há apenas um único arquivo sequencial sem acesso aleatório). Mas espero que reavaliaremos as suposições básicas com bastante frequência, dependendo de como as coisas acontecem. :)

GLTFExporter pode exportar BufferGeometry e importar para o Facebook sem problemas. Mas qualquer Geometry ou BufferGeometry convertido usando o método fromGeometry não está funcionando no Facebook. Eu sempre recebo isso no validador FB:

[msg] => Os atributos Vertex COLOR_0 do tipo RGB não são (temporariamente) suportados. Eles devem ser RGBA.

Etapa para reproduzir:

• Usando misc_exporter_gltf exemplo mais recente em dev, Export Sphere ou Walthead funcionando bem no FB, mas export Scene1 result não pode importar para o FB.

Este é algum comportamento esperado e tem que esperar do lado do FB?

Eu esperava que BufferGeometry usando fromGeometry funcionasse perfeitamente como BufferGeometry normal, por favor, me oriente algumas soluções rápidas para superar esse problema.

@ Ben-Mack, isso é algo que deve ser corrigido nas próximas semanas de acordo com @zellski -> https://github.com/mrdoob/three.js/issues/13397#issuecomment -367534958

A partir da versão 161 em diante (a versão atual da App Store é 160) do aplicativo FB principal, isso não será mais um crasher e removeremos essa verificação de validação. Espero que isso aconteça dentro de uma semana.

@zellski isso é incrível! obrigado :)

Mas me faz pensar ...

A razão "real" que THREE.GLTFExporter não pode exportar THREE.Geometry é porque quando convertemos THREE.Geometry em THREE.BufferGeometry estamos criando um color atributo que está, na maioria dos casos, cheio de zeros.

Portanto, uma "solução" (e otimização) seria não exportar o atributo color se material.vertexColors estiver definido como THREE.NoColors ?

Ops, eu não sabia disso: D com certeza é uma otimização obrigatória: D

@fernandojsg obrigado pelas atualizações que você fez, muito apreciado. Existem mais duas coisas que vale a pena adicionar:

1. Suporte para malhas multimateriais. Aqueles que têm grupos em suas geometrias e array em Mesh.material - eles atualmente não podem ser exportados adequadamente;
2. Melhor compatibilidade entre o único MeshStandardMaterial suportado e o resultado que temos no Facebook. Até agora, as superfícies metálicas e difusas parecem bastante diferentes no three.js e no Facebook. Talvez tenhamos um material especial no "Facebook" um dia?

Obrigado

@ov , acho que ambos devem ser corrigidos em torno de r91:

1. exportação de vários materiais https://github.com/mrdoob/three.js/pull/13536
2. correções de metal / rugosidade https://github.com/mrdoob/three.js/pull/13501

É possível que os materiais do Facebook também não estejam certos, mas o glTF é muito específico sobre como as coisas devem aparecer, então, eventualmente, devemos convergir.

Oh, devemos adicionar a capacidade de exportar KHR_materials_unlit também ...

EDIT: https://github.com/mrdoob/three.js/pull/13566 aberto

A razão "real" de THREE.GLTFExporter não pode exportar THREE.Geometry é porque quando convertemos THREE.Geometry em THREE.BufferGeometry estamos criando um atributo de cor que está, na maioria dos casos, cheio de zeros.

Portanto, uma "solução" (e otimização) seria não exportar o atributo de cor se material.vertexColors estiver definido como THREE.NoColors?

1 espero que isso seja corrigido em breve. Muita biblioteca para Three.js ainda com desempenho com base em THREE.Geometry .

(FB ainda apresentando erro ...must be RGBA com THREE.Geometry )

@ Ben-Mack, quais bibliotecas você está usando que ainda usam geometria? Talvez possamos trabalhar com os proprietários para atualizá-los.

@looeee Por favor, dê uma olhada nesta biblioteca: https://github.com/a-jie/threejs-geometry-modifiers

Ei pessoal - a partir desta manhã, o Facebook não rejeita mais cores de vértice RGB (VEC3) como "inválidas".

Os requisitos de texturas de potência de dois permanecem por enquanto, mas estou trabalhando nisso também.

@zellski coool! :) Estou muito perto de ter suporte total para um pintor: D Existe algum plano para implementar o resto dos modos primitivos? No momento, acredito que apenas TRIANGLE é compatível. Seria ótimo dar suporte ao resto, por exemplo, no A-painter estamos usando TRIANGLE_STRIP para economizar espaço 👼

Seria uma loucura não implementá-los, certo? Idealmente, todos os glTF válidos devem ser aceitos. Não sei como esse trabalho será priorizado, no entanto. Somos uma equipe pequena com muitos desejos fortes. :)

Acho que esse problema já pode ser resolvido?