Lista muito extensa!
Também proponho o carregador AMF (http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format).
(formato de arquivo 3D usado para impressão 3D).
Eu já tenho o básico do loader feito, então poderia modificá-lo um pouco e adicionar aos exemplos.

A maioria desses carregadores é mais importante para casos especiais, como um editor, porque para, digamos, jogos, pode ser melhor converter para o formato three.js imediatamente, certo? Nestes casos, os conversores/exportadores são mais importantes.

Testamos o glTF como um substituto para os formatos de três como uma otimização - lá os dados são binários e podem ser compactados com compactação geom.

Herst [email protected] kirjoitti 28 de outubro de 2014 kello 17:38:

A maioria desses carregadores é mais importante para casos especiais, como um editor, porque para, digamos, jogos, pode ser melhor converter para o formato three.js imediatamente, certo? Nestes casos, os conversores/exportadores são mais importantes.

—
Responda a este e-mail diretamente ou visualize-o no GitHub.

@kaosat-dev Adicionado à lista!
@Herst Sim. É principalmente para editores ou aplicativos que não exigem tempos de carregamento rápidos.

Também estou procurando um carregador IGES. Eu até começaria a construir um eu mesmo, mas não tenho certeza por onde começar.

que tal adicionar 3DM (usado por Rhinoceros ) à lista?

@nyaao adicionado. obrigado!

Sobre o 3DS Loader:

Olá a todos, há muito tempo atrás eu precisava fazer um loader 3DS para o motor 3DzzD Web 3D, que era um pouco difícil de fazer... Consegui produzir um carregador bastante eficiente. as especificações de formato de arquivo 3DS são difíceis de encontrar, mas acabei encontrando uma que funcionou muito bem. Eu construí o loader para 3DzzD com esta documentação e ele funciona ainda melhor do que o do photoshop atual (melhor manuseio em pivô/grupos suaves/escala/quadro-chave/etc...), então aqui estão as especificações que usei (O código-fonte 3DzzD é opensource e pode ajudar, mas o código é muito feio... um projeto de dez anos...)

http://dzzd.net/3DSchunkDefinitions.html

Sobre o OBJ Loader:

Modifiquei o OBJ loader atual e consigo pelo menos 10/15 FPS a mais em muitos modelos 3d, mas por enquanto não encontrei como devo fazer para postar essas mudanças ?

O problema deveu-se principalmente ao fato do atual OBJ loader criar muitos objetos (mais do que o modelo 3d original, um objeto criado a cada troca de material) e também o 3dFaces com mesmo material não ser agrupado mesmo dentro do mesmo objeto, e estava produzindo muitas chamadas WebGL

http://dzzd.net/3DSchunkDefinitions.html

Obrigado! Adicionado ao primeiro post.

O problema deveu-se principalmente ao fato do atual OBJ loader criar muitos objetos (mais do que o modelo 3d original, um objeto criado a cada troca de material) e também o 3dFaces com mesmo material não ser agrupado mesmo dentro do mesmo objeto, e estava produzindo muitas chamadas WebGL

Oh! Interessante. Você quer dizer o OBJMTLLoader um embora. Direito?

Oh! Interessante. Você quer dizer o OBJMTLLoader. Direito?

Sim, para ser mais preciso o bloco "if ( /^usemtl /.test( line ) ) " cria um novo objeto/malha para cada troca de material, isso acaba com um desempenho ruim e uma hierarquia de objetos errada.

Vou postar um caso de teste simples mostrando a diferença entre o carregador atual e o modificado (a diferença é perceptível principalmente no dispositivo móvel)

Aqui está o caso de teste para o carregador atual e o otimizado:

http://demo.dzzd.fr/threejs/OBJMTLLLoaderTest/

EDITAR:
Consegui 10 FPS no GalaxyTab3 com o carregador atual e mais de 60 FPS com o novo, a diferença pode ser difícil de ver em dispositivos rápidos

PS: Se você quer saber de onde vem o modelo 3D :)

