Three.js: Utils: Obsoletar exportadores (Blender, 3DS Max e Maya)

+1 para isso - a existência de exportadores mal mantidos e desatualizados no repo é um ponto desnecessário de confusão para os novatos, especialmente porque, como @ Mugen87 aponta, agora existem opções muito melhores.

Nota: o exportador oficial do GLTF Blender (https://github.com/KhronosGroup/glTF-Blender-Exporter) não permite atualmente a exportação de animação adequada (apenas 1 animação por objeto é suportada atualmente).
https://github.com/KhronosGroup/glTF-Blender-Exporter/issues/112

@Usnul como isso se compara ao exportador JSON do Blender neste repo?

@looeee
O exportador JSON do Blender exporta animações muito bem. Existem algumas falhas estranhas com UVs ou normais de vértice em certas condições que não estão presentes no exportador de GLTF, mas isso é outra história.

Ok, eu não uso o Blender, então não vou comentar mais sobre isso.

No entanto, posso dizer por experiência própria que tentar usar o exportador 3DS Max, que não é atualizado há vários anos, é uma dor de cabeça sem fim e eu apoiaria fortemente sua remoção do repositório em favor do formato FBX.
Quase tudo exportado pelo exportador 3DS Max FBX agora é suportado pelo FBXLoader e como esse exportador é mantido pelo AutoDesk, podemos contar com a sua atualização.

Da mesma forma com o exportador Maya FBX, embora o FBXLoader ainda precise ser atualizado para suportar adequadamente os pontos de pivôs lá.

Quando bem me lembro, o Blender não exporta animações quando você seleciona BufferGeometry . Definitivamente, há um problema com os alvos de metamorfose, consulte # 10932. Além disso, o exportador utiliza o formato de hierarquia de animação "antigo" e não o do sistema de animação atual.

Acho que devemos remover o README do exportador Revit também - ele apenas se conecta a um repositório separado que parece que quase não foi tocado nos últimos anos.

Provavelmente, existem centenas de ferramentas three.js para as quais poderíamos nos vincular, mas a menos que estejamos dispostos a garantir que sejam mantidas ativamente e funcionando corretamente, não acho que precisamos incluir links para elas aqui.

Pesquisando por "exportador de revit three.js ', o repositório está bom de qualquer maneira.

Acho que devemos remover o README do exportador Revit também - ele apenas se conecta a um repositório separado que parece que quase não foi tocado nos últimos anos.

👍

a existência de exportadores mal mantidos e desatualizados no repo é um ponto desnecessário de confusão para os recém-chegados

Só quero destacar esta afirmação porque acho que é muito importante para three.js . Quando os usuários encontram esses exportadores, eles esperam ferramentas que simplesmente funcionem. Mas na maioria dos casos eles ficam confusos e talvez causem uma má impressão de todo o projeto. Isso não é bom. 😢

Como um usuário inocente, atrevo-me a fazer um comentário ...

Sobre o Blender:
Se three.js tivesse um importador de formato .blend nativo ,
obviamente não haveria necessidade de um exportador.

Nenhum esforço de instalação no lado do Blender,
nenhuma compilação de API / structs do blender para javascript por meio de código python ...

Houve esforços tremendos para escrever o exportador JSON em python,
Eu me pergunto por que vocês colaboradores não escolheram assim ...?

@wolfgangvonludwigsburg
É uma pergunta bastante simples de responder. O formato do Blend não é muito próximo da representação interna do three.js, então alguma conversão é necessária. O formato JSON de three.js é muito próximo à representação interna, então o trabalho de conversão da representação do blender para three.js existe de qualquer maneira, se você escolher chamá-lo de Exportador ou Carregador. Dito isto, .blend não é um formato de transferência comum, nada exceto o blender realmente o suporta, então ter um carregador para ele iria satisfazer um público bastante pequeno, já que mesmo pessoas que usam o blender prolificamente tendem a usar outro software também, e .blend não é um formato escolhido como formato de troca. Normalmente é obj, fbx ou algum padrão aberto como gltf ou collada.

@wolfgangvonludwigsburg se você _estesse_ procurando construir um carregador de arquivos .blend, este provavelmente seria um bom lugar para começar:

https://raginggazebo.com/parsing-blender-3d-files-blend-1-of-3/

Muito THX pelos seus comentários!

Mas por que o exportador JSON do Blender é tão sujeito a erros ...
=> Depende da API do Blender, é escrito em Python, deve compreender as estruturas de dados do Blender,
e compila para um formato JSON, que o three.js reconverte em seu interior ...

Muitas tarefas, que todos podem (e realmente fazem!) Falhar, principalmente nas mudanças de versão do Blender.
Bem, eu preferiria a forma de "compilação direta de dados" ...

Bem, eu preferiria a forma de "compilação direta de dados".

Essa não é uma boa abordagem. Carregar blend arquivos diretamente em aplicativos é algum tipo de uso indevido. Em vez disso, você deve utilizar um formato de arquivo destinado à transferência de dados e entrega de ativos. glTF é o primeiro formato padronizado que foca neste aspecto do ponto de vista da aplicação. Essa é uma das razões pelas quais eu promovo glTF tantas vezes 😇. Deve ser o padrão para todos os próximos aplicativos 3D.

Bem, eu preferiria a forma de "compilação direta de dados" ...

Infelizmente, existem problemas mais profundos em usar .blend dessa maneira. Ele armazena coisas como histórico de edição, estado atual da UI do Blender, dados do complemento do blender. O formato muda conforme novos lançamentos do Blender são lançados. E os tamanhos dos arquivos podem ser muito grandes, então nunca seria uma boa escolha para aplicativos 3D de alta qualidade. A melhor maneira de obter dados diretamente do Blender é usar as APIs do Blender (como os exportadores FBX e glTF fazem), ao invés de tentar fazer a engenharia reversa do formato .blend interno do Blender.

Para a pergunta original, vou pular a adição de um voto sim / não, pois não tenho muita familiaridade com fluxos de trabalho de autoria 3D.

Mas como um mantenedor e principalmente um desenvolvedor JS, ser capaz de focar no carregamento e suporte para formatos como FBX e glTF - que têm mantido ativamente ferramentas de autoria de terceiros - parece mais provável de fornecer resultados confiáveis.

Além disso, se houver algum problema com o ecossistema glTF atual que o impeça de ser um fluxo de trabalho bom o suficiente para resolver esse tipo de necessidade, esse é um feedback útil também. 🙂

Eu não argumentei para usar o formato Blender .blend como um formato de troca geral ,
mas pode simplificar a colaboração entre o Blender e three.js ...

Não posso estimar os esforços, mantendo um exportador Python + GUI sob a estrutura do Blender,
mas eu acho que isso pode facilmente se tornar um horror ... ;-)

