Isso está parecendo muito bom!

A propósito, estamos planejando remover THREE.GLTFLoader e renomear GLTF2Loader → GLTFLoader breve *. Pode ser uma boa ideia renomear o exportador como GLTFExporter antes do desembarque do r87, para evitar qualquer confusão e assim não haverá uma mudança de nome necessária entre os lançamentos. Opa, não entendi que você já nomeou assim .. continue! 😆

* @mrdoob , alguma preferência sobre quando isso deve acontecer? IMO, poderíamos fazer isso agora, a menos que queiramos manter GLTFLoader em r87 com apenas um aviso de depreciação e removê-lo em r88?

Acho que quanto mais cedo melhor. Contanto que o novo GLTFLoader seja capaz de detectar 1.0 e avisar o usuário de que oferecemos suporte apenas para 2.0+.

IIRC podemos detectar vendo asset como mencionei antes.

Podemos detectar o IIRC vendo o ativo como mencionei antes.

✅ Sim! https://github.com/mrdoob/three.js/pull/11864

Legal! Mas eu encontrei um pequeno bug. Estou fazendo relações públicas agora. Vamos fundir antes de renomear.

Podemos especificar os itens nos quais alguém está trabalhando na lista de verificação?

@takahirox com certeza! as pessoas poderiam apenas escrever comentários aqui e eu poderia atualizar a lista e apontar para um PR, se já houver algo acontecendo

A próxima coisa que estarei trabalhando é nas texturas, para convertê-las em base64 em vez de usar apenas o url

Obrigado! Eu quero ajudar a tornar o exportador glTF. Estou procurando o que posso ajudar na lista de verificação ...

BTW, você propositalmente deixou duas variáveis WEBGL_CONSTANTS e THREE_TO_WEBGL global?

@takahirox cool!
Em relação às duas variáveis, isso é algo que irei abordar no PR a seguir para torná-las parte de WebGLUtils e apenas importá-lo. Não faz sentido que cada um que precisa dessas constantes precise redefini-las novamente a cada vez.

@takahirox btw

@fernandojsg Claro! Sobre as variáveis, eu queria propor movê-las para algum lugar se elas forem declaradas propositalmente como globais, então é bom saber que você faz.

Eu quero trabalhar na visualização de buffer compartilhado.

BufferViews: Atualmente estou criando um novo bufferView para cada acessador, isso deve ser corrigido para usar apenas um para esses atributos que compartilham o mesmo componentType

O motivo pelo qual um para os atributos que compartilham o mesmo componentType, e não um para todos os atributos, é para alinhamento de dados, correto?

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

Legal, acabei de adicionar você à lista 👍 Sim, basicamente você deseja compartilhar a mesma visualização de buffer para componente com o mesmo tipo, por exemplo, se você tiver posição e normal, você terá dois acessores VEC3, mas eles apontarão para o mesmo bufferview. Isso pode ser um ótimo ponto de partida;)

Quero dizer, a razão pela qual não permitimos que a visualização do buffer seja compartilhada entre diferentes componentType (ex: float e short) é para manter um bom alinhamento de dados, correto?

Acredito que você pode armazenar na mesma visualização de buffer diferentes tipos de componentes, desde que tenham o mesmo target , por exemplo normal (Vec3) , position (Vec3) e uv (Vec2) poderia estar na mesma visualização do buffer, mas indices não. @donmccurdy você poderia confirmar isso?

Sim, concordou. E como esta especificação glTF menciona

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data -alignment

O deslocamento de um acessador em um bufferView (ou seja, accessor.byteOffset) e o deslocamento de um acessador em um buffer (ou seja, accessor.byteOffset + bufferView.byteOffset) deve ser um múltiplo do tamanho do tipo de componente do acessador.

É uma boa ideia separar as visualizações de buffer entre os diferentes componentType (= tipo de dados como float e short, não vec2 ou vec3) para simplificar. Se os separarmos entre diferentes componentType de comprimento de dados, ele será mais otimizado.

