L’objectif final du projet IASBIM est la production de maquette BIM numérique collaborative. Faciliter l’exploitation est donc également un objectif important pour cette collaboration. La plateforme collaborative par excellence étant le web, pouvoir visualiser facilement les maquettes BIM dans ce contexte permet en pratique cette collaboration.
Le format standard pour les échanges de fichiers BIM est le format IFC. En terme de volumétrie, les fichiers peuvent être de taille réduite comme de taille plus importante, certaines maquettes peuvent maintenant atteindre 10Go ou plus.
Le format IFC
Le format IFC - fonctionnellement extrêmement complet - pose des défis pour la visualisation temps réel web.
Fig 1 : extrait d’un IFC:
#20873= IFCPRESENTATIONSTYLEASSIGNMENT((#20871));
#20875= IFCSTYLEDITEM(#20868,(#20873),$);
#20878= IFCSHAPEREPRESENTATION(#118,'Body','Brep',(#20868));
#20880= IFCPRESENTATIONLAYERASSIGNMENT('R\X2\00E4\X0\ume',$,(#20878,#21256,#21613,#33745,#34158,#34734),$);
#20883= IFCCARTESIANPOINT((0.,0.,0.));
#20885= IFCBOUNDINGBOX(#20883,5.45,4.05,2.5);
#20886= IFCSHAPEREPRESENTATION(#375,'Box','BoundingBox',(#20885));
#20888= IFCGEOMETRICREPRESENTATIONSUBCONTEXT('FootPrint','Model',*,*,*,*,#62,$,.MODEL_VIEW.,$);
#20889= IFCCARTESIANPOINT((0.,0.));
#20891= IFCCARTESIANPOINT((5.45,0.));
#20893= IFCCARTESIANPOINT((5.45,4.05));
#20895= IFCCARTESIANPOINT((0.,4.05));
#20897= IFCPOLYLINE((#20889,#20891,#20893,#20895,#20889));
#20899= IFCGEOMETRICCURVESET((#20897));
#20901= IFCSHAPEREPRESENTATION(#20888,'FootPrint','GeometricCurveSet',(#20899));
#20904= IFCPRODUCTDEFINITIONSHAPE($,$,(#20878,#20886,#20901));
#20909= IFCSPACE('347jFE2yX7IhCEIALmupEH',#12,'4',$,$,#20819,#20904,'Schlafzimmer',.ELEMENT.,$,$);
Parmi les problématiques qu’il présente pour ce cas d’usage, deux caractéristiques empêchent une utilisation optimisée pour la visualisation temps réel.
La hiérarchie des entités à reconstruire
Un fichier IFC contient un certain nombre de relations entre entités, entre géométrie et entité etc. Ces relations sont matérialisées par des références entre identifiants.
Par exemple dans l’exemple précédent, l’IfcSpace d’identifiant #20909 a pour forme spatiale l’IfcProductDefinitionShape d’identifiant #20904 (cf les deux dernières lignes).
Malheureusement, ces relations peuvent être répartie dans tout le fichier. Il n’y a aucune garantie que la représentation géométrique d’un objet soit situé à proximité de sa déclaration. Il est donc impossible de reconstruire une hiérarchie complète avant d’avoir lu tout le fichier.
Le format texte non indexé
Le format IFC est un format texte délimité par des sauts de ligne. Il est très rapide pour un système d’exploitation moderne d’accéder à un endroit aléatoire d’un fichier, même de grande taille, à condition qu’on connaisse le nombre exact d’octets qu’on doit sauter.
Chaque ligne étant de taille variable et le fichier n’étant pas indexé, il n’est pas possible de retrouver un élément d’identifiant arbitraire sans parcourir potentiellement tout le fichier.
La visualisation
Comme nous l’avons vu précédemment, nous sommes obligés de parcourir et interpréter l’ensemble d’un IFC avant de pouvoir l’exploiter, notamment pour la visualisation.
Pour des fichiers de taille réduite (typiquement inférieure à 100Mo), cette lecture complète est envisageable dans un contexte navigateur, et nous utilisons alors l’excellente librairie javascript components de IFCjs pour l’interprétation, ainsi que la librairie 3D THREE.js. Pour ces fichiers, le processus est donc le suivant:
- le code javascript s’exécutant sur le navigateur internet de l’utilisateur va télécharger le fichier ifc hébergé sur les serveurs de l’application
- la librairie IFCjs va parser l’intégralité du fichier et le transformer en modèle 3D compatible avec THREE.js
- ce modèle sera ensuite chargé directement et intégralement dans la scène 3D de THREE.js.
Cette approche permet d’obtenir sans grand effort un résultat complet. Néamoins, elle nécessite de la bande passante et de la puissance de calcul pour respectivement télécharger puis interpreter le fichier.
De plus, un téléchargement de 100Mo et l’interprétation du fichier ne passeront pas inaperçu par l’utilisateur ! Un délai dû au téléchargement voire un ralentissement de la machine seront probables…
Fig 2 : L’affichage d’un IFC dans piero, Environ 5 secondes de téléchargement et entre 5 et 10 secondes de traitement pour un fichier de 20Mo.
Cette approche ne passe pas à l’échelle lorsque la taille des fichiers augmente. La quantité de mémoire nécessaire est au moins égale à la taille du fichier source, sans parler du temps de téléchargement et de traitement.
Conclusion : nécessité d’une conversion
Il est donc nécessaire de convertir le fichier en amont dans un format plus adapté qui réponde à cette problématique de visualisation rapide dans un contexte web.
Dans les articles suivants, nous décrirons le format que nous avons choisi pour un tel affichage - le 3Dtiles - puis nous expliquerons les choix de structure que nous avons fait pour optimiser au maximum les performances.