@donmccurdy
BTW, Wavefront .obj, 3D Studio .3ds são formatos nativos também, que estão em uso amplamente difundido ...

BTW, Wavefront .obj, 3D Studio .3ds são formatos nativos também, que estão em uso amplamente difundido ...

Sim, eu acho que OBJ não é mencionado aqui porque o formato não suporta alguns recursos populares como animação, mas certamente three.js continuará suportando OBJ por muito tempo - é um formato clássico e confiável.

Do 3DS Max .3ds está na mesma categoria como Blender de .blend ou de Maya .mlt ou de Cinema4D .c4d . Cada editor tem seu próprio formato interno, e esses formatos mudam conforme o software. Manter carregadores para o formato interno privado de cada ferramenta de modelagem é muito mais difícil e sujeito a erros do que usar os formatos de exportação fornecidos pelos próprios desenvolvedores do editor. Vale a pena notar que tanto o 3DS quanto o Blender vêm com exportação FBX embutida - mantida por seus autores - e que o Blender terá exportação glTF embutida em uma versão futura também.

Um último lance ...

Já temos um exportador / importador independente de ferramenta de modelagem: Collada,
mas, por qualquer motivo, isso não parece muito aceito.

De preferência, eu tinha esse tipo de implementação em mente:
uma solução de carregamento, baseada em Google Protocol Buffers

https://developers.google.com/protocol-buffers/

É um

... mecanismo extensível de linguagem neutra, plataforma neutra para serializar dados estruturados - pense em XML, mas menor, mais rápido e mais simples.

Uma vez que os dados vetoriais 2D / 3D com os quais temos que lidar não são tão complexos por natureza, o desenvolvimento de um esquema de arquivo de dados do Blender deve ser simplesmente viável ...

Na verdade, existe um analisador de arquivos blend em javascript 😁
https://github.com/Galactrax/js.blend

uhh, eu recebo suporte ... - obrigado mrdoob ;-))

