Liste très complète !
Je propose également le chargeur AMF (http://en.wikipedia.org/wiki/Additive_Manufacturing_File_Format).
(format de fichier 3d utilisé pour l'impression 3d).
J'ai déjà fait les bases du chargeur, je pourrais donc le modifier un peu et ajouter des exemples.

La plupart de ces chargeurs sont plus importants pour des cas particuliers tels qu'un éditeur, car pour des jeux, par exemple, il serait peut-être préférable de convertir immédiatement au format three.js, n'est-ce pas ? Dans ces cas, les convertisseurs/exportateurs sont plus importants.

Nous avons testé glTF en remplacement des trois formats à titre d'optimisation - là, les données sont binaires et peuvent être compressées avec la compression geom.

Herst [email protected] kirjoitti 28 octobre 2014 kello 17h38 :

La plupart de ces chargeurs sont plus importants pour des cas particuliers tels qu'un éditeur, car pour des jeux, par exemple, il serait peut-être préférable de convertir immédiatement au format three.js, n'est-ce pas ? Dans ces cas, les convertisseurs/exportateurs sont plus importants.

—
Répondez directement à cet e-mail ou consultez-le sur GitHub.

@kaosat-dev Ajouté à la liste !
@ Herst Oui. C'est principalement pour les éditeurs ou les applications qui ne nécessitent pas de temps de chargement rapides.

Je recherche également un chargeur IGES. Je commencerais peut-être même à en construire un moi-même, mais je ne sais pas par où commencer.

que diriez-vous d'ajouter 3DM (utilisé par Rhinoceros ) à la liste ?

@nyaaao ajouté. Merci!

À propos de 3DS Loader :

Salut tout le monde, il y a longtemps, j'avais besoin de faire un chargeur 3DS pour le moteur 3D Web 3DzzD, c'était un peu difficile à faire... pas difficile d'obtenir des premiers résultats mais plutôt de gérer correctement tous les morceaux, mais après un certain temps J'ai réussi à produire un chargeur assez efficace. les spécifications du format de fichier 3DS sont difficiles à trouver, mais j'ai fini par en trouver une qui fonctionnait plutôt bien. J'ai construit le chargeur pour 3DzzD avec cette documentation et il fonctionne encore mieux que celui du photoshop actuel (meilleure gestion des pivots/groupes lisses/échelle/keyframe/etc...), voici donc les spécifications que j'ai utilisées (Le code source de 3DzzD est open source et peut aider mais le code est vraiment moche... un projet vieux de dix ans...)

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

À propos du chargeur OBJ :

J'ai modifié le loader OBJ actuel et j'obtiens environ au moins 10/15 FPS de plus sur pas mal de modèles 3d, mais pour l'instant je n'ai pas trouvé comment je dois faire pour poster ces changements ?

Le problème était principalement dû au fait que le chargeur OBJ actuel créait trop d'objets (plus que le modèle 3d d'origine, un objet créé à chaque changement de matériau) et que les 3dFaces avec le même matériau n'étaient pas regroupées même au sein du même objet, et produisait trop d'appels WebGL

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

Merci! Ajouté au premier message.

Le problème était principalement dû au fait que le chargeur OBJ actuel créait trop d'objets (plus que le modèle 3d d'origine, un objet créé à chaque changement de matériau) et que les 3dFaces avec le même matériau n'étaient pas regroupées même au sein du même objet, et produisait trop d'appels WebGL

Oh! Intéressant. Vous voulez dire le OBJMTLLoader cependant. À droite?

Oh! Intéressant. Vous voulez dire celui d'OBJMTLLoader. À droite?

Oui, pour être plus précis, le bloc "if ( /^usemtl /.test( line ) ) " crée un nouvel objet/maillage pour chaque changement de matériau, cela se termine par de mauvaises performances et une mauvaise hiérarchie des objets.