Alguém conhece o IGES? Eu realmente poderia usar um carregador IGES. Se alguém pudesse apenas me apontar em uma direção para começar a construir um? Ou se houver um por aí em algum lugar. Percebi que o pessoal em http://www.3dfile.io/ e alguns dos outros sites de visualização 3D estão usando ThreeJS e permitindo uploads IGES.

K3D.js (licença MIT) tem um analisador para OBJ, 3DS, MD2 e Collada. http://k3d.ivank.net. Consulte #3843.

que tal NIfTI para médico?

@jugl Você tem alguma informação sobre o formato?

Eu realmente espero pelos modelos .m2, é uma comunidade enorme ao redor. Eu ofereceria minha ajuda com arquivos de modelo etc. você pode entrar em contato comigo para esse caso no skype: deexone . Como dica de um desenvolvedor de lib http://bridge.net/ pode ser usado para transformar sua lib em js.

Ei, eu tenho um carregador BVH que analisa um arquivo BVH e gera um THREE.Skeleton e AnimationClip para facilitar o uso com o Mixer:
https://github.com/herzig/BVHImporter
e o exemplo de trabalho: http://herzig.github.io/BVHImporter/
É testado principalmente nos arquivos CMU BVH e alguns outros.

Existem diretrizes sobre como a API do carregador deve ser?

@herzig Doce! Um BVHLoader seria incrível! Os carregadores basicamente têm .load() e .parse() . Você pode usar o MD2Loader como referência, mas eu ficaria feliz em limpar seu código se você fizer um PR com o que você tem agora (um exemplo + animação de amostra também seria muito apreciado).

Olá,
apenas para sincronizar esta lista com o carregador de arquivos no repositório ...

3MFLoader está faltando na lista, mas já implementado.
BinaryLoader está faltando na lista, mas já implementado.
DDSLoader está faltando na lista, mas já implementado.
O FBXLoader está desmarcado, mas já implementado.
HDRCubeTextureLoader está faltando na lista, mas já implementado.
O MD2Loader está desmarcado, mas já implementado.
NRRDLoader está desmarcado, mas já implementado.
PCDLLoader está faltando na lista, mas já implementado.
PlayCanvasLoader está faltando na lista, mas já implementado.
RGBLLoader está faltando na lista, mas já implementado.
O SVGLoader está desmarcado, mas já implementado.
TGALoader está faltando na lista, mas já implementado.
TTFLoader está faltando na lista, mas já implementado.

Next:

O ASCLoader deve ser adicionado à lista e o PR será enviado em poucos dias.
O LASLoader deve ser adicionado à lista e o PR será enviado em poucos dias.
O XYZLoader deve ser adicionado à lista e o PR será enviado em poucos dias.

Atenciosamente,
Tristão

apenas para sincronizar esta lista com o carregador de arquivos no repositório ...

Atualizada!

O OpenCTM pode ser uma boa adição, já que a Autodesk o está usando para seus
serviço na nuvem
https://en.m.wikipedia.org/wiki/OpenCTM

Em domingo, 13 de novembro de 2016 às 6h33 Mr.doob [email protected] escreveu:

apenas para sincronizar esta lista com o carregador de arquivos no repositório ...

Atualizada!

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/mrdoob/three.js/issues/5524#issuecomment -260168120,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AAkmxkkOn179ZJvqc8yScOoxnaDGzuH6ks5q9qE6gaJpZM4CzpFw
.

@dlabz Já temos CTMLoader .

Estou trabalhando com alguns desenvolvedores iOS no espaço AR, pode haver um carregador para os arquivos SCN binários usados ​​pela Apple no ARKit? Estou trabalhando para fazer uso do BinaryLoader e vamos ver se consigo fazer isso funcionar.

Existe uma especificação em algum lugar para esse formato SCN ?

@mrdoob Desculpe o atraso. NIfTI é um formato de dados NMR que foi transferido do DICOM. Minha solução atual é obter uma forma 3D dele como formato VTK/OBJ.

Eu vejo. Existe alguma especificação em algum lugar?

Como sobre o carregador IFC. Este formato está usando muito comum na construção para seu modelo 3d