O maior (em termos de Terrabyte) aplicativo de modelo 3D (Google Maps 3D) usa este tipo eficiente (protobufs) de implementação ...

Seguir o caminho de carregamento de .blend pode não ser muito sensato. Mas não é tão diferente de carregar .dae e .fbx ...

Enfim, concordo com a ideia de depreciar os exportadores.
No entanto, eu esperaria até que o gltf esteja um pouco mais maduro e testado. Verão de 2018?

Eu concordo em remover esses exportadores também. Você pode até mesmo movê-los para algum outro repositório onde eles possam fazer o RIP :)

No entanto, eu esperaria até que o gltf esteja um pouco mais maduro e testado. Verão de 2018?

Esperar me parece razoável. Em particular para o glTF, seria bom ter algumas coisas no lugar primeiro:

• [] Remessa do Blender com exportação glTF embutida e suporte a várias animações.
• [x] Fluxo de trabalho aprimorado de Maya e 3DS Max para glTF, ou apenas mais testes de FBX2GLTF .
• [x] Atualizações para o conversor oficial COLLADA2GLTF para glTF 2.0.

Revisitar a questão no verão de 2018 parece certo.

No entanto, eu esperaria até que o gltf esteja um pouco mais maduro e testado. Verão de 2018?

Para o exportador do Blender, tendo a concordar. No entanto, eu recomendo remover pelo menos o exportador 3DS Max imediatamente, uma vez que já existe uma alternativa madura e muito melhor no FBX.

No entanto, eu recomendo remover pelo menos o exportador 3DS Max imediatamente, uma vez que já existe uma alternativa madura e muito melhor no FBX.

Parece bom para mim 👌

Ok, o exportador 3DS Max se foi. Vamos revisitar os outros exportadores (Blender e Maya) em alguns meses.

Eu não acho que muito mudará em relação ao exportador Maya naquele tempo.

Provavelmente deveríamos avaliar isso agora. Vou testá-lo e ver se vale a pena mantê-lo nos próximos dias.

Boa sugestão 👍.

Enquanto estamos aqui, qual é o status de https://github.com/mrdoob/three.js/tree/dev/utils/converters/fbx ? Parece que isso poderia ser substituído por um script node.js como o conversor obj2three, apenas usando THREE.FBXLoader e serializando no final. Atualmente, o conversor tem muitos problemas em aberto:

No animation support
Only Lambert and Phong materials are supported
Some camera properties are not converted correctly
Some light properties are not converted correctly
Some material properties are not converted correctly
Textures must be put in asset's folder, and use relative path in the material

Também os conversores msgPack, UTF8 e CTM - eles não são tocados há anos.

Eles ainda são úteis para alguém?

@donmccurdy Infelizmente você não pode usar FBXLoader dentro de um script node.js, pois você não tem acesso ao DOM. Todos os carregadores que utilizam TextureLoader dependem de ImageLoader e, portanto, de document . Obteremos erros de tempo de execução como ReferenceError: document is not defined . O mesmo problema para o objeto window que é acessado de FileLoader .

Como uma solução temporária, talvez pudéssemos redefinir ImageLoader e FileLoader no arquivo fbx2three.js ?

talvez pudéssemos redefinir ImageLoader e FileLoader no arquivo fbx2three.js?

Acho que isso seria bastante simples e ainda requer muito menos código do que o conversor Python que existe agora ... vou tentar.

talvez pudéssemos redefinir ImageLoader e FileLoader no arquivo fbx2three.js?

Boa ideia: blush:

.3ds do 3DS Max está na mesma categoria que .blend do Blender ou .mlt do Maya ou .c4d do Cinema4D.

Isso pode não ser totalmente verdade, .max é mais parecido com a mesma categoria, .3ds é bastante reduzido.

Eu gostava de ter o exportador 3ds max por aí como exemplo de como escrever um exportador, e também no maxscript. Acho que nunca fui capaz de exportar o espaço tangente correto do 3ds max via fbx, com o maxscript é fácil experimentar e pegar o que você precisa.

Vale a pena fazer um novo repo, com as isenções de responsabilidade apropriadas? Tudo para exemplos de como escrever um exportador, mas se ele não tiver manutenção e o FBXLoader agora for mais confiável, não queremos que as pessoas presumam que é a maneira recomendada de trazer ativos do 3DS Max para o three.js.

Sim, eu voto em um novo repo.