BTW, há algum motivo especial pelo qual o exportador atual suporta apenas accessor.componentType float, uint e ushort? O glTF 2.0 pode lidar com char, uchar e short, além deles.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#accessorcomponenttype -white_check_mark

@takahirox não realmente, eu só os defini agora porque são os usados ​​para o tipo de atributos que suportamos agora (posições, normais, cores, uvs, índices ..).
A próxima etapa em que estou trabalhando são as texturas, então precisaremos de outras como uchar por exemplo

OK, então primeiro irei trabalhar no accessor.componentType s, a menos que você já tenha começado a implantar.

Quase pronto, mas meu PR deve entrar em conflito com o # 11978.
Então, envio o meu assim que o # 11978 for mesclado e consertar o conflito.

Você adicionaria animação à lista?

@takahirox claro, pode ser ótimo adicionar animação. Eu só não adicionei porque não estava familiarizado o suficiente com o estado atual dos recursos de animação no three.js, mas se você quiser assumir, seria ótimo;)

Você planeja oferecer suporte a grupos BufferGeometry?
As especificações do GLTF cobrem isso ou resultariam na criação de uma nova malha para cada grupo?
Isso também deve levar em conta, a propriedade do material de uma malha sendo uma variedade de materiais.

@marcatec A especificação glTF tem uma distinção "malha" vs. "primitiva" que permitiria a você criar grupos BufferGeometry que poderiam cada um fazer referência a um material diferente. Atualmente THREE.GLTFLoader não otimiza carregamentos primitivos - ele cria malhas separadas - mas isso poderia ser implementado.

Bom trabalho, ótima lista e bom saber que já existe tanto apoio no formato! Também funciona muito bem em conjunto com o exportador do blender gltf. Mal posso esperar pelo suporte de luzes! Continue com o ótimo trabalho.

Eu concordo, ótimo trabalho!

Existem planos para adicionar suporte para outros materiais além do StandardMaterial?

Obrigado!

@homerjam quaisquer propriedades do material compartilhadas com MeshStandardMaterial serão preservadas - então, por exemplo, um MeshPhongMaterial usando map e normalMap exportaria com essas texturas intactas, mas quando você importá-lo de volta para three.js, será um MeshStandardMaterial. O exportador atualmente faz uma conversão ingênua para PBR para isso.

O suporte de ida e volta (exportar Phong de GLTFExporter, carregar Phong de GLTFLoader) exigirá trabalho em andamento no formato glTF: https://github.com/KhronosGroup/glTF/pull/1150

baseColorTexture : é compatível (material.map), mas o texCoord está sempre definido como 0

@fernandojsg você poderia esclarecer o que está faltando aqui? Uma vez que .map é sempre o primeiro UV definido em three.js, essa parece ser a maneira correta de representar isso em glTF?

Também por aviso, eu risquei três itens da lista. Raciocínio abaixo:

• tangentes
  
  
  
  • three.js apenas os calcula na GPU; adicionar uma implementação apenas para o exportador não parece ideal.
  
  
• acessores esparsos
  
  
  
  • Acho que é melhor deixar isso para a otimização pós-exportação, como o script de mattdesl .
  
  
• verifique se o material corresponde ao padrão do glTF e omita-o
  
  
  
  • parece um caso extremo / desordem, sinta-se à vontade para implementar se alguém se sentir fortemente
  
  

Exportando para GLB do editor, notei que alphaMap , roughnessMap e metalnessMap não são exportados.

Em # 13397, eu disse que normalMap nenhum dos dois é exportado, mas parece que estava errado.

Ao exportar para o GLB do editor, percebi que alphaMap, roughnessMap e metalnessMap não são exportados.

Vou trabalhar nisso hoje, a menos que alguém já tenha começado.

@donmccurdy

acessores esparsos
Acho que é melhor deixar isso para a otimização pós-exportação, como o script de mattdesl.

Sentir vontade de permitir que o exportador suporte acessores esparsos para metamorfose. Vou tentar mais tarde.