@YouYue123 https://github.com/mrdoob/three.js/issues/9764

@mrdoob Muito obrigado.

@mrdoob quais são as diretrizes + pré-requisitos de conhecimento para construir um carregador three.js?
Eu quero construir um, mas quero ter certeza de fazê-lo da maneira certa. Obrigado

@Aarbel para qual formato você deseja construir um carregador?

@looeee arquivos .ifc

A estrutura básica do seu carregador ficaria assim:

import {
    FileLoader,
    Loader,
    LoaderUtils
} from '../../../build/three.module.js';

function IFCLoader( manager ) {

    Loader.call( this, manager );

}

IFCLoader.prototype = Object.assign( Object.create( Loader.prototype ), {

    constructor: IFCLoader,

    load: function ( url, onLoad, onProgress, onError ) {

        var scope = this;

        var path = ( this.path !== undefined ) ? this.path : LoaderUtils.extractUrlBase( url );

        var loader = new FileLoader( scope.manager );

        loader.load( url, function ( text ) {

            try {

                scope.parse( text, path, onLoad, onError );

            } catch ( e ) {

                if ( onError !== undefined ) {

                    onError( e );

                } else {

                    throw e;

                }

            }

        }, onProgress, onError );

    },

    parse: function ( text, path, onLoad, onError ) {

        // parsing logic goes here

    }

} );

obrigado, vou trabalhar no próximo mês

Boa sorte! 😊

O padrão crossOrigin deve ser Anonymous ?

Eu reutilizei o padrão de GLTFLoader e ColladaLoader .

Eu gostaria de ver um carregador LWO.
A especificação do arquivo está bem documentada aqui: http://static.lightwave3d.com/sdk/2018/html/filefmts/lwo3.html

Costumo ver o tamanho do arquivo LWO em torno de 1/10 do OBJ, e o formato pode conter dados de transformação e vários outros recursos que o OBJ não permite. Além disso, muitos dos modelos que a NASA disponibiliza estão apenas no formato LWO https://nasa3d.arc.nasa.gov/search/lwo/model

Se eu soubesse o que estava fazendo, tentaria fazer isso acontecer, mas escrever um loader está além de qualquer coisa que eu tenha feito antes.

FWIW existe um analisador LWO aqui: https://github.com/marcbizal/lwo-parser ... hipoteticamente, isso seria um bom começo para um carregador ou conversor, mas infelizmente não parece suportar a versão específica do formato LWO que a NASA está usando. Ele espera LWOB (binário?) mas a string da versão mágica no modelo da NASA que tentei foi LWO2. Se você encontrar um analisador funcional escrito em alguma linguagem diferente de JS, pode ser mais fácil escrever um conversor para algo que o three.js suporte, em vez de tentar escrever um novo analisador em JS.

Oi, minha agenda mudou muito, então não há tempo para trabalhar no carregador .ifc para three.js. Pode ser ótimo buscar o contato desse cara: https://github.com/mrdoob/three.js/issues/9764

me desculpe não percebi

Eu estava fazendo um carregador de "LWO 2". No entanto, achei que não havia demanda e não a completei.

http://adrs2002.com/sandbox/lwoLoader/lwoTest.html
https://github.com/adrs2002/threeLwoLoader

Espero que seja útil para algo.

Olá pessoal,

Eu vi que o M2 está na lista.

Isso é interessante para mim porque eu gostaria de realizar um personagem, objeto, NPC e visualizador de itens com três.

Em conexão com o M2 é sinônimo de BLP2 (Blizzard Picture File) semelhante ao DDS S3 Texture Compression usado.

Encontrei até agora:

.m2 = https://github.com/vjeux/jsWoWModelViewer

.blp

• https://wowdev.wiki/BLP
• http://wowwiki.wikia.com/wiki/BLP_file
• https://github.com/Kruithne/js-blp
• https://en.wikipedia.org/wiki/S3_Texture_Compression

Eu mesmo tento adicioná-lo, mas ainda sou um pouco inexperiente com o todo :D

@adrs2002 Um LWOLoader seria ótimo! Você gostaria de fazer um PR com o que você tem?