Só queria adicionar antes de abandonar totalmente o formato json: estamos usando o exportador do blender para exportação de cena, ou seja, configurando câmera e hierarquia de cena com animações e propriedades personalizadas junto com objetos de espaço reservado, que são então substituídos dinamicamente em tempo de execução por malhas reais (carregadas em outros caminhos). Como se trata de 'apenas' json, é muito fácil introspectar e modificar em js e fazer esse tipo de coisas. Não tenho certeza, por exemplo, glTF (pelo menos em sua forma atual) é um bom ajuste como formato de cena, então espero que o exportador do blender e o formato json durem um pouco mais

@pjoe Eu espero que o formato JSON e o exportador do Blender sejam mais propensos a se manter no curto prazo do que outras coisas mencionadas neste tópico (por exemplo, exportadores 3DS Max + Maya).

Mesmo assim, seria bom receber seu feedback sobre o glTF e o exportador do

• configurar câmera
• hierarquia de cena
• animações (para várias ações do Blender, você precisará de um exportador diferente )
• propriedades personalizadas (selecione "Exportar extras" nas opções)
• "apenas JSON" para os materiais, metadados e assim por diante. Os dados de malha são otimizados como carga útil binária separada

@donmccurdy devo admitir que não tenho muita experiência com glTF (pelo menos ainda) - embora eu tenha tentado ler as especificações :)

Eu acho que minha principal 'carne' com glTF (que eu acho que é um ótimo formato de transporte e também ótimo para obter 'os bytes' tão rápida e diretamente quanto possível em buffers de GPU) é que todos os refs são baseados em índice, o que não é bom adequado para um formato de cena mutável. Então, se você, por exemplo, quiser deletar entradas ou adicionar coisas no meio, você precisa atualizar todas as referências para índices após aquele local. Fazer esse 'gerenciamento de índice' rapidamente torna-se bastante confuso.

Pelo breve tempo que passei com o liquidificador glTF exportador, também parecia bastante imaturo na época (cerca de dois meses atrás). Isso pode obviamente ser corrigido ajudando a melhorá-lo :)

... todas as referências são baseadas em índice, o que não é um bom ajuste para um formato de cena mutável. Então, se você, por exemplo, quiser deletar entradas ou adicionar coisas no meio, você precisa atualizar todas as referências para índices após aquele local.

Sim, ele não foi projetado para edições manuais nesse sentido e, como um formato de tempo de execução / transmissão, provavelmente nunca será. Existem várias bibliotecas para trabalhar com ele que podem ajudar.

Geralmente eu descobri que o exportador do Blender glTF dá melhores resultados do que qualquer outra saída do Blender, mas por favor, registre os bugs se você encontrou problemas específicos. :)

@donmccurdy concordou em manter o glTF fiel ao transporte / tempo de execução ... uma das melhores coisas sobre ele, é exatamente que ele não está tentando ser um formato adequado para todos (como collada - não me faça começar).

Estamos tentando evitar libs extras ou sobrecarga de conversão, pois estamos fazendo um aplicativo da web que precisa ser pequeno e rápido - e até agora o formato JSON three.js tem sido um bom ajuste como formato de cena para este caso de uso. Ser capaz de configurar toda a cena no blender, com animação de câmera, por exemplo, apenas exportar, carregar e em tempo de execução substituir dinamicamente os modelos (para o qual provavelmente acabaremos usando o glTF em algum momento em breve) - tudo isso contribui para um pipeline razoavelmente bom para nós :)

Como uma observação lateral, também usamos o webpack json loader para incluir o arquivo de cena em nosso pacote principal - torna ainda mais fácil de lidar.

Eu não acho que muito mudará em relação ao exportador Maya naquele tempo. Provavelmente deveríamos avaliar isso agora. Vou testá-lo e ver se vale a pena mantê-lo nos próximos dias.

@looeee estou curioso, você tem alguma notícia sobre isso 😊? Você acha que podemos remover o exportador agora e nos referir a FBX ?

Você acha que podemos remover o exportador agora e nos referir ao FBX?

Fiz apenas alguns testes, planejei fazer mais, mas não tive tempo. Mas eu diria que sim, devemos removê-lo e trabalhar para fazer o FBXLoader suportar totalmente o Maya.

Chimando como um usuário do exportador do Blender aqui: uma vantagem de ter o JSON é que ele é extremamente simples de modificar após a exportação. O Blender é apenas uma parte de nossa cadeia de ferramentas automatizada e fazemos muito processamento no JSON exportado, antes que ele esteja pronto para ir para nosso visualizador da web. Ter um formato de transferência tão próximo do formato interno threejs é um grande bônus para nós.

