Three.js: Importateur IFC pour threejs

oublié de mentionner que cela dépend de ThreeCSG

Jamais entendu parler de ce format. Où est-il généralement utilisé ?

Pour autant que je sache, il est principalement utilisé dans le secteur de la construction, la modélisation du bâtiment. Pris en charge par Autocad, Revit, Tekla et Solibri pour n'en citer que quelques-uns.

Je vois je vois!
Pourquoi a-t-il besoin de ThreeCSG ?

Par example; un objet Mur (forme extrudée en trois parties) peut avoir une ouverture. Et la solution la plus simple que j'ai trouvée était d'utiliser ThreeCSG. Également utilisé dans d'autres cas comme IfcBooleanResult.

Lien vers la spécification IfcOpeningElement :
http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcproductextension/lexical/ifcopeningelement.htm

vous pouvez vous référer à
http://www.ifcquery.com

@mrdoob , IFC signifie Industry Foundation Classes et est censé être un format d'échange standard pour les projets BIM (Building Information Model/Management). Les progiciels généralement liés à cela sont Revit , ArchiCAD , VisualARQ et quelques autres. Bien que je généralise, le logiciel BIM fournit des types d'objets standard tels que des murs, des dalles, des toits, des escaliers, des fenêtres, etc., tous pilotés par une définition de famille/style où l'opérateur définit les paramètres de l'objet. Par conséquent, si j'ai un mur avec une couche de CMU, de plaques de plâtre et de carreaux, je peux définir les épaisseurs de toutes les couches. Je change quelque chose, je change la définition de famille/style, et tout se met à jour automatiquement ! La réalité n'est pas si magique ! C'est un format litigieux, car chaque éditeur de logiciel est libre de jouer avec la définition de ce qu'un mur peut constituer en import/export http://buildingsmart.org/compliance/certified-software/.
C'est un excellent format à prendre en charge, et je remercie @kdilayer de l' avoir configuré. @ johnney88 ce spectateur utilise-t-il threejs ?

Oui, The Viewer utilise Threejs.
Le fichier enregistré 'ifcquery.min.js' est écrit par Three.js, mais il est encodé.

Je peux confirmer que ifc est utilisé dans ConSci. En fait, j'ai utilisé une application de conversion ifc pour convertir les fichiers de mon entreprise en .objs avec des fichiers .mtl et ils lisent très bien. Il serait donc très utile de supprimer l'intermédiaire, car nos clients ont de toute façon tendance à télécharger des fichiers ifc.

@rhairston Une application de conversion ifc ? Elle peut convertir le fichier ifc en fichier obj afin que Threejs puisse le charger correctement.
Ai-je raison?

voici une application de conversion ifc?

Merci à tous d'être intervenu !

@kdilayer un PR serait génial. S'il vous plaît, incluez également ThreeCSG 😊

Des progrès ici? Nous sommes actuellement en train de convertir IFC en DAE pour une utilisation avec three.js, et nous serions ravis que three.js supporte directement IFC.

Salut kdilayer,

Je suis très intéressé à jeter un coup d'œil et à aller plus loin.

Salut tout le monde,

J'ai vu ça aussi https://www.npmjs.com/package/ifc-convert
Avec cela, vous pouvez convertir IFC en DAE, OBJ, STP et IGS.

@kdilayer Des progrès ?

@kdilayer Des progrès ici? Cela économisera beaucoup de choses si three.js pouvait prendre en charge directement le format IFC.

@dslwz2008 https://github.com/mrdoob/three.js/issues/9860

Personne n'a de nouvelles ?

J'ai modifié l'éditeur pour prendre en charge les fichiers ifc.
Quelques captures d'écran en pièce jointe. J'y travaille depuis un certain temps maintenant... actuellement, je n'ai vu aucun fichier IFC 2x3 qu'il ne peut pas rendre... le plus gros fichier que j'ai essayé est de 180 Mo...
Impressionnant.