Eu mesmo tento adicioná-lo, mas ainda sou um pouco inexperiente com o todo :D

Tome seu tempo 👌

Um LWOLoader seria ótimo!

Eu escrevi um carregador LWO3 alguns meses atrás, trabalhando para onthez.com.
Concordamos em um período de exclusividade, então vamos contribuir aqui. Espero que em algum momento por volta do final de fevereiro.

Acho que @jds580s é o Justin do z, talvez ele possa dar uma ideia melhor de quando podemos adicioná-lo aqui.

@mrdoob @looeee
Eu acho que o commit de LWO2 loader é desnecessário se o LWO3 loader do looeee for confirmado.
O formato LWO3 é porque contém todos os sucessos do formato LWO2.

LWOLoader chegou! 😁

16011

Alguma atualização no carregador IFC? Seria bom para vistas de construção!

Eu dei uma chance para um IFCLoader e como dizer... Isso é impossível! Todo o código necessário para analisar corretamente o formato IFC é de cerca de 650 arquivos de classe. (Eu sei porque eu fiz isso). O carregador será 5 vezes maior que a biblioteca Threejs.

Sobre a especificação se você quiser implementar a sua própria: http://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/

Eu poderia liberar meu código, e alguma ajuda sobre isso seria legal. Mas não espere ver este carregador em ThreeJs antes de um tempo...

Eu poderia liberar meu código, e alguma ajuda sobre isso seria legal. Mas não espere ver este carregador em ThreeJs antes de um tempo...

Por que não?

BTW: Falei recentemente com um colega e ele me disse que o IFC é baseado no formato STEP que é bem conhecido na comunidade CAD. Em geral, STEP é muito difícil de analisar e você precisaria escrever um analisador personalizado semelhante a VRMLLoader . No entanto, os arquivos IFC também podem ser expressos em XML (eles têm a extensão .ifcxml ). Esses arquivos seriam muito mais fáceis de manusear (veja 3MFLoader ou ColladaLoader ) para que o carregador pudesse se concentrar na construção de dados de geometria real. Talvez seja mais fácil criar um carregador que suporte apenas .ifcxml no início?

@mrdoob , @Mugen87

Por que não?

Porque

O carregador será 5 vezes maior que a biblioteca Threejs.

e eu uso Class com os recursos de javascript mais recentes.

O IFC é baseado no formato STEP que é bem conhecido na comunidade CAD.

Sim, um dia mostro-vos o que estou a fazer com o Threejs ;)

Os arquivos IFC também podem ser expressos em XML (eles têm a extensão .ifcxml).
...
Talvez seja mais fácil criar um carregador que suporte apenas .ifcxml no início?

A análise claramente não é um grande problema. Mas a geração das geometrias é ! Porque o formato ifc não contém nenhuma geometria. Mas use interpolação/interação entre objetos para determinar a geometria final.

De qualquer forma, se você quiser, talvez você deva criar um branch específico para isso antes de tomar qualquer decisão. Só para ver o GRANDE.

O carregador será 5 vezes maior que a biblioteca Threejs.

Bem, sim, se o loader não for tão compacto quanto os outros, provavelmente é melhor colocar o código em um repositório separado.

@Itee Algum plano para lançar o IFCLOADER em breve?
Estaria interessado em ver a coisa GRANDE

Não tenho conhecimento de alguém disposto a contribuir e mantê-lo...

Estou usando o conversor IFC do IfcOpenShell felizmente, ele faz boa geometria e materiais, pode fazer Collada DAE (que usamos para importar para o Unity), IIRC OBJ e estava lá glTF hoje em dia também

Estou usando o conversor IFC do IfcOpenShell felizmente, ele faz boa geometria e materiais, pode fazer Collada DAE (que usamos para importar para o Unity), IIRC OBJ e estava lá glTF hoje em dia também

Mas você usa algum dos dados IFC como Buildingstorey, Site, etc?
Não há dúvida de que a web seria melhor capaz de analisar IFC e não essa merda de cliente-servidor com a qual todos estão lidando.