Além disso, fizemos alguns testes com outros formatos de exportação e descobrimos que o formato JSON não é tão ruim em termos de tamanho de transferência, uma vez decentemente compactado, muito melhor do que Collada ou FBX, por exemplo. Fizemos um teste rápido baseado em protobuffers e poderíamos diminuir um pouco assim, mas nada que valesse a pena para nós.

Para cenas grandes e clientes lentos, a velocidade de análise e conversão para o modelo interno ThreeJS também se torna importante. Como a análise JSON é altamente otimizada nos navegadores e como a estrutura do modelo é muito semelhante, presumimos que o formato JSON se sairia muito bem a esse respeito. Na verdade, não testei isso.

A Soft8Soft acaba de lançar o exportador baseado em glTF para o 3ds Max . Portanto, pode ser uma boa alternativa para o exportador JSON removido.

Obrigado @alexkowel , ótimo ver isso (e parabéns!). Se você pudesse adicionar um link neste tópico, nós o listaremos com outros recursos glTF. 🙂

@dherben pontos positivos, obrigado -

Sobre a velocidade de análise, espero que você descubra que o glTF é ainda mais rápido. A diferença essencialmente é que os metadados ainda são "apenas JSON", enquanto as grandes partes da carga útil (posições de vértice, dados de animação) estão em um fragmento ArrayBuffer que pode ser usado para criar uma matriz digitada para THREE.BufferAttribute construtores. Em um carregador totalmente otimizado (não sei se THREE.GLTFLoader já chegou), você nunca precisa ler ou copiar esses dados em JS.

Mas, para modificações nos dados como parte de um pipeline, concordo que é mais fácil trabalhar com JSON simples, como você disse. Existem bibliotecas em várias linguagens para trabalhar com glTF, mas as ferramentas ainda não estão muito maduras.

Status atual deste problema:

Exportadores:

• [X] exportador maia
• [X] Exportador 3DS Max
• [X] Exportador de liquidificador
  
  
  
  • não vai a lugar nenhum agora, pode revisitar no futuro.
  
  
  • Removido em maio de 2018.
  
  

Conversores:

• [] FBX
  
  
  
  • substituição simplificada proposta como https://github.com/mrdoob/three.js/pull/13013; precisa de teste
  
  
• [] CTM (não discutido)
• [] utf8 (não discutido)
• [] obj2três (não discutido)

EDIT: Atualizado em maio de 2018.

@donmccurdy Só queria voltar depois de experimentar mais com o exportador glTF Blender e o carregador Three.js. Acontece que ele está funcionando muito bem como formato de cena para nosso caso de uso até agora. O que estou fazendo agora é carregar o arquivo glTF exportado para uma cena Three.js e, em seguida, manipular a hierarquia de cenas Three.js (trocando marcadores de posição por coisas carregadas dinamicamente) antes de fazer a primeira renderização.

Provavelmente ainda existem alguns recursos que eu gostaria de ver no exportador glTF, tentarei comentar ou fazer PRs lá :)

Provavelmente ainda existem alguns recursos que eu gostaria de ver no exportador glTF, tentarei comentar ou fazer PRs lá :)

Incrível, por favor! 🙂

O exportador do Blender não vai a lugar nenhum agora, pode revisitar no futuro.

Então, alguém vai trabalhar nos bugs atuais do exportador do Blender? Espero que a resposta seja não. Nesse caso, devemos dizer isso.

Se ninguém o faz antes de mim ... Eu gostaria, pelo menos, de tentar resolver os problemas de rotação. # 13130

Então, alguém vai trabalhar nos bugs atuais do exportador do Blender? Espero que a resposta seja não.

Eu não li toda a discussão, mas meus dois centavos.

Na semana passada fui convidado para ajudar uma empresa que tem uma solução que usa Three.js na entrega de conteúdo em exposição permanente. Sinalizações com modelos 3D que os usuários podem explorar e interagir. Os desenvolvedores originais que se foram há muito tempo usaram o formato JSON Three.js . Preparar e obter novos modelos (com a condição de que alterar o código de tempo de execução é inútil) é um verdadeiro pesadelo.