Hé, super travail !
Peut-on y accéder directement depuis la branche master ou le code modifié pour le support IFC se trouve ailleurs ?

Ouais ! Impressionnant ! Comment pouvons-nous avoir accès à ce code de chargement, s'il vous plaît ? :o

Je vote pour un PR . THREE.IFCLoader serait une excellente contribution !

Nous aimerions également cette fonctionnalité, pour l'instant, je convertis les fichiers IFC en obj avec https://github.com/IfcOpenShell/IfcOpenShell , mais certaines géométries plus compliquées ne sont toujours pas analysées, donc parfois l'objet, pas 100 % Achevée.

Bonjour, je me demandais si vous pouviez obtenir certaines des choses complexes telles que les portes et les transparents avec le chargement des fenêtres dans votre visionneuse et votre chargeur. Il a l'air génial jusqu'à présent ! Je suis curieux de savoir si vous avez prévu de publier une version de cela dans un proche avenir.

Bonne chance !, Merci pour la mise à jour.

Salut @kdilayer , pourrions-nous s'il vous plaît avoir accès à votre application ?

Je suis intéressé de voir la différence de taille de fichier entre les formats .ifc et three.js.

Merci!

@Foosballfan Je pense qu'un IFC n'est pas un format intéressant pour la taille, car il est très verbeux. C'est juste un format d'échange pour les logiciels d'architecture comme AutoDesk.
C'est une norme du BIM. (demandez à google ce terme qui est célèbre dans ce genre de métier)

@jean-noelp Merci pour la réponse.

J'ai un fichier ifc pour un bâtiment de 34 Mo et j'essaie d'afficher ces données sur le Web avec la plus petite taille de téléchargement possible.

Avec Unity WebGL, je peux le réduire à environ 11 Mo, mais j'aimerais voir si c'est possible avec un WebGL plus pur en utilisant Three.js. J'espère pouvoir atteindre une taille de téléchargement encore plus petite.

Avez-vous une expérience avec une situation similaire?

@Foosballfan pour minimiser la taille du fichier, les étapes que j'essaierais sont :

1. convertir en OBJ
2. parcourir obj-simplify
3. compresser l'OBJ avec Draco
4. charger avec THREE.DRACOLOader

Si le fichier ne peut pas être converti en OBJ ou dans un autre format, vous ne pouvez probablement pas faire grand-chose à part simplifier le modèle ou utiliser gzip... "pure WebGL utilisant three.js" est un moyen de rendre le fichier, mais vous devez toujours utiliser un format ou un autre pour que le fichier soit chargé en premier.

@donmccurdy Ça a l'air super, merci !

Je vais essayer et voir comment ça se passe.

À l'origine, j'ai abandonné obj car celui que j'ai créé fait 220 Mo du fichier de 34 Mo.

Clôture du sujet puisque @kdilayer n'est évidemment pas disposé à partager son implémentation. J'ai ajouté IFCLoader tant que tâche à la liste de souhaits du chargeur dans #5524.

Tant qu'il n'y a pas de IFCLoader , essayez de convertir les fichiers IFC vers d'autres formats comme OBJ . Il semble que l'outil suivant puisse effectuer cette conversion : http://ifcopenshell.org/ifcobj.html

Voir également https://github.com/IfcOpenShell/IfcOpenShell

@Foosballfan : IFC est le moyen le plus efficace de compresser la géométrie. Le problème est que l'approche procédurale requise pour le rendre n'est pas vraiment compatible avec les triangles. Un IFC de 34 Mo peut facilement extraire jusqu'à 4 Go de flux triangulaires. IFC décrit un tuyau coudé avec seulement 4 sommets, mais il faudra des centaines de triangles pour le rendre. Un coup d'œil aux rendus de l'OP, et je peux dire qu'il n'y a pas de cuillère. Bien sûr, il peut faire des lignes droites et des formes toroïdales à un axe. Mais, la spécification IFC inclut des définitions de surfaces balayées par deux splines de Bézier. Il s'agit donc de 8 sommets 3D définissant un ensemble pratiquement infini de triangles. Les architectes adorent cet outil, mais même le rendu d'une représentation 2D sur un ordinateur est problématique, car la formule ne permet pas l'approche f(x) = y .
Ici, jetez un œil aux spécifications officielles de l'IFC : http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcgeometryresource/lexical/ifcbsplinesurface.htm