@takahirox cool! vá em frente!

Não acho que alphaMap seja compatível com glTF 2.0.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#material

Sim, eu temia isso ... Que tal metalnessMap e roughnessMap ?

Estou trabalhando neles agora!

13415

Com relação aos formatos de imagem. O glTF 2.0 suporta apenas .png e .jpg como arquivos de imagem externos. Estou pensando em como lidar com arquivos de formato de imagem não suportados (por exemplo: .bmp) em modo não embedImages .

1. Converter para .png ou .jpg e incorporar
2. Não se importe. Exportar como arquivos de imagem originais
3. Não exporte

Eu prefiro 1. Alguma ideia?

Nossa, estou gostando muito do trabalho de vocês.

Espero que Multi-material meshes seja implementado o mais rápido possível porque a maioria dos modelos 3D usa materiais múltiplos.

1. Converter para .png ou .jpg e incorporar
2. Não se importe. Exportar como arquivos de imagem originais
3. Não exporte

Eu voto em 3 e registrando um aviso no console.

Espero que as malhas multimateriais sejam implementadas o mais rápido possível, porque a maioria dos modelos 3D usa multimateriais.

Concordo, para mim esse é o problema número um que impede o uso do exportador.

Espero que as malhas multimateriais sejam implementadas o mais rápido possível, porque a maioria dos modelos 3D usa multimateriais.

Como eu disse no outro tópico, estou trabalhando nisso.

1. Converter para .png ou .jpg e incorporar
2. Não se importe. Exportar como arquivos de imagem originais
3. Não exporte

Eu voto em 3 e registrando um aviso no console

Sim, cheguei a pensar que 3. seria mais simples e não confundiria os usuários. Obter a imagem incorporada em um modo diferente de emedImages seria um pouco confuso.

A razão pela qual eu prefiro 1. foi para converter de outros formatos para glTF. Alguns (ou muitos) de outros formatos não têm limitação de formato de imagem.

O exportador converte no modo embedImages . Portanto, adicionar "usar a opção embedImages se quiser converter" para o aviso do console seria bom, estou pensando.

Eu também iria para 3 também. Como a conversão de outros formatos pode ser entediante, e você precisará priorizar alguns formatos em relação a outros. Provavelmente vale a pena fazer 3 agora e esperar para ver se gltf adiciona suporte para novos formatos de textura como ktx ou assim e podemos revisitar a implementação.

Conforme discutido em https://github.com/mrdoob/three.js/pull/13415#issuecomment -369022383, seria bom se o exportador pudesse compor a textura ambientRoughnessMetalness para o usuário. Provavelmente melhor colocar esse código em ImageUtils .

Eu atualizei a lista de verificação com as alterações mais recentes. Eu adicionei @takahirox ao multimaterial , e irei me encarregar da tarefa de composição de imagens.
Eu adicionei também a extensão material_unlit, embora ainda esteja em rascunho, acredito que esteja bem perto do lançamento e não mudará muito (/ cc @donmccurdy)

Espero que as malhas multimateriais sejam implementadas o mais rápido possível, porque a maioria dos modelos 3D usa multimateriais.

Como eu disse no outro tópico, estou trabalhando nisso.

WIP ... (Miku possui multimaterial)

Sobre formatos de imagem não suportados, ok vamos para 3.

@takahirox com boa aparência! 👍

BTW, vocês estão interessados ​​em suporte a arquivos zip? .glTF + .bin externo e texturas seriam adequados a outras ferramentas de autoria (talvez), mas seriam difíceis de fazer sem arquivamento. Portanto, o arquivo zip seria necessário. E podemos reduzir o tamanho do arquivo exportado.

Eu quero e tentei em minha filial local antes, posso compartilhar mais tarde se você estiver interessado.

Isso não é praticamente o mesmo que gzipar um glb?

.glTF + .bin externo e texturas seriam adequados a outras ferramentas de autoria (talvez)