Je publierai un cas de test simple montrant la différence entre le chargeur actuel et celui modifié (la différence est principalement perceptible sur l'appareil mobile)

Voici le cas de test pour le loader actuel et celui optimisé :

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

ÉDITER:
J'ai obtenu 10 FPS sur GalaxyTab3 avec le chargeur actuel et plus de 60 FPS avec le nouveau, la différence peut être difficile à voir sur les appareils rapides

PS : Si vous vous demandez d'où vient le modèle 3D :)

Est-ce que quelqu'un connaît IGES. Je pourrais vraiment utiliser un chargeur IGES. Si quelqu'un pouvait simplement m'indiquer une direction pour commencer à en construire un? Ou s'il y en a un quelque part. J'ai remarqué que les gens de http://www.3dfile.io/ et certains des autres sites de visualisation 3D utilisent ThreeJS et autorisent les téléchargements IGES.

K3D.js (licence MIT) a un analyseur pour OBJ, 3DS, MD2 et Collada. http://k3d.ivank.net. Voir #3843.

qu'en est-il du NIfTI pour le médecin ?

@jugl Avez-vous des informations sur le format ?

J'espère vraiment pour les modèles .m2, c'est une énorme communauté autour. Je proposerais mon aide avec les fichiers modèles etc. vous pouvez me contacter pour ce cas sur skype : deexone . Comme indice d'un développeur de lib http://bridge.net/ pourrait peut-être être utilisé pour transformer sa lib en js.

Hé, j'ai un chargeur BVH qui analyse un fichier BVH et produit un THREE.Skeleton et AnimationClip pour une utilisation facile avec le Mixer :
https://github.com/herzig/BVHImporter
et l'exemple de travail : http://herzig.github.io/BVHImporter/
Il est principalement testé sur les fichiers CMU BVH et quelques autres.

Existe-t-il des directives sur la façon dont l'API du chargeur devrait ressembler ?

@herzig Doux ! Un BVHLoader serait génial ! Les chargeurs ont essentiellement un .load() et .parse() . Vous pouvez utiliser MD2Loader comme référence, mais je serais heureux de nettoyer votre code si vous faites un PR avec ce que vous avez maintenant (un exemple + un exemple d'animation serait également très apprécié).

Salut,
juste pour synchroniser cette liste avec le chargeur de fichiers dans le référentiel ...

3MFLoader est absent de la liste mais déjà implémenté.
BinaryLoader est absent de la liste mais déjà implémenté.
DDSLoader est absent de la liste mais déjà implémenté.
FBXLoader est décoché mais déjà implémenté.
HDRCubeTextureLoader est absent de la liste mais déjà implémenté.
MD2Loader est décoché mais déjà implémenté.
NRRDLoader est décoché mais déjà implémenté.
PCDLLoader est absent de la liste mais déjà implémenté.
PlayCanvasLoader est absent de la liste mais déjà implémenté.
RGBLLoader est absent de la liste mais déjà implémenté.
SVGLoader est décoché mais déjà implémenté.
TGALoader est absent de la liste mais déjà implémenté.
TTFLoader est absent de la liste mais déjà implémenté.

suivant:

ASCLoader devrait être ajouté à la liste, et le PR sera envoyé dans quelques jours.
LASLoader devrait être ajouté à la liste, et le PR sera envoyé dans quelques jours.
XYZLoader devrait être ajouté à la liste, et PR sera envoyé dans quelques jours.

Meilleures salutations,
Tristan

juste pour synchroniser cette liste avec le chargeur de fichiers dans le référentiel ...

Mis à jour!

OpenCTM pourrait être un bon ajout, car Autodesk l'utilise pour leur
service cloud
https://en.m.wikipedia.org/wiki/OpenCTM

Le dimanche 13 novembre 2016 à 6h33, Mr.doob [email protected] a écrit :

juste pour synchroniser cette liste avec le chargeur de fichiers dans le référentiel ...

Mis à jour!

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/mrdoob/three.js/issues/5524#issuecomment -260168120,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAkmxkkOn179ZJvqc8yScOoxnaDGzuH6ks5q9qE6gaJpZM4CzpFw
.

@dlabz Nous avons déjà un CTMLoader .

Je travaille avec des développeurs iOS dans l'espace AR, pourrait-il y avoir un chargeur pour les fichiers SCN binaires utilisés par Apple dans ARKit ? Je travaille sur l'utilisation du BinaryLoader et nous verrons si je peux le faire fonctionner.

Existe-t-il une spécification quelque part pour ce format SCN ?

@mrdoob Désolé, je suis si en retard. NIfTI est un format de données RMN transféré depuis DICOM. Ma solution actuelle consiste à obtenir une forme 3D au format VTK/OBJ.

Je vois. Y a-t-il une spécification quelque part ?

Que diriez-vous du chargeur IFC. Ce format est très courant en construction pour son modèle 3d

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

@mrdoob Merci beaucoup.

@mrdoob quelles sont les directives + les connaissances préalables pour créer un chargeur three.js ?
Je veux en construire un, mais il veut être sûr de le faire dans le bon sens. Merci

@Aarbel pour quel format voulez-vous créer un chargeur ?

@looeee fichiers .ifc

La structure de base de votre chargeur ressemblerait à ceci :

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

    }

} );