Eu dei uma chance a isso recentemente. Eu consegui gerar alguma geometria

Mas na verdade deveria ser isso:

A coisa básica que deu errado é o posicionamento real e rotação aqui e minha matemática 3D é quase inexistente (eu simplesmente não tenho paciência).

Embora existam muitas classes no esquema IFC. O tamanho do arquivo eventual pode ser reduzido usando interfaces Typescript e funções para pesquisar e aplicar os argumentos de cada 'STEP' no arquivo.

Bottomline, para um carregador IFC; Não sei se temos um gênio da matemática 3D, porque isso resolveria muitos problemas ao analisar as relações matemáticas enquanto construímos a geometria.

Mas você usa algum dos dados IFC como Buildingstorey, Site, etc?

Sim, através do serviço de conversão do Tridify, que também usa o IfcOpenShell (também o usei localmente) para o geom. Acho que esses metadados são fáceis de analisar.

A geração de geometria é de fato não trivial. Se você quiser fazer isso no navegador, talvez você possa compilar o IfcOpenShell para o WebAssembly e usá-lo como uma biblioteca do seu Javascript. É simples C++ sem GUI ou qualquer coisa, apenas uma biblioteca para a qual existe uma interface de linha de comando separadamente, então pode ser fácil construir para a web também. A análise de IFCs é meio pesada, portanto, obter o desempenho do WASM e o baixo consumo de memória pode ser bom. E a lib faz um belo trabalho na criação do geom.

@MaartenBreeedveld eu posso ajudar com a matemática, para a base teórica não tenho dúvidas e tenho alguma experiência com ifc, de fato pode haver várias transformações em série necessárias para as coordenadas do mundo. Para a implementação em three.js talvez seja possível otimizá-lo.

Mas você usa algum dos dados IFC como Buildingstorey, Site, etc?

Sim, através do serviço de conversão do Tridify, que também usa o IfcOpenShell (também o usei localmente) para o geom. Acho que esses metadados são fáceis de analisar.

A geração de geometria é de fato não trivial. Se você quiser fazer isso no navegador, talvez você possa compilar o IfcOpenShell para o WebAssembly e usá-lo como uma biblioteca do seu Javascript. É simples C++ sem GUI ou qualquer coisa, apenas uma biblioteca para a qual existe uma interface de linha de comando separadamente, então pode ser fácil construir para a web também. A análise de IFCs é meio pesada, portanto, obter o desempenho do WASM e o baixo consumo de memória pode ser bom. E a lib faz um belo trabalho na criação do geom.

Já tentamos isso no passado. Mas a versão compilada do WASM é um download de 40 MB, acho que isso se deve a todas as bibliotecas referenciadas no ifcConvert.

@Jesusbill , Incrível! Atualmente, não tenho tempo para trabalhar neste projeto. Mas se estiver tudo bem, eu volto para você.

Impressionante! Atualmente, não tenho tempo para trabalhar neste projeto. Mas se estiver tudo bem, eu volto para você.

Parece bom @MaartenBeeedveld

Adicionado VDBLoader à lista. https://www.openvdb.org/

Alguma ideia sobre o IFCLOADER? @mrdoob

não

Em relação a um carregador 3dm: comecei a trabalhar nisso agora que a biblioteca openNURBS foi compilada para wasm graças ao emscripten ( rhino3dm ).

Estou trabalhando nisso aqui e tenho suporte de malha, breps, extrusões, nuvens de pontos, materiais, camadas e grupos iniciados e funcionando.

Arquivos Relevantes:

• carregador
• biblioteca
• exemplo html
• arquivo de exemplo

Espero enviar um PR que tenha suporte para mais tipos de objeto em breve _em breve. Devo admitir que tenho pouca experiência com web workers, e estou me apoiando nos exemplos do draco e do carregador de base . Espero que #18234 simplifique um pouco isso.

ps já estamos adicionando suporte a threejs diretamente à biblioteca rhino3dm.js como aqui e aqui .

Editar: links de atualização para apontar para a bifurcação da organização McNeel.

Podemos verificar isso ;)