@kdilayer es-tu toujours actif sur github ? Souhaitez-vous partager votre implémentation ? :ok_hand: Merci !

L'approche que j'ai choisie consistait à utiliser BimServer pour diffuser les données IFC binaires, puis à les construire dans ThreeJS. La taille de téléchargement sur la prise Web est satisfaisante et j'ai un contrôle total sur le modèle dans Three.

Vous pouvez jeter un œil au fonctionnement de BimViewer comme point de départ.

des réponses ?

@Joao-b4 Et ?

à propos d'un éventuel chargeur IFC

Ah, je suppose que c'est à @kdilayer...

Je crois que @kdilayer n'aura rien, puisque cela fait 3 ans depuis la publication et aucune réponse, ni activité sur son profil.
Je ne comprends pas comment fonctionne la création d'un chargeur, et j'ai un peu de connaissances dans la bibliothèque, j'ai travaillé avec il y a peu de temps, j'aurais des liens pour créer un chargeur, je peux avoir assez de disposition et de connaissances dans l'avenir.

J'ai décrit ici un échafaudage de base de THREE.IFCLoader . La partie la plus difficile lors de l'écriture d'un chargeur est de comprendre le format 3D respectif. Ce n'est qu'alors que vous pouvez analyser le format et transformer la géométrie et/ou les données matérielles en entités three.js (par exemple THREE.BufferGeometry ). Je recommande d'étudier un loader plus ou moins simple comme THREE.PLYLoader afin de comprendre ce processus. Et bien sûr la norme IFC (https://www.iso.org/standard/51622.html)

merci, un chargeur ifc serait vraiment utile, et j'en ai besoin d'un en ce moment, j'utilise ce qu'ils ont mentionné ci-dessus, pour convertir en OBJ, mais je ne pense pas que ce soit le meilleur moyen

C'était il y a un an et demi, donc ma mémoire est rouillée, mais je pense que notre solution consistait à utiliser le serveur bim pour fournir les géométries du serveur, puis à utiliser Three sur le front-end pour gérer le rendu.

Il a fallu un peu de déconner mais a finalement fonctionné.

IfcConvert est un IfcConverter pour Node.js. Il convertit de .ifc en .dae, .obj, .stp et .igs. Je ne l'ai pas encore essayé, mais si cela fonctionne comme décrit, je suppose que nous n'aurions plus besoin de chargeur .ifc dans Three.js, n'est-ce pas ?
.ifc contient beaucoup plus d'informations que le modèle 3D, mais en ce qui concerne Three.js, seul le modèle 3D doit être importé.
Pour un exportateur, ce serait différent, car on pourrait vouloir exporter sa propre bibliothèque BIM dans un fichier .ifc, à côté du modèle 3D exporté.
Est-ce que ça fait du sens ?

Il peut toujours être intéressant de charger directement IFC dans le navigateur sans avoir besoin d'un outil de conversion séparé. Cependant, l'outil node.js mentionné n'est qu'un wrapper autour de IfcOpenShell . Donc ça ne fait pas quelque chose de vraiment nouveau...

Je pense que le flux de travail d'importation via IfcConverter pourrait être bon !

Au contraire, l'export ifc n'a aucun sens pour moi, car vous perdez toutes les données ifc pertinentes (composants architecturaux, acteurs BIM...) dans une visionneuse lambda Three.js, à moins de construire un éditeur Ifc avec Three.js .

@Mugen87 Eh bien, la principale valeur ajoutée est le package Node, car à ma connaissance, IfcOpenShell est en ligne un outil CLI.

@jean-noelp Vous avez raison. Je ne parlais pas d'une exportation du "fichier maître .ifc", mais plutôt d'un "fichier bibliothèque .ifc" que les intervenants BIM pourraient importer dans leur propre "fichier maître .ifc". Par exemple, vous êtes un fabricant de portes de garage, utilisez Three.js pour planifier l'installation pour vos clients (architectes, par exemple) et exportez la bibliothèque BIM contenant vos objets BIM (généralement la porte de garage). Tu vois ce que je veux dire ? Mais de toute façon, il n'y aurait aucun moyen d'avoir cet exportateur intégré à Three.js car chaque cas d'utilisation particulier est beaucoup trop spécifique (je suppose).

Je trouve un OUTIL, IFC peut être résolu,
C'est pas gratuit
Mais l'analyse de la structure IFC est gratuite et open source
http://www.apstex.com/

Salutations, il n'y a pas de nouvelles de @kdilayer, n'est-ce pas ? il n'a jamais publié le code source?

?

------------------ Le message d'origine ------------------
De : "Daniel Ramos"< [email protected]> ;
Heure de livraison : 28 mai 2020 (jeudi) 22h08
À : "mrdoob/three.js"[email protected]> ;
Cc : " Leave the net de fish"< [email protected]>;
Objet : Re : [mrdoob/three.js] Importateur IFC pour threejs (#9764)

Salutations, il n'y a pas de nouvelles de @kdilayer n'est-ce pas ? Il n'a jamais publié le code source ?

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub ou désabonnez-vous.

Des nouvelles à ce propos ?

Hey! Il y a quelques jours, j'ai commencé à implémenter un analyseur IFC dans JS avec l'idée de l'appliquer à Three.js. C'est un projet personnel que je fais pendant mon temps libre, donc je n'ai aucune idée précise du temps que cela prendra. Cependant, j'ai vu ce fil aujourd'hui et j'ai pensé qu'il pourrait vous intéresser. Vous pouvez le trouver ici .

@agviegas attend avec impatience ce que vous en ferez ! un PR pourrait être vraiment le bienvenu

En effet! @agviegas, nous pourrons peut-être obtenir plus de personnes pour aider si vous faites un PR avec 😍

Malheureusement, je n'ai pas pu publier mon travail sur ifcimporter, mais je peux aider @agviegas

@mrdoob Cela sonne bien. Je travaille toujours sur les fonctionnalités de base de l'analyseur syntaxique ; il peut déjà charger tous les éléments de la structure spatiale et je commencerai bientôt à construire la géométrie. Je suppose que le code doit également être adapté à cela avant de faire le PR. Y a-t-il des références à vérifier pour préparer le code du PR ? Nous pouvons le faire quand vous le souhaitez. Toute aide à ce sujet sera la bienvenue.

En revanche, le format IFC est très simple à mettre en œuvre, même s'il peut être un peu intimidant en raison de la rigueur de la documentation officielle. Je considère que je connais relativement bien le format IFC, donc si quelqu'un est intéressé à participer, nous pouvons sûrement le préparer plus tôt. ??

Je suppose que le code doit également être adapté à cela avant de faire le PR.

Oui, il doit utiliser la même interface que les autres chargeurs. Peut-être que le MD2Loader est la référence la plus simple en ce moment.

Ne vous inquiétez pas d'avoir tout parfait pour le PR. Vous pouvez soumettre ce que vous avez en tant que brouillon et nous pouvons vous aider à nous assurer que le code correspond au reste.

Après plusieurs trébuchements et difficultés avec le format, il y a déjà des résultats. J'ai implémenté la première version de l'analyseur, ainsi que certaines des entités géométriques (y compris les extrusions et les b-reps). Il reste encore beaucoup à faire, mais je suis satisfait des résultats obtenus jusqu'à présent. L'image ci-dessous montre un petit IFC généré par Revit fonctionnant correctement dans Chrome. Chaque instance géométrique est associée aux informations IFC analysées (en fait, dans la scène ci-dessous, chaque instance a un matériau en fonction de sa catégorie / classe ifc), donc la création de filtres à l'aide de valeurs de propriétés (Psets et Qsets) ne devrait pas être difficile à archiver à partir de ce point . Toutes les idées ou suggestions sont les bienvenues. ??

@agviegas Excellent !

@agviegas Très bien joué !

Quant aux idées de gestion immobilière. Comment les stockez-vous maintenant ? Tout comme userData sur les maillages ou la géométrie je suppose ?

La plupart de nos clients utilisent des logiciels comme HiCad ou ArchiCAD pour leur modélisation et ils stockent UNE TONNE d'informations très importantes pour les ouvriers du bâtiment (densité thermique, résistance au vent, mesures, poids, etc. etc.).

Je suis également très curieux de connaître la vitesse d'analyse/chargement. Les modèles avec lesquels j'ai testé mon implémentation prennent environ 5 secondes à analyser, mais pour générer la géométrie, le processus prend près de 2 minutes pour se convertir en modèle DAE. (Je le convertis côté serveur en raison du manque de temps et d'expérience de mon côté :sweat_smile:, c'est pourquoi je suis tellement excité que ce chargeur fonctionne « nativement »)

@haroldiedema Je n'ai pas encore implémenté les ensembles de propriétés, mais la structure de données actuelle se compose d'un objet JS où les clés sont les ID express et les valeurs sont les objets analysés chargés en mémoire. Chaque propriété qui était un ID express est remplacée par une référence à l'objet avec cet ID. Dans l'implémentation actuelle, chaque instance de _IfcProduct_ avec une ou plusieurs représentations géométriques possède une propriété supplémentaire appelée _Geometry_ , qui est un tableau de références aux géométries de la scène. Par exemple, chaque _IfcWallStandardCase_ a une propriété _Geometry_ avec une référence au _Path_ (a Line ) a au _Body_ (a Mesh ).

Chaque instance géométrique de Three.js aura probablement une propriété contenant l'ID express, il sera donc facile de retrouver l'entité ifc chargée en mémoire (et les informations associées) (par exemple en cliquant sur les maillages de la scène).

En ce qui concerne les propriétés définies par l'utilisateur, il y aura un ou plusieurs _IfcRelDefinesByProperties_ (ou un autre objet de relation indirecte) pour tout lier ensemble. Peut-être que chaque instance de IfcProduct peut avoir un attribut _hasPropertySets_ qui contiendrait un tableau des ensembles de propriétés analysés associés (j'ai vu ce modèle dans d'autres bibliothèques IFC, et c'est ce que je fais avec d'autres relations indirectes telles que _IfcRelAggregates_). Je ne m'inquiète pas du nombre de propriétés car elles seront structurées selon l'IFC, mais voyons comment ça se passe quand j'y arriverai. ??

Je fais tout côté client, et actuellement l'analyse prend moins d'une seconde et la génération géométrique de la dernière scène affichée environ 4 secondes. Je suis conscient qu'avec des fichiers plus volumineux, ce temps augmentera ; cependant, j'espère pouvoir optimiser le système lorsque j'aurai couvert plus d'entités IFC et que je pourrai charger des IFC à partir de projets réels. 🙂 Je vais étendre le document _CONTRIBUTING_, au cas où quelqu'un voudrait creuser dans tout cela.

@agviegas ça a l'air génial !

J'ai essayé de cloner la branche principale de votre référentiel pour tester certains des modèles de nos clients, mais malheureusement chacun d'entre eux produit une erreur dans la console à propos de _ExpressId n'est pas défini (tous les modèles ne sont pas cohérents à 100 % lorsqu'il s'agit de référencer des enregistrements qui existe réellement). Je pense que certains logiciels de CAO ne nettoient pas correctement les références aux propriétés supprimées.

Je pourrais partager certains de ces modèles avec vous, mais nous devrons le faire en privé. Vous pouvez me joindre à [email protected] si vous êtes intéressé par d'autres cas de test de modèles exportés avec ArchiCAD ou HiCAD.

@haroldiedema Je n'ai pas encore implémenté les ensembles de propriétés, mais la structure de données actuelle se compose d'un objet JS où les clés sont les ID express et les valeurs sont les objets analysés chargés en mémoire. Chaque propriété qui était un ID express est remplacée par une référence à l'objet avec cet ID. Dans l'implémentation actuelle, chaque instance de _IfcProduct_ avec une ou plusieurs représentations géométriques possède une propriété supplémentaire appelée _Geometry_ , qui est un tableau de références aux géométries de la scène. Par exemple, chaque _IfcWallStandardCase_ a une propriété _Geometry_ avec une référence au _Path_ (a Line ) a au _Body_ (a Mesh ).

Chaque instance géométrique de Three.js aura probablement une propriété contenant l'ID express, il sera donc facile de retrouver l'entité ifc chargée en mémoire (et les informations associées) (par exemple en cliquant sur les maillages de la scène).

En ce qui concerne les propriétés définies par l'utilisateur, il y aura un ou plusieurs _IfcRelDefinesByProperties_ (ou un autre objet de relation indirecte) pour tout lier ensemble. Peut-être que chaque instance de IfcProduct peut avoir un attribut _hasPropertySets_ qui contiendrait un tableau des ensembles de propriétés analysés associés (j'ai vu ce modèle dans d'autres bibliothèques IFC, et c'est ce que je fais avec d'autres relations indirectes telles que _IfcRelAggregates_). Je ne m'inquiète pas du nombre de propriétés car elles seront structurées selon l'IFC, mais voyons comment ça se passe quand j'y arriverai. ??

Je fais tout côté client, et actuellement l'analyse prend moins d'une seconde et la génération géométrique de la dernière scène affichée environ 4 secondes. Je suis conscient qu'avec des fichiers plus volumineux, ce temps augmentera ; cependant, j'espère pouvoir optimiser le système lorsque j'aurai couvert plus d'entités IFC et que je pourrai charger des IFC à partir de projets réels. 🙂 Je vais étendre le document _CONTRIBUTING_, au cas où quelqu'un voudrait creuser dans tout cela.

L'analyse de User Defined IFC Property Sets est super facile. J'ai un repo qui fait ça. Mon analyseur n'est pas aussi sophistiqué que le tien.

Cependant, j'ai remarqué que certaines propriétés ont tendance à casser les analyseurs. Je n'ai pas utilisé chevrotain , donc je ne sais pas comment votre code tiendrait. J'ai écrit plus sur ces problèmes ici . J'espère que cela pourra vous être utile.

En tout cas, très bon travail jusqu'à présent! ??

Mise à jour : j'ai déployé l'application dans les pages Github pour faciliter les tests utilisateur tout au long du développement. Cela inclut la navigation réactive pour la prise en charge des mobiles et des tablettes. En outre, ici vous pouvez trouver une alternative qui Déployez charge un modèle de la SFI au démarrage; la logique pour effacer la scène et ajouter plusieurs IFC n'est pas encore implémentée, mais au moins vous pouvez voir à quoi ressemble la navigation. L'analyse est faite par le client, donc les temps de chargement dépendent de l'appareil utilisé. Mon ordinateur portable le fait en 5 secondes environ, tandis que mon Moto G5 Plus a besoin d'environ 50 secondes pour cette scène. Il reste encore des classes à implémenter avant de charger un projet complet, mais n'hésitez pas à m'envoyer des IFC pour les ajouter aux fichiers de test.