merci, j'y travaillerai le mois prochain

Bonne chance! 😊

La valeur par défaut crossOrigin devrait-elle être Anonymous ?

J'ai réutilisé le modèle de GLTFLoader et ColladaLoader .

Je voudrais voir un chargeur LWO.
La spécification de fichier est bien documentée ici : http://static.lightwave3d.com/sdk/2018/html/filefmts/lwo3.html

Je vois souvent une taille de fichier LWO d'environ 1/10 de celle d'OBJ, et le format peut contenir des données de morphing et un certain nombre d'autres fonctionnalités qu'OBJ ne permettra pas. De plus, de nombreux modèles mis à disposition par la NASA sont uniquement au format LWO https://nasa3d.arc.nasa.gov/search/lwo/model

Si je savais ce que je faisais, j'essaierais de faire avancer les choses, mais écrire un chargeur dépasse tout ce que j'ai fait auparavant.

FWIW il y a un analyseur LWO ici : https://github.com/marcbizal/lwo-parser ... hypothétiquement, ce serait un bon début pour un chargeur ou un convertisseur, mais malheureusement, il ne semble pas prendre en charge la version particulière du format LWO utilisé par la NASA. Il attend LWOB (binaire?) Mais la chaîne de version magique sur le modèle de la NASA que j'ai essayé était LWO2. Si vous trouvez un analyseur de travail écrit dans un langage autre que JS, il peut être plus facile d'écrire un convertisseur vers quelque chose que three.js prend en charge, plutôt que d'essayer d'écrire un nouvel analyseur en JS.

Salut, mon emploi du temps a beaucoup changé donc pas le temps de travailler sur .ifc loader pour three.js. Pourrait être génial d'aller chercher le contact de ce gars : https://github.com/mrdoob/three.js/issues/9764

Je suis désolé je n'avais pas réalisé

Je faisais un chargeur de "LWO 2". Cependant, je pensais qu'il n'y avait pas de demande et je ne l'ai pas complété.

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

J'espère que cela sera utile pour quelque chose.

Bonjour tous le monde,

J'ai vu que M2 est dans la liste.

C'est intéressant pour moi car j'aimerais réaliser une visionneuse de personnages, d'objets, de PNJ et d'objets avec Three.

En relation avec M2, on utilise également BLP2 (Blizzard Picture File) similaire à DDS S3 Texture Compression.

J'ai trouvé pour l'instant :

.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

J'essaie moi-même de l'ajouter, mais je suis encore un peu trop novice avec l'ensemble :D

@adrs2002 Un LWOLoader serait super ! Aimeriez-vous faire un PR avec ce que vous avez ?

J'essaie moi-même de l'ajouter, mais je suis encore un peu trop novice avec l'ensemble :D

Prenez votre temps 👌

Un LWOLoader serait super !

J'ai écrit un chargeur LWO3 il y a quelques mois, travaillant pour onthez.com.
Nous nous sommes mis d'accord sur une période d'exclusivité puis nous l'apporterons ici. Espérons que vers la fin février.

Je pense que @ jds580s est Justin depuis le z, peut-être qu'il peut donner une meilleure idée du moment où nous pouvons l'ajouter ici.