IMHO Three.js deve se concentrar no suporte a formatos estabelecidos e também a formatos de crescimento rápido, como FBX e glTF . Prioridade nos formatos que podem conter vários depósitos de dados UV (portanto, o amado OBJ NÃO deve ser incentivado). Depois, animação. Eu sei que o complemento de exportação do Blender supostamente suporta os dois, mas o FBX também.

Imagine o fluxo de trabalho onde as coisas do Blender vão para

1) WebGL
Three.js obviamente 😃

2) OpenGL 3.3+
cru / cinza

3) OpenGL ES 2.0 em RISC
De smartphone para RaspberryPi

4) Motores de jogo

5) Aplicativos gráficos em tempo real integrados com servidores de mídia (hipopótamo, disfarce D3)
Aquelas VFX de palco que os caras usam.

Em vez de ter que usar muitos exportadores diferentes para resultados diferentes, o objetivo seria usar 1, no máximo 2 formatos. Ao escrever OGL nos 3 primeiros casos ... o mesmo formato de modelo deve ser usado, é isso. Nos dois últimos pontos, o FBX é o rei (diferentes implementações para COLLADA em todos os pacotes dificultam o trabalho) e aí, na verdade, o modelo não está "exposto".
Não estou criticando o formato JSON do Three.js ou o complemento do Blender ( @mrdoob 🙇 🙏), ele tem (tinha?) O seu uso e provavelmente foi inventado para resolver problemas que outros formatos não conseguiam no momento em primeiro lugar (e eu faço também têm síndrome NIHS).
Eu só quero compartilhar isso da perspectiva em que é preciso entregar constantemente para diferentes resultados dentro da indústria. O formato JSON Three.js não se encaixa no cenário, é supérfluo.

@kroko definitivamente concordo 👍

Acho que o panorama dos formatos está começando a ficar mais claro. O formato three.js json foi feito porque não havia formato json na época. Definir um formato de arquivo era a última coisa que eu queria fazer quando já estava fazendo um mecanismo de renderização e uma API 😩

Como um novato, o exportador JSON Three.js foi muito educacional porque me permitiu ver os dados brutos e a estrutura subjacente das geometrias de saída. Outros exportadores, por mais eficientes que sejam, não permitem que você veja os dados porque eles estão, em sua maioria, em formato binário.

Concordo que removê-lo deste repo seria a melhor opção hoje, mas como disse @hccampos , talvez ele pudesse ser colocado em seu próprio repo para permanecer para fins educacionais.

Concordo que removê-lo deste repo seria a melhor opção hoje, mas como disse @hccampos , talvez ele pudesse ser colocado em seu próprio repo para permanecer para fins educacionais.

Sempre haverá a opção de exportar como JSON de http://threejs.org/editor/

Fechado em https://github.com/mrdoob/three.js/pull/14117.

Sugiro que encerremos agora todos os problemas em aberto relacionados ao exportador do Blender. Acordado?

Acho que alguém pode escrever alguma documentação / pipeline "oficial" para a exportação / importação de modelos 3D (para recursos básicos e especiais), solucionar problemas comuns e eliminar ou atualizar todos os documentos e exemplos desatualizados. Por exemplo, o exemplo do knight é muito confuso, visto que você não tem mais um exportador de blender json. Talvez JSONLoader para modelos 3D deva ser mantido apenas para retrocompatibilidade, mas temos que ler isso, etc.

@stmaccarelli há alguma documentação nova aqui: https://threejs.org/docs/#manual/introduction/Carregando modelos -3D, mas sim, por favor nos diga o que mais seria útil!

@donmccurdy Acho que o papel é ruim.
No momento, todo o sistema de importação / animação 3D, dada a mistura de documentações, exemplos e coisas encontradas na internet de diferentes épocas, é confuso.

O documento mestre do Sistema de Animação estaria ok se as referências dos objetos individuais estivessem corretas.
Vejamos a referência do AnimationClip. Não tenho certeza se estou exportando morphTargets da maneira certa, mas li aqui:

_.CreateClipsFromMorphTargetSequences (name: String, morphTargetSequence: Array, fps: Number, noLoop: Boolean): Array
Retorna uma matriz de novos AnimationClips criados a partir das sequências de destino de metamorfose de uma geometria, tentando classificar nomes de destino de metamorfose em padrões baseados em grupos de animação como "Walk_001, Walk_002, Run_001, Run_002 ..." _

O problema é que se eu importar um arquivo glTF, não há array morphTargetSequence ... há alguns objetos morphTargetSomething armazenados aqui e ali, mas não sei o que e como usar.