Espero que as ferramentas de autoria não exijam arquivos separados; estamos encorajando todos a usar o GLB por padrão. Mas é mais fácil editar manualmente uma imagem se ela não estiver incorporada, com certeza.

Nenhuma opinião forte sobre se queremos colocar essa funcionalidade em THREE.GLTFExporter diretamente ... mas quase acho que não devemos ter muitas opções que poderiam ser pós-otimizações no glTF. Outro exemplo, Draco é meio complicado e requer vários arquivos externos, então talvez seja melhor deixar ferramentas especializadas de glTF para glTF fazer essa otimização. E, da mesma forma, poderíamos fazer um glb-unpacker (oposto de http://glb-packer.glitch.me/) para ajudar as pessoas a descompactar arquivos do GLB para o ZIP se descobrirmos que as pessoas precisam dele.

De https://github.com/KhronosGroup/glTF/issues/1256 -

... a intenção original do gltf-pipeline - e realmente do glTF em geral - tornar os exportadores o mais simples possível e enviar as otimizações para uma ferramenta comum. É claro que também ajudará na fragmentação.

dito isso, nenhum glb-unpacker existe ainda que eu saiba ...

@mrdoob

Eu queria que as imagens de textura fossem externas, em vez de .glTF vs .glb.

@donmccurdy

Eu acompanhei https://github.com/KhronosGroup/glTF/issues/1117 discussão e concordo em encorajar arquivos incorporados .glb + e abordagem de pipeline agora. Um .glb é bom para transmissão de dados, especialmente para web e a abordagem de pipeline pode manter os exportadores e as ferramentas simples e reutilizáveis. (Eu também gosto da abordagem de pipeline de comando UNIX / Linux!)

Portanto, não acho que o exportador precise de suporte de arquivo zip agora. E talvez também não precise de acessador esparso e suporte de draco pelo mesmo motivo.

Com relação ao glb-unpacker, posso fazer isso no meu tempo livre. Acho que alguns artistas gostam de arquivos externos .glTF + porque eles podem ser lidos sem nenhuma ferramenta específica do glTF. E às vezes os arquivos externos podem reduzir o tempo de carregamento devido ao arquivo de carregamento paralelo, de forma que ele pode ser usado para fins de otimização.

Com relação às ferramentas de pipeline / otimização, quero observar que não queremos transferir muitos dados pela rede. Os usuários desejam otimizar / compactar antes de ~ transformar ~ transferir dados. Portanto, o serviço da web de otimização de glTF às vezes não funciona bem para dados enormes porque o usuário precisa enviar um arquivo enorme para o servidor.

Além disso, para Three.js e outros mecanismos baseados em navegador JavaScript, ficaríamos felizes se tivéssemos ferramentas de otimização glTF que rodam no navegador. Podemos otimizar / compactar antes que os dados sejam transmitidos aos usuários. Sem eles, os usuários precisam baixar manualmente os dados exportados e, em seguida, passá-los para as ferramentas do pipeline, devido às limitações do navegador.

Desse ponto de vista, quero que uma ferramenta possa ser executada em qualquer lugar, no navegador, no servidor, CUI e assim por diante, para ser mais comum e reutilizável. Não queremos fazer ferramentas com o mesmo propósito duas ou mais vezes para plataformas diferentes. Então, uma ferramenta baseada em node.js seria boa? A equipe glTF (pipeline) tem alguma sugestão? (Talvez esta discussão deva ser feita no glTF, não aqui.)

Apenas no caso, em GLTFLoader suporte binário é implementado como extensão, mas .glb está nas especificações principais do glTF 2.0, correto?

Por precaução, no GLTFLoader o suporte binário é implementado como extensão, mas .glb está nas especificações principais do glTF 2.0, correto?

Sim, era uma extensão do glTF 1.0 e eu nunca realoquei ou renomeei aquele código depois que ele se tornou parte da especificação principal do glTF 2.0.

Desse ponto de vista, quero que uma [ferramentas de otimização] possa ser executada em qualquer lugar, no navegador, no servidor, CUI e assim por diante, para ser mais comum e reutilizável. Então, uma ferramenta baseada em node.js seria boa? A equipe glTF (pipeline) tem alguma sugestão? (Talvez esta discussão deva ser feita no glTF, não aqui.)

Vale a pena perguntar sobre o roteiro do glTF-Pipeline ... não tenho certeza de quão geral eles querem que o glTF-Pipeline seja, ou se é principalmente para uso de césio, ou se é apenas uma questão de tempo limitado de desenvolvedor. Além disso, o glTF-Toolkit parece relevante, mas (atualmente) só funciona no Windows. Eu pessoalmente gosto de Node.js, mas C ++ ou Rust podem ser escolhas razoáveis ​​com compilação para WASM.

Oh, eu estava perdendo a compilação para WASM. Especificar algumas plataformas de desenvolvimento recomendadas seria bom para os desenvolvedores de otimização. Então, eu proporia um tópico apropriado.

Concordo com @donmccurdy, pois sinto que essas otimizações no pipeline poderiam viver em um repo diferente do three.js, para que todos pudessem se beneficiar delas. Ainda preciso verificar as diferenças entre o pipeline gltf e as ferramentas do kit de ferramentas, mas espero que esse tipo de recurso seja incluído neles.
Eu também concordo que, enquanto tivermos um WASM, não importaria o idioma de origem, mas também é verdade que, se for escrito em node.js, provavelmente muitos da comunidade em torno dos motores da web 3D poderiam ajudar a melhorá-los, pois agora são o alvo principal para este formato de arquivo de qualquer maneira.

Não tenho certeza se entendi sobre "otimizar antes de transformar" ... existem vários tipos de transformações que um pipeline pode fazer em um modelo, e as otimizações são provavelmente o tipo mais comum de transformação?

Acordado além disso. É bom ter ferramentas focadas de baixo nível que podem ser usadas para construir outras ferramentas ou conectadas a uma GUI mais amigável.

Ops, é erro de digitação. Não se transformando, mas se transferindo. Quero dizer, a maioria dos usuários deseja otimizar / compactar antes de enviar dados pela rede. Eu atualizei as postagens para torná-las mais claras.

Oi, pessoal

Estou usando o exportador de GLTF THREE.js para exportar uma cena inteira do frame como um objeto gltf.
Como posso fazer com que as tags a-animation definidas em um nome façam parte das animações no objeto gltf?

@donmccurdy @fernandojsg @mrdoob

Olá @siddhartpai - THREE.GLTFExporter converte apenas objetos THREE.AnimationClip em animações glTF, enquanto o sistema de animação do A-Frame usa TweenJS. Então, atualmente, isso não é possível. Você pode querer abrir um problema no A-Frame ou no A-Frame Inspector, que também usa GLTFExporter , para solicitá-lo como um recurso futuro.

Suporte multimaterial # 13536

Acabei de notar que o validador lança um erro em cada elemento normal em um bufferview que não é normalizado. Por exemplo, se eu armazenei valores não inicializados como [0,0,0], esse erro será gerado.
Como é um erro e não um aviso / aviso, vejo que é sensível para corrigir. O que você acha sobre garantir que os elementos normais do bufferview sejam normalizados? Mesmo assim, para valores que não podem ser normalizados como [0,0,0], devemos usar um vetor unitário válido? / cc @donmccurdy

Parece que NORMAL deve ser normalizado.

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#meshes

NORMAL | "VEC3" | 5126 (FLOAT) | Vértices normais XYZ normalizados

Concordou em garantir porque Three.js normal não tem essa limitação.

Sim, mas o que fazer quando você não tem um valor normal real, como um valor não utilizado de [0,0,0], apenas crie um válido e está tudo bem? digamos [1,0,0]. Portanto, devemos modificar o código do bufferview para detectar que estamos analisando um atributo normal e normalizar cada um antes de salvá-lo no dataview.

o que fazer quando você não tem um normal real, como um valor não utilizado de [0,0,0]

Hm .... substituindo por um válido e exibindo um aviso?

Portanto, devemos modificar o código do bufferview para detectar que estamos analisando um atributo normal e normalizar cada um antes de salvá-lo no dataview.

Eu prefiro fazer isso em processMesh() porque seria mais simples, como

var originalNormal = geometry.attributes.normal;

if ( hasNonNormalizedValues( originalNormal ) ) {

    geometry.attributes.normal = createNormalizedAttribute( originalNormal );

}

processAccessorHere();

geometry.attributes.normal = originalNormal;

Se fizermos isso em processBufferView() , o código se tornará um pouco complexo porque precisamos nos preocupar se os dados são compartilhados entre atributos diferentes, por exemplo, posição e normal. (Eu sei que é um caso de uso muito raro, mas Three.js não restringe.)

Sim, eu gosto dessa abordagem, eu estava com medo de modificar os normais depois de exportar, mas deve ficar tudo bem se salvarmos uma referência e colocá-los novamente após terminar. : +1: Você se importaria de empurrar um PR com essas mudanças? ou quer que eu faça isso?

Sim eu vou. (Você está com pressa para consertar isso?)

@takahirox legal, obrigado! mas sem pressa eu estava apenas revisando o estado do exportador ^ _ ^

OK, então farei ~ amanhã ~ esta semana.

Certo, glTF não permite omitir normais em vértices particulares, mas não em outros em uma única primitiva. Precisamos fornecer algum tipo de valor, remover esses vértices ou lançar um erro.

Eu preferiria tornar as coisas mais fáceis para o usuário, então meu voto é para criar um novo array de normais normalizando-os e adicionando um valor (0,1,0) para os vazios.

Parece bom. Se for lento para modelos grandes, podemos querer uma opção checkNormals ou algo parecido, então os usuários que não precisam disso podem cancelar, em vez de escanear cada vértice.

Sim, eu estava prestes a escrever o mesmo! : D

Se for lento para modelos grandes, podemos querer uma opção checkNormals ou algo parecido, então os usuários que não precisam disso podem optar por sair, em vez de escanear todos os vértices.

Vou fazer relações públicas sem essa opção primeiro. Vamos adicionar quando / se necessário. Pessoalmente, suponho que essa verificação não desacelere muito.

Vou fazer relações públicas sem essa opção primeiro. Vamos adicionar quando / se necessário. Pessoalmente, suponho que essa verificação não desacelere muito.

Eu estava normalizando todos os buffers ao carregar cada pincelada em um pintor e era bem lento

Mesmo que seja apenas verificando se eles estão normalizados?

@takahirox você precisará calcular o comprimento de qualquer maneira, então eu acho que não vai mudar muito

HM OK. Vou avaliar com o PR.

É o primeiro recurso GLTFExporter que introduzimos que faz qualquer cálculo com cada vértice (exceto conversão de destino de metamorfose relativa / absoluta), então sim, potencialmente mais lento .. de qualquer maneira.

Ótimo trabalho! IMHO deve ser mesclado no core three.js, ao invés de "exemplos".
Adoraria ver o suporte de KHR_lights_punctual !

PR https://github.com/mrdoob/three.js/pull/15519 adiciona KHR_lights_punctual. :)

Acho que esse problema provavelmente pode ser resolvido - os itens restantes são de conveniência ou otimização menos crítica e podem ser rastreados em outro lugar:

• [] reutilizar bufferviews
• [] mesclar texturas metal / áspero / ao automaticamente

Ei pessoal, alguém sabe como posso exportar uma malha de formato personalizado por alterações de metamorfose aplicando os morfos e removendo-o do objeto final?
Como esta pergunta https://stackoverflow.com/questions/57423471/how-to-export-morph-changed-meshes-from-threejs-application
Desde já, obrigado!

@ vini-guerrero Use os fóruns (https://discourse.threejs.org/) ou Stack Overflow para obter ajuda, em vez de problemas com o GitHub.