@mrdoob @looeee
Je pense que le commit de LWO2 loader n'est pas nécessaire si le LWO3 loader de looeee sera commité.
Le format LWO3 est dû au fait qu'il contient tous les succès du format LWO2.

LWOLoader est arrivé ! 😁

16011

Une mise à jour sur le chargeur IFC ? Ce serait bien pour les vues de la construction!

J'ai essayé un IFCLoader et comment dire... C'est impossible ! L'ensemble du code requis pour pouvoir analyser correctement le format IFC est d'environ 650 fichiers de classe. (Je le sais parce que je l'ai fait). Le chargeur sera 5 fois plus gros que la bibliothèque Threejs.

À propos des spécifications si vous souhaitez implémenter les vôtres : http://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/

Je pourrais publier mon code, et un peu d'aide serait cool. Mais n'espérez pas voir ce loader dans ThreeJs avant un moment...

Je pourrais publier mon code, et un peu d'aide serait cool. Mais n'espérez pas voir ce loader dans ThreeJs avant un moment...

Pourquoi pas?

BTW : J'ai récemment parlé avec un collègue et il m'a dit que l'IFC est basé sur le format STEP qui est bien connu dans la communauté CAO. En général, STEP est très difficile à analyser et vous auriez besoin d'écrire un analyseur personnalisé similaire à VRMLLoader . Cependant, les fichiers IFC peuvent également être exprimés en XML (ils ont l'extension .ifcxml ). De tels fichiers seraient beaucoup plus faciles à gérer (voir 3MFLoader ou ColladaLoader ) afin que le chargeur puisse se concentrer sur la construction des données géométriques réelles. Peut-être est-il plus facile de créer un chargeur qui ne prend en charge que .ifcxml au début ?

@mrdoob , @Mugen87

Pourquoi pas?

Parce que

Le chargeur sera 5 fois plus gros que la bibliothèque Threejs.

et j'utilise Class avec les dernières fonctionnalités javascript.

IFC est basé sur le format STEP qui est bien connu dans la communauté CAO.

Oui, un jour je te montrerai ce que je fais avec Threejs ;)

Les fichiers IFC peuvent également être exprimés en XML (ils ont l'extension .ifcxml).
...
Peut-être est-il plus facile de créer un chargeur qui ne prend en charge que .ifcxml au début ?

L'analyse n'est clairement pas un gros problème. Mais la génération des géométries l'est ! Parce que le format ifc ne contient aucune géométrie. Mais utilisez l'interpolation/interaction entre les objets pour déterminer la géométrie finale.

Quoi qu'il en soit, si vous le souhaitez, vous devriez peut-être créer une branche spécifique pour cela avant de prendre une décision. Juste pour voir la grande chose.

Le chargeur sera 5 fois plus gros que la bibliothèque Threejs.

Eh bien oui, si le chargeur n'est pas aussi compact que les autres, il est probablement préférable de mettre le code dans un référentiel séparé.

@Itee Avez -vous l'intention de publier prochainement l'IFCLOADER ?
Serait intéressé de voir la GRANDE chose

Je ne connais personne qui veuille y contribuer et le maintenir...

J'utilise avec plaisir le convertisseur IFC d'IfcOpenShell, il fait de beaux geom et matériaux, peut faire Collada DAE (que nous utilisons pour importer vers Unity), IIRC OBJ et était là aussi glTF de nos jours

J'utilise avec plaisir le convertisseur IFC d'IfcOpenShell, il fait de beaux geom et matériaux, peut faire Collada DAE (que nous utilisons pour importer vers Unity), IIRC OBJ et était là aussi glTF de nos jours

Mais utilisez-vous des données IFC telles que Buildingstorey, Site, etc. ?
Il ne fait aucun doute que le Web ferait mieux d'être capable d'analyser IFC et non cette merde client-serveur avec laquelle tout le monde a affaire.

J'ai donné un coup de feu récemment. J'ai réussi à générer de la géométrie

Mais ça devrait être ça en fait :

La chose fondamentale qui a mal tourné est le placement et la rotation réels ici et mes calculs 3D sont presque inexistants (je n'ai tout simplement pas la patience).

Bien qu'il existe de nombreuses classes dans le schéma IFC. La taille de fichier éventuelle pourrait être réduite en utilisant des interfaces Typescript et en utilisant des fonctions pour rechercher et appliquer les arguments de chaque 'STEP' dans le fichier.

Bottomline, pour un chargeur IFC ; Je ne sais pas si nous avons nous-mêmes un génie des mathématiques 3D, car cela résoudrait beaucoup de problèmes d'analyse des relations mathématiques tout en construisant la géométrie.

Mais utilisez-vous des données IFC telles que Buildingstorey, Site, etc. ?

Oui, via le service de conversion de Tridify, qui utilise également IfcOpenShell (je l'ai également utilisé localement) pour le geom. Je pense que ces métadonnées sont faciles à analyser.

La génération de la géométrie est en effet non triviale. Si vous voulez le faire dans le navigateur, vous pouvez peut-être compiler IfcOpenShell en WebAssembly et l'utiliser comme bibliothèque à partir de votre Javascript. C'est du C++ simple sans interface graphique ou quoi que ce soit, juste une bibliothèque pour laquelle il existe une interface de ligne de commande séparément, il peut donc être facile à créer pour le Web également. L'analyse des IFC est un peu lourde, donc obtenir les performances WASM et une faible empreinte mémoire peut être agréable. Et la lib fait un beau travail pour créer le geom.

@MaartenBreeedveld Je peux aider avec les maths, pour la base théorique je n'ai aucun doute et j'ai une certaine expérience avec ifc, en fait il pourrait y avoir plusieurs transformations en série requises pour les coordonnées mondiales. Pour l'implémentation dans three.js il sera peut-être possible de l'optimiser.

Mais utilisez-vous des données IFC telles que Buildingstorey, Site, etc. ?

Oui, via le service de conversion de Tridify, qui utilise également IfcOpenShell (je l'ai également utilisé localement) pour le geom. Je pense que ces métadonnées sont faciles à analyser.

La génération de la géométrie est en effet non triviale. Si vous voulez le faire dans le navigateur, vous pouvez peut-être compiler IfcOpenShell en WebAssembly et l'utiliser comme bibliothèque à partir de votre Javascript. C'est du C++ simple sans interface graphique ou quoi que ce soit, juste une bibliothèque pour laquelle il existe une interface de ligne de commande séparément, il peut donc être facile à créer pour le Web également. L'analyse des IFC est un peu lourde, donc obtenir les performances WASM et une faible empreinte mémoire peut être agréable. Et la lib fait un beau travail pour créer le geom.

Nous avons essayé cela dans le passé. Mais la version compilée de WASM est un téléchargement de 40 Mo, je suppose que cela est dû à toutes les bibliothèques référencées dans ifcConvert.

@Jesusbill , Génial ! Actuellement, je n'ai pas le temps de travailler sur ce projet. Mais si c'est bon, je reviendrai vers vous.

Impressionnant! Actuellement, je n'ai pas le temps de travailler sur ce projet. Mais si c'est bon, je reviendrai vers vous.

Ça sonne bien @MaartenBreeedveld

Ajout VDBLoader à la liste. https://www.openvdb.org/

Une idée sur IFCLOADER ? @mrdoob

non

Concernant un chargeur 3dm : j'ai commencé à travailler dessus maintenant que la bibliothèque openNURBS a été compilée en wasm grâce à emscripten ( rhino3dm ).

Je travaille là-dessus ici et j'ai démarré et fonctionne le maillage, les breps, les extrusions, les nuages ​​de points, les matériaux, les calques et les groupes.

Fichiers pertinents:

• chargeur
• bibliothèque
• exemple html
• fichier d'exemple

J'espère soumettre un PR qui prend en charge plus de types d'objets _bientôt_. Je dois admettre que j'ai peu d'expérience avec les web workers, et je m'appuie sur les exemples de draco et de based loader. Espérons que # 18234 simplifie un peu cela.

ps nous ajoutons déjà le support de threejs directement à la bibliothèque rhino3dm.js comme ici et ici .

Modifier : mettre à jour les liens pour qu'ils pointent vers le fork de l'organisation McNeel.

Nous pouvons vérifier celui-ci ;)