Soutenance mémoire
Depuis 2008, plus de la moitié de la population mondiale vit dans des villes. Les environnements virtuels urbains inspirés de ceux-ci se sont trouvés à la base de nombreuses applications et sont une plate-forme de choix pour l’intégration d’informations sur les villes via différentes ressources. Ces environnements sont utilisés pour la visualisation et l’exploration des paysages urbains et de nos jours, sont utilisés pour assister à différentes tâches allant de la planification urbaine, contrôle de trafic, la gestion de désastres ou encore la création de mondes virtuels. Des modèles de réalité augmentée sont utilisés pour fournir une assistance à l’aide d’informations qui sont visuellement superposés sur une visualisation du monde réel, et de tels systèmes requièrent des modèles de villes 3D pour se faire.
Ces modèles de villes 3D virtuels, dans un effort de se rapprocher des villes réelles, sont de plus en plus complexes en ce qui concerne leurs structures spatiales et thématiques. Afin de stocker ces informations, un modèle de données normalisé, assurant la structuration de données cohérente et interopérable doit être construit.
D’un autre côté, avec les progrès des matériels informatiques, le monde des jeux en 3D est de plus en plus complexe visuellement parlant. Les jeux contemporain 3D sont souvent situés dans des environnements de plus en plus grands. La qualité visuelle des jeux vidéo à base de polygones s’améliore avec chaque nouvelle génération de matériel graphique. Pour gérer la visualisation de cette quantité de données, au lieu de créer manuellement des grandes quantités de modèles, une possible solution pour le problème de création de contenu est d’introduire l’application de techniques procédurales. En effet, une ville complexe contenant de nombreux modèles différents prendrait des mois à construire manuellement, ainsi pour réduire au minimum les coûts pour la création de mondes, la génération des objets avec une approche procédurale, ajoute non seulement un caractère aléatoire contrôlable dans le monde, mais donne également des résultats qui sont inattendus dans la forme et l’apparence.
État de l’art
Plusieurs méthodes existent pour générer des villes. La réalisation de cela peut requérir la combinaison de différentes étapes, différentes selon la nécessité et le résultat attendu. Ainsi, pour ce faire, une des méthodes consiste à s’appuyer sur un modèle déjà existant, dans ce domaine, des normes de représentations ont été établies, après la définition de ce modèle vient la visualisation qui peut alors consister à lire ce modèle, ou à en créer à partir d’autres supports comme les photographies aériennes et terrestres, enfin la visualisation peut se passer de modèles et se faire de manière complètement procédurale.
Représentation des bâtiments et des villes
Comme les modèles peuvent provenir de sources différentes, une forme de représentation doit être adoptée pour décrire, stocker et gérer ces environnements virtuels. Plusieurs standards existent déjà, allant de la gestion du simple bâtiment jusqu’à une ville entière afin de gérer toute la complexité que peuvent présenter ces environnements.
Le standard IFC
Le format IFC [16] est un format neutre de données pour décrire, échanger et partager des informations généralement utilisées dans l’industrie du bâtiment et de la construction. IFC est la norme internationale pour openBIM, il a été imaginé pour fournir une base universelle pour l’échange de données concernant les bâtiments. Le modèle de données IFC est un modèle de données orienté objet basé sur des définitions de classe représentant les objets (éléments, processus, formes, etc.) qui sont utilisés par des applications logicielles au cours d’un projet de gestion de construction. On y retrouve par exemple les entites comme IfcWall ou des représentations de géométries dans IfcExtrudedAreaSolid.
Le modèle IFC est représenté par des structures qui renferment des espaces (IfcSpatialStructureElement). Les structures qui en dérivent sont les sites, buildings, étages. La classe IfcSpatialStructureElement dérive de la classe IfcProduct, qui a un lieu et une représentation géométrique. La plupart des géométries utilisées pour les bâtiments sont des modèles solides, qui sont définis comme la forme d’un IfcProduct.
Le standard CityGML
Vue d’ensemble de CityGML
Le standard CityGML [20] est un modèle de données pour la représentation et l’échange de modèles virtuels en 3D des villes et de paysages. Le modèle comprend des informations sur la géométrie, l’apparence, la sémantique et la topologie de ses objets. Il est basé sur le langage de balisage extensible (XML), la famille des normes ISO 19100 et la version 3.1.1 de Geography Markup Language (GML3). CityGML est une norme officielle de l’Open Geospatial Consortium et joue un rôle de premier plan dans la modularisation de l’information géospatiale urbaine.
Les modules
Une ville est complexe, cette complexité se reflète par la couverture de nombreuses thématiques des objets urbains. CityGML contient un module de base et des modules d’extensions thématiques. Le module de base définit les concepts et composantes basiques de CityGML. Toutes les extensions thématiques dépendent de ce modèle et il doit être implémenté par tout système qui utilise CityGML. Les extensions thématiques sont au nombre de onze, ces modules sont : Building, Apparences, CityFurniture, CityObjectGroup, GenericCityObject, LandUse, Relief, Transportation, Vegetation, WaterBody, TexturedSurface.
Les niveaux de détails (LOD)
Pour satisfaire le fait que les données peuvent avoir des modes de collecte et des applications diverses, CityGML supporte cinq différents niveaux de détails. Le LOD0 est un modèle numérique de terrain 2.5D. Le LOD1 est le modèle de blocs comprenant des bâtiments prismatiques avec des toits plats. Le LOD2 contient des structures et des surfaces de toit différenciées. Le LOD3 est un modèle architectural avec des structures détaillées de murs et de toits. Le LDO4 combine un modèle LOD3 avec des structures intérieures.
3DCityDB
Dans le cadre de la création d’une base pour stocker le modèle de la ville de Berlin [31], le projet 3DCityDB, basé sur CityGML a été créé. 3DCityDB se propose de reprendre les caractéristiques principales de CityGML, mais en simplifiant le modèle de données complexe pour avoir une base plus compacte et améliorer la rapidité des requêtes. Par exemple, les relations de types n : m sont réduites à des relations de type 1 : n pour éviter la création de tables additionnelles. La gestion des relations de récursives a également été simplifie, car ce genre de requête peut être très couteux. Il existe actuellement deux versions de cette base, l’une sous Oracle 10g Spatial et l’autre sous Postgres Structured Query Language (PostgreSQL) avec l’extensions Post Geographical Information System (PostGIS) pour les données spatiales.
Le modele QUASY
Le modèle QUASY [4] est un modèle pour représenter les bâtiments. Il ajoute des extensions sémantiques aux modèles de base habituels comme les étages, les passages et l’ajout d’une variante qui peut contenir une description paramétrique des modèles de bâtiments ou d’une partie du bâtiment, ces derniers sont caractérisés par un plan d’étage et les murs sont générés par extrusion verticale de ce polygone. La complexité sémantique du modèle QUASY se trouve entre CityGML et le standard IFC. Un bâtiment peut y contenir un nombre d’attributs non géométriques (fonction, année de construction, . . . ) et contient une agrégation d’éléments appelés QVariants. Ces derniers peuvent contenir : des volumes et des surfaces géométriques qui caractérisent l’extérieur du bâtiment, des composantes avec une signification sémantique claire (mur, toit, etc . . . ) et enfin une description paramétrique qui permettra d’instancier des modèles géométriques purs.
CityTree
CityTree [23] est une structure de données en arbre proposé pour représenter une ville, le modèle de ville initiale est stocké sous CityGML et les bâtiments y sont par la suite divisés en groupes par le réseau routier et une CityTree est créé pour chaque groupe. Les feuilles de l’arbre représentent les objets 3D d’origine de chaque bâtiment, et les nœuds intermédiaires représentent des groupes de bâtiments à proximité. Cette structure permet de transformer l’affichage selon le niveau de zoom effectué.
Transition entre les modèles
Nous avons pu constater que parmi les modèles ci-dessus, certains s’intéressent exclusivement à la forme des bâtiments tandis que d’autres se concentrent sur leur représentation dans un lieu donne. Un projet [9] s’intéresse à l’intégration de deux importants modèles dans le domaine du BIM, le modèle IFC, qui se focalise sur la création des bâtiments, pour fournir un grand niveau de détail pour les architectures, et le modèle CityGML, qui représente les objets d’une ville et leurs informations géographiques. Ce projet s’intéresse donc à la mise en place d’une méthode bidirectionnelle capable d’effectuer la transition d’un modèle vers l’autre et vice-versa et à l’intégration sémantique des deux modèles. Un nouveau modèle, UBM a été créé pour faciliter le transfert entre les deux, ce modèle contient toutes les caractéristiques et objets entre les deux modèles, la conversion s’effectue vers ce modèle intermédiaire en premier avant de terminer vers le modèle final.
Dans ce même domaine, l’échange d’informations entre design de bâtiment et modèles GIS à partir d’un Framework a également été étudié [17], le Framework en question réalise la transition grâce aux étapes suivantes : la définition d’un ensemble de règles pour la réalisation du mapping des éléments sémantiques entre IFC et CityGML, ensuite la création d’algorithmes pour la simplification des modèles géométriques et enfin la définition des informations qui seront transformés en attributs des objets de CityGML pour chaque niveau de détail.
|
Table des matières
INTRODUCTION
I État de l’art
1 État de l’art
1.1 Introduction
1.2 Représentation des bâtiments et des villes
1.2.1 Le standard IFC
1.2.2 Le standard CityGML
1.2.2.1 Vue d’ensemble de CityGML
1.2.2.2 Les modules
1.2.2.3 Les niveaux de détails (LOD)
1.2.2.4 3DCityDB
1.2.3 Le modele QUASY
1.2.4 CityTree
1.2.5 Transition entre les modèles
1.2.6 Synthèse sur les standards de modélisation de villes
1.3 Visualisation des villes
1.3.1 Visualisation directe
1.3.2 Visualisation basée sur des modèles 3D
1.3.3 Visualisation basée sur CityGML
1.4 Génération procédurale des villes
1.4.1 Undiscovered Worlds
1.4.1.1 View Frustrum Filling
1.4.1.2 Mise en cache des géométries
1.4.1.3 Génération des géométries
1.4.2 CityGen
1.4.2.1 Génération d’un réseau routier primaire
1.4.2.2 Génération d’un réseau routier secondaire
1.4.2.3 Génération des bâtiments
1.4.3 Synthèse sur les techniques de visualisation
1.5 Conclusion
II Méthodologie
2 Méthodologie
2.1 Introduction
2.2 La base de données
2.2.1 Conception de la base
2.2.1.1 PostgreSQL
2.2.1.2 PostGIS
2.2.1.3 La représentation des éléments géométriques
2.2.1.4 Les objets prédéfinis
2.2.1.5 Cohérence spatiale et sémantique
2.2.1.6 Les modèles
2.2.1.6.1 Les composantes de base
2.2.1.6.2 Les tables pour représenter les géométries
2.2.1.7 Le modèle relationnel de la base de données
2.2.2 L’alimentation de la base
2.2.2.1 Blender
2.2.2.2 Interaction entre Blender et PostGIS
2.2.2.2.1 Opérations préliminaires
2.2.2.2.2 Insertion des éléments basés sur des polygones
2.2.2.2.3 Insertion des objets prédéfinis
2.3 La génération des villes
2.3.1 Couplage entre Unity3D et PostGIS
2.3.2 La visualisation
2.3.2.1 Les entités et composantes
2.3.2.2 Les systèmes
2.3.2.3 La génération des bâtiments
2.3.2.3.1 La génération des polygones
Les triangles
Les coordonnées de base des textures
2.3.2.3.2 La génération des objets prédéfinis
2.3.2.3.3 Placement des bâtiments
2.3.2.3.4 Les éléments thématiques
2.3.2.4 Les objets urbains
2.3.2.5 Les véhicules
2.4 Conclusion
III Résultats
3 Résultats
3.1 Introduction
3.2 Outil et langage utilises
3.3 Présentation de l’interface du système
3.4 Conclusion
CONCLUSION
Bibliographie
