Dans l’article précédent, nous avons vu que le format 3D Tiles offrait un ensemble d’outils pour rendre un jeu de donnée volumineux facilement visualisable dans une application web 3D.
Parmi les possibilités que nous offre ce format, nous pouvons:
- segmenter la donnée dans une hiérarchie de tuile définissant des niveaux de détails croissants
- définir deux grandeurs : l’erreur géométrique et le volume de requête pour le visualisateur, permettant au visualisateur de choisir quel segment (ou tuile) afficher en fonction de la vue actuelle.
Il est maintenant temps de décrire comment nous allons concrètement utiliser ces notions sur un fichier issu du BIM.
Les caractéristiques de la donnée BIM
Une donnée résolument 3D
L’organisation optimale d’un tileset 3D Tiles dépend de la donnée source et de ses caractéristiques. Est-elle ramassée ? Principalement 2D comme une acquisition de Lidar aérien par exemple, ou sous forme de sphère comme les résultats de photogrammétrie ? Caractériser la donnée est important pour définir une organisation générique donnant de bon résultats avec tous les jeux de donnée possibles.
La première caractéristique de la donnée BIM est le fait qu’elle soit résolument 3D, contrairement à un Lidar aérien par exemple. Cela structure la séparation en tuile, et on privilégiera des segmentations en octree plutôt qu’en quadtree par exemple.
Une donnée déjà structurée
L’autre élément structurant est la présence de notions géométriques. La structure générale d’un ifc est décrite par l’ensemble des sous-classes de IfcSpatialElement:
- un IfcProject, contient:
- des IfcSite, représentant les différents sites de la maquette, contenant
- des IfcBuilding (bâtiments) contenant éventuellement
- des IfcBuildingStorey (étages d’un batiment), contenant enfin
- des IfcSpace, qui sont les pièces ou espaces d’un bâtiment.
Chaque élément (sauf l’IfcProject) peut contenir des IfcElement divers.
Une précision pouvant être grande
L’Ifc définit plus de 800 types d’objets géométriques différents de taille très variables, du IfcBuilding jusqu’aux éléments de mobilier individuel (IfcFurniture) en passant par les murs, portes ou fenêtres. Pour chacun de ces éléments, la précision géométrique est arbitraire et peut potentiellement être très fidèle.
Concrètement, cela se traduit par des géométries volumineuses, mais dont la précision n’est pas utile à tous les niveaux de zoom.
Des métadonnées nombreuses
Les fichiers IFC contiennent souvent des données attributaires riches et complètes sur les éléments qu’ils décrivent. Quelques fois, la donnée attributaire peut être plus volumineuse que la donnée géographique.
L’organisation du 3D Tiles
Respecter la hiérarchie naturelle
Nous pensons que respecter la hiérarchie naturelle des IfcSpatialElement
est une bonne idée pour avoir une première organisation de tuile. En effet, c’est souvent selon cette hiérarchie que les utilisateurs exploitent leur donnée : ils souhaitent afficher, cacher ou mettre en valeur un site, un étage ou une pièce.
Fig 1: La hiérarchie naturelle d’un IFC
Du niveau de détail au sein des éléments structurants
Néanmoins, au sein d’un de ces éléments structurants, le nombre de géométries peut rester important. On pourra donc introduire un autre niveau de hiérarchie, afin de grouper les petits éléments dans des sous-tuiles, qui ne seront pas affichées immédiatement.
Utiliser le volume de requête (Viewer request volume) pour l’intérieur des pièces
Dans un bâtiment, les pièces sont regroupées ! Pour cette raison, lorsque que la caméra se rapproche du bâtiment, le visualisateur peut être amené à traiter les nombreuses géométries de plusieurs pièces, alors que celles-ci ne sont probablement pas visible à cause des murs.
Le mécanisme de volume de requête pour le visualisateur est intéressant pour empêcher cela, et n’afficher les éléments d’une pièce que lorsqu’on est à l’intérieur de celle-ci.
Ce volume de requête est pertinent pour les IfcSpace
, mais pas pour les autres éléments structurants car ceux-ci contiennent fréquemment des éléments qu’on ne veut pas cacher, comme les IfcWall
par exemple.
une sous-tuile pour les systèmes
Certains systèmes (réseaux, etc…) sont situés au niveau du bâtiment ou de l’étage. Il peut être envisageable de les grouper dans une même tuile afin de pouvoir les mettre en valeur, les cacher ou les montrer facilement.
Conclusion
Le seul fait de segmenter un jeu de donnée ne garantit pas à lui seul de bonnes performances. Choisir une bonne organisation du tileset est également essentiel.
L’objectif principal reste le suivant : donner la meilleur qualité visuelle à l’utilisateur avec le moins de donnée possible !