Acho que devemos ter alguns documentos que descrevem o gerenciamento / fluxos de trabalho de modelos 3D com exemplos muito simples.
E as referências dos carregadores 3D devem respeitar o mesmo modelo.
Digamos
1- importação de modelo 3D simples
2- importação de material (s) (com todos os sinos e assobios como os diferentes mapas, parâmetros de mapas, gerenciamento multimaterial, etc)
3- importação de toda a cena (como atravessar / gerenciar cenas importadas como as do glTF)
4- importação e gerenciamento de animação (s) esquelética
5- importação e gerenciamento de animação (s) de metamorfose

Devemos também verificar se todos os exemplos que apresentam carregamento de modelo 3D, respeitam o mesmo padrão.

Devemos atualizar os exemplos e, embora não seja possível, devemos escrever claramente que algumas partes estão obsoletas e o que (como no exemplo do cavaleiro ...)

_EG- se decidirmos que o formato de arquivo JSON para o modelo 3D deve ser descontinuado, em favor de - digamos - glTF, não faz sentido que o único exemplo de animação que apresenta animação esquelética e morphtargets seja o antigo cavaleiro, que usa um Modelo JSON de 10 versões atrás, que armazena uma estrutura de dados que não é mais usada._

@stmaccarelli Não há um único fluxo de trabalho de ponta a ponta recomendado; Acho que seria difícil fornecer isso, dados os diferentes níveis de habilidade, preferências por ferramentas de modelagem gratuitas e pagas e necessidades específicas.

Não acho que você normalmente precise desse método CreateClipsFromMorphTargetSequences . O documento acima não entra em detalhes sobre o uso de qualquer carregador em particular (como você mencionou, eles são inconsistentes), mas os documentos do

loader.load('foo.glb', function(gltf) {
  const clips = gltf.clips;  // Array<THREE.AnimationClip>
  const model = gltf.scene; // THREE.Scene
  ...
});

Nesse caso, não importa se os clipes são alvos TRS, skin ou metamorfose - você pode reproduzir todas as animações da mesma forma. Eu escrevi um fluxo de trabalho possível usando Mixamo e Blender . Aqui está outro usando o Maya .

Devemos também verificar se todos os exemplos que apresentam carregamento de modelo 3D, respeitam o mesmo padrão.

E as referências dos carregadores 3D devem respeitar o mesmo modelo.

Este é um ponto justo e temos espaço para melhorar aqui.

não faz sentido que o único exemplo de animação que apresenta animação esquelética e morphtargets seja o antigo knight, que usa um modelo JSON de 10 versões atrás, que armazena uma estrutura de dados que não é mais usada.

Estritamente falando, o formato JSON e a estrutura de dados não foram descontinuados e ainda é uma maneira totalmente razoável de [des] serializar uma cena, mas ponto final. @mrdoob o que você acha sobre a nossa substituição de alguns dos exemplos de animação? Tal como:

animation / keyframes / json
animation / scene
animation / skinning / blending
animation / skinning / morph

o que você acha de substituir alguns dos exemplos de animação?

1 para isso. Eu voto para substituir pelo menos o soldado de animation / skinning / blending a por um modelo mais moderno da Mixamo, como este:

Poderíamos mesclar entre inatividade / caminhada / corrida e provavelmente seria possível converter o modelo para glTF, se preferir.

O tamanho do modelo seria de cerca de 9 MB, enquanto o modelo atual, juntamente com todos os arquivos associados, é de 71 MB !!

Por animation / skinning / morph , poderíamos usar o modelo com o qual venho testando os alvos de metamorfose FBX:

É quase do mesmo tamanho que o modelo de cavaleiro atual, mas como os alvos de metamorfose são mais comumente usados ​​para expressões faciais, eu diria que este faz mais sentido. Novamente, ele está atualmente no formato FBX, mas pode ser convertido para glTF se preferir.

Aqui estão alguns exemplos a serem considerados:

| captura de tela | link | tamanho |
| --- | --- | - |
| | link | 6 MB |
| | link | 3 MB |
| | link | 5 MB |
| | link | 12 MB |

Eles são todos animados, funcionam corretamente em three.js e provavelmente poderiam ser compactados ou otimizados um pouco mais do que a versão de download do Sketchfab. Eu não tenho um personagem manipulado com bons ciclos de corrida / caminhada, mas o fluxo de trabalho Mixamo-> glTF não é tão ruim.