Post on 14-Jun-2015
description
transcript
Universite Paul Sabatier – Toulouse 3 Ecole Doctorale Informatique et Telecommunications
Modelisation automatique de zones
urbaines
THESE
presentee et soutenue publiquement le 30 septembre 2008
pour l’obtention du
Doctorat de l’Universite Paul Sabatier
(Specialite Informatique)
par
Mathieu Larive
Composition du jury
President : Mr Jean Pierre Jessel, professeur a l’Universite Paul Sabatier de Toulouse
Rapporteurs : Mr Mohamed Slimane, professeur a l’Universite de Tours
Mr Marc Daniel, professeur a l’Ecole Superieure d’Ingenieurs de Luminy
Examinateurs : Mr Yann Dupuy, ingenieur, Oktal Synthetic Environment
Mme Veronique Gaildrat, Mdc HdR, Universite Paul Sabatier (directeur de these)
Institut de Recherche en Informatique de Toulouse — UMR CNRS 5505
Auteur : Mathieu Larive
Titre : Modelisation de zones urbaines virtuelles
Directeur de these : Veronique Gaildrat
Lieu et date de soutenance : Toulouse, septembre 2008
Discipline administrative : Informatique
Resume La modelisation precise de zones urbaines etendues represente un defi en informatique
graphique. Une ville reelle repond a des regles de construction (implicites ou explicites) et reflete
souvent de multiples influences historiques, culturelles et sociales a travers le temps. Atteindre
une precision suffisante pour qu’une ville virtuelle soit credible, pour un utilisateur la visitant au
niveau du sol, demande une modelisation extremement detaillee qui exige bien trop de temps et
d’efforts de la part d’un concepteur meme experimente. L’emergence de nouveaux problemes
lies a l’urbanisation de masse, tels que l’influence des rayonnements electromagnetiques, la
preparation de plans d’evacuation ou la prevision de l’evolution necessaire des moyens de trans-
ports urbains, entraıne des besoins croissants en matiere d’etudes et de previsions. La capacite
a generer rapidement des maquettes virtuelles credibles permet de repondre a ces besoins et
constitue donc un sujet d’avenir appele a se developper car les resultats actuels ne satisfont pas
les criteres precedemment definis.
Nous presentons donc en premier lieu une synthese des travaux dans ce domaine. Cette synthese
est decomposee selon six etapes de generation, les resultats de chaque etape representant un
niveau de detail logique de la zone urbaine. Nos travaux portent principalement sur deux etapes
distinctes du processus de generation d’une zone urbaine virtuelle.
La premiere etape etudiee traite du placement automatique du mobilier dans une piece. Nous
presentons une etude de l’application de methodes issues de la recherche locale pour resoudre le
placement d’objets au sein d’un probleme defini par des contraintes. Les objets traites sont definis
par leur boıte englobante, et peuvent prendre une orientation quelconque (non isothetique). Nous
decrivons egalement le modeleur declaratif DEMONS LE qui a ete developpe pour evaluer la
pertinence de cette approche.
La seconde etape etudiee traite de la generation automatique d’exterieurs de batiments (facades,
fondations et toits). Notre methode est basee sur la definition de gabarits de batiments qui
sont appliques a des descriptions de batiments. Une description est uniquement constituee de
l’embase tridimensionnelle, de la hauteur de toit et de la hauteur des murs du batiment. En-
1
suite, les facades de batiments sont creees en utilisant une grammaire de murs tridimension-
nelle isometrique, basee sur un ensemble de regles. Ces regles peuvent etre simples ou bien tres
detaillees en fonction des besoins de l’utilisateur.
En conclusion, nous presentons les perspectives concernant la poursuite de ces travaux, plus
particulierement pour les deux etapes que nous avons etudiees en profondeur, mais aussi pour
les autres etapes de generation.
Mots-cles : synthese d’images, realite virtuelle, modelisation, architecture, urbanisme, methodes
procedurales, modelisation declarative
Laboratoire : IRIT, Universite Paul Sabatier, 118 route de Narbonne, F-31062 Toulouse Cedex
9
2
Remerciements
J’aimerais remercier en premier lieu Mme Veronique Gaildrat pour avoir encadre mon stage de
maıtrise, puis continue en etant mon directeur de stage de DEA et enfin pour avoir m’avoir
confie ce sujet de these. J’aimerais surtout la remercier pour la qualite des ses nombreuses re-
lectures, j’atteste ici qu’elle ne saurait etre tenue responsable des abominations grammaticales
et orthographiques qui demeurent dans ce memoire.
Je remercie egalement M Jean Latger pour avoir accepte ma presence dans l’entreprise qu’il
dirige, Oktal Synthetic Environment, dans le cadre de cette these CIFRE. J’aimerais remercier
particulierement les personnes d’OktalSE qui m’ont apporte leur aide et leur soutien pendant
ces annees, que ce soit Paul Pitot, Yann Dupuy ou Carole Nissoux, car j’ai enormement appris
en travaillant avec elles.
Je remercie messieurs Marc Daniel et Mohamed Slimane pour m’avoir fait l’honneur de s’interesser
a ce travail. Les commentaires pertinents qu’ils ont su formuler ont grandement contribue a
ameliorer la qualite de ce manuscrit.
Je remercie M Jean Pierre Jessel, responsable de l’equipe Vortex, pour sa disponibilite, sa gen-
tillesse et son ecoute qui m’ont ete fort precieuses pour ma vie de doctorant et aussi pour mes
diverses experiences professionnelles. Je ne sais pas si beaucoup d’etudiants en DEA ont la pos-
sibilite d’aller assister a des colloques, mais j’ai enormement apprecie l’honneur que tu as fait
en m’y emmenant.
Il y a quelques annees, j’avais felicite M Mathias Paulin pour sa patience et sa perseverance dans
ses tentatives de ”¡pingouinisation”¿ de la societe. Je ne sais pas ce qu’il en est de la societe, mais
pour le parc de machines de l’equipe, ca prend bonne tournure. Merci encore de ton enthousiasme
et de ton energie, et surtout, merci de m’avoir demarche pour le DEA, il y a deja fort longtemps.
J’aimerais temoigner ici de l’affection et du respect que j’eprouve pour toutes les personnes que
j’ai eu l’occasion de croiser durant ces annees a l’IRIT. Que ce soit Loıc Barthe et ses seminaires
tenus a bout de bras (que j’ai particulierement apprecies), Patrice Torguet et Roger Pujado
3
pour leur accueil toujours chaleureux a chacune de mes questions saugrenues ou encore tous les
etudiants en DEA (et maintenant master) et en these. Je garderai longtemps un souvenir emu
du mail que Gael nous a envoye en rentrant d’un pot a 2h du matin, ou des moments passes en
compagnie d’Antoine.
Je remercie enfin mon entourage pour leur presence et toutes leurs qualites que je ne saurai
toutes enumerer. Mention speciale a Elodie pour sa relecture de manuscrit pas du tout au der-
nier moment (je me demanderai longtemps comment tu as fait pour faire un travail pareil en si
peu de temps). Je souhaite a Romain que sa fin de doctorat soit aussi agreable que la mienne et
au final trois docteurs pour trois enfants, merci beaucoup a nos parents de nous avoir supportes
dans nos etudes.
Je profite egalement de ces lignes pour adresser un grand merci a la joyeuse troupe que nous
avons constituee ces dernieres annees, que les noms de Bibinne, Gerd, Censhi, Dezou, Ecknouille
et autres Sysy et Baba nous accompagnent encore de longues annees.
Et enfin, last but definitively not least, j’adresse un enorme merci du fond de mon coeur a Lætitia.
Me supporter a tous les sens du terme est deja un exploit en soi, mais ce que tu fais tous les
jours avec moi et pour moi, ainsi que tout ce que nous construisons ensemble me donne une
envie folle de me depasser pour vous. Je termine ce paragraphe avec un petit mot pour Emma,
quand tu liras ce texte, passe donc faire un calin a ton pere.
4
Table des matieres
Table des figures 9
Glossaire 13
Introduction 17
1 Objectifs de l’etude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Cadre de l’etude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Structure du rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Placement automatique d’objets . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Generation automatique d’exterieur de batiment . . . . . . . . . . . . . . 25
3.4 Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapitre 1 Etat de l’art relatif a la generation d’environnements urbains 29
1.1 Zone urbaine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.2 Reseau routier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.2.2 Methodes issues de l’analyse d’image . . . . . . . . . . . . . . . . . . . . . 32
1.2.3 Methode quasi-semantique . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.2.4 Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.2.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.3 Blocs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.4 Parcelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.4.1 Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.4.2 Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.5 Exterieurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.5.1 Methodes non automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.5.2 Methodes automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5
Table des matieres
1.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.6 Plan de batiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.6.1 Algebre de Manhattan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.6.2 EAAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.6.3 ARCHIPLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1.6.4 HM2PH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
1.7 Interieurs meubles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.7.1 Approches manuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.7.2 Approches semi-automatiques . . . . . . . . . . . . . . . . . . . . . . . . . 62
1.7.3 Approches automatiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
1.8 Conclusion et perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
1.8.1 Niveaux de detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
1.8.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
1.8.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Chapitre 2 Placement automatique d’objets 77
2.1 Metaheuristiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.1.1 Panorama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.1.2 Differents types de metaheuristiques . . . . . . . . . . . . . . . . . . . . . 86
2.1.3 Analyse des metaheuristiques . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
2.2.1 Operateurs de Minkowski pour les contraintes geometriques . . . . . . . . 96
2.2.2 Domaines et objets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.2.3 Contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
2.3 Limitations actuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.3.1 Limitation a la convexite . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
2.3.2 Du placement aleatoire dans un polygone . . . . . . . . . . . . . . . . . . 105
2.3.3 Ni 2D, ni 3D : 2D et demi . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.4 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Chapitre 3 Generation de facades 113
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.2 Gabarits de Facades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.2.1 Grammaire de murs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.2.2 Mise en œuvre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.3 Gabarits de toits et de fondations . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6
3.3.1 Gabarits de fondations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.3.2 Gabarits de toits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.4 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.4.1 Format de fichier et mode operatoire . . . . . . . . . . . . . . . . . . . . . 131
3.4.2 Performance et complexite . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3.4.3 Exemple de gabarit de facades . . . . . . . . . . . . . . . . . . . . . . . . 134
3.5 Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
3.6 Conclusions et travaux futurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Conclusions et perspectives 141
Annexes 147
Annexe A Oktal Synthetic Environment 147
A.1 Identite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
A.2 Competences generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
A.3 Les clients d’OktalSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Annexe B Approche CSP 151
B.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
B.2 Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
B.3 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
B.4 Types de CSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
B.4.1 CSP numeriques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
B.4.2 CSP hierarchiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
B.4.3 CSP dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
B.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Annexe C L-System 155
C.1 Origine (sic) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
C.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
C.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Annexe D Modelisation declarative 159
D.1 Presentation generale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
D.2 Les trois phases de la modelisation declarative . . . . . . . . . . . . . . . . . . . . 162
D.2.1 La phase de description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
D.2.2 La phase de generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
D.2.3 La phase de visualisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7
Table des matieres
Annexe E Approches manuelles 167
Bibliographie 171
8
Table des figures
1 Les trois phases de la modelisation declarative. . . . . . . . . . . . . . . . . . . . 19
2 Visualisation vectorielle, visible et infrarouge d’une partie de l’aeroport de Blagnac 20
3 Decomposition hierarchique de la generation d’une ville . . . . . . . . . . . . . . 24
4 Exemple de resultats obtenus avec notre outil de generation de facades de batiments 26
1.1 Detail du centre ville de Canberra (Australie) . . . . . . . . . . . . . . . . . . . . 31
1.2 Differents types de troncons d’un reseau routier dans VUEMS [Don04] . . . . . . 35
1.3 Un reseau routier genere a partir de donnees en entree [PM01] . . . . . . . . . . 37
1.4 Exemple de schemas urbains [Lie96], de gauche a droite : (a) concentrique, (b)
radial, (c) echiquier, (d) diamant. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.5 Differentes etapes successives de generation de geometrie complexe a base de
graphtales [MBST01] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.6 Generation d’une zone urbaine a partir d’un L-System et de regles de contraintes
environnementales et topographiques [MBST01] . . . . . . . . . . . . . . . . . . . 41
1.7 De gauche a droite : routes, blocs et parcelles [PM01] . . . . . . . . . . . . . . . . 43
1.8 Exemples de parcellisation de blocs [Per06] . . . . . . . . . . . . . . . . . . . . . 45
1.9 Exemple d’espace de solution reduit a cause de la discretisation de l’espace [Lie96] 46
1.10 Exemple de realisations du projet LaHave [RMS96] . . . . . . . . . . . . . . . . . 48
1.11 Exemple de chateau-fort genere avec le Castle Construction Kit [GBHF05] . . . . 49
1.12 Differentes etapes de derivation [PM01] . . . . . . . . . . . . . . . . . . . . . . . 50
1.13 Reconstruction de l’Empire State Building (New York City) [PM01] . . . . . . . 51
1.14 Reconstruction d’un batiment existant (a gauche) a Rennes. Le modele virtuel,
utilisant les FL-system est montre a droite[Per06] . . . . . . . . . . . . . . . . . . 52
9
Table des figures
1.15 Un autre batiment de Rennes. Ce modele utilise le meme FL-system que la figure
precedente, seuls les elements terminaux et les textures ont ete modifies.[Per06] . 52
1.16 Cette image montre plusieurs batiments generes a l’aide des split grammar [WWSR03] 53
1.17 De gauche a droite : (a) donnee en entree (image rectifiee d’une facade), (b)
facade automatiquement subdivisee et encodee comme un arbre de forme, (c)
modele polygonal et enfin (d) rendu du resultat final incluant ombres et reflections
rendues possibles par les informations semantiques [MZWG07] . . . . . . . . . . 53
1.18 Incoherences geometriques resolues dans [MWS+06] . . . . . . . . . . . . . . . . 55
1.19 Exemples de batiments generes par BatiMan [Cha98] . . . . . . . . . . . . . . . 56
1.20 Exemple de batiment generes par AGETIM [LLGC+05] . . . . . . . . . . . . . . 56
1.21 3 solutions au probleme de Maculet [Mac91] . . . . . . . . . . . . . . . . . . . . . 58
1.22 Exemples de resultats obtenus par EAAS [Cha95] . . . . . . . . . . . . . . . . . . 59
1.23 Deux solutions geometriques differentes avec la meme topologie [MY01] . . . . . 60
1.24 Scene comprenant environ 500 objets generee en 25min grace a CAPS (par pla-
cement et ajustements interactifs) . . . . . . . . . . . . . . . . . . . . . . . . . . 63
1.25 Exemples de resultats de WordsEyes a partir de descriptions textuellese. . . . . . 64
1.26 Oranos dans DEM2ONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
1.27 Un exemple de scene generee par Manhattan [LRG03] . . . . . . . . . . . . . . . 69
1.28 Probleme de placement bidimensionnel dans un environnement fige [LR03] . . . . 71
1.29 Image reconstruite a partir des resultats obtenus avec le solveur DEMONS-GA
[SRGL03] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.1 Exemples de vallees et plateaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.2 Importance du choix de la caracteristique tabou. . . . . . . . . . . . . . . . . . . 88
2.3 Somme de Minkowski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.4 Soustraction de Minkowski . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.5 Occupation au sol : rectangle englobant (gauche) et enveloppe convexe (droite) . 100
2.6 Choix des contraintes a satisfaire lors de l’ajout d’un nouvel objet dans la scene. 101
2.7 Contraintes d’orientation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.8 Problemes faciles et difficiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.9 Distances minimale et maximale entre le point de reference et l’enveloppe dans le
cas d’un rectangle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10
2.10 Premiere scene resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.11 Seconde scene resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.12 Interface de DEMONS LE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.1 De haut en bas : donnees d’entree (embase de batiment), premiere etape de
derivation, preparation des extrusions et batiment final. . . . . . . . . . . . . . . 113
3.2 Details du batiment decrit dans la Figure 3.1. . . . . . . . . . . . . . . . . . . . . 116
3.3 Diagramme de classes de notre systeme de generation de facades . . . . . . . . . 116
3.4 Un exemple de suppression des faces de fond d’un pan de mur . . . . . . . . . . . 119
3.5 Exemple de mur a bordures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.6 Mur extrude avec une profondeur negative. . . . . . . . . . . . . . . . . . . . . . 121
3.7 Un exemple de mur extrude referencant un objet tridimensionnel (les piliers au
premier plan). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.8 Un exemple de grille de mur horizontale. . . . . . . . . . . . . . . . . . . . . . . . 122
3.9 Un exemple de grille de mur bidirectionelle. . . . . . . . . . . . . . . . . . . . . . 122
3.10 Un exemple de liste de mur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.11 Regle de redimensionnement pour une liste de murs verticales. . . . . . . . . . . 124
3.12 Les trois differents types de gabarits de fondations. De gauche a droite, z min, z
max et extrude. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.13 Axe median (au centre) et squelette droit (a droite) d’un polygone simple . . . . 127
3.14 Vue de profil d’un toit a deux pentes standard. . . . . . . . . . . . . . . . . . . . 128
3.15 Vue de profil d’un toit a deux pentes mansarde. . . . . . . . . . . . . . . . . . . . 128
3.16 Vue de profil d’un toit a deux pentes de type grange. . . . . . . . . . . . . . . . . 128
3.17 Exemples de toits generes par differents gabarits de toits a deux pentes. De gauche
a droite : deux pentes standard, mansarde, grange. . . . . . . . . . . . . . . . . . 129
3.18 Vue de profil d’un toit a quatre pentes de type porche. . . . . . . . . . . . . . . . 130
3.19 Vue de profil d’un toit a quatre pentes de type alsacien. . . . . . . . . . . . . . . 130
3.20 Exemples de toits pour divers gabarits de toits a quatre pentes. De gauche a
droite : quatre pentes standard, mansarde, pagode, porche, alsacien. . . . . . . . 131
3.21 Trois batiments generes a partir de la meme embase. . . . . . . . . . . . . . . . . 132
3.22 Etat actuel de notre editeur de gabarit de batiments. . . . . . . . . . . . . . . . . 133
11
Table des figures
3.23 Zone urbaine constituee de 17 362 batiments, la generation s’effectue en 7mn 55
sec pour 920 182 faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
3.24 Exemple de batiment genere a partir du gabarit de facades decrit en 3.4.3. . . . . 135
3.25 Exemple de grammaire utilisee pour generer le batiment presente dans la Figure
3.24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
3.26 Details des differents pas de derivations necessaires a la creation du batiment
presentes dans la Figure 3.25 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
1 Cette image montre l’espace perdu a cause des ouvertures pour le placement des
meubles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
2 Exemple des donnees multimedia disponibles pour la place du Capitole a Toulouse
au sein du logiciel Google Earth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3 Exemple de zones urbaines genere en couplant notre systeme de generation de
batiments avec le prototype de notre methode de generation de reseau routier. . 144
4 Exemple de partition d’un etage de batiment en pieces par notre methode. . . . . 145
C.1 Plante generee par un L-System simple . . . . . . . . . . . . . . . . . . . . . . . . 158
D.1 La modelisation declarative : un domaine pluri-disciplinaire. Schema initial par
Champciaux [Cha98], etendu par Gaildrat [Gai03] . . . . . . . . . . . . . . . . . 162
D.2 Les trois phases de la modelisation declarative [CDMM97]. . . . . . . . . . . . . 163
D.3 Interaction multimodale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
E.1 Plan et vue crystal view d’une maison cree par Architecte 3D (Punch Software) 167
E.2 Plan et facade d’une maison cree par Architecte et Construction 3D (Anuman
Interactive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
E.3 Exemple d’interface graphique, 3D Architecte Expert CAD 2008 (edite par Micro
Application) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
E.4 Exemple de rendu final, 3D Architecte Expert CAD 2008 (edite par Micro Ap-
plication) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
12
Glossaire
Sigles
CAO Conception assistee par ordinateur
CAPS Constraint-based Automatic Placement System : Systeme de placement automatique
base sur les contraintes
CSP Constraint Satisfaction Problem : Probleme de satisfaction de contraintes
DEM2ONS DEclarative Multimodal MOdeliNg System
DHNCSP Dynamic Hierarchic Numeric CSP
EAAS Environnement d’aide a l’amenagement spatial
MGII Modelisation geometrique et infographie interactive
IA Intelligence artificielle
IHM Interaction Homme Machine
IRIN Institut de recherche en informatique de Nantes
IRIT Institut de recherche en informatique de Toulouse
RO Recherche operationnelle
RV Realite virtuelle
SIRV Synthese d’images et realite virtuelle
Modelisation declarative
CSP L’approche probleme de satisfaction de contraintes (CSP) [Mac77] est une famille de tech-
niques constructives generales. Cette approche est constructive : la solution est construite
13
Glossaire
graduellement. Comme ces algorithmes sont bases sur un processus d’enumeration, ils sont
deterministes et exhaustifs donc complets. Un CSP est un triplet P = (V,D,C) defini par :
– un ensemble de variables V = X1, ..., Xn.
– un ensemble de domaines D = D1, ..., Dn, ou Di un ensemble de valeurs, est le domaine
associe a la variable Xi.
– un ensemble de contraintes C = C1, ..., Cm, ou Ci est une contrainte definie par une
relation sur un sous-ensemble des variables.
Deictique Element de linguistique qui sert a montrer, a designer un objet singulier determine
dans la situation.
Isothetique Parallele ou perpendiculaire aux axes du systeme de coordonnees cartesiennes de
notre monde virtuel.
Modelisation declarative La modelisation declarative est un cadre conceptuel pour la concep-
tion assistee de scenes ou de formes virtuelles. Son but est de soulager l’utilisateur lors
de la tache de conception en rendant possible la description d’un modele par le biais de
commandes d’un haut niveau d’abstraction, le liberant ainsi du modele geometrique sous-
jacent. Trois phases principales peuvent etre distinguees lors de l’utilisation d’un modeleur
declaratif :
1. la phase de description durant laquelle l’utilisateur decrit la scene en enoncant un
ensemble de commandes de haut niveau, appelees proprietes dans la plupart des
modeleurs declaratifs ;
2. la phase de generation qui calcule les solutions correspondantes [LDG05] ;
3. la phase de prise de connaissances qui permet a l’utilisateur de visualiser et de choisir
une solution particuliere dans le cas de l’exploration d’un domaine de recherche.
Ces trois phases sont parcourues successivement au sein d’un processus iteratif en spirale,
i.e. l’utilisateur peut affiner sa description en fonction des solutions obtenues.
Multimodal Combinant souris, clavier, geste, reconnaissance parole, casque de Realite Vir-
tuelle pour construire un seul evenement multimodal a partir de divers evenements mono-
modaux.
NP complet Non deterministe polynomial complet
NP-difficile Probleme au moins aussi complexe que n’importe lequel des problemes NP.
14
Metaheuristiques
Backtrack Retour arriere, methodes permettant de revenir en arriere afin de corriger la variable
qui bloque la recherche de la solution
Configuration complete Affectation de toutes les variables (les contraintes ne sont, a priori,
pas satisfaites).
Heuristique Methode concue pour un probleme d’optimisation donne, qui produit une solution
non necessairement optimale lorsqu’on lui fournit une instance d’un probleme.
Mecanisme d’exploration Procedure qui precise comment passer d’une configuration A a
une autre configuration A’ appartenant au voisinage de A.
Mouvement Operation elementaire permettant de passer d’une solution A a une solution A’
voisine de A.
Optimisation combinatoire Consiste a trouver le meilleur choix entre un nombre fini de
choix. Autrement dit, minimiser une fonction, avec contraintes, sur un ensemble fini.
Plateau Ensemble de solutions de meme cout, connexes par voisinage.
Solution Affectation de toutes les variables (les contraintes ne sont, a priori, pas satisfaites).
Solution optimale Solution optimisant la valeur de la fonction de cout.
Voisinage de A Ensemble des solutions A’ accessibles a partir de A en realisant un seul mou-
vement.
Generation urbaine
SIG Un systeme d’information geographique (SIG) permet de gerer des donnees alphanumeri-
ques spatialement localisees, ainsi que les donnees graphiques permettant d’afficher ou
d’imprimer plans et cartes. Ses usages couvrent les activites geomatiques de traitement et
diffusion de l’information geographique.
Le role du systeme d’information est de proposer une representation plus ou moins realiste
de l’environnement spatial en se basant sur des primitives graphiques telles que des points,
des vecteurs (arcs), des polygones ou des maillages (raster). A ces primitives sont associees
des informations qualitatives telles que la nature (route, voie ferree, foret, etc.) ou toute
autre information contextuelle.
15
Glossaire
L’information geographique peut etre definie comme l’ensemble de la description d’un
objet et de sa position geographique a la surface de la Terre.
En France, dans son acceptation courante, le terme fait reference aux outils logiciels.
Cependant, le concept englobe l’ensemble constitue par les logiciels, les donnees, le materiel
et les savoir-faire lies a l’utilisation de ces derniers.
16
Introduction
Cette these s’inscrit dans le cadre d’une collaboration CIFRE entre le groupe de recherche
VORTEX (Visual Objects : from Reality To EXpression) de l’IRIT (Institut de Recherche en
Informatique de Toulouse) d’une part, et la societe Oktal Synthetic Environment (c.f. Annexe A)
d’autre part.
Le groupe de recherche VORTEX1 aborde par ses differents travaux l’ensemble des problemati-
ques des objets visuels, qu’il s’agisse d’images, de videos, de scenes 2D et 3D. Ces problematiques
englobent les methodes, les modeles et les outils utilises pour traiter les objets visuels, reels,
virtuels et mixtes, en allant jusqu’a les doter, par creation ou par enrichissement, d’elements
permettant de les utiliser. Tout utilisateur, qu’il soit scientifique, ingenieur, artiste, formateur
ou medecin peut alors s’exprimer, independamment de son niveau de maıtrise technique.
Au sein du groupe de recherche VORTEX, la composante Modelisation, encadree par Veronique
Gaildrat, etudie les outils de modelisation d’environnements virtuels, et plus precisement les
outils de modelisation declarative (cf. Figure 1). Ces travaux sur la modelisation declarative
s’integrent dans une chaıne complete de production d’images de synthese, en apportant une aide
au concepteur dans la creation d’objets et de scenes. Au final, le processus aboutit a la creation
d’un environnement virtuel dans lequel le concepteur-utilisateur pourra ensuite evoluer. Le pro-
jet DEM2ONS (DEclarative Multimodal MOdeliNg System) regroupe les travaux de recherche
autour de la modelisation declarative. Ces travaux ont conduit au developpement de plusieurs
systemes de generation qui ont permis d’evaluer la pertinence de differentes approches pour le
placement contraint d’objets dans une scene tridimensionnelle.1Cree en 2007 par la fusion des equipes SIRV (Synthese d’Images et Realite Virtuelle) et VPCAB (VISION
PAR CALCULATEUR ANDRE BRUEL).
17
Introduction
Contrairement aux approches classiques (ou imperatives) qui necessitent des donnees numeriques
en entree, la modelisation declarative offre la possibilite de decrire une entite ou une scene a
modeliser en exprimant une simple image mentale de la scene (cette image peut etre floue).
Le concepteur n’a qu’a enoncer les attributs geometriques, photometriques et physiques de
l’environnement ainsi que les relations entre ces elements dans un langage quasi-naturel. Ces
proprietes permettent, a l’aide d’un ordre unique, de realiser une operation qui aurait demande
un nombre important d’actions elementaires avec un modeleur geometrique imperatif classique.
Ces proprietes sont ensuite interpretees en contraintes resolues par le systeme de generation
pour fournir un modele solution (cf Figure 1). Le but de la modelisation declarative n’est pas
de se substituer a la modelisation geometrique imperative, mais plutot de l’enrichir en four-
nissant des mecanismes permettant de faciliter la generation de scenes realistes. Pour cela, la
modelisation declarative cherche a tirer parti de toutes les informations semantiques sur l’en-
vironnement et les objets a placer, de facon a automatiser le mieux possible ce placement, en
evitant au concepteur des taches repetitives et fastidieuses. En plus de permettre un maniement
accessible a tous, le recours a la modelisation declarative engendre donc un gain de temps certain.
Le second initiateur de cette these est la societe Oktal SE. Cette societe a developpe une gamme
d’outils de visualisation capables d’effectuer des rendus d’une meme scene dans plusieurs do-
maines spectraux : infrarouge (bande I, II et III), radar, BNL (bas niveau de lumiere), acoustique
et bien sur visible. Pour generer ces scenes, Oktal SE utilise un modeleur de terrain multi-senseur
appele AGETIM (Atelier de GEneration de TerraIn Multi senseur). Le logiciel AGETIM per-
met de generer un environnement virtuel 3D a des fins de simulation ou de modelisation a un
niveau de realisme fixe par l’utilisateur. Ce logiciel fournit des moyens d’integration de donnees
cartographiques existantes, de correction ou d’enrichissement de ces donnees, des processus de
generation automatique d’environnement virtuel 3D et d’exploitation simple de cet environne-
ment. Afin d’offrir une plus grande simplicite d’utilisation et une ergonomie adaptee au traite-
ment de l’information cartographique heterogene, l’outil AGETIM s’appuie sur un standard en
matiere de Systemes d’Information Geographique (SIG), le logiciel GEOCONCEPT.
Les bases de donnees 3D generees en utilisant AGETIM peuvent etre tres etendues : la plus vaste
couvre actuellement le quart du territoire francais. Elles peuvent egalement etre tres detaillees,
en incluant par exemple les murs interieurs et le mobilier des batiments. La Figure 2 presente
trois representations des alentours de l’aeroport de Toulouse-Blagnac : representation vectorielle
18
Figure 1. Les trois phases de la modelisation declarative.
19
Introduction
Figure 2. Visualisation vectorielle, visible et infrarouge d’une partie de l’aeroport de Blagnac
qui donne un apercu de la complexite geometrique de la scene, representation dans le domaine
visible et enfin une representation en infrarouge.
Comme on peut le constater sur la Figure 2, la modelisation des alentours de l’aeroport apporte
une reelle plus value afin d’observer l’objet de l’etude dans son environnement naturel. Ne pas
integrer l’environnement immediat au sujet etudie, fait courir le risque aux utilisateurs de ne pas
prendre en compte les influences de l’environnement proche dans leur analyse et ce, quelque soit
la qualite de la modelisation du sujet principal. Par exemple, si l’on se restreint a une visualisation
dans le domaine visible, la presence de l’environnement permet de se rendre reellement compte
des notions d’echelles, de visibilite ou de distance. La modelisation du voisinage est encore
plus critique dans le cadre d’une visualisation dans les domaines infrarouge, electromagnetiques
ou BNL (bas niveau de lumiere, i.e. vision nocturne). Une visualisation electromagnetique qui
ne prendrait pas en compte des systemes radars situes a l’ecart des batiments principaux de
l’aeroport perdrait en realisme.
20
1 Objectifs de l’etude
Cette these a pour but d’etudier la possibilite d’enrichir AGETIM avec des modules de generation
automatique de zones urbaines.
En effet, lors de l’expression d’un besoin en terme de modelisation, il n’est pas rare que le
client soit sensible au fait qu’en plus de la modelisation fine (et exacte) de son sujet d’interet,
ses abords soient aussi modelises. Par exemple, si la mairie de Toulouse lance un appel d’offre
concernant la maquette 3D du Capitole (qui regroupe l’hotel de ville et l’opera de Toulouse), un
prestataire capable de fournir non seulement ce batiment, mais aussi un trajet pietonnier autour
du centre d’interet avec des batiments credibles, beneficie de solides atouts pour emporter le
marche. Cependant, meme si le voisinage du centre d’interet n’a pas a etre finement modelise,
il reste que la surface et le volume occupes par le voisinage sont generalement bien plus impor-
tants que ceux du centre d’interet. Il est donc necessaire d’etre capable de generer rapidement
un ensemble de batiments geospecifiques2, reprenant globalement les dimensions des batiments
reels, leurs aspects et decorations (balcons, renfoncements, etc.).
La modelisation de vastes bases de donnees 3D presente aussi un besoin particulier en terme de
modelisation de zone urbaine. Une des realisations d’AGETIM a notamment consiste a modeliser
un quart du territoire francais a des fins de simulation aeriennes. Une telle surface contient
un grand nombre de zones urbaines, allant du hameau a la capitale regionale. Les outils de
modelisation actuels (dont fait partie AGETIM) sont capables de traiter les bases de donnees car-
tographiques afin de generer des maquettes virtuelles representant les ensembles geographiques
existants :
– reliefs,
– cours d’eau et lacs,
– contours maritimes.
Les outils plus avances sont capables de representer les forets ainsi que les reseaux routiers. Selon
la finesse des bases de donnees cartographiques utilisees, les informations disponibles concernant
les zones urbaines peuvent enormement varier. Voici un apercu des informations disponibles,
classees de la plus vague a la plus precise :
– seules les limites de la zone urbaine sont disponibles, sous forme d’un polygone,
– ses grands axes de circulation sont presents (ou esquisses),2Geospecifique : un batiment geospecifique est la modelisation (potentiellement approchee) d’un batiment reel.
21
Introduction
– des axes intermediaires sont disponibles, et on observe un classement par role des parties de
cette ville (habitations, bureaux, industrie, centre commercial, espace vert, lac, etc.),
– la totalite du reseau routier est disponible, avec egalement les plans cadastraux (la limitation
des parcelles),
– enfin, on peut disposer dans le cas le plus precis, des contours exterieurs de tous les batiments,
voire de leurs hauteurs.
Cette liste montre bien la difficulte inherente a l’integration d’un outil de generation de zone
urbaine au sein d’un modeleur de terrain. Cet outil doit etre capable de prendre en compte des
donnees parcellaires, potentiellement erronees. En plus des capacites d’analyse et de rectification
de la donnee source, un outil de generation de zones urbaines doit etre capable de creer des
informations credibles. Ces informations ainsi creees doivent etre geotypiques3 afin de ne pas
perturber l’utilisateur parcourant la base de donnees.
Le premier objectif de cette these est de realiser une etude des solutions existantes pour repondre
a ces deux besoins :
– etre capable de generer des zones urbaines a partir d’informations geospecifiques disponibles,
– etre capable de creer de la donnee source geotypique.
Dans un second temps, nous avons decide de developper nos axes de travail en fonction de
l’interet potentiel d’un nouveau travail de recherche par rapport aux methodes existantes ainsi
qu’aux besoins specifiques d’AGETIM.
2 Cadre de l’etude
Les progres recents des applications de realite virtuelle, des jeux video ainsi que des simulations
d’expansion urbaine ont augmente la pertinence de l’utilisation de maquettes virtuelles pour les
etudes d’urbanisme. Par exemple, la croissance des cites entraıne des problemes emergents qui
necessitent la mise en place d’outils de prevision. Des modeles peuvent permettre de prendre en
compte l’influence des radiations electromagnetiques, la prediction de la propagation du bruit par
des modeles de pollution sonore ou encore l’anticipation des reseaux de transports necessaires.
Par ailleurs, la prochaine generation de Systemes Globaux de Navigation par Satellite (SGNS)
tirera avantage de l’utilisation de modeles de villes tridimensionnels. Ainsi, etre capable de3Geotypique : specifique a une zone geographique et a une epoque donnees
22
generer rapidement des modeles de villes credibles permettra d’aider l’utilisateur a effectuer ses
etudes de facon plus rapide et plus efficace.
La modelisation detaillee de zones urbaines represente un defi en informatique graphique. Une
ville reelle repond a des regles de construction (implicites ou explicites) et reflete souvent de
multiples influences historiques, culturelles et sociales a travers le temps. Atteindre une precision
suffisante pour qu’une ville virtuelle soit credible pour un utilisateur la visitant au niveau du
sol, demande une modelisation extremement detaillee qui exige bien trop de temps et d’efforts
de la part du concepteur. La capacite a generer rapidement des maquettes virtuelles credibles
permet de repondre a ce besoin et constitue donc un sujet d’avenir qui doit se developper car
les resultats actuels ne satisfont pas les besoins precedemment definis.
3 Structure du rapport
Ce memoire s’articule en trois parties, etat de l’art, placement automatique d’objets et enfin
generation de automatique de zones urbaines.
3.1 Etat de l’art
La premiere partie de ce memoire propose un etat de l’art des methodes existantes permettant
la generation, automatique ou non, de zones urbaines.
Une zone urbaine represente, la plupart du temps, un ensemble de donnees trop important
pour etre apprehende, modelise ou meme visualise directement. Utiliser une approche multi-
resolution, a base de structures logiques imbriquees, permet de decomposer directement cet
ensemble en niveaux de detail successifs, afin de permettre un traitement plus cible. Il s’agit
ici de niveaux de detail logiques et non pas uniquement de niveaux de detail comme objets
de substitution lors d’une visualisation tridimensionelle. La pertinence de l’approche multi-
resolution, nous amene a presenter un etat de l’art des differentes techniques mises en œuvre
pour generer automatiquement une zone ur baine, conformement au decoupage en niveau de
detail.
La Figure 3 presente un decoupage hierarchique de la tache de generation d’une ville en sept
etapes. Inspire par les travaux de Parish et Mueller dans [PM01], ce decoupage est utilise comme
plan de cet etat de l’art pour exposer les differentes methodes existantes. Certains travaux
couvrent plusieurs etapes, ils seront donc cites plusieurs fois. En fonction de la complexite de
23
Introduction
Figure 3. Decomposition hierarchique de la generation d’une ville
chaque etape, nous proposons une breve presentation du formalisme et des donnees traitees ainsi
qu’une discussion sur les methodes de generation presentees. Une etape peut etre assimilee a un
niveau de detail lors d’une representation multi-echelle de la ville.
3.2 Placement automatique d’objets
Nous avons ensuite etudie le probleme de placement d’objets, qui correspond a la derniere des
etapes presentees a la Figure 3. Cette etape prend la suite de travaux deja effectues au sein de
notre equipe. Nous presentons dans cette partie une etude de l’application de methodes issues de
la recherche locale pour resoudre le placement d’objets au sein d’un probleme modelise par des
contraintes. Les objets traites sont definis par l’enveloppe convexe de leur projection orthogra-
phique au sol, et peuvent prendre une orientation quelconque. Pour pouvoir prendre en compte
ces deux particularites, nous avons eu recours aux operateurs de Minkowski sur les polygones
convexes pour le calcul de la validite de nos contraintes.
Nous presentons le modeleur declaratif DEMONS LE qui a ete developpe pour evaluer la per-
tinence de cette approche. Ce modeleur est une variante du modeleur DEM2ONS developpe
precedemment dans notre equipe. Ce developpement a servi de base a l’evaluation de l’utilisa-
tion des metaheuristiques issues de la recherche locale ainsi que des operateurs de Minkowski.
24
De plus, ce travail nous a permis de proposer la possibilite a un utilisateur, non expert dans la
modelisation 3D, de generer facilement, rapidement et intuitivement des scenes complexes. Ceci
se traduit non seulement au niveau de la specification de l’interface utilisateur, mais egalement
dans l’expression des proprietes entre les objets de la scene.
3.3 Generation automatique d’exterieur de batiment
Le troisieme chapitre s’attache a presenter l’outil que nous avons developpe dans le cadre de
cette these pour la generation automatique de batiments (sans interieurs). Cet outil a pour but
de creer la maquette numerique d’un batiment, decompose en fondations, facades et toits. Notre
methode est basee sur la definition de gabarits de batiments qui sont appliques a des descriptions
de batiments. Une description est constituee de l’embase tridimensionnelle, de la hauteur de toit
et de la hauteur des murs du batiment. Nous proposons plusieurs modes de generation pour
chacune de ces composantes. La contribution la plus notable de cette partie est la generation
des facades de batiments a partir de gabarits de facades. Les facades de batiments sont creees en
utilisant une grammaire de murs tridimensionnelle isometrique, basee sur un ensemble de regles.
Ces regles peuvent etre simples ou tres detaillees en fonction des besoins de l’utilisateur.
La Figure 4 presente un exemple de resultat obtenu avec notre outil de generation de facades de
batiments. Nous pouvons y voir les details de deux facades de batiments qui entourent la place
du Capitole a Toulouse. Les textures utilisees pour le rez-de-chaussee correspondent aux devan-
tures reelles. Une fois l’arche de l’arcade modelisee manuellement, toute la geometrie restante
(notamment les decrochements autour de chaque fenetre) a ete generee de facon automatique
par notre outil. Le gabarit ainsi cree, bien que correspondant a un batiment reel, peut etre
applique a une description quelconque de batiment, et s’y adaptera au mieux, en faisant varier
le nombre d’etages ou de fenetres dans les limites permises par le gabarit.
3.4 Annexes
Afin de faciliter la lecture et la comprehension des trois principaux chapitres de ce memoire,
nous avons reporte en annexe un certain nombre de definitions et descriptions.
L’annexe A presente la societe Oktal Synthetic Environment ainsi que ses activites.
L’annexe B propose une definition et un apercu de l’approche CSP (probleme de satisfaction de
contrainte) qui est utilisee dans certains travaux de notre etat de l’art (notamment la generation
de plans de batiments ainsi que les problemes d’amenagement d’interieurs).
25
Introduction
Figure 4. Exemple de resultats obtenus avec notre outil de generation de facades de batiments
26
L’annexe C presente les L-System, auxquels font appel les etapes de generation de reseau urbain
et facades de batiments.
L’annexe E decrit certains logiciels du commerce permettant de creer des modeles numeriques
de batiments.
L’annexe D presente les concepts et les definitions relatifs a la modelisation declarative utilisee
pour la generation de batiments et le placement des objets dans les pieces.
27
Chapitre 1
Etat de l’art relatif a la generation
d’environnements urbains
Dans ce chapitre, nous utilisons le terme generique de ville pour designer une zone dans laquelle
on trouve un reseau routier et des batiments. Cette zone peut aussi bien definir un hameau
qu’une megapole.
1.1 Zone urbaine
La generation d’une ville necessite au minimum de connaıtre ses limites physiques (ou geogra-
phiques). Nous considerons comme niveau le plus vague d’information, la definition de la surface
que couvre (ou doit recouvrir) cette ville.
Cette information est generalement definie au sein d’un SIG (Systeme d’Information Geo-
graphique). Il est egalement possible de contraindre la definition de la zone urbaine afin de
prendre en compte des donnees supplementaires en entree. Ces informations complementaires
sont generalement donnees sous forme de cartes :
– altimetriques : les routes sont generalement perpendiculaires ou paralleles aux lignes de ni-
veaux ;
– hydrographiques (surfaciques : mer, lac, etang, delta, etc. ou vectorielles : fleuve, riviere) :
le reseau routier traite differemment ces zones, en les evitant, ou en les traversant (pont ou
tunnel) ;
– de vegetation : generalement les zones de vegetation sont contournees par le reseau routier ;
29
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
– de densite de population : cette donnee modifie de deux facons le reseau routier, premiere-
ment, le reseau routier secondaire est affecte (rue, residence), ensuite le reseau routier primaire
presente des axes a plusieurs voies qui relient les zones a forte densite de population (auto-
routes, voies rapides) ;
– de schemas de construction de reseau routier.
A partir des informations donnees lors de la definition de la zone urbaine, les differentes etapes
de generation permettent de modeliser la ville dans son integralite. La premiere de ces etapes,
qui genere le reseau routier, est la seule a traiter la zone urbaine dans son ensemble. Les deux
etapes suivantes, qui generent les blocs et les parcelles, realisent deux partitions successives de
la zone urbaine ce qui permet de reduire la complexite de ces taches. Enfin, les trois dernieres
etapes traitent des batiments, de la generation des exterieurs (facades, fondations et toits), a
celle des plans de batiments pour finir avec le placement de mobilier au sein des pieces.
1.2 Reseau routier
1.2.1 Presentation
La forme la plus couramment rencontree pour representer les reseaux routiers est le graphe. Un
graphe value permet de stocker, en plus de la geometrie, des informations telles que la densite
de trafic, le nombre et la largeur des voies ou leur sens de circulation. Les algorithmes existants
en theorie des graphes permettent d’obtenir des donnees supplementaires, comme par exemple,
le plus court chemin d’un point a un autre.
Meme s’il paraıt illusoire de tenter de caracteriser les villes existantes selon des schemas predefinis
de trace de routes, certains schemas, notamment ceux presentes dans la Figure 1.4 peuvent
etre utilises lors de la generation. On peut, par exemple, constater que la plupart des villes
americaines sont concues selon un schema de damier, tandis que les villes europeennes reposent
plus souvent sur un schema radiocentrique. Neanmoins, ces observations sont a ponderer par le
fait que la structure d’une ville est amenee a evoluer dans le temps en fonction de contraintes
geographiques, sociales et economiques. En pratique, on observe plutot une composition de
schemas au sein d’une meme ville. La Figure 1.1 montre un reseau routier qui presente la
composition de plusieurs schemas, principalement les schemas radiocentriques et en damier.
30
On reconnaıt en bas de l’image deux noyaux de schemas routier radiocentriques. Tandis que les quartier au nord
presentent les caracteristiques de schemas routiers en damier.
Figure 1.1. Detail du centre ville de Canberra (Australie)
31
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
1.2.2 Methodes issues de l’analyse d’image
1.2.2.1 Extraction du reseau routier
Il existe trois familles de methodes d’extraction de reseaux routiers a partir d’image (photogra-
phique ou radar) :
– les methodes d’extraction locale ;
– les methodes de poursuite ;
– les methodes de reconnexion de graphes.
Dans la plupart des approches, le probleme peut etre ramene a un probleme d’extraction de
structures lineaires.
1.2.2.2 Les methodes locales
Ce premier type de methode vise a detecter dans une image des zones presentant les ca-
racteristiques locales d’une route. Ces methodes recherchent des segments (ou des points) pou-
vant appartenir a des routes. En pratique, on simplifie le probleme initial de detection des
troncons de routes en un probleme de detection de structures lineaires fortement contrastees
avec leur voisinage immediat (i.e. de radiometrie foncee ou claire).
Les principales methodes locales reposent sur la morphologie mathematique [CML01] ou la trans-
formee de Hough [DG02]. Ces methodes ne sont, la plupart du temps, pas capables de detecter
le reseau routier dans sa totalite, mais elles sont en mesure d’en trouver les portions princi-
pales. Elles peuvent cependant generer un taux significatif d’erreur. Les methodes locales sont
rarement utilisees seules, toutefois, elles presentent un interet certain en realisant un traitement
initial des donnees pour obtenir une amorce de reseau routier.
Nous allons a present detailler les methodes de poursuite et de reconnexion, des algorithmes de
plus haut niveau qui peuvent utiliser cette amorce pour realiser l’extraction de la totalite du
reseau routier.
1.2.2.3 Les methodes de poursuite
Ces methodes d’extraction sont basees sur le suivi de structures. Elles sont iteratives et ont pour
principe le chaınage successif de tous les pixels d’une structure en partant d’une amorce.
Pour chaque section de la structure lineaire decrivant le reseau routier en cours d’extraction, le
systeme s’efforce de choisir le prochain pixel qui permettra de faire croıtre cette structure.
32
Les methodes de poursuite ont en commun la necessite de connaıtre une structure initiale
(potentiellement ponctuelle). Celle-ci peut avoir ete renseignee par l’utilisateur ou obtenue
de facon automatique par une des methodes locales precedemment decrites. Ces algorithmes
presentent l’avantage (propre aux algorithmes iteratifs) d’evoluer de facon autonome. Cepen-
dant, ils peuvent etre delicats a controler si les criteres de poursuite n’ont pas ete correctement
definis (en fonction du type de reseau routier).
Parmi les methodes de poursuite, nous pouvons par exemple citer les methodes dites de suivi
structurel (ou de ”tracking”) [GJ96] et celles a base de programmation dynamique [GL95].
1.2.2.4 Les methodes de reconnexion
Ces methodes realisent l’extraction du reseau routier par reconnexion de graphes. Elles sont
utilisees principalement en sortie des methodes de poursuite et des methodes locales, car elles
permettent de lever deux des defauts inherents a ces methodes.
Premierement, les methodes de reconnexion permettent de valider les resultats en supprimant
les fausses alarmes (detection d’erreur). Deuxiemement, elles sont a meme de completer un
resultat en connectant divers troncons de la meme route. Les methodes de reconnexion reposent
sur l’utilisation de la topologie des objets a extraire, et permettent, dans notre cas, de passer
d’un resultat compose d’une nuee de troncons de routes a la representation globale d’un reseau
routier.
De nombreux travaux sont classes parmi ces methodes : certains reposent sur une approche baye-
sienne [Tup97], d’autres sur l’approche des processus ponctuels marques [Sto01], sur la logique
floue [WHMJ98] ou encore les algorithmes genetiques [HL01].
Les differentes methodes citees ci-dessus ont pour point commun de s’efforcer de creer la re-
presentation virtuelle d’un reseau routier existant. Ce reseau routier peut etre utilise comme
donnee d’entree pour un systeme de generation de zone urbaine. Cependant, certaines applica-
tions requierent des donnees de plus haut niveau semantique, ou des modeles plus simples pour
la navigation temps reel. C’est pourquoi il nous a paru interessant de privilegier l’etude des
methodes procedurales. Celles-ci ont egalement pour but d’etre capables de creer des reseaux
routiers non existants.
33
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
1.2.3 Methode quasi-semantique
Nous reprenons ici la description realisee par Julien Perret dans son manuscrit de these [Per06]
des travaux realises au sein de son equipe de recherche par ses encadrants, Stephane Donikian
et Gwenola Thomas.
L’application proposee par l’equipe SIAMES4 [Tho99] en collaboration avec la societe IVT com-
bine les contraintes de generation d’informations semantiques et de controle de la complexite
du modele. En effet, l’objectif de cette application est la visualisation en temps reel de pietons
en environnement urbain informe semantiquement (voies de circulation pietons/vehicules, sens,
etc.). Une approche (quasi) semantique est justifiee dans ce cadre, puisque les humanoıdes, afin
d’etre autonomes, necessitent des informations autres que celles concernant la geometrie.
Ainsi, l’environnement de modelisation VUEMS5 [Don97, Tho99] est utilise pour traiter une
base de donnees existante et permet l’introduction du reseau routier, de la signalisation, du
mobilier urbain, des batiments, des places et des espaces verts. L’environnement ainsi construit
est utilise par une application simulant le deplacement de centaines de pietons autonomes et la
navigation en temps reel. Dans cette phase de ses travaux, l’equipe SIAMES ne s’interesse pas
a la partie simulation du modele mais plutot aux representations de l’environnement urbain.
Ainsi, afin de representer la voirie, chaque rue est decomposee en troncons.
De plus, un corpus de 12 types de troncons de reseau routier a ete defini et est illustre par la
Figure 1.2. Chaque troncon est lui-meme compose de troncons elementaires, ce qui permet de
construire le graphe de connexite entre les differents troncons.
Pour completer le graphe ainsi constitue, un tissu urbain compose de batiments, d’espaces verts
et d’autres zones de circulation est ajoute, ainsi qu’un second graphe de passages qui est utilise
pour la navigation des pietons virtuels [Don04].
1.2.4 Generation
Nous allons a present decrire des methodes de generation automatique de reseaux urbains. Si le
but de ces methodes peut occasionnellement etre de recreer des reseaux urbains existants, leur
interet principal reside dans leur capacite a generer des reseaux urbains credibles a partir de
donnees reelles ou imaginaires. Cette particularite rend ces approches tres utiles pour fournir
des donnees d’entree afin d’evaluer les methodes de generation de batiments.4Synthese d’Images, Animation, Modelisation Et Simulation5A Virtual Urban Environment Modeling System
34
Figure 1.2. Differents types de troncons d’un reseau routier dans VUEMS [Don04]
35
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Differents travaux de recherche ont ete menes afin de proposer des solutions pour cette etape. Ces
travaux font appel a differents mecanismes, notamment les L-System, la modelisation declarative
et les graphtales.
1.2.4.1 L-System
Parmi les travaux qui utilisent les L-System (voir Annexe C), CityEngine [PM01] propose des
resultats particulierement interessants.
CityEngine est constitue d’une chaıne entiere d’outils couvrant les quatres premieres etapes
presentees dans cet etat de l’art. A savoir : la generation du reseau routier, les etapes de par-
titionnement des blocs et parcelles, ainsi que la generation des exterieurs des batiments. La
contribution la plus remarquable de ces travaux au probleme de generation de zones urbaines
est l’utilisation d’une extension des L-System pour la creation d’un reseau routier.
Concevoir un systeme complexe de regles pour creer un reseau routier conduit a introduire
un grand nombre de parametres et de conditions qui doivent etre integres dans la grammaire
formelle sur laquelle le L-System est base. L’introduction d’une nouvelle contrainte oblige a
reecrire de nombreuses regles, ce qui rend difficile l’extension du systeme. Au lieu de faire croıtre
l’ensemble des regles de facon exponentielle, les auteurs ont defini une extension des L-System
qui cree a chaque etape de derivation des successeurs generiques appeles successeurs ideaux.
Les parametres de ces successeurs ne sont pas instancies. C’est l’appel a une fonction objectif
global qui instancie ces parametres de facon a ce qu’elle soit satisfaite. Ensuite, le systeme verifie
que ces parametres satisfont les contraintes locales et les modifient si besoin.
Les fonctions d’objectifs globaux (dont les zones d’influence sont definies par l’utilisation des
cartes definies en 1.1) evaluent la validite des parametres des segments de route en cours de
construction (cf. Figure 1.3) :
– densite de population : les zones les plus peuplees doivent etre reliees par des routes, tandis
que les rues doivent se developper dans les zones residentielles et etre reliees a la route la plus
proche ;
– schemas du reseau routier : cet objectif global assure la coherence de la ville avec les schemas
choisis.
La fonction de contraintes locales ajuste les parametres proposes par la fonction d’objectif global
afin de satisfaire les contraintes environnementales locales. Par exemple, un nouveau segment de
route peut voir sa direction initialement definie par la fonction d’objectif global (relier deux zones
36
A gauche : cartes d’hydrographie, d’elevation et de densite de population d’une ville virtuelle
Figure 1.3. Un reseau routier genere a partir de donnees en entree [PM01]
37
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
tres peuplees) modifiee afin de tenir compte des caracteristiques locales (presence d’une falaise).
Lorsque aucun ajustement n’est possible, le segment de reseau routier concerne est efface grace
a une regle de production du L-System. Cet effacement peut etre la consequence de la rencontre
d’un certain nombre de situations : reseau routier suffisamment fin dans la zone traitee, presence
d’une surface interdite au reseau routier (parc, plan d’eau, zone generee manuellement) ou
rencontre avec un element du relief incompatible avec les capacites de franchissement (longueur
maximale d’un segment) du segment de reseau routier actif (cas d’une falaise ou d’une riviere).
Les L-System n’ont pas ete crees pour representer des graphes cycliques (circuits), mais dans un
reseau routier, les differentes routes et rues sont generalement connexes et les impasses sont peu
nombreuses. Il faut donc considerer le L-System non plus comme un arbre, mais plutot comme
un reseau. Pour ce faire, la distance entre le segment cree et le reseau existant est testee et
en dessous d’un seuil de proximite, l’extremite du segment est modifie de facon a rejoindre le
reseau. Ces modifications permettent de regrouper les intersections entre les axes aux extremites
des segments de rues, creant naturellement des croisements entre plusieurs axes (plus de de deux
axes).
1.2.4.2 Modelisation declarative de segments de droite
Dans [Lie96], Sylvain Liege applique au domaine de la conception urbaine l’approche de la
modelisation declarative (cf. Annexe D). Il met en evidence les notions d’elements urbains qui
peuvent etre combines afin de composer des figures urbaines plus complexes. Le processus de
description du reseau routier est mene de facon hierarchique et incrementale [LH97]. Le concep-
teur debute par une description grossiere, donnant uniquement les traits caracteristiques tels
que grands axes et croisements. Cette description est utilisee pour proposer une ou plusieurs
solutions que le concepteur pourra affiner. Le processus de generation est base sur un algorithme
de propagation de contraintes et un modele de scene.
Le principal inconvenient du processus de generation choisi est qu’il repose sur un espace faible-
ment discretise, ce qui restreint la quantite de configurations possibles et donc de solutions.
1.2.4.3 Generation de motifs pseudo-urbains
Le laboratoire ARIA6 de l’Ecole d’Architecture de Lyon possede une thematique de recherche
qui s’articule selon deux directions : un generateur de graphtale qui, a partir de simples regles6Applications et Recherches en Informatique pour l’Architecture - www.aria.archi.fr
38
(a) (b) (c) (d)
Figure 1.4. Exemple de schemas urbains [Lie96], de gauche a droite : (a) concentrique, (b)
radial, (c) echiquier, (d) diamant.
binaires basees sur le formalisme des L-System, produit rapidement des geometries complexes
(Figure 1.5) et un generateur de schemas multi-echelle qui utilise le precedent moteur base sur
les L-System et des regles de contraintes environnementales et topographiques (Figure 1.6).
La combinaison de l’approche fractale avec un moteur de generation base sur les L-System
permet d’obtenir rapidement des resultats varies. Malheureusement, cette rapidite entraıne aussi
des imperfections telles que des collisions de batiments ou des reseaux routiers sans coherence.
1.2.5 Discussion
Les deux methodes procedurales basees sur les L-System (CityEngine et une partie des travaux
du laboratoire ARIA) proposent des resultats a l’echelle d’une ville. Parmi les travaux de re-
cherche existants dans ce domaine, CityEngine fait office de reference. La diversite des etapes
traitees, le degre de realisme atteint ainsi que la capacite a prendre en compte des donnees
socio-statistiques existantes, ont ouvert la voie a un grand nombre de travaux de recherche.
CityEngine a ete enrichi grace aux travaux de Peter Wonka [WWSR03] ce qui a conduit aux
resultats decrits en 1.5.2.2.
L’approche issue de la modelisation declarative decrit des schemas urbains non encore geres au
sein des approches procedurales (tel le schema en diamant presente a droite de la Figure 1.4).
Malheureusement, la methode de generation qui a ete utilisee dans [Lie96] (solveur de contraintes
numeriques dans un espace discret) ne permet pas une resolution a l’echelle d’une ville. Pour
garantir une plus grande diversite de l’ensemble des reseaux routiers pouvant etre generes, il
serait bon d’integrer au formalisme des L-System les schemas urbains non encore disponibles
mais presents dans les ouvrages d’urbanisme tels que ceux auxquels se refere S. Liege [Lie96].
39
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Figure 1.5. Differentes etapes successives de generation de geometrie complexe a base de
graphtales [MBST01]
40
Figure 1.6. Generation d’une zone urbaine a partir d’un L-System et de regles de
contraintes environnementales et topographiques [MBST01]
41
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Une fois le reseau routier genere, il est possible de realiser une partition de la ville en blocs. Ce
passage d’un probleme de grande taille a plusieurs problemes similaires mais de plus petite taille
est comparable au paradigme de conception algorithmique recursif appele divide and conquer.
1.3 Blocs
Bloc Nous definissons comme bloc une surface connexe entouree de routes. On peut aussi trouver
le terme ılot urbain pour decrire cette entite.
Le processus de generation associe a cette etape est d’une complexite negligeable par rapport a
celle de l’etape de generation du reseau routier. Elle est, de fait, souvent realisee automatique-
ment durant la generation du reseau routier. Il s’agit, le plus souvent, uniquement d’un calcul
d’intersections sur les voies du reseau routier, comme dans la Figure 1.7. Neanmoins, il peut
etre utile d’integrer a ce traitement des raffinements supplementaires :
– fusion des zones trop petites ;
– prise en compte des donnees hydrographiques et des espaces verts ;
– specification des blocs : zones commerciales, de bureau, residentielle, industrielle, scolaire,
hospitaliere, etc.
Le decoupage de la ville en blocs permet une premiere etape de hierarchisation. Ceci diminue le
nombre de contraintes a gerer, notamment dans le cas de la prise en compte de la contrainte de
non-chevauchement. Le format utilise pour decrire un bloc est le polygone, mais une restriction
aux polygones convexes est generalement faite (comme dans [PM01] ou [Lie96]), de facon a
profiter de la moindre complexite des algorithmes de traitement geometrique pour ce type de
polygones. Des informations supplementaires peuvent etre associees a ces polygones, comme par
exemple le nombre de personnes habitant ou travaillant au sein de ces blocs, ou encore leur type
(residentiel, bureau, immeuble, centre commercial, etc.).
Si la generation des blocs a partir des reseaux routiers est d’une faible complexite, elle reste
necessaire pour diminuer la complexite generale de la generation de villes. L’etape suivante
profite de ce niveau de detail logique pour restreindre les calculs et les contraintes au bloc en
cours.
Apres l’etape de decoupage du reseau routier en bloc, la generation des parcelles a partir des
blocs constitue une nouvelle etape dans le processus de hierarchisation de la scene.
42
Figure 1.7. De gauche a droite : routes, blocs et parcelles [PM01]
1.4 Parcelles
Parcelle Surface possedant une meme adresse postale, les parcelles sont les zones sur lesquelles
seront places les batiments (le contour d’un batiment est inclus dans une unique parcelle,
mais une parcelle peut accueillir plusieurs batiments).
1.4.1 Presentation
Les similitudes entre les etapes de generation route → blocs et blocs → parcelles sont tres fortes :
le format utilise est generalement le polygone, le plus souvent convexe (comme dans [PM01] ou
[Lie96]). Il est possible de generer separement la parcellisation de chaque bloc, puis de relancer
la generation uniquement pour les blocs dont les parcelles ne correspondent pas aux attentes de
l’utilisateur.
1.4.2 Generation
Comme pour les reseaux routiers, la definition des parcelles au sein d’un bloc est generalement
effectuee selon un schema predefini. Cette similitude de description ne s’etend pas aux methodes
de generation : les dimensions restreintes des blocs ne necessitent pas l’utilisation de L-System.
Les methodes utilisees sont plutot basees sur un partitionnement purement geometrique ou
l’instanciation d’un schema.
1.4.2.1 Parcellisation geometrique
Algorithme dichotomique Dans [PM01], les blocs sont decoupes en parcelles par un pro-
cessus recursif qui coupe la plus grande parcelle au milieu de son plus grand cote. Le processus
s’arrete quand la surface de la plus grande parcelle est inferieure a un seuil predefini. Ensuite
43
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
un post-filtrage est effectue sur les parcelles de facon a eliminer les parcelles trop petites ainsi
que celles qui n’ont pas acces a une route. Cette methode de raffinement successif limite la
parcellisation au schema en damier. Cette methode souffre egalement de plusieurs defauts :
– sensibilite aux parametres (seuil) ;
– traitement restreint aux blocs decrits par un seul polygone convexe ;
– generation de parcelles definies par un seul polygone convexe ;
Diagramme de Voronoı Dans [Per06], Julien Perret fait appel au diagramme de Voronoı (dont
on peut trouver les details d’une mise en œuvre informatique dans [Gho90]) et a l’algorithme du
squelette droit [FO98], afin d’automatiser le processus de parcellisation des blocs. L’utilisation
de cet algorithme lui permet de proposer une methode applicable aux polygones simples, et non
plus uniquement aux polygones convexes.
Dans le contexte urbain, cette methode propose l’utilisation de criteres simples, tels que la
surface, la largeur et la profondeur. Ainsi, pour un ılot donne, plusieurs variables sont position-
nables :
– la surface moyenne, minimale et maximale de chaque parcelle,
– la largeur moyenne, minimale et maximale de chaque parcelle,
– la profondeur moyenne, minimale et maximale de chaque parcelle.
La Figure 1.8 presente differents ensembles de parcelles generes a partir d’un bloc. On peut
deceler dans la derniere image des artefacts de generation (parcelles tres peu larges ou triangu-
laire avec un angle tres ferme).
1.4.2.2 Parcellisation selon un schema
Dans [Lie96], l’environnement de depart est une surface plane discretisee, representant le bloc.
Un point de la grille est choisi de facon arbitraire, puis un autre point est recherche de facon
a creer un segment compatible avec le schema a utiliser. La recherche guidee de l’extremite du
segment permet de reduire efficacement l’espace de recherche. La methode de parcellisation est
utilisee pour l’ensemble de l’ossature du schema. Pour les segments qui separent les parcelles
entre elles, une autre discretisation est effectuee. Celle-ci porte sur les segments constituant le
squelette interieur du schema. Les points ainsi definis sont nommees points d’ancrage. Chaque
point d’ancrage est ensuite apparie a un ou plusieurs points de l’enveloppe exterieure de facon
a creer une parcellisation conforme au schema.
44
Figure 1.8. Exemples de parcellisation de blocs [Per06]
45
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Les problemes potentiels de cette methode sont l’utilisation d’une discretisation initiale grossiere
ainsi que le guidage strict de la recherche qui peuvent conduire a ne pas trouver de solutions
pour certains problemes.
Figure 1.9. Exemple d’espace de solution reduit a cause de la discretisation de l’espace [Lie96]
1.4.3 Discussion
Les methodes presentees ici sont extremement differentes.
CityEngine propose une approche efficace en terme de performances mais fournit des resultats
peu varies et est limite aux polygones convexes en entree (blocs) et en sortie (parcelles).
L’approche basee sur les diagrammes de Voronoı permet de s’affranchir de la limitation aux
polygones convexes et propose une gamme de resultats plus varies, malheureusement desservie
par des parcelles resultats qui sont impossibles (certainement evitable par un post-traitement
des donnees).
Enfin, l’approche issue de la modelisation declarative offre la plus grande diversite de resultats
mais utilise un processus de generation base sur une enumeration d’un ensemble, ce qui conduit
a restreindre le domaine d’application.
Chacune de ces methodes peut donc etre choisie selon le degre de realisme et d’efficacite (et de
variation dans les schemas) souhaite. Il apparaıt neanmoins necessaire d’ameliorer les travaux
existants, que ce soit en ajoutant un post traitement sur les parcelles pour l’approche basee sur
les diagrammes de Voronoı ou en perfectionnement le processus de discretisation du monde pour
l’approche issue de la modelisation declarative.
46
1.5 Exterieurs
Dans cette section, nous allons utiliser la notion d’embase. L’embase (ou empreinte) d’un batiment
represente l’intersection du batiment avec le terrain. Elle est generalement representee par un
polygone non plan (le terrain ne presente pas forcement une altimetrie constante autour du
batiment).
L’instanciation d’un batiment est contrainte par la specificite du paysage urbain environnant
la parcelle. Par exemple, placer des batiments en centre ville conduit generalement a respecter
une continuite des facades ainsi qu’une homogeneite des hauteurs des differents batiments. Dans
ce cas, les embases des batiments doivent etre jointives et alignees par rapport a la route. Au
contraire, dans un quartier residentiel, ou au sein d’un village, le placement vise a positionner le
batiment a distance de la route et des batiments situes sur les parcelles mitoyennes, ainsi qu’a
limiter le plus possible l’inter-visibilite des ouvrants exterieurs (portes, fenetres) des differents
batiments. Les variables a instancier durant cette etape sont : la forme, la hauteur et l’orientation
du batiment, ainsi que les distances aux differentes frontieres de la parcelle.
Certains travaux [PM01, Lie96] creent et positionnent les batiments en se basant uniquement
sur des operations geometriques : ils effectuent une erosion (i.e. une difference de Minkowski
[Min97]) de la surface de la parcelle de facon a obtenir l’embase du batiment. Pour ces methodes,
les variables definies ci-dessus ne sont donc pas reellement prises en compte.
Une fois les variables necessaires definies, plusieurs techniques existent pour generer les batiments.
Elles sont decrites dans la suite de cette section.
1.5.1 Methodes non automatiques
En plus des travaux de recherche decrits dans les prochains paragraphes, il existe des logiciels
destines au grand public qui proposent de generer des batiments, en prenant en compte les
exterieurs et les interieurs (plan et ameublement). L’objectif initial des premieres versions de
ces logiciels etait la generation des plans de batiments ; nous decrirons rapidement certains de
ces outils en Annexe E.
1.5.1.1 Grammaire de formes
Le projet Lahave House, decrit par Rau-Chaplin dans [RMS96], est principalement base sur
l’etude du design architectural industriel dans le but de creer des batiments a partir de librairies
47
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
de classes d’agencements d’elements architecturaux. Cet outil est destine a aider le concepteur a
concevoir des habitations esthetiques, fonctionnelles et architecturalement realisables. Une etude
exhaustive des maisons vernaculaires (un batiment vernaculaire est caracteristique d’une zone
geographique et d’une epoque donnee) construites autour de la riviere La Have au Canada a
permis de creer un ensemble de grammaires de formes. A partir de ces grammaires, une librairie
de modeles d’agencements d’elements architecturaux est generee puis utilisee pour visualiser les
resultats en trois dimensions (Figure 1.10). Un modele est constitue de la description geometrique
et de la configuration des niveaux de l’habitation. Des elements (cuisine, salle de bain, etc.) sont
predefinis et associes aux volumes correspondants. Ce systeme est capable de creer des batiments
suffisamment detailles et parfaitement definis pour determiner automatiquement le cout final de
construction.
L’un des objectifs de nos travaux etant d’inclure la capacite a definir des formes non-existantes,
sans etre restreint a l’assemblage d’elements preexistants, l’approche du projet Lahave House
presente quelques inconvenients. En effet, cette approche repose sur le fait qu’elle est restreinte
a un type de batiments vernaculaires (specifiques a une zone geographique donnee). De plus, ce
systeme n’est pas capable de traiter des formes qui n’ont pas ete decrites durant la creation de
la librairie d’elements architecturaux.
Figure 1.10. Exemple de realisations du projet LaHave [RMS96]
1.5.1.2 Castle Construction Kit
Les travaux decrits Gerth et Haveman dans [GBHF05, Hav05] presentent quelques caracteristiques
communes aux notres. Les resultats de ces travaux montrent que les outils de modelisation qui
y sont proposes sont adaptes specifiquement au domaine etudie. Ces outils sont developpes pour
48
permettre a des personnes neophytes en modelisation tridimensionnelle d’exprimer leurs idees
ou connaissances par eux-memes en creant leurs propres maquettes numeriques (Figure 1.11).
Notamment, les cibles visees par ces travaux peuvent aussi bien etre des archeologues que des
historiens de l’art qui possedent de grandes connaissances sur les sites et monuments historiques.
Les auteurs ont identifie des modeles realistes de chateaux forts comme un outil potentiellement
utile pour les chercheurs, les conservateurs de musees ainsi que pour les organisateurs d’exposi-
tion.
Figure 1.11. Exemple de chateau-fort genere avec le Castle Construction Kit [GBHF05]
1.5.2 Methodes automatiques
Depuis 1975, les grammaires, les L-System [PL91] ou les grammaires de formes [Sti75] ont ete
utilises en modelisation architecturale afin de decrire des batiments ou de creer des algebres de
construction (voir [Mit90]). Ces methodes ont ete recemment mise en œuvre au sein de differents
projets portant sur la generation de maquettes numeriques de batiments.
1.5.2.1 L-System
CityEngine Decrit dans [PM01], permet de generer des batiments simples, en faisant appel
a un L-System vertical (une definition des L-System peut etre trouvee dans l’Annexe C). Les
batiments generes sont de type gratte-ciel, c’est a dire qu’ils partent d’un rectangle au sol
et s’affinent en progressant en hauteur (Figure 1.12). Dans cette approche, le systeme peut
rapidement creer un grand nombre de batiments, mais les facades de ces batiments sont limitees
a des faces plates sans aucun detail geometrique, auxquelles on applique une texture.
49
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Figure 1.12. Differentes etapes de derivation [PM01]
FL-system Dans son memoire de these [Per06], Julien Perret propose les FL-system, un lan-
gage fonctionnel de modelisation geometrique. Les FL-system etendent le formalisme propose par
Prusinkiewicz [PL91] en y ajoutant la notion d’objets generiques comme parametres, le controle
de l’application des regles, et surtout l’utilisation de fonctions comme elements terminaux et
comme operateurs sur les parametres.
La motivation principale du developpement et de l’utilisation des FL-system est la souplesse
apportee lors de la generation. En effet, les L-system manquent de souplesse car les objets
geometriques generes par homomorphisme sont implicites, c’est-a-dire que l’utilisateur n’a pas
d’autre moyen que de modifier la fonction pour pouvoir modifier les proprietes des objets.
De plus, a l’exception du modele propose par Prusinkiewicz [PL91] pour la modelisation de
phenomenes continus, le temps est, lui aussi, exprime de facon implicite, ce qui ne permet pas
de controler des sequences de facon simple.
Julien Perret propose egalement deux strategies de reecriture pour ces systemes. Il decrit la pos-
sibilite de generer un modele geometrique au fil de la reecriture (ce qui presente un interet pour
generer divers modeles d’un meme objet pour une utilisation des niveaux de detail graphiques),
ainsi qu’un systeme de cache visant a ameliorer les performances de la reecriture.
1.5.2.2 Methodes basees sur les grammaires de formes
InstantArchitecture Le projet Instant Architecture, decrit Peter Wonka dans [WWSR03],
permet d’obtenir des batiments a partir de split grammar. Ce type de grammaire est un ensemble
de grammaires parametriques basees sur le concept de forme. Ce systeme utilise egalement un
second type de grammaire, la control grammar afin de controler la propagation des attributs de
la split grammar. En faisant appel a ces deux types de grammaires, le systeme peut creer des
batiments realistes a partir de descriptions qui peuvent etre precises ou vagues. Dans le cas d’une
description vague, la control grammar se chargera de donner des valeurs precises aux attributs.
50
Figure 1.13. Reconstruction de l’Empire State Building (New York City) [PM01]
51
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Figure 1.14. Reconstruction d’un batiment existant (a gauche) a Rennes. Le modele virtuel,
utilisant les FL-system est montre a droite[Per06]
Figure 1.15. Un autre batiment de Rennes. Ce modele utilise le meme FL-system que la
figure precedente, seuls les elements terminaux et les textures ont ete modifies.[Per06]
52
Figure 1.16. Cette image montre plusieurs batiments generes a l’aide des split grammar
[WWSR03]
Recemment, ces travaux ont ete etendus dans [MZWG07] afin d’automatiser la tache de creation
de la grammaire. L’utilisation conjointe de methodes issues de l’analyse d’images et de leurs
travaux anterieurs sur la modelisation procedurale leur permet de proposer deux nouvelles ap-
plications de leurs approches :
– reconstruction urbaine a partir d’images aeriennes basse resolution,
– reconstruction de facades a partir d’images terrestres haute resolution,
(a) (b) (c) (d)
Figure 1.17. De gauche a droite : (a) donnee en entree (image rectifiee d’une facade),
(b) facade automatiquement subdivisee et encodee comme un arbre de forme, (c) modele
polygonal et enfin (d) rendu du resultat final incluant ombres et reflections rendues possibles
par les informations semantiques [MZWG07]
Dans cette approche, les batiments produits sont extremement realistes. Le recours a une unique
base de regles permet a l’utilisateur de creer differents types de batiments, mais une longue
periode d’apprentissage est requise avant d’etre capable de maıtriser la complexite du systeme.
53
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Il faut, en effet, connaıtre et comprendre deux bases de regles et deux grammaires differentes.
L’apprentissage le plus delicat etant celui des split grammar et celle du systeme de base de
donnees de regles. En outre, ce systeme tend facilement a creer des batiments comportant un
grand nombre de faces (de 1 000 a 100 000 faces par batiments), et comme precedemment enonce,
il reste trop generique pour atteindre nos objectifs en termes de simplicite d’utilisation et de
prise en main.
CGA shape Dans [MWS+06], Parish et Mueller [PM01] et Peter Wonka [WWSR03] ont
presente un systeme base sur les grammaires de formesqui est compatible avec des batiments
definis par des plans de masse complexes. Cet outil de modelisation de batiments, base sur une
approche procedurale autour de modeles de masse consistants, permet de creer des batiments
complexes. Les differentes parties des batiments generes tiennent compte les unes des autres lors
de la generation des facades. Cette propriete permet aux split grammar utilisees de prendre en
compte les facades qui sont susceptibles de se chevaucher : par exemple, une fenetre d’une facade
donnee ne sera pas masquee par un element d’une autre facade. En utilisant les split grammar et
les plans de masse, les auteurs sont capables de modeliser des batiments tres complexes, tels que
les tours Petronas de Kuala Lumpur (Malaisie). De la meme facon que les travaux decrits dans
[WWSR03], les methodes utilisees dans [MWS+06] traitent la geometrie de facon generique.
La Figure 1.18 presente le type de probleme que les auteurs veulent resoudre. Le batiment
modelise consiste en quatorze primitives volumetriques (cubes, toits, etc.) places grace a une
grammaire stochastique de forme. L’image de gauche de la Figure 1.18 presente le resultat
imparfait qu’obtiendraient les methodes existantes. Ce resultat peut etre obtenu par l’utilisa-
tion de textures sur chaque volume individuel [PM01] ou par l’utilisation de regles de decoupe
(split grammar) [WWSR03]). Dans les deux cas, il apparaıt des intersections involontaires
entres differents elements (principalement des fenetres partiellement cachees par des murs dans
l’exemple). Ceci arrive car les volumes n’ont pas connaissance les uns des autres. Dans l’image
de droite, la nouvelle approche developpee dans [MWS+06] permet la resolution de ces conflits.
De plus, cette approche permet un affinement de la geometrie du batiment (les rainures sur
le toit). Cet exemple a ete cree en utilisant uniquement six regles (dont une pour les toits en
pente, une pour les toits plats, une pour les facades qui utilisent deux regles differentes pour les
fenetres).
54
Figure 1.18. Incoherences geometriques resolues dans [MWS+06]
1.5.2.3 Modelisation declarative
BatiMan [Cha98] est un modeleur declaratif (cf. Annexe D) de quelques batiments (le terme
quelques est de l’auteur). BatiMan est l’illustration de deux principaux axes de recherche. Le
premier de ces axes repose sur les processus d’apprentissage issus de l’Intelligence Artificielle
afin d’ameliorer, au fur et a mesure de ses utilisations, les performances du modeleur. Cette
amelioration se fait sous la forme d’un elagage (ou cycle recherche/suppression) des valeurs
connues comme menant a un echec. Le second axe de recherche est la classification des solutions
permettant de proposer a l’utilisateur un nombre restreint de solutions caracteristiques. La
notion de prototype de forme prend ici tout son interet : un modeleur declaratif peut trouver un
tres grand nombre de solutions et seule la capacite a les classifier peut permettre a l’utilisateur
d’avoir une vue d’ensemble des solutions distinctes.
La methode de generation utilisee au sein de BatiMan fait appel a un solveur base sur l’approche
CSP (cf. Annexe B) sur les domaines finis. Le nombre de variables definissant un batiment peut
aller jusqu’a une vingtaine. Mais le domaine de ces variables est limite avec peu (entre cinq
et dix) de valeurs possibles par variable. La Figure 1.19 presente des batiments generes par
BatiMan
55
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Figure 1.19. Exemples de batiments generes par BatiMan [Cha98]
1.5.2.4 Modelisation geometrique
AGETIM [LLGC+05] est une suite logicielle integree permettant de generer un environne-
ment virtuel 3D, a des fins de simulation ou de modelisation. AGETIM fournit des moyens
d’integration de donnees cartographiques existantes, des moyens de correction ou d’enrichisse-
ment de ces donnees (caracterisation electromagnetique, infrarouge et acoustique), des proces-
sus de generation automatique d’environnement virtuel 3D, ainsi que des moyens d’exploitation
simple de cet environnement. Le module GenVillage permet de creer des batiments a partir de
leur embase (creee de facon automatique ou manuelle) en utilisant des gabarits predefinis. Ces
gabarits sont restreints a quelques textures, les facades sont forcement planes. La Figure 1.20
presente un batiment genere par AGETIM.
Figure 1.20. Exemple de batiment generes par AGETIM [LLGC+05]
56
1.5.3 Discussion
L’etape de generation des exterieurs de batiments est importante pour la qualite du resultat
final. Les methodes decrites pour cette etape repondent a des besoins differents. La methode la
plus adaptee a un cas selectionne varie selon que l’utilisateur recherche une generation rapide,
une grande finesse geometrique ou la possibilite de chiffrer le cout du batiment.
Seule la methode du projet La Have [RMS96] permet de chiffrer le cout de construction d’un
batiment, mais l’etablissement de la librairie necessaire a l’utilisation d’une grammaire de formes
necessite d’importants moyens et n’est pas reutilisable si le type de batiment evolue.
Les batiments crees par CityEngine [PM01] sont generes tres rapidement et peuvent donc etre
utilises pour prototyper la zone urbaine, mais ne sont ni assez generiques (ils sont restreints aux
seuls gratte-ciels) ni assez detailles (le rendu final est base sur une seule texture).
La modelisation declarative [Cha98] permet de creer facilement une bibliotheque de batiments
grace a la classification qui permet de regrouper les batiments ayant des caracteristiques com-
munes.
La methode GenVillage [LLGC+05], basee sur la modelisation geometrique est concue essentiel-
lement pour faciliter l’instanciation de batiments dans un paysage. Mais son cote automatique
est restreint a une gestion intelligente de la repetition de texture (pour eviter de couper une
ouverture par un angle de mur).
Des methodes presentees ici, les methodes basees sur les split grammar nous semblent les plus
prometteuses. La capacite de generer avec le meme outil n’importe quel type de batiment, tout
en proposant des resultats satisfaisants d’un point de vue esthetique, apporte reellement une
plus-value par rapport aux limitations des autres approches.
Neanmoins ces methodes souffrent de plusieurs defauts, notamment une utilisation ardue (l’ap-
prentissage du double systeme de grammaire semblant en etre la cause) et un relatif manque de
controle de la complexite du resultat final (en terme de nombre de polygones).
Dans le cadre de cette etude, nous avons developpe une nouvelle methode pour generer des
exterieurs de batiments. Cette methode, initialement inspiree des travaux de Peter Wonka
[WWSR03] vise a generer rapidement des batiments realistes, tout en etant facile et rapide
a comprendre et maıtriser pour un non specialiste. Nous presentons nos travaux dans le Cha-
pitre 3.
57
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
1.6 Plan de batiments
Ce probleme architectural bidimensionnel a fait l’objet de nombreux travaux [Mac91, Cha95,
MY01]. Il correspond a une activite de partitionnement du plan d’un batiment en pieces. C’est
un probleme non trivial, et pour lequel il n’est pas possible de trouver une solution en un temps
polynomial dans le cas ou de nombreuses contraintes ont ete exprimees pour de nombreuses
pieces. Il a ete essentiellement etudie comme une recherche de la solution optimale a un probleme
de satisfaction de contraintes utilisant l’approche CSP (cf. Annexe B) pour sa resolution.
Il existe de nombreux logiciels grand public ayant pour vocation de permettre a tout un chacun
de (re)creer son habitation. Comme ces outils ne sont pas automatiques, nous les presentons en
Annexe E.
1.6.1 Algebre de Manhattan
Dans ses travaux, R. Maculet [Mac91] presente la conception de batiments comme un processus
de satisfaction de contraintes. Afin d’etre capable de definir les contraintes spatiales relatives
a ce probleme, R. Maculet a plus particulierement etudie la representation des connaissances
spatiales en architecture, notamment l’articulation entre les connaissances spatiales symboliques
(topologiques) et les connaissances spatiales numeriques qui avaient encore ete peu etudiees en
IA.
La representation spatiale des objets sur lesquels portent ces connaissances est effectuee par l’uti-
lisation des boıtes de Manhattan qui sont des rectangles isothetiques definis dans un monde dis-
cretise. Les boıtes de Manhattan, ainsi que les differentes operations associees, forment l’algebre
de Manhattan. Ce choix a ete guide par son adequation avec la realite architecturale ; l’auteur
rappelle qu’un batiment est generalement un ensemble complexe de formes simples.
Figure 1.21. 3 solutions au probleme de Maculet [Mac91]
58
Les problemes de placement sont representes par un reseau de contraintes. La resolution s’effectue
par un mecanisme de propagation statique des contraintes, guide par des heuristiques en fonction
des contraintes pour le choix de l’ordre de placement des objets.
1.6.2 EAAS
EAAS (Environnement d’aide a l’amenagement spatial) est un ensemble d’outils pour l’aide a
l’amenagement spatial concu et realise par P. Charman [Cha95]. N’entrant pas directement dans
le cadre de la modelisation declarative (car plutot oriente CAO et solveur de contraintes), il peut
cependant y etre rattache, principalement a cause de la phase de generation et par le niveau
d’abstraction utilise.
Figure 1.22. Exemples de resultats obtenus par EAAS [Cha95]
L’element principal de EAAS est son solveur de contraintes fonde sur une extension des CSP,
les Spatial-CSP. Ce modele a ete developpe specialement par l’auteur pour tenir compte des
caracteristiques geometriques des problemes d’amenagement spatial. Les methodes developpees
dans EAAS, notamment une nouvelle technique de filtrage (l’arc-coherence semi-geometrique)
ainsi que l’implantation d’un large choix d’heuristiques et de techniques de backtrack, garan-
tissent une resolution efficace dans de nombreux cas. Ce modele permet donc de prevoir les
collisions au plus tot (pendant les phases de filtrage), ce qui limite d’autant l’espace de recherche
et le nombre de tentatives pour parvenir a une solution.
EAAS a ete developpe pour resoudre des problemes d’amenagement spatial dans le plan. De
plus, les orientations gerees sont reduites a 0, 90, 180 et 270 degres, ce qui limite le monde a des
objets isothetiques, plus exactement a des objets dont la boıte englobante est un parallelepipede
isothetique. De fait, EAAS est limite (comme les autres methodes presentees ici) au partitionne-
59
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
ment de batiments dont les etages sont des rectangles. De plus, les pieces creees seront forcement
elles aussi des rectangles.
1.6.3 ARCHIPLAN
Dans ARCHiPLAN [MY01], B. Medjoub et B. Yannou proposent une amelioration des ap-
proches precedentes par l’utilisation d’heuristiques dynamiques d’ordonnancement spatial. Ces
heuristiques, inspirees des heuristiques d’ordonnancement dynamique de variables, introduisent
une caracterisation topologique de l’espace des solutions. Cette introduction de notions topolo-
giques permet de diminuer la combinatoire du probleme et donc de simplifier la recherche d’une
solution. L’avantage d’un niveau topologique de solutions est la restriction d’un point de vue
topologique du nombre de solutions existantes differentes, ce nombre rendant possible la visua-
lisation de la totalite des solutions par l’utilisateur final. Ceci permet d’avoir une vue globale de
l’espace des solutions puis d’etudier en detail uniquement la partie de l’espace des solutions qui
correspond a l’image mentale du concepteur.
Figure 1.23. Deux solutions geometriques differentes avec la meme topologie [MY01]
1.6.4 HM2PH
Le projet HM2PH (Habitat Modulaire et Mobile pour Personnes Handicapees), developpe par
l’equipe HaNT (Handicap et Nouvelles Technologies) du Laboratoire d’Informatique de l’Uni-
versite de Tours, vise a utiliser les nouvelles technologies pour ameliorer le cadre de vie des
personnes handicapees.
Dans son memoire de doctorat [Pur07], Arnaud Puret realise une synthese des methodes decrites
precedemment dans cette section en les appliquant a un probleme concret. Ce probleme peut
etre defini comme le developpement d’une application capable de generer des plans d’habitations
adaptees aux handicaps d’une personne.
Pour definir les contraintes resultantes de ces handicaps pour la definition des plans de ces
habitations, les auteurs ont cree une base de donnees a partir des normes et recommandations
60
existantes definies par les organismes officiels, les associations et les fournisseurs de materiel
(definissant l’espace necessaire au deplacement d’un lit medicalise, par exemple). En plus des
handicaps moteurs, certains handicaps specifiques sont aussi traites, tels les handicaps visuels,
auditifs ou ceux lies au vieillissement.
La generation des habitations deduit les dimensions minimales des pieces (de vie et de com-
munication) des contraintes selectionnees. Le moteur de generation par contraintes genere un
grand nombre de solutions qui sont ensuite classifiees de facon topologique. A partir d’une ou
plusieurs solutions topologiques, l’utilisateur peut modifier geometriquement les pieces de facon
a satisfaire ses propres preferences (taille relative des pieces, positionnement des ouvrants).
L’outil developpe permet de transformer la liste des contraintes d’amenagement d’un batiment
(contraintes economiques, contraintes liees a l’emplacement du batiment ou contraintes liees
aux handicap ou aux desirs de l’habitant) en plans comprehensibles par l’utilisateur, ce qui lui
permet de choisir par lui-meme sa future habitation.
La possibilite pour l’utilisateur d’apprehender de facon autonome les differents resultats pos-
sibles est encore facilitee par l’etude et la realisation d’un outil de visualisation qui presente les
maquettes tridimensionnelles des solutions topologiques retenues.
Nous allons a present etudier l’etape de placement des meubles a l’interieur des batiments.
1.7 Interieurs meubles
Il a ete prouve que le probleme d’amenagement spatial est un probleme NP-complet, ce qui im-
plique qu’il n’existe pas d’algorithme le resolvant en temps polynomial. Cette complexite en fait
un domaine d’application privilegie en modelisation declarative afin d’evaluer les performances
des processus de generation.
Il est possible de definir entierement l’instanciation d’un objet au sein d’un modele 3D par la
donnee de sa description geometrique et les variables qualifiant son orientation, sa position et
ses dimensions (ces dernieres etant le plus souvent fixees).
1.7.1 Approches manuelles
En plus des travaux de recherche decrits dans les prochains paragraphes, il existe des logiciels
destines au grand public qui proposent de generer des batiments, en prenant en compte les
61
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
exterieurs et interieurs (plans et ameublement). Comme ces outils ne presentent pas d’approche
automatique, nous avons reporte leurs descriptions en Annexe E.
1.7.2 Approches semi-automatiques
1.7.2.1 CAPS
CAPS (Constraint-based Automatic Placement System : Systeme de placement automatique
base sur les contraintes) a ete developpe en 2001 par K. Xu [XSF02] au sein du departement
Computer Science de l’Universite de Toronto.
CAPS s’attache a construire une seule scene de facon iterative en laissant l’utilisateur decider du
placement des objets. Il agit plus comme une assistance au placement interactif que comme un
modeleur. CAPS utilise de nombreuses techniques pour faciliter la creation de scenes complexes :
– implantation d’une pseudo-physique, modele physique simplifie (disparition des accelerations
et des vitesses) qui maintient une scene coherente par rapport a la gravite,
– utilisation des sommes et differences geometriques de Minkowski pour accelerer le placement
(en reduisant les domaines de recherche),
– utilisation de contraintes 2D, il rejoint ici la modelisation declarative,
– developpement d’une base de donnees semantique qui definit les zones de placements autorisees
(zones ou placer des assiettes sur une table par exemple) et interdites.
Les resultats (cf. figure 1.24) que presente K. Xu, notamment ceux concernant les temps de
generation de scenes relativement complexes (plusieurs centaines d’objets), representent une
reference a laquelle les modeleurs futurs devront se mesurer. Neanmoins, ses travaux ne sont
pas directement comparables a ceux effectues dans le cadre du projet DEM2ONS etant donne
l’absence d’un moteur de maintien de contraintes. Par exemple, si des objets ont ete places sur
une table, le fait de deplacer cette table plus tard durant le processus de modelisation ne les
conservera pas sur la table. Or, un modeleur declaratif doit pouvoir maintenir les contraintes pre-
etablies satisfaites, meme en cas de deplacement d’un des objets mis en jeu dans une contrainte.
1.7.2.2 WordsEyes
Alors que les modeleurs presentes sont tous issus de la recherche academique, WordsEyes [CS01]
a ete developpe dans un des laboratoires de recherche de AT&T. Cette specificite se traduit
directement par la taille des equipes impliquees.
62
Figure 1.24. Scene comprenant environ 500 objets generee en 25min grace a CAPS (par
placement et ajustements interactifs)
63
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Le texte suivant produit la premiere image. The Broadway Boogie Woogie vase is on the Richard Sproat coffee
table. The table is in front of the brick wall. The van Gogh picture is on the wall. The Matisse sofa is next to the
table. Mary is sitting on the sofa. She is playing the violin. She is wearing a straw hat.
Le texte suivant produit la seconde image. John uses the crossbow. He rides the horse by the store. The store is
under the large willow. The small allosaurus is in front of the horse. The dinosaur faces John. A gigantic teacup
is in front of the store. The gigantic mushroom is in the teacup. The castle is to the right of the store.
Figure 1.25. Exemples de resultats de WordsEyes a partir de descriptions textuellese.
64
Le systeme WordsEyes se base sur une description entierement textuelle, associee a des in-
formations semantiques, pour generer une scene (text-to-scene system). Le texte fourni par le
concepteur est analyse pour construire un graphe de dependances, qui est ensuite interprete de
facon a produire une representation semantique. Celle-ci est alors convertie en un ensemble de
descripteurs, relativement a un ensemble de regles, permettant la mise en place d’objets 3D dans
une scene (cf. figure 1.25) respectant au mieux la description fournie.
Cette technique, qui donne des resultats remarquables, repose sur deux parties essentielles :
– une analyse linguistique poussee, permettant l’interpretation des enonces fournis par le concep-
teur (on peut noter l’utilisation de WordNet7 comme systeme de reference lexical),
– une base de connaissances extremement riche (et couteuse a construire) contenant des objets
3D associes a des caracteristiques qui permettent de les positionner au mieux en fonction du
contexte, de facon a respecter leurs fonctionnalites et l’attitude des personnages utilisant ces
objets (couleur, relations spatiales, etc).
1.7.3 Approches automatiques
1.7.3.1 Approche CSP
Durant ces dix dernieres annees, plusieurs solveurs de contraintes bases sur l’approche CSP
ont ete developpes dans le domaine de la modelisation declarative pour resoudre le probleme
d’amenagement d’interieurs. Ces solveurs peuvent etre divises en deux classes :
– ceux restreints a un placement parallele aux axes de la scene (isothetique), ces solveurs [Kwa98,
BP99, LR03] ont ete historiquement les premiers etudies,
– ceux capables de placer les objets avec une orientation quelconque [RP02, LR03].
Au sein de notre equipe, les differents travaux de recherche concernant le placement automatique
d’objet dans un monde tridimensionel sont regroupes au sein du projet DEM2ONS8.
DEM2ONS Le projet DEM2ONS est assimilable a un atelier de mise en scene multimodal,
ayant pour but de simplifier et d’accelerer la conception et la creation d’environnements virtuels.
Base sur l’interaction multimodale et la modelisation declarative, le but de ce systeme est d’offrir7WordNet est un systeme de reference lexical en ligne dont le fonctionnement est inspire par les theories
psycholinguistiques actuelles concernant la memoire lexicale humaine.8DEclarative Multimodal MOdeliNg System
65
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
au concepteur un ensemble d’outils de haut niveau d’abstraction, capables de l’assister pendant
les differentes etapes de la conception d’une scene tridimensionnelle complexe.
Les proprietes enoncees par le concepteur doivent etre interpretees pour etre traduites dans le for-
malisme sous-jacent, de facon a etre traitees lors de la phase de generation. Ce formalisme, interne
au systeme de generation, est constitue de contraintes (actuellement geometriques) associees a
des methodes de resolution qui permettent de definir precisement l’effet d’une telle contrainte
sur l’environnement. La phase de generation est effectuee par un solveur de contraintes dont le
role est de satisfaire un ensemble de contraintes geometriques afin de fournir une solution au
probleme pose. La definition des proprietes de type relations spatiales ainsi que la definition des
contraintes geometriques correspondantes a ete menee en collaboration avec l’equipe LRC9 de
l’IRIT.
Plusieurs methodes ont ete etudiees pour resoudre les contraintes dans le cadre de DEM2ONS,
certaines basees sur les CSP, d’autres sur les algorithmes genetiques ou les meta-heuristiques de
voisinage.
ORANOS [KGC97] (cf. Figure 1.26) est un solveur de contraintes destine a la modelisation
declarative et utilise dans la phase de generation du modeleur de scenes de DEM2ONS a la
fin des annees 90. Concu et realise par G. Kwaiter [Kwa98], ce solveur s’appuie sur un modele
etendu de CSP developpe par l’auteur : les DHNCSP10. Base sur les CSP numeriques et l’analyse
par intervalle [Moo79], ce modele introduit une hierarchisation des contraintes afin de pouvoir
automatiquement en relacher certaines dans les cas sur-contraints. Il presente des caracteristiques
tres interessantes pour un solveur dans le cadre de la modelisation declarative :
– base sur une hierarchie de boıtes englobantes afin de reduire la complexite des scenes (les
objets places dans des conteneurs differents s’ignorent au sens des contraintes),
– utilisant une gestion dynamique et incrementale du systeme de generation afin de permettre
son integration dans une application interactive.
Le principal inconvenient d’ORANOS est, comme pour EAAS, la restriction a un placement de
boıtes englobantes isothetiques. Les solveurs developpes par O. Le Roux dans le cadre de ses
9LRC : Equipe Langage Raisonnement et Calcul.10DHNCSP : Dynamic Hierarchic Numeric CSP.
66
Figure 1.26. Oranos dans DEM2ONS
67
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
recherches pour DEM2ON03 levent pour certains le probleme du placement isothetique et de la
restriction aux boıtes englobantes.
Manhattan [LRG03, LR03] est un outil de generation exclusivement dedie a l’agencement de
boıtes isothetiques tridimensionnelles orientees. Il est issu des trois constats suivants :
– dans la creation d’un environnement virtuel, l’agencement isothetique des objets est tres
courant (la plupart des meubles dans une piece, les livres dans une armoire, les murs d’une
maison) ;
– des outils comme Oranos (CSP numeriques) [Kwa98], comme le solveur de contraintes du
systeme MultiFormes4 (CLP(FD)11) [Bon99] ou encore comme le noyau de generation de
MultiCad (Prolog) [Fri03] permettent de resoudre ce probleme particulier, mais s’averent trop
generaux pour s’acquitter de cette tache efficacement. En effet, ils ne tirent pas parti de
toutes les caracteristiques intrinseques de l’agencement isothetique : la nature des domaines
utilises par ces outils ne permet pas d’exploiter pleinement l’information contenue dans les
contraintes. La reduction de l’espace de recherche est effective, mais les contraintes molles
(comme la contrainte de disjonction) limitent notablement la portee du filtrage ;
– tous les outils de generation que nous avons recenses se limitent au placement de boıtes ou
de rectangles non-orientes ou avec un nombre d’orientations tres restreint (deux pour EAAS).
Or, les objets que nous cherchons a placer possedent une semantique propre qui impose de
considerer l’orientation des boıtes englobantes associees.
Avec le solveur de contraintes Manhattan, O. Le Roux a apporte au projet sa contribution pour
l’ensemble de ces preoccupations. Cet outil, base sur l’approche CSP, permet en effet de recher-
cher de facon systematique les solutions d’un probleme de placement de boıtes tridimensionnelles
orientees, soumises a un ensemble de contraintes geometriques. L’algorithme de recherche, noyau
du solveur, est constitue d’un processus de backtrack lie a une puissante technique de filtrage
issue du modele geometrique approprie au probleme. Pour ameliorer les performances du solveur
et le realisme des scenes engendrees, O. Le Roux propose en outre un ensemble d’heuristiques
dynamiques en rapport avec le placement d’objet.
Manhattan est un solveur de contraintes optimise pour un probleme tres precis. Cette specialisa-
tion empeche d’etendre l’utilisation de cet outil a des situations plus generales. Pour augmenter le11Constraint Logic Programming on Finite Domains
68
Gauche : description d’une scene sous forme de script.
Droite : projection orthographique d’une scene resultat. Cette scene contient 28 objets. Chaque objet peut prendre
l’une des 4 orientations isothetiques possibles autour de l’axe vertical ; dans ce schema, les triangles symbolisent
l’orientation.
Temps de calcul : env. 10 secondes. Ce probleme est largement sous-contraint.
La meme scene exportee en VRML avec un rendu type lancer de rayons.
Figure 1.27. Un exemple de scene generee par Manhattan [LRG03]
69
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
realisme des scenes et fournir une palette de possibilites beaucoup plus riche, il est necessaire de
disposer d’un outil de generation plus generique. La contrepartie de cette genericite est souvent
une vitesse de resolution des problemes plus lente.
Le solveur de contraintes numeriques Admunsen Dans le cadre du projet DEM2ONS,
O. Le Roux propose de remplacer le solveur Oranos par Admunsen [LR03]. Admunsen exploite
les possibilites de l’approche numerique. En effet :
– la richesse des possibilites offertes par la modelisation mathematique (equations/inequations)
permet d’aborder une grande variete de problemes. Utilise dans un espace de recherche continu,
un solveur de contraintes numeriques se revele par consequent un outil particulierement
generique. En s’appuyant sur les mathematiques liees au placement des objets dans l’es-
pace, il est par ailleurs possible de modeliser des problemes de placement d’objets realistes
extremement varies ;
– une strategie de recherche basee sur un decoupage recursif du probleme (strategie de branch
and prune : elagage) permet de resoudre de facon garantie un systeme compose d’equations
et inequations quelconques. Les progres effectues depuis la creation d’Oranos [KGC97] dans le
domaine de la resolution des CSP numeriques permettent d’atteindre l’objectif de robustesse,
tout en conservant des performances tres correctes (tant que le probleme possede plusieurs
solutions).
Bien que s’inspirant d’Oranos, Admunsen offre de multiples avantages en termes de fonctionna-
lites et de performances. Voici les distinctions les plus significatives :
– Admunsen explore l’espace de recherche de maniere exhaustive (a une precision fixee par
l’utilisateur) : il s’affranchit ainsi du mecanisme de discretisation utilise par Oranos. Il utilise
pour cela un decoupage du domaine guide par des heuristiques. Cette caracteristique per-
met notamment d’aborder la resolution de systemes d’equations complexes (en particulier
non-lineaires). Cette propriete se revele utile pour resoudre, par exemple, des problemes de
construction d’objets ;
– Admunsen abandonne l’algorithme de filtrage fort utilise dans Oranos au profit de techniques
de reduction de l’espace de recherche plus efficaces ;
70
Probleme 2D comprenant 32 objets et 60 contraintes.
Le pavage indique les positions possibles pour l’origine du repere du nouvel objet.Figure 1.28. Probleme de placement bidimensionnel dans un environnement fige [LR03]
– il contient plusieurs heuristiques dynamiques (comme ARCHiPLAN) adaptees a l’amenage-
ment spatial. Ces heuristiques permettent a la fois d’ameliorer le realisme des scenes generees
et d’accelerer considerablement la vitesse de generation des scenes dans le cas general ;
– enfin, Admunsen peut prendre en compte n’importe quelle expression mathematique sans
avoir recours au processus de decomposition du probleme. Par rapport a Oranos, cette ca-
racteristique evite l’introduction de variables supplementaires (variables muettes) et limite
notablement le travail du concepteur qui n’a plus a programmer des fonctions specifiques de
filtrage pour chaque type de contraintes.
Concernant le placement realiste d’objets geometriques complexes dans un environnement vir-
tuel, Admunsen integre une modelisation mathematique du probleme basee sur l’utilisation de
fonctions quadriques. Cette approche offre un vaste eventail de possibilites a l’utilisateur (niveau
de detail important, contraintes de placement tres variees, etc.).
La resolution de problemes non-isothetiques en modelisation declarative constitue une nouveaute
et une specificite importante de notre projet DEM2ONS.
L’inefficacite de l’approche CSP pour des problemes de grande taille et difficiles, ainsi que leur
tendance a creer des mondes trop ordonnes a conduit a l’etude des methodes stochastiques.
71
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
1.7.3.2 Metaheuristiques
Les methodes stochastiques (ou heuristiques) ont ete initialement etudiees dans le cadre de
l’optimisation combinatoire en Recherche Operationnelle et en Intelligence Artificielle. Si la
completude n’est pas essentielle, elles constituent une alternative interessante aux methodes
completes pour trouver des solutions aux problemes difficiles de grandes dimensions. Les premieres
heuristiques ont ete developpees pour resoudre des probleme specifiques. Durant les quinze
dernieres annees, les methodes stochastiques ont sensiblement progresse avec l’emergence d’une
nouvelle generation d’outils puissants et generiques appeles metaheuristiques [Glo86]. On appelle
metaheuristique une heuristique de plus haut niveau d’abstraction.
Parmi les differentes metaheuristiques existantes, peu ont ete etudiees pour le probleme d’ame-
nagement d’interieurs :
– les algorithmes genetiques [Hol75] bases sur le principe darwinien de l’evolution des especes
ont ete etudies pour la modelisation declarative dans [SRGL03, VMC+02],
– la recherche tabou a ete proposee par Glover et Hansen [Glo86, Han86] pour permettre aux
methodes de recherche locale de depasser les optima locaux. Le chapitre 2 presente l’utilisation
de la recherche tabou pour l’amenagement d’interieurs.
DEMONS-GA DEMONS-GA est un solveur de contraintes geometriques complexes base sur
un algorithme genetique. Principalement developpe par S. Sanchez [SRGL03], cet outil est dedie
a l’agencement d’objets tridimensionnels pour la construction de mondes virtuels realistes.
Algorithme genetique Les algorithmes genetiques [Hol75] classiques reposent sur un codage
universel sous la forme de chaınes de bits (0/1) de longueur fixe ainsi que sur des operateurs
d’evolution genetiques : la mutation, l’inversion et le croisement. Les individus codes de cette
maniere sont appeles chromosomes. Les operateurs agissent sur un ou plusieurs individus sans
connaissance de ce qu’ils manipulent (ni du probleme a resoudre).
Les operateurs genetiques sont complementaires : l’un concentre, l’autre diversifie, alors que
le croisement (mono ou multipoint) echange des sous-chaınes de bits sans creer de nouvelles
valeurs. La mutation qui consiste a changer aleatoirement la valeur de certains bits permet de
creer des variantes jusque-la absentes dans la population.
72
Aujourd’hui consideres comme appartenant aux methodes d’optimisation, les algorithmes genetiques
ont ete initialement developpes comme un systeme d’apprentissage general, robuste et adaptatif,
pouvant s’appliquer a une large classe de problemes. Cette demarche est a l’origine de l’universa-
lite des algorithmes genetiques : ni le codage, ni les operateurs d’evolution ne prennent en compte
les specificites du probleme. Cela a permis des analyses theoriques conduisant a la theorie des
schemas, a la caracterisation du role et de l’importance du croisement ainsi qu’a des resultats
concernant leur convergence.
En pratique, alors que les createurs des algorithmes genetiques en ont toujours vante l’univer-
salite, cette approche conduit a des problemes d’efficacite si les choix concernant le codage des
individus ainsi que celui des operateurs sont realises sans prendre en compte les specificites
du probleme. La restriction a des operateurs aveugles entraıne un desavantage lors d’une com-
paraison avec les methodes de voisinage. Comme en optimisation combinatoire classique, pour
ameliorer ces algorithmes, il est necessaire d’ameliorer les operateurs d’evolution aleatoires (croi-
sement, mutation) en tenant compte des specificites du probleme.
Figure 1.29. Image reconstruite a partir des resultats obtenus avec le solveur DEMONS-GA
[SRGL03]
Specificites de DEMONS-GA A partir de la definition des algorithmes genetiques exposee
ci-dessus, on peut donner l’acceptation des termes calques sur la biogenetique et employes com-
munement par les AG, relativement a l’application d’amenagement spatial :
73
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
1. chromosome : represente une serie d’objets a placer dans la scene selon une combinaison
de contraintes a leur appliquer ;
2. gene : correspond a un seul objet :
– la position du point de reference de la boıte englobante,
– l’orientation de la boıte englobante par rapport a la verticale,
– les dimensions au sol de la boıte englobante ;
3. allele : (position (x, y, z), orientation o, dimensions (dx, dy)) ;
4. adaptation (fitness) d’un individu : evaluation des genes par rapport aux contraintes puis
evaluation de la note finale de l’individu ;
5. genotype ou genome :
– pour un objet a placer : un chromosome a un gene,
– pour 10 objets de memes contraintes : un chromosome a 10 genes,
– pour 10 objets de memes contraintes et 3 objets avec d’autres contraintes : 1 chromosome
a 10 genes et 1 chromosome a 3 genes.
Les problemes que le solveur peut traiter sont exprimes sous forme de conjonctions ou de dis-
jonctions de contraintes elementaires. Une meme contrainte peut etre appliquee a un ensemble
d’objets et sera introduite dans le systeme de resolution grace a un seul chromosome.
Un chromosome a autant de genes que d’objets concernes par la contrainte qu’il represente.
Un individu, qui est une solution possible du probleme, est constitue d’autant de chromosomes
que de series d’objets a placer selon une combinaison de contraintes elementaires.
Resultats Les resultats sont prometteurs et permettent de penser que les algorithmes geneti-
ques sont un bon moyen de resoudre un ensemble important de contraintes sur un grand nombre
d’objets, ce qui actuellement impossible pour une methode complete (temps de calculs trop
importants et croissants de facon exponentielle selon le nombre d’objets a placer dans le cas
d’un probleme difficile).
Les temps de calculs, avec les techniques evolutives, dependent essentiellement du nombre de
generations necessaires pour obtenir un individu solution. Ils restent generalement superieurs a
la minute, mais pour les problemes envisages, les temps de placement avec des outils imperatifs
classique sont au moins equivalents et souvent nettement superieurs.
74
La convergence de l’algorithme peut etre amelioree en rendant le solveur interactif : l’utilisateur
peut visualiser les resultats partiels en cours de resolution pour l’orienter vers un choix de
solutions possibles.
Cette technique est par nature fortement parallelisable, ce qui devrait entraıner une nette dimi-
nution des temps de calculs dans les cas les plus favorables (qui restent a etudier).
Les possibilites de combinaison de contraintes sont extremement elevees, rendant l’expression
de proprietes particulierement riche pour le concepteur.
1.8 Conclusion et perspectives
1.8.1 Niveaux de detail
La gestion des niveaux de detail geometriques au sein d’un systeme integrant les differentes etapes
presentees dans cet etat de l’art peut etre complexe. Les niveaux de detail logiques decrits ici
correspondent a un echantillonnage discret du processus de generation d’une ville et donc a des
transitions brutales. Ces transitions s’effectuant a un niveau logique, il est possible de proposer
des solutions specifiques a chaque etape pour ameliorer la visualisation. Par exemple, pour les
blocs et les parcelles, nous pouvons approcher leur rendu par l’affichage de polyedres ayant pour
hauteur l’elevation maximale des batiments les recouvrant. Pour les batiments en eux-memes,
il est possible d’afficher une simple texture a grande distance, qui sera remplacee par une boite
texturee, puis par un modele simplifie (sans details geometriques), et enfin, par un exterieur de
batiment detaille. Le niveau de detail geometrique le plus fin comprendra egalement les objets
presents a l’interieur du batiment.
Le recours aux niveaux de detail logiques devrait permettre de controler au sein du graphe de
scene, la complexite de la visualisation et donc la fluidite de l’affichage de la maquette virtuelle.
1.8.2 Conclusion
Les travaux presentes dans cet etat de l’art montrent la diversite des approches existantes pour
la generation de villes. Si Parish et Mueller[PM01] presentent un systeme integre prenant en
charge les quatre premieres etapes de generation, il n’existe pas actuellement d’outil proposant
une solution pour l’integralite de la chaıne de generation. Les methodes etudiees provenant
de differents domaines de recherche, il est difficile de les comparer. Une mise en parallele est
d’autant plus ardue que l’on ne dispose pas d’outils de comparaison ou de scenes de reference.
75
Chapitre 1. Etat de l’art relatif a la generation d’environnements urbains
Il faut cependant ponderer ce constat par le fait que l’eventail des travaux presentes dans ce
chapitre semble montrer qu’il est possible d’obtenir des resultats pour l’ensemble des phases, tout
en permettant de choisir la finesse souhaitee (ou le temps de generation maximum admissible).
1.8.3 Perspectives
Certaines des six etapes de generation presentees dans ce chapitre ont fait l’objet de recherche
plus approfondies que d’autres.
L’etape de generation des parcelles est actuellement geree comme un probleme purement geo-
metrique, et il nous semble necessaire de se rapprocher davantage de la realite des codes urbains
afin d’en ameliorer la qualite.
Au vu des differentes methodes existantes pour chaque etape, il paraıt envisageable de proposer
une suite logicielle prenant en compte l’integralite du processus de generation d’une ville. Cette
suite permettrait de generer automatiquement une ville, dont l’organisation repondrait a des
contraintes de differents types (hydrographie, reliefs, densite de population) et dans laquelle
il serait possible d’entrer dans tous les batiments et d’interagir avec les objets meublant ces
batiments.
Dans cet etat de l’art, nous nous sommes attache a presenter des methodes manuelles, semi-
automatiques et automatiques pour generer des maquettes numeriques de zones urbaines reelles
ou imaginaires. Les chapitres suivant sont consacres aux differents travaux que nous avons ef-
fectues dans certains de ces domaines.
Dans un premier temps nous chercherons a evaluer l’interet des metaheuristiques issues de la
recherche locale pour le probleme d’ameublement d’interieurs. Dans un second temps, nous
presenterons notre methode de generation d’exterieurs de batiments ainsi que les resultats que
nous avons pu obtenir.
76
Chapitre 2
Placement automatique d’objets
Ces dernieres annees ont vu croıtre l’interet porte aux images de synthese ainsi qu’aux systemes
de realite virtuelle. Alors que les champs d’application12 et le nombre d’utilisateurs (qu’ils
soient infographistes, usager ou spectateur) de ces systemes ne cesse d’augmenter, les outils
de modelisation n’ont guere evolue. Les principaux outils de modelisation existants13 proposant
a present des versions d’apprentissage gratuites, tout utilisateur d’un ordinateur peut potentiel-
lement devenir un createur d’images, voire de mondes virtuels.
Les logiciels actuels, developpes depuis plus de dix ans pour certains, sont parfaitement maıtrises
par les specialistes du domaine et permettent de generer des scenes de grande qualite. Malgre
les tres bons resultats qu’ils permettent d’atteindre, il apparaıt que ce sont ces logiciels qui
constituent le facteur limitant pour le developpement de la modelisation vers le grand public.
Bien que developpes par des equipes differentes, ces logiciels presentent la plupart du temps les
memes specificites, que l’on pourrait considerer comme des defauts dans le cadre d’une utilisation
par le grand public :
– les modeles numeriques sous-jacents sont omnipresents, ce qui demande une connaissance
approfondie de ces modeles de la part de l’utilisateur,
– les possibilites d’abstraction sont reduites a une portion congrue du logiciel, obligeant l’utili-
sateur a raisonner en termes de primitives geometriques ou d’entites de tres bas niveau plutot
qu’au niveau des objets qu’il manipule,12En voici un echantillon, bien loin d’etre exhaustif : simulateurs (vol, conduite, meteorologique, etc), architec-
ture, audiovisuel, jeux video.13Citons 3DS-Max de Discreet, Maya de Alias/Wavefront ou encore LightWave de Newtek
77
Chapitre 2. Placement automatique d’objets
– enfin, les interfaces ont souvent pour point commun de decourager instantanement toute
personne n’etant pas tres motivee par l’apprentissage du logiciel.
Typiquement, lors de la modelisation d’une scene, l’utilisateur part d’une image mentale de la
scene et va tenter, par iterations successives en ajoutant ou en modifiant des objets, de generer
le modele tridimensionnel correspondant. L’image mentale est generalement assez floue, ce qui
permet a plusieurs modeles finaux d’y correspondre. Les modeleurs actuels ne permettent pas
cette demarche et imposent a l’utilisateur de fixer tres tot des positions, des orientations, c’est
a dire des valeurs numeriques, alors que le concepteur raisonne plutot en terme d’objets. Pour
developper des modeleurs tridimensionnels sachant accompagner le raisonnement humain, il est
necessaire d’utiliser des approches telles que la modelisation par contrainte, la modelisation
declarative ou l’interaction multimodale tout en integrant des lois physiques simples (gravite
principalement).
Dans ce chapitre, nous envisageons l’amenagement spatial d’une scene tridimensionnelle par des
methodes declaratives. Plus precisement nous nous interessons au probleme du canape [How68],
qui peut etre enonce ainsi [LR99] :
Etant donne un espace de placement borne (le salon), des objets (les meubles), et
un ensemble de contraintes sur ces objets (la chaise devant la table, l’armoire contre le
mur, la lampe sur la table, etc.) il faut determiner les emplacements, les orientations
et eventuellement les dimensions des objets dans cet espace pour satisfaire au mieux
ces contraintes.
L’exemple du salon sera utilise dans la suite de ce chapitre pour illustrer certains fondements
theoriques ainsi que le cadre de l’utilisation de notre modeleur. Precisons ici que notre etude ne
traite pas de redimensionnement d’objets en fonction de contraintes.
L’optimisation combinatoire14 est une voie d’etudes importante en recherche operationnelle, en
mathematiques discretes et en informatique. Typiquement, les problemes d’optimisation com-
binatoire sont faciles a definir mais difficiles a resoudre. En effet, la plupart de ces problemes
appartiennent a la classe des problemes NP-difficiles15 et ne possedent donc pas a ce jour de
solution algorithmique efficace [GJ79].14L’optimisation combinatoire consiste a trouver le meilleur entre un nombre fini de choix. Autrement dit,
minimiser une fonction, avec contraintes, sur un ensemble fini (http ://www-leibniz.imag.fr/).15NP-difficile : probleme au moins au moins aussi complexe que n’importe lequel des problemes NP.
78
De nombreuses methodes ont ete developpees en Recherche Operationnelle (RO) et en Intelli-
gence Artificielle (IA) afin de resoudre ces problemes. Ces methodes peuvent etre classees en
deux grandes categories :
– les methodes exactes (completes) capables de trouver la solution optimale si elle existe et de
prouver l’inconsistance du probleme dans le cas contraire,
– les methodes approchees (incompletes) qui perdent la completude afin de gagner en efficacite.
Certaines methodes exactes (basees sur les CSP16 ; voir Annexe B) ont deja ete etudiees dans le
cadre de la modelisation declarative [Cha95, Kwa98], elles ont permis de trouver des resultats
optimaux pour des problemes de taille raisonnable.
Les travaux realises dans notre equipe concernant les solveurs de contraintes [Kwa98, LR99,
LRG03, SRGL03] ont principalement porte sur les methodes de resolution completes (sauf
[SRGL03] qui a recours aux algorithmes genetiques). L’interet principal de ces methodes est
l’assurance de trouver toutes les solutions existantes, et de pouvoir garantir le cas echeant qu’il
n’en existe aucune. Principalement basees sur les CSP, elles heritent de leur principal defaut :
elles sont de complexite theorique exponentielle, comme tous les problemes NP-complets17, a
partir d’un certain nombre de donnees (ici des objets a placer) la charge de calcul depasse les
capacites des machines existantes et futures.
Le but de cette etude est de proposer des reponses supplementaires a la question suivante :
Quels solveurs de contraintes sont applicables a la modelisation declarative ? Apres l’etude des
algorithmes genetiques [SRGL03] et des CSP [Kwa98, LR99, LRG03], ce chapitre presente nos
recherches sur les metaheuristiques de voisinage. Dans ces travaux, nous avons souhaite mettre
l’accent sur le cote interaction et evolution incrementale.
Contribution et demarche
Dans son memoire de these [LR03], O. Le Roux a presente deux solveurs de contraintes, qui
capitalisent huit annees de recherche dans ce domaine au sein de notre equipe :
– l’un, Admunsen, base sur l’analyse d’intervalles comme Oranos [KGC97], leve la restriction
isothetique d’Oranos mais conserve la limitation au placement de boıtes englobantes,16CSP : Constraint Satisfaction Problem, probleme de satisfaction de contrainte17NP complet : non-deterministe polynomial complet (le temps de calcul croıt de facon exponentielle avec le
nombre de variables.
79
Chapitre 2. Placement automatique d’objets
CSP Algorithme
genetique
Metaheu-
ristique de
voisinage
Oranos
[Kwa98]
Admunsen
[LRG03]
Manhattan
[LRG03]
[SRGL03]
garantie non (dis-
cret)
oui oui non non
aspect na-
turel
non non oui oui oui
interactivite non non non non oui
nature du
probleme
(in)equations
non lineaires
(in)equations
non lineaires
geometrique geometrique geometrique
restriction
isothetique
oui non oui non non
restriction
boıtes
englobantes
oui oui oui oui non
incremental oui non (par-
tiel)
non (par-
tiel)
non oui
Remarques parametres
a fixer
Cible recherche recherche recherche recherche grand
public
Table 2.1. DEM2ONS
80
– l’autre, Manhattan, est fonde sur des contraintes geometriques (comme notre outil ou celui
developpe par S. Sanchez [SRGL03]), et conserve les limitations d’Oranos (boıtes englobantes
isothetiques).
Ces deux algorithmes sont une grande avancee en termes de robustesse et de performance mais,
de par leur conception, ils conservent des limitations dont notre outil entend s’affranchir :
– non-interactivite,
– restriction aux boıtes englobantes,
– non utilisable par le grand public.
La particularite de nos travaux est de developper un modeleur declaratif base sur des techniques
non encore appliquees a ce domaine. Pour ce projet, nous avons fixe les imperatifs suivants :
– l’agencement doit etre naturel (les objets places plutot au centre de leurs domaines de place-
ment et non aux bords)18,
– le but vise est l’interactivite,
– le placement des objets est non-isothetique19,
– l’algorithme doit etre incremental et stable d’une situation a la suivante.
Dans le but de satisfaire ces criteres dont certains s’averent pour le moins antagonistes (ex :
interactivite et optimisation), nous nous sommes tournes vers les metaheuristiques derivees de la
recherche locale. Les metaheuristiques permettent de creer naturellement des scenes equilibrees,
plus proche d’une scene reelle que celles generees par un solveur base sur les CSP. De plus, elles
presentent l’avantage de pouvoir etre facilement contraintes temporellement20.
Il existe une grand diversite parmi les modeleurs declaratifs. Malgre cela, et a cause de la relative
jeunesse du domaine, de nombreuses voies de recherche n’ont pas encore ete explorees. Dans la
phase de generation, les solveurs de contraintes sont bases sur les CSP ou bien sur les algorithmes
genetiques. Dans d’autres domaines, les problemes ou ces deux techniques sont utilisees sont aussi18Ce critere induit un probleme d’optimisation non lineaire non trivial. Par exemple : maximiser la distance
entre les objets de la scene : Σi,jd(obji, objj).19Isothetique : parallele ou perpendiculaire aux axes du systeme de coordonnees cartesiennes de notre monde
virtuel.20Si elles sont arretees a un instant quelconque, elles donneront un resultat (meme s’il n’est pas optimal).
81
Chapitre 2. Placement automatique d’objets
traites par le recours aux methodes issues de la recherche locale. Il etait donc naturel de nous
interesser a ces techniques dans le cadre de notre probleme de placement tridimensionnel.
Ce chapitre se decompose en deux parties principales, suivies d’une conclusion presentant les
perspectives futures.
La premiere partie s’attache a decrire les differentes methodes stochastiques existantes, pour la
plupart provenant de la recherche operationnelle.
Dans la seconde partie, nous proposerons une presentation des operateurs de Minkowski, ainsi
que des details de leur mise en œuvre, puis nous presenterons notre solution pour repondre aux
besoins specifiques de cette etude et expliciterons les choix effectues lors du developpement de
notre solveur.
2.1 Metaheuristiques
Les methodes exactes rencontrent des difficultes dans le cas de problemes de taille importante
fortement contraints, car le temps de calcul necessaire pour trouver une solution peut croıtre de
facon exponentielle avec la taille du probleme.
Les methodes approchees constituent une alternative tres interessante pour trouver des solutions
aux problemes difficiles si la completude n’est pas primordiale. Les premieres recherches autour
des methodes approchees ont ete initiees pour repondre a des probleme specifiques.
Depuis une quinzaine d’annees, les methodes approchees ont progresse notamment avec l’appari-
tion d’une nouvelle generation de methodes puissantes et generales, souvent appelees metaheuri-
stiques [Glo86]. P. Galinier et M. Habib proposent la definition suivante pour une metaheuristique
dans [HGH99] ou une synthese des principales metaheuristiques est egalement realisee, Jin-Kao
Hao, :
Une metaheuristique est constituee d’un ensemble de concepts fondamentaux et
des mecanismes d’intensification et de diversification, qui permettent d’aider a la
conception de methodes heuristiques21 pour un probleme d’optimisation.21Une heuristique est une methode, concue pour un probleme d’optimisation donne, qui produit une solution
non necessairement optimale lorsqu’on lui fournit une instance d’un probleme.
Une metaheuristique est definie de maniere similaire, mais a un niveau d’abstraction plus eleve [HGH99].
82
La difference principale entre une metaheuristique et une heuristique se situe sur le niveau
d’abstraction ou elles operent, les premieres agissant a un plus haut niveau. Les metaheuristiques
peuvent etre classees en trois familles :
– les methodes de voisinage, citons le recuit simule et la recherche tabou,
– les algorithmes evolutifs comme les algorithmes genetiques et les strategies d’evolution,
– enfin les methodes hybrides qui combinent des techniques issues des deux premieres familles.
Afin de replacer les metaheuristiques dans leur contexte, nous presentons dans ce chapitre un
apercu des methodes de resolution. Le lecteur souhaitant se documenter sur ce domaine et
obtenir une bibliographie complete peut se referer a [HGH99].
2.1.1 Panorama
Un probleme d’optimisation combinatoire est defini par un ensemble de variables. A chaque
variable du probleme est associe un ensemble de configurations22 S, un sous-ensemble X de S
representant les configurations admissibles (realisables), et une fonction de cout ϕ (ou fonction
objectif). Resoudre un tel probleme consiste a trouver une solution s* ∈X (solution optimale23)
optimisant la valeur de la fonction de cout ϕ.
Un tres grand nombre de methodes de resolution ont ete developpees en RO et en IA pour
l’optimisation combinatoire et l’affectation sous contraintes. On peut classer sommairement ces
methodes selon l’approche choisie pour la recherche de la solution :
1. l’approche de construction,
2. l’approche de relaxation,
3. l’approche de voisinage,
4. l’approche d’evolution.
Les metaheuristiques combinant principalement les approches de construction et de voisinage,
nous allons a present les detailler.
2.1.1.1 Approche de construction
Probablement la plus ancienne et encore tres repandue, l’approche de construction elabore de
facon iterative une configuration en affectant une valeur a toutes les variables libres du probleme.22Configuration : affectation de toutes les variables (les contraintes ne sont, a priori, pas satisfaites).23Solution optimale : configuration optimisant la valeur de la fonction de cout.
83
Chapitre 2. Placement automatique d’objets
Debutant avec une configuration partielle vide, elle cherche a l’etendre en affectant a chaque
etape une nouvelle variable libre. Elle effectue des choix (guides par des heuristiques) pour
determiner la prochaine variable a instancier ainsi que la valeur associee. Les methodes de cette
approche different entre elles par ces heuristiques. La performance d’une de ces methodes depend
generalement de l’adequation des heuristiques retenues avec le probleme.
Les methodes gloutonnes sont des methodes de construction [BR64]. Une instanciation gloutonne
des variables d’un probleme consiste a choisir a chaque etape la valeur d’une variable sans
modifier les affectations des variables precedemment choisies. Ces methodes sont tres rapides
mais fournissent des resultats de qualite mediocre, et notamment ne garantissent pas de retourner
un optimum meme local.
Les methodes a retour arriere (backtrack) [BR75] sont un autre exemple de methode de construc-
tion. On peut les caracteriser comme le parcours d’un arbre de recherche en profondeur d’abord,
complete par une detection des erreurs (generalement l’ensemble des valeurs possibles pour la
variable courante est nul). Lorsque un echec est detecte, le processus effectue un retour arriere
sur la derniere variable instanciee, offrant une instanciation alternative. Ces methodes sont le
plus souvent completes et de complexite exponentielle. Afin de reduire la complexite, on utilise
des techniques de filtrage permettant de detecter les echecs. Ces techniques ont deja ete etudiees
en modelisation declarative au sein de notre equipe ([LR03, Kwa98]).
2.1.1.2 Approche de voisinage, recherche locale
La recherche locale, appelee aussi la descente [Flo56] ou l’amelioration iterative, est historique-
ment une des methodes de voisinage. Neanmoins, ce terme tend a designer aujourd’hui toutes
les methodes de voisinage. Contrairement a l’approche de construction, la recherche locale ne
manipule que des configurations au cours de la recherche.
Ces methodes sont basees sur la notion de voisinage. Nous allons definir cette notion ainsi que
quelques notions associees :
Une methode typique de voisinage debute avec une configuration initiale (souvent un tirage
aleatoire dans l’espace des configurations), puis realise un processus iteratif qui consiste a effec-
tuer un mouvement24 choisi par le mecanisme d’exploration25 en tenant compte de la fonction24Mouvement : operation elementaire permettant de passer d’une configuration A a une configuration A’ voisine
de A.25Mecanisme d’exploration : procedure qui precise comment passer d’une configuration A a une autre configu-
ration A’ appartenant au voisinage de A.
84
de cout. Ce processus s’arrete et retourne la meilleure configuration trouvee une fois que la
condition d’arret est satisfaite. La condition d’arret peut porter sur le nombre d’essais effectues,
sur une limite temporelle ou sur le degre de qualite de la meilleure configuration courante. Cette
versatilite permet de controler le temps de calcul. La qualite de la solution optimale trouvee
s’ameliorant au cours du temps, l’utilisateur est libre d’arreter l’execution au bout du temps
choisi (dans notre cas, temps interactif voire temps reel, entre 0.04 et 0.2 secondes soit entre 5
et 25 images par secondes).
A* ←creerUneSolution()
pour t = 1 a MAXESSAIS faire
A ←newSol()
pour m = 1 a MAXMVTS faire
A’ ←choisirVoisin()
δ ← ϕ(A’) - ϕ(A)
si accepter(δ) alors A ← A’
fin pour
si ϕ(A*) ¿ ϕ(A) alors A* ←A
fin pour
retourner A*, ϕ(A*)
Algorithme 1. Recherche locale
L’algorithme 1 presente le deroulement classique d’une methode de recherche locale. Les methodes
de voisinage different essentiellement entre elles par le voisinage26 utilise et la strategie de par-
cours de ce voisinage. La recherche locale etant a la base des metaheuristiques, nous presentons
ici les heuristiques les plus repandues la concernant.
Le mecanisme d’exploration peut consister en une enumeration des voisins : le choix portera sur
le premier voisin ameliorant (au sens de la fonction de cout) strictement la configuration. Il est
egalement possible d’evaluer tous les voisins afin de selectionner le meilleur ; cette heuristique est
plus couteuse mais permet une evolution plus rapide vers un optimum. Comme cette methode
ne s’appuie que sur un voisinage restreint, elle ne retourne que des minima locaux.
Comme les methodes gloutonnes, cette approche est simple a mettre en œuvre et rapide a
l’execution. La principale limitation provient du fait qu’elle retourne le premier optimum local26Voisinage de A : ensemble des configurations A’ accessibles a partir de A en realisant un seul mouvement.
85
Chapitre 2. Placement automatique d’objets
rencontre. On peut contourner cette limitation en relancant le processus apres avoir genere une
nouvelle configuration aleatoire, ou bien en etendant le choix du meilleur voisin aux meilleurs
voisins de meme valeur (lever la condition stricte d’amelioration), afin de pouvoir se deplacer
sur des plateaux 27.
Sur ce profil,et dans le cadre d’un probleme de minimisation : 1 est un optimum global, 2, 3 et 4 sont des optima
locaux, 3 est un plateau, enfin les quatre points caracterises se trouvent au fond d’une vallee.
Figure 2.1. Exemples de vallees et plateaux
Le terme plateau fait reference au profil d’une chaıne de montagne. Un autre terme provenant
de la meme origine est employe en optimisation combinatoire, c’est celui de vallee28. La figure
2.1 permet de visualiser le choix de ces appellations.
2.1.2 Differents types de metaheuristiques
2.1.2.1 Methodes de voisinage
Recuit simule (Simulated Annealing) La methode du recuit simule [KGV83, MRR+53]
s’inspire d’un phenomene physique utilise en metallurgie, le recuit. Afin d’ameliorer la qualite
d’un solide, la matiere est porte a tres haute temperature, bien au-dela de la temperature de
fusion, puis la matiere est ramenee par palier a la temperature de solidification, en lui laissant
le temps de parvenir a un equilibre thermodynamique a chaque etape.
Le mecanisme de parcours associe a cette methode consiste a realiser un tirage aleatoire au sein
du voisinage de la configuration courante. Si la configuration trouvee ameliore (au sens de la
fonction de cout) la configuration courante, le mouvement est effectue. Sinon, le mouvement est27Plateau : ensemble de configurations de meme cout, connexes par voisinage.28Vallee : dans un probleme de minimisation, ce terme caracterise un minimum (local ou global).
86
effectue avec une probabilite suivant la loi de probabilite definie par p(∆ϕ, T ) = e−∆ϕ
T ou T est
un parametre de controle (la temperature du systeme) et ∆ϕ la difference entre la configuration
courante et la configuration tiree aleatoirement au sens de la fonction de cout ϕ.
Le recuit simule peut etre vu comme une version etendue de la methode de descente. L’amelio-
ration principale consiste en la possibilite (controlee) d’accepter des mouvements qui degradent
la fonction de cout. Cette degradation est acceptee en fonction de son importance et de la
temperature du systeme. La temperature est definie par une fonction decroissante qui controle
l’evolution du systeme. L’algorithme s’arrete lorsque aucune configuration n’a ete acceptee depuis
un certain temps, depuis un certain nombre d’iterations, ou bien lorsque la temperature atteint
la valeur de solidification (generalement zero). Il a ete prouve qu’a la limite (i.e. si la temperature
descend infiniment lentement) cette methode est complete.
Les algorithmes d’acceptation avec seuil (Threshold algorithms) Ces algorithmes
[DS90] sont des variantes du recuit simule. Ils en different par la fonction d’acceptation de
degradation. Pour le recuit simule, ce choix est fait selon une loi de probabilite. Pour cette
methode, il est fait de facon deterministe. L’acceptation d’un mouvement est validee par la sa-
tisfaction de l’inegalite suivante : r(s, s′) < Tk. Dans le cas le plus simple, r(s, s′) = ∆ϕ et
le seuil Tk a la meme fonction que la temperature dans le cas du recuit simule. Il est initie a
une valeur elevee puis decroıt progressivement apres un certain nombre (variable) d’iterations.
Les seuils forment une suite decroissante avec lim Tk → 0 afin de diminuer au cours du temps la
possibilite d’accepter une configuration qui degrade la fonction de cout.
Methodes de bruitage La methode de bruitage [CH93] s’applique a des problemes dont les
configurations portent sur des domaines continus. Elle fait appel a une notion de bruitage de la
donnee qui est effectue en ajoutant a chaque reel de la donnee initiale une composante calculee
comme le produit de trois termes :
1. une fonction aleatoire a valeur sur l’intervalle [0, 1],
2. un parametre qui controle le niveau de bruit,
3. le plus grand des reels concernes, dans le but de normaliser le niveau de bruit par rapport
a la donnee.
A chaque etape, il est effectue une descente par rapport a la donnee bruitee et le niveau de
bruit est progressivement diminue. Il existe des variantes pour cette methode, par exemple il
87
Chapitre 2. Placement automatique d’objets
est possible d’effectuer a chaque etape une descente sur la donnee non bruitee et de selectionner
le meilleur candidat. Il est egalement envisageable de remplacer regulierement la configuration
courante par la meilleure trouvee depuis l’initialisation de la methode.
L’utilisation du bruitage permet a la recherche de ne pas rester bloquee dans le voisinage d’un
minimum local (possibilite de sortir d’une vallee).
Recherche tabou Cette methode [Glo86, Han86] fait appel a des concepts et mecanismes
generaux pour executer la recherche dans l’ensemble des configurations de maniere plus intelli-
gente.
Soit un probleme
de placement en deux dimensions. L’image de gauche represente l’etape courante. Le carre en noir correspond a
la configuration courante. La caracteristique choisie pour figurer dans la liste tabou est l’ordonnee.
La figure de droite met en evidence les configurations interdites par la liste tabou. On constate que quatre
configurations non testees sont interdites.Figure 2.2. Importance du choix de la caracteristique tabou.
Alors que la methode du recuit simule tire aleatoirement une configuration dans le voisinage de la
configuration courante, la recherche tabou examine un echantillon de configurations du voisinage
(potentiellement toutes) et realise le mouvement en direction de la meilleure configuration de cet
echantillon. Ce mouvement peut conduire a degrader la fonction de cout, ce qui permet de ne
pas stopper la recherche sur le premier optimum local rencontre. Neanmoins, cette heuristique
de choix est extremement vulnerable aux cycles : si deux configurations voisines forment un
plateau, la recherche ne sortira jamais de ce cycle de longueur 2. Pour lever cette limitation, il a
ete introduit le concept de liste tabou qui memorise les k dernieres configurations visitees par la
recherche. Comme l’exprime le terme tabou, ces configurations ne pourront pas etre selectionnees
a nouveau au cours de la recherche. Cette liste permet de s’affranchir des cycles de longueur
inferieure ou egale a k. La valeur de k doit etre choisie en considerant le probleme a resoudre, elle
peut aussi etre modifiee dynamiquement durant la recherche. Comme pour le recuit simule, dans
le cas limite (i.e. k tend vers le cardinal de l’espace de recherche), la recherche tabou s’apparente
a une methode complete.
88
Dans un probleme de placement gerant un millier d’objets, chacun defini par six degres de liberte
(trois pour le positionnement, trois pour l’orientation), la sauvegarde dans la liste tabou peut
tres rapidement etre trop couteuse en espace memoire et en temps de calcul. Pour eviter ce
probleme, la liste tabou ne stocke pas les configurations completes mais des caracteristiques de
ces configurations. Concretement, apres qu’un mouvement ait ete effectue, on stocke la variable
modifiee par ce mouvement, ainsi que son ancienne valeur. Ce couple est memorise, et devient
donc interdit pour les k prochains mouvements. L’ancienne configuration ne pourra plus etre
visitee, ainsi que toutes les configurations qui affectent la valeur tabou a la variable tabou.
Nous avons vu (cf. Figure 2.2) que la sauvegarde des caracteristiques interdisait de facto l’acces
a certaines configurations non testees. Pour assouplir cette restriction, il a ete developpe un
mecanisme particulier, l’aspiration qui permet de lever un statut tabou sans introduire un risque
de cycle dans la recherche. La maniere la plus simple consiste a lever le statut tabou si le mou-
vement conduit a une configuration de qualite superieure a la meilleure configuration courante
(au sens de la fonction de cout).
Il a ete introduit d’autres techniques pour ameliorer la recherche tabou, citons :
– l’intensification qui consiste a memoriser les criteres communs aux meilleures configurations
pour orienter la recherche preferentiellement dans leurs directions,
– la diversification, qui, au contraire, tend a diriger la recherche vers des zones inexplorees de
l’espace des configurations.
La recherche tabou peut etre caracterisee par une strategie agressive de recherche (par la selection
d’un des meilleurs mouvements), ainsi que par les nombreuses techniques developpees pour
ameliorer la recherche. Cette diversite a un prix, qui est l’obligation d’adapter la recherche au
probleme a resoudre.
2.1.2.2 Algorithmes evolutifs
Dans cette categorie de metaheuristiques, on retrouve tous les algorithmes bases sur le pro-
cessus naturel (darwiniste) d’evolution du vivant. Un algorithme evolutif typique reunit trois
composants :
1. une population qui regroupe plusieurs individus (en optimisation combinatoire classique :
configuration du probleme),
2. une fonction d’adaptation (fitness) qui evalue la performance d’un individu par rapport
au milieu (en optimisation combinatoire classique : fonction de cout),
89
Chapitre 2. Placement automatique d’objets
3. un mecanisme d’evolution, compose de plusieurs operateurs de modification et de selection.
Typiquement, un algorithme evolutif debute avec une population (generalement obtenue de facon
aleatoire), puis repete la boucle suivante (le terme employe est generation a la place de celui
habituel d’iteration) :
1. evaluer chaque individu de la population,
2. selectionner des individus,
3. produire des nouveaux individus par recombinaison des individus selectionnes.
Les differences principales entre les algorithmes evolutifs et les methodes classiques d’optimisa-
tion combinatoire sont les phases de selection et d’evolution. La selection permet de choisir les
meilleurs individus et c’est a partir de ceux-ci que l’on construit la generation suivante. On peut
la rapprocher du mecanisme d’intensification de la recherche tabou applique de facon massive-
ment parallele. L’evolution repose sur deux principaux operateurs, la recombinaison qui combine
plusieurs individus parents pour creer des individus enfants pour la generation suivante, et la
mutation qui altere legerement certains individus.
Les algorithmes evolutifs les plus souvent rencontres sont les algorithmes genetiques (presentes
en 1.7.3.2.0) et les strategies d’evolution [Rec73].
2.1.2.3 Methodes hybrides
Les methodes hybrides combinent des methodes issues de la recherche locale classique (descente),
des metaheuristiques locales et des algorithmes d’evolution.
Algorithmes memetiques La memetique est l’etude des memes, autrement dit d’entites
replicatives d’information. Le terme de memetique a ete propose pour la premiere fois par
Richard Dawkins dans son œuvre The Selfish Gene (1976), et provient d’une association entre
gene et mimesis (du grec ”imitation”).
Cette approche [Mos89] combine la puissance de recherche des methodes de voisinage avec celle
de recombinaison des algorithmes evolutifs. Un algorithme memetique utilise des methodes de
voisinage sur les individus d’une population pendant un certain nombre d’iterations ou jusqu’a la
decouverte d’un ensemble d’optima locaux, puis utilise un mecanisme de recombinaison adapte
au probleme pour creer une nouvelle population.
90
Cette methode, bien que tres puissante, souffre de defauts redhibitoires : les temps de calcul
peuvent devenir prohibitifs lors de l’utilisation de population de grande taille, ce probleme
pouvant etre contourne par l’utilisation de machines distribuees qui sont bien adaptees aux
algorithmes memetiques.
GRASP (Greedy Randomized Adaptive Search Procedure) Cette methode hybride
[FR89] cherche a combiner les avantages des heuristiques gloutonnes, de la recherche aleatoire
et des methodes de voisinage. Un algorithme GRASP peut etre defini comme une boucle com-
portant deux etapes :
1. la construction d’une configuration de facon iterative (cf. 2.1.1.1), en choisissant a chaque
etape la valeur a instancier dans le voisinage de facon aleatoire,
2. une descente (cf. 2.1.1.2) est effectuee pour ameliorer cette configuration.
Ces deux etapes sont repetees jusqu’a satisfaction de la condition d’arret. Une fois cette condi-
tion satisfaite, la procedure retourne la meilleure configuration trouvee. Les parametres de cette
methode sont la methode de determination du voisinage ainsi que le nombre d’iterations auto-
risees.
2.1.3 Analyse des metaheuristiques
Apres avoir presente les differentes methodes existantes basees sur les metaheuristiques, nous
nous appliquerons a present a les analyser.
2.1.3.1 Exploitation et exploration
Les notions complementaires d’exploitation et d’exploration ont ete introduites par les inventeurs
des algorithmes genetiques. L’exploitation consiste a rechercher plus particulierement dans les
zones de recherches deja definies (strategie de recherche en profondeur d’abord), tandis que
l’exploration realise un survol de l’ensemble de l’espace des configurations afin de decouvrir des
zones prometteuses (strategie de recherche en largeur d’abord). Ces deux notions ne sont pas
restreintes aux algorithmes genetiques mais concernent l’ensemble des methodes de recherche et
peuvent servir a caracteriser ces methodes.
Exploitation Les methodes de voisinage utilisent la fonction de voisinage afin de diriger ra-
pidement la recherche vers des configurations de qualite. En cherchant les candidats potentiels
91
Chapitre 2. Placement automatique d’objets
uniquement a faible distance des meilleures configurations retenues, elles realisent de fait une
recherche axee sur l’exploitation.
Les algorithmes genetiques font reposer la notion d’exploitation sur le mecanisme de croisement
alors que les methodes de voisinage utilisent la selection des meilleurs mouvements. Certaines
methodes ont, par ailleurs, developpe des mecanismes de renforcement de cette exploitation
comme, par exemple, l’intensification pour la recherche tabou.
Une utilisation exclusive du principe d’exploitation ne suffit pas a donner des resultats satisfai-
sants. En effet, ce principe ne conduit qu’a des optima locaux, qui peuvent se reveler etre des
solutions mediocres. Ceci est du au fait qu’une infime partie de l’espace des configurations a ete
exploree durant la recherche. La solution pour s’affranchir de ce probleme consiste a mettre en
place des mecanismes correctifs, utilisant la notion d’exploration.
Exploration La premiere strategie envisageable est la relance. Elle consiste a recommencer
entierement le processus de recherche (en gardant la meilleure configuration obtenue precedem-
ment) a partir d’un nouveau tirage aleatoire dans l’espace des configurations.
La seconde strategie, qui est aussi simple a mettre en œuvre que la precedente, consiste a
introduire des perturbations aleatoires au cours de la recherche. Cette strategie a donne naissance
a la notion de mutation pour les algorithmes evolutifs, ainsi qu’a la methode qui genere un voisin
aleatoire pour le recuit simule. Dans les deux cas, la configuration courante est perturbee de
maniere aleatoire et un mecanisme d’acceptation est applique a posteriori.
La troisieme strategie consiste a memoriser les caracteristiques des regions visitees et a inciter
la recherche a s’eloigner de ces zones. On retrouve cette strategie dans la recherche tabou par la
mise en œuvre de la liste tabou (court terme) et de la diversification (long terme). On peut re-
marquer que cette strategie est plus complexe a implanter que les precedentes et qu’elle necessite
l’utilisation d’une memoire.
Recombinaison Cette notion complete (voire combine) les deux precedentes afin d’essayer
d’atteindre des zones non encore explorees. Ces methodes permettent de commencer la recherche
dans une nouvelle region tout en ayant deja des individus satisfaisants au sens de la fonction de
cout. Initialement issue des algorithmes genetiques (le croisement), elle consiste a recombiner
plusieurs configurations interessantes pour en creer de nouvelles.
92
Cette notion est en fait la base principale des algorithmes hybrides qui allient une methode de
voisinage et la recombinaison. On retrouve ces deux principes egalement dans le recuit simule
ou le controle s’effectue en reglant la temperature.
2.1.3.2 Specificite contre generalite
Historiquement, les premiers algorithmes developpes l’ont ete pour un probleme specifique. Les
metaheuristiques etant concues a un niveau d’abstraction plus eleve, elles peuvent etre adaptees
a des classes tres larges de problemes. Pour expliquer l’efficacite d’un algorithme specifique,
l’argument le plus souvent avance est la prise en compte des caracteristiques du probleme.
Un des avantages le plus souvent cite par les precurseurs des algorithmes genetiques est leur
genericite. Si le comportement global de l’algorithme est bien le meme quel que soit le probleme,
ce n’est pas le cas du codage des individus qui determine aussi la fonction de croisement ainsi que
la definition de la fonction d’adaptation. Cette necessite d’integrer les specificites du probleme
est egalement presente pour les autres metaheuristiques.
La facon la plus immediate d’ameliorer les performances d’une metaheuristique pour un probleme
donne est d’adapter ses operateurs en fonction des connaissances specifiques que possede le
concepteur sur ce probleme. Cette adaptation (si les connaissances necessaires sont dispo-
nibles) demande un effort de conception pour specialiser l’operateur. Ainsi, la recherche tabou
se specialise selon le choix des caracteristiques sauvegardees dans la liste tabou. Les algorithmes
genetiques, autrefois parangons de la genericite, proposent a present des operateurs specifiques
ainsi que des codages des individus ne reposant plus uniquement sur les chaınes de bits. D’un
autre cote, le recuit simule est un exemple de methode facile a adapter a un probleme et ne
demandant pas de connaissances specifiques.
2.1.3.3 Choisir une metaheuristique
Dans [HGH99], J. Hao, P. Galinier et M. Habib proposent une grille permettant de choisir une
metaheuristique en fonction d’un probleme.
93
Chapitre 2. Placement automatique d’objets
A.I. R.S. R.T. A.G. A.H.
Simplicite 0 - - - –
Facilite d’adaptation 0 0 - - -
Connaissance 0 0 + + +
Qualite 0 + ++ + ++(+++)
Rapidite 0 - - – –Table 2.2. Comparaison generale des principales metaheuristiques [HGH99]
Dans le tableau 2.2, les six metaheuristiques comparees sont les suivantes :
A.I. : amelioration iterative (descente) avec relance,
R.S. : recuit simule,
R.T. : recherche tabou,
A.G. : algorithme genetique adapte,
A.H. : algorithme hybride.
La methode d’amelioration iterative est utilisee comme point de reference pour l’ensemble des
methodes : les signes -, 0, + indiquent des performances respectivement inferieures, egales ou
superieures a celles obtenues par l’amelioration iterative.
Les criteres de comparaison retenus sont les suivants :
– simplicite de la metaheuristique, i.e. simplicite de la methode elle-meme,
– facilite d’adaptation au probleme,
– possibilite d’integrer des connaissances specifiques du probleme,
– qualite des meilleures configurations trouvees,
– rapidite, i.e. le temps de calcul necessaire pour trouver une telle configuration (la valeur entre
parentheses correspond a une architecture distribuee).
2.1.3.4 Discussion
Les metaheuristiques partagent un certain nombre d’avantages, parmi lesquels nous pouvons
citer :
– Une mise en œuvre facilitee par le fait qu’il suffit d’avoir une fonction d’evaluation (par
opposition aux algorithmes de parcours d’arbre et de filtrage necessaire pour l’approche CSP).
94
– La possibilite de limiter le temps d’execution ce qui permet d’envisager des systemes interac-
tifs. En effet il est possible d’obtenir tres vite une configuration du probleme, qui ne sera pas
forcement une solution. Plus il sera laisse de temps a l’algorithme, meilleure sera la solution
(sauf si la solution est deja optimale).
– La capacite de traiter de tres vastes domaines de recherche. Une fois de plus, c’est surtout par
opposition aux CSP que cet avantage prend tout son sens.
– Enfin, ils sont tres facilement parallelisables. Par exemple, dans le cas de la Recherche Tabou,
seule la liste tabou est a partager entre les differents processus. Ce sont le peu d’information a
partager et la possibilite de lancer des nouvelles recherches a partir d’un etat initial different
qui rendent la parallelisation aisee.
Bien entendu, les metaheuristiques souffrent aussi de certains defauts comparees a l’approche
CSP :
– Une solution optimale au probleme peut ne pas etre trouvee. Ceci decoule de l’aspect stochas-
tique de ces methodes.
– L’inconsistance d’un probleme ne peut pas etre prouvee. Contrairement a l’approche CSP
qui elimine de grands pans du domaine de recherche grace au filtrage, les metaheuristiques
ne parcourent pas l’ensemble de ce domaine. Meme si une liste tabou de longueur infinie
pourrait permettre de tester l’inconsistance d’un probleme, il ne s’agirait plus reellement
d’une metaheuristique mais plutot d’une methode backtrack particulierement inefficace.
– Les meilleurs resultats (en termes de fonction d’evaluation ou en temps de recherche) sont
atteints avec des parametres ideaux qui sont generalement trouves de maniere empirique.
2.1.3.5 Adequation a notre probleme
Les metaheuristiques sont particulierement adaptees a notre probleme de resolution de contraintes.
En effet celui-ci presente :
– Un domaine de recherche tres vaste, chaque objet pouvant avoir jusqu’a neuf degres de liberte.
– Certaines contraintes, notamment la plus utilisee qui est la contrainte de non-intersection, ne
sont pas differentiables.
– Il est preferable que les objets de la scene ne soient pas disposes de facon trop reguliere.
Contrairement aux systemes deterministes, les approches stochastiques tendent a creer des
scenes plus realistes car moins ordonnees.
95
Chapitre 2. Placement automatique d’objets
– Certaines de nos descriptions de problemes presentent des graphes de contraintes cycliques,
toujours delicats a traiter.
Nous allons maintenant presenter notre modeleur declaratif, capable de traiter des scenes com-
plexes en un temps interactif (entre 5 et 25 images par seconde). Le recours aux metaheuristiques
nous permet de controler la duree de la phase de generation. Ainsi, notre modeleur peut s’adap-
ter a la plateforme d’execution et aux attentes de l’utilisateur en choisissant le nombre d’essais
en fonction des capacites de la machine. Un tel controle nous permet de creer des scenes avec
plusieurs centaines d’objets et ceci de facon interactive.
2.2 Mise en œuvre
Jusqu’a present, les solveurs de contraintes utilises en modelisation declarative ont souffert de
leur limitation aux objets isothetiques et au placement d’objets bases sur leurs boıtes englo-
bantes. Notre approche nous permet de prendre en compte la geometrie des objets de maniere
plus satisfaisante en utilisant l’enveloppe convexe de leur projection verticale au sol.
Pour illustrer les travaux decrits dans ce chapitre, nous avons developpe un modeleur declaratif
interactif : DEMONS LE. Ceci nous a permis de tester l’interactivite reelle de notre approche.
Dans un premier temps, nous presentons notre mise en œuvre des operateurs de Minkowski sur
les polygones convexes qui permettent a notre modeleur de mieux prendre en compte la geometrie
des objets de la scene. Ensuite, nous decrivons le modele qui integre la prise en compte de ces
operateurs ainsi que les domaines et objets manipules. Enfin, nous detaillons les contraintes
utilisees ainsi que leur mise en œuvre dans le modeleur.
2.2.1 Operateurs de Minkowski pour les contraintes geometriques
Depuis le debut du developpement de DEM2ONS, les solveurs de contraintes utilises, et donc
le modeleur en lui-meme, ont ete restreints au placement de boıtes englobantes (le plus souvent
isothetiques). Cette restriction fait que DEM2ONS realise essentiellement un placement en deux
dimensions (les objets peuvent toutefois etre places les uns sur les autres). Le placement en deux
dimensions peut etre vu comme un cas particulier des problemes de planification de trajectoire29,29Motion planning.
96
rencontres en robotique. Ce cheminement nous a conduit a etudier les techniques utilisees dans
ce domaine.
Dans un probleme de placement en deux dimensions, les differents objets du monde peuvent etre
representes par des polygones. Cette representation conduit a considerer ce probleme comme
une recherche d’intersection ou d’inclusion entre polygones. Parmi les outils mathematiques
existants pour ces recherches, les plus utilises en planification de trajectoire sont ceux bases sur
les operateurs de Minkowski.
Les sommes et differences de Minkowski [Min97] sont utilisees dans notre outil afin de calculer
le degre de satisfaction des contraintes entre les objets. Ces objets sont places actuellement en
manipulant le contour qu’ils projettent verticalement sur le sol. Nous allons a present nous atta-
cher a definir les operateurs de Minkowski, puis a presenter leur mise en œuvre au sein de notre
outil.
Les definitions suivantes sont issues de [Gho90].
2.2.1.1 Somme de Minkowski
La somme de Minkowski peut etre vue comme l’operateur addition dans l’espace des polygones.
Elle est generalement decrite comme une croissance ou une dilatation30 d’un polygone par un
autre polygone (cf. figure 2.3).
Somme de Minkowski Soit B et T deux ensembles de points de Rn. La somme de Minkowski
S de B et de T est obtenue en positionnant B sur chaque point de T , c’est a dire en ajoutant
vectoriellement tout les points de B a ceux de T . Nous notons ceci par :
S = B ⊕ T = { b + t : b ∈ B, t ∈ T }
avec ⊕ representant l’operateur somme de Minkowski.
Si on note A~p, le resultat de la transformation de l’ensemble A par le vecteur ~p, et si l’on note
b et t des points inclus dans B et T on peut noter la somme de Minkowski ainsi :
S = T ⊕ B = B ⊕ T =⋃
p∈T
B~tp =⋃
p∈B
T~bp
Dans [O’R98], J. O’Rourke enonce ce theoreme qui relie la somme de Minkowski a notre probleme
de placement :30Elle est d’ailleurs utilisee sous ces termes en analyse d’images.
97
Chapitre 2. Placement automatique d’objets
Soit B, un polygone a placer et r ∈ B son point de reference. Soit P , un polygone
obstacle. Alors le polygone P+ = P ⊕ −B est l’ensemble des points interdits a r
dans le sens ou :
1. Si B est translate de facon a ce que r soit strictement interieur a P+, alors B
chevauche P .
2. Si B est translate de facon a ce que r repose sur l’enveloppe de P+, alors P et
B se touchent.
3. Si B est translate de facon a ce que r soit strictement exterieur a P+, alors P
et B sont disjoints.
Ici, −R represente le symetrique de B par rapport a r.
Le triangle B represente le contour de l’objet que l’on souhaite placer.
La croix interieure a ce triangle en est le point de reference.
Le triangle −B est le symetrique de B par rapport a son point de reference.
Le rectangle P represente la forme que ne doit pas chevaucher le triangle.
Le pentagone P+ est le resultat de la somme de Minkowski de P et −B
Pour que les deux formes soient disjointes, il suffit de placer le point de reference a l’exterieur de ce pentagone.
Figure 2.3. Somme de Minkowski
98
2.2.1.2 Soustraction de Minkowski
La soustraction de Minkowski est l’operation inverse de la somme. Elle est generalement decrite
comme un operateur d’erosion ou d’effacement (cf. figure 2.4).
Soustraction de Minkowski Soit B et T deux ensembles de points de Rn. La soustraction
de Minkowski S de B par T est definie par :
S = B T =⋂
p∈T
B~tp
avec T correspondant a l’ensemble symetrique de T par rapport a l’origine du repere.
Le rectangle (A) a l’interieur du pentagone (S) represente la soustraction de Minkowski du pentagone plein (S)
par le triangle (-B).
Si le point de reference du triangle (B) est a l’interieur du contour du rectangle (A), alors le triangle (B) est inclus
dans le pentagone (S).
Figure 2.4. Soustraction de Minkowski
2.2.2 Domaines et objets
Le domaine de placement, au sein duquel de nouveaux objets sont ajoutes, est un espace tridi-
mensionnel limite. Cet espace est base sur une forme polygonale (pour le contour de la zone) et
une hauteur. Lorsque aucune contrainte explicite n’est definie, ce polygone represente le sol du
monde ainsi que la surface de support par defaut. Si une contrainte plus restrictive est definie,
le domaine est plus specifique. Par exemple, dans le cas de la contrainte Pose sur, la surface de
support doit etre l’une des surfaces de support de l’objet site.
99
Chapitre 2. Placement automatique d’objets
Les objets peuvent prendre n’importe quelle orientation. Actuellement DEMONS LE peut uni-
quement gerer les rotations autour de l’axe vertical, c’est une consequence de l’absence de moteur
physique. Lorsqu’un objet presente des symetries autour de l’axe vertical, le domaine associe a
l’angle de rotation est reduit en fonction (par exemple, dans le cas d’une table carree, ce domaine
sera reduit a des valeurs appartenant a [0° ; 90°[).
Figure 2.5. Occupation au sol : rectangle englobant (gauche) et enveloppe convexe (droite)
Dans sa version actuelle, DEMONS LE place les objets en utilisant l’enveloppe convexe de
la projection orthographique au sol des sommets de l’objet. La Figure 2.5 presente la surface
gagnee en utilisant cette approche en lieu et place des rectangles englobants precedemment
utilises. Dans le cas le plus favorable (lorsque que cette projection a une forme triangulaire), le
recours a l’enveloppe convexe permet d’utiliser moitie moins de place que l’approche basee sur
le rectangle englobant.
Bien que cette technique permette des resultats plus precis que l’approche basee sur les boıtes
englobantes, elle ne reste qu’une etape avant l’utilisation de la veritable forme tridimensionnelle
des objets.
2.2.3 Contraintes
Les contraintes presentes au sein de notre modeleur sont basees sur celles proposees par Philippe
Charman dans son memoire de these [Cha95]. Nous utilisons des contraintes binaires, qui mettent
en relation seulement deux objets. Nos contraintes decrivent un probleme local de placement
que le solveur peut facilement traiter afin de trouver une solution satisfaisante. Neanmoins, de
telles contraintes peuvent etre aisement combinees dans le but de creer des proprietes de plus
haut niveau. Par exemple, placer cinq objets A autour d’un objet B et tournevers B.
Toutes nos contraintes utilisent la terminologie de Vandeloise [Van86] dans laquelle l’objet cible
est a placer relativement a l’objet site :
100
Objetcible Contrainte(p) Objetsite
Lorsque que l’utilisateur veut ajouter un Objetcible au sein de la scene, il selectionne un Objetsite
dans la fenetre ou la scene tridimensionnelle est visualisee et exprime les contraintes de la section
suivante qui doivent etre satisfaites entre ces deux objets. La Figure 2.6 presente ce processus.
Dans cette image, l’utilisateur a choisi d’ajouter une chaise en bois a la scene, alors qu’une chaise a roulettes etait
selectionnee dans la fenetre 3D. Le modeleur propose les choix possibles de contraintes entre ces objets.
Figure 2.6. Choix des contraintes a satisfaire lors de l’ajout d’un nouvel objet dans la scene.
Dans la suite de cette section, nous presentons une liste non exhaustive des contraintes mises en
œuvre dans notre outil. Ces contraintes fournissent un resultat exprimant, en pourcentage, leur
degre de satisfaction. Preferee aux classiques reponses booleennes, cette approche permet une
notation plus fine de la qualite d’une solution. Ces contraintes sont dites explicites ou implicites.
101
Chapitre 2. Placement automatique d’objets
Une contrainte est implicite si elle n’a pas besoin d’etre specifiquement enoncee par l’utilisateur
(contrainte de non-chevauchement).
2.2.3.1 Contraintes topologiques
Cette categorie rassemble les contraintes qui definissent la position des objets les uns par rapport
aux autres.
Voici quelques-unes de ces contraintes :
– au dessus,
– a l’interieur,
– en face de,
– derriere,
– a gauche,
– a droite.
La premiere contrainte, dite de superposition, utilise une liste de surfaces de support, propres
a l’objet site. Ces surfaces correspondent a la partie superieure de l’objet site. Si l’on prend
l’exemple d’une bibliotheque, la liste des surfaces de support serait restreinte a la partie superieure
du meuble.
La seconde contrainte, dite d’inclusion, utilise aussi une liste de surfaces correspondant aux zones
sur lesquelles on peut placer l’objet cible pour qu’il soit a l’interieur de l’objet site. En reprenant
l’exemple de la bibliotheque, la liste des surfaces supports contiendrait toutes les etageres.
Ces contraintes sont basees sur la difference de Minkowski. Les objets etant places soit sur le
sol, soit sur un autre objet, il faut egalement verifier que l’objet ne deborde pas du haut de la
scene ou hors de la surface support de l’objet site.
Les quatre autres contraintes sont calculees comme les contraintes d’orientation.
2.2.3.2 Contraintes physiques
Les contraintes physiques de disjonction et de gravite sont actuellement les seules contraintes
implicites presentes au sein de notre modeleur.
La premiere, la contrainte de disjonction ou non-chevauchement, est ajoutee automatiquement
entre tout nouvel objet du monde et chacun des objets deja places sur la meme surface de
support. La contrainte de disjonction fait generalement l’objet de beaucoup d’attention dans
le developpement d’un modeleur declaratif. En effet, pour un monde contenant n objets, cette
102
contrainte est utilisee n(n−1)2 fois. De son efficacite et de sa robustesse dependent le confort
d’utilisation et la reactivite d’un modeleur. Pour ces raisons, nous avons decide d’utiliser les
operateurs de Minkowski sur les polygones pour calculer cette contrainte.
La seconde contrainte physique, celle de gravite, n’est pas encore reellement prise en compte par
notre modeleur mais le placement des objets est restreint aux surfaces horizontales valides (i.e.
de support). La prise en charge de cette contrainte serait facilitee par l’utilisation d’un moteur
physique, mais la mise en œuvre d’un tel outil depasse les limites de notre cadre de travail.
2.2.3.3 Contraintes de distance
Les contraintes de distance sont parametrees par une variable d. Nous utilisons trois contraintes
de ce type :
– distance egale a d,
– distance inferieure a d,
– distance superieure a d.
Nous disposons actuellement de 2 manieres de traiter ces contraintes. La premiere est basee
sur les operations de Minkowski sur les polygones convexes, la seconde sur le calcul de distance
polygone-polygone (calcul sommets-aretes).
En effet, pour placer un objet a moins d’une distance d d’un autre objet, nous reduisons le
domaine de placement a la somme de Minkowski des enveloppes convexes des deux objets et
d’un cercle de rayon d2 alors que pour placer un objet exactement a la distance d d’un autre
objet, nous reduisons le domaine de placement au contour de cette somme. Enfin, pour placer
un objet a plus d’une certaine distance d d’un autre objet, nous ne restreignons pas le domaine
de placement et evaluons a posteriori la distance entre les objets.
2.2.3.4 Contrainte d’orientation
Comme precise en Annexe D.2.1, il existe deux types d’orientations possibles pour les objets :
deictique et intrinseque.
Deictique : element de linguistique qui sert a montrer, a designer, un objet singulier determine
dans la situation.
103
Chapitre 2. Placement automatique d’objets
A est l’objet site et B est l’objet cible.
Soit ~vB , le vecteur de direction de B.
Soit ~vAB , le vecteur allant du point de reference de A au point de reference de B.
Les contraintes suivantes entre A et B peuvent etre evaluee grace au produit scalaire :
B est en face de A si et seulement si ~vA · ~vAB = 1.
B est oriente vers A si et seulement si ~vB · ~vAB < 0.
B est dans la meme direction que A si et seulement si ~vB · ~vA = 0.
B est plutot oriente dans la direction oppose a A si et seulement si ~vB · ~vAB > 0.
B est oriente dos a A si et seulement si ~vA · ~vAB = −1.Figure 2.7. Contraintes d’orientation
Intrinseque : la gauche intrinseque d’un objet est fixe (ou inexistante dans le cas d’un objet
sans direction privilegiee, ex : une boule), alors que sa gauche deictique depend de la
position d’un referent.
Dans un modeleur, ou l’utilisateur peut placer et orienter le point de vue comme bon lui semble
(voire en inversant la direction verticale), il a ete choisi de ne gerer que les orientations in-
trinseques. Ce choix resulte d’un souci de simplification au niveau de la gestion des interactions
entre l’utilisateur et le modeleur.
Ce choix fait, il est encore possible de trier les objets selon la possibilite d’appliquer ou non ces
orientations. Par exemple, parler de la gauche intrinseque d’une table rectangulaire n’a pas de
sens.
Les contraintes d’orientation necessitent qu’au moins l’un des deux objets cible et site dispose
d’une orientation intrinseque. Elles sont au nombre de cinq, et sont detaillees dans la Figure
2.7 :
– En face de : les objets sont exactement face-a-face, ils ont tous les deux une orientation
intrinseque,
– Oriente vers : l’objet B (qui a une orientation intrinseque) est tourne vers l’objet A (qui n’a
pas forcement une orientation intrinseque),
104
– Parallele : les deux objets partagent la meme orientation, ils ont tous les deux une orientation
intrinseque,
– Oriente oppose a : l’objet B (qui a une orientation intrinseque) est tourne dans la direction
opposee a l’objet A (qui n’a pas forcement une orientation intrinseque),
– Dos a : les objets sont exactement dos a dos, ils ont tous les deux une orientation intrinseque.
Comme montre dans la Figure 2.7 nous evaluons ces contraintes par un calcul de produit scalaire.
2.3 Limitations actuelles
2.3.1 Limitation a la convexite
Notre modeleur se limite au placement d’enveloppes convexes d’objets. Bien que constituant
une avancee par rapport au placement de boıtes englobantes par la prise en compte la forme des
objets, ce placement reste encore imprecis. D’autres approches, a base de hierarchie de boıtes
englobantes orientees par exemple, permettent une gestion plus fine de la geometrie des objets.
2.3.2 Du placement aleatoire dans un polygone
Dans la version actuelle de notre outil, quand un objet est ajoute dans le monde sans contrainte
particuliere, sa position et son orientation sont determinees de facon aleatoire sans prendre en
compte les autres objets du monde. Dans une seconde phase, en cas de chevauchement, ce tirage
aleatoire est relance jusqu’a ce que l’objet ne soit plus en collision avec les objets ou les frontieres
du monde. Cette methode permet de proposer des scenes variees, et son avantage evident est la
facilite de sa mise en œuvre : un simple tirage aleatoire en x et en y dans le rectangle englobant
le monde.
Cependant cette methode se revele plutot inefficace dans un cas fortement contraint, comme
par exemple lorsque de nombreux objets sont deja places dans le monde (cf Figure 2.8). Une
amelioration de cette methode pourrait etre de retrancher a l’espace de placement du point de
reference de l’objet l’union des sommes de Minkowski de l’enveloppe convexe de l’objet a placer
avec celles des objets deja places. Dans ce cas, il parait difficile de conserver la caracteristique
d’interactivite.
105
Chapitre 2. Placement automatique d’objets
Dans la scene de droite, il n’y a qu’une seule position possible pour ajouter une nouvelle table (a proximite du
centre du mur de gauche). Si le domaine initial de placement ne prend pas en compte les objets deja presents
dans la scene, cette solution ne sera probablement pas trouvee.Figure 2.8. Problemes faciles et difficiles.
2.3.2.1 Prise en compte de la forme du monde
Une des methodes envisagees pour prendre en compte la forme du monde est de discretiser cette
forme en l’echantillonnant par une grille. Le tirage aleatoire du placement est ensuite realise
parmi les points de la grille. Cette technique presente l’avantage de pouvoir etre adaptee aux
performances de la machine sur laquelle est utilisee l’application en faisant varier dynamiquement
le pas d’echantillonnage.
Dans une optique d’integration des methodes issues de la recherche locale, les points de la grille
peuvent etre utilises pour amorcer le processus de recherche, sequentiellement pour une methode
classique, simultanement pour une methode hybride.
2.3.2.2 Prise en compte des objets du monde
Pour prendre en compte les objets du monde, l’utilisation d’une grille permet de balayer l’espace
de recherche en classant les candidats selon leur qualite. Pour mesurer cette qualite, il est
necessaire d’introduire les notions de distance minimale dMin et de distance maximale dMax
(cf. figure 2.9).
Si on considere p le point de reference d’un objet, sm le point de son enveloppe le plus proche
de p et sM le point de son enveloppe le plus eloigne de p, nous pouvons alors definir :
– dMin comme la distance minimale par rapport a p en deca de laquelle un point est obligatoi-
rement a l’interieur de l’objet,
106
Figure 2.9. Distances minimale et maximale entre le point de reference et l’enveloppe dans
le cas d’un rectangle
– dMax comme la distance maximale par rapport a p au-dela de laquelle un point ne peut pas
etre a l’interieur de l’objet.
Ces distances introduites, il est possible de caracteriser les points de la grille : pour les objets
les plus proches d’un point de la grille, on calcule la distance d de leur point de reference avec
le point courant de la grille. Notons Osite l’objet a placer et Oi les objets les plus proches.
– si d < OsitedMin+Oi
dMin, alors les deux objets s’intersecteront quelles que soient leurs orientations
respectives,
– si OsitedMin + Oi
dMin ≤ d ≤ OsitedMax + Oi
dMax, alors en fonction de leurs orientations respectives,
les deux objets peuvent etre disjoints,
– si d > OsitedMax+Oi
dMax, alors les deux objets sont disjoints, quelles que soient leurs orientations
respectives.
2.3.3 Ni 2D, ni 3D : 2D et demi
L’utilisation des operateurs de Minkowski permet a notre outil de generer des scenes plus
realistes31 que les approches precedentes. Le gain de realisme n’est qu’un des avantages que
peuvent apporter les operateurs de Minkowski a la modelisation declarative. Les contraintes de
temps ne nous ont cependant pas permis une mise en œuvre approfondie de toutes les fonction-
nalites envisagees (recours a la planification de mouvement pour guider les deplacements d’un31Essentiellement au sens ou les objets sont places par rapport a leur forme et non plus par leurs boıtes
englobantes.
107
Chapitre 2. Placement automatique d’objets
objet a placer, aide interactive au positionnement en affichant les zones autorisees ou interdites,
etc.).
Depuis le debut du developpement par notre equipe du projet DEM2ONS, les solveurs de
contraintes utilises, et donc le modeleur en lui-meme, ont ete restreints au placement de rec-
tangles englobants (le plus souvent isothetiques). Cette restriction fait que DEM2ONS realise
essentiellement un placement en deux dimensions (les objets peuvent toutefois etre places les
uns sur les autres). Cette methode est egalement utilisee dans DEMONS LE, a ceci pres que
l’utilisation des operateurs de Minkowski permet de definir plus precisement les surfaces de pla-
cement. Par consequent, DEMONS LE peut utiliser des polygones convexes d’une orientation
quelconque a la place des rectangles englobants isothetiques precedemment utilises.
2.4 Resultats
Actuellement, il n’existe pas de tests standardises pour comparer des approches de placements
d’objet 3D. Cependant, les atouts de DEMONS LE sont sa facilite d’utilisation et sa rapidite.
Nous presentons quelques scenes 3D generees par DEMONS LE sur notre plateforme de test,
constituee d’un processeur a 733MHz.
La premiere de ces scenes, presentee dans la Figure 2.10, contient 120 objets et a ete generee
en 3 minutes. Une grande partie de ce temps a ete utilisee a placer certains objets (ceux par
rapport auxquels les autres objets sont places). Ces objets ont ensuite servis comme objet site
pour le placement d’un ensemble d’objets identique.
Figure 2.10. Premiere scene resultat
108
La seconde scene contient 431 objets et est presentee dans la Figure 2.11. Le placement de ces
objets est defini par 50065 contraintes et a demande 4 minutes de modelisation. Dans ce case,
les temps d’interaction sont minimes car un grand nombre d’objets identiques sont places avec
les memes contraintes.
Figure 2.11. Seconde scene resultat
La Figure 2.12 presente l’interface de DEMONS LE. La partie superieure de l’interface comprend
la barre de menu (a gauche) ainsi que la liste des objets 3D presents dans la bibliotheque d’objets.
La partie centrale contient la fenetre de visualisation 3D de la scene. Enfin, la partie gauche
presente la liste des objets places dans la scene (les objets qui n’ont pas pu etre places sont
dans le second onglet) ainsi que le temps maximum de calcul alloue par objet et un indicateur
d’avancement pour l’operation de placement en cours.
2.5 Conclusion
L’etude qui a porte sur les metaheuristiques a permis d’identifier une dizaine de methodes ou de
principes differents, susceptibles d’etre utilises en modelisation declarative. Concernant la mise
en œuvre au sein de DEMONS LE, nous nous sommes focalises sur l’integration de la recherche
tabou.
Idealement, chaque metaheuristique devrait faire l’objet d’une mise en œuvre complete au sein
d’un meme outil afin de disposer d’une plateforme de test permettant de quantifier l’adequation
d’une methode a un probleme.
109
Chapitre 2. Placement automatique d’objets
Figure 2.12. Interface de DEMONS LE
110
DEMONS LE est le premier modeleur declaratif developpe dans notre equipe a offrir a un utili-
sateur, non expert en la modelisation 3D, la possibilite de generer facilement et intuitivement des
scenes complexes. Cet outil a ete pense pour etre facile a apprehender et a utiliser. L’utilisateur
peut choisir le temps maximum de calcul pour chaque operation de placement, ce qui permet
de s’adapter a la puissance de calcul disponible ainsi qu’aux desirs de l’utilisateur en terme de
temps d’attente. Les methodes stochastiques utilisees au sein de DEMONS LE permettent de
generer des scenes plus realistes que les approches precedentes basees sur les CSP.
Dans le chapitre suivant, nous presentons l’outil que nous avons developpe pour traiter l’etape
de la generation automatique d’exterieurs de batiments.
111
Chapitre 3
Generation de facades
Figure 3.1. De haut en bas : donnees d’entree (embase de batiment), premiere etape de
derivation, preparation des extrusions et batiment final.
Ce chapitre a pour objectif de presenter la technique que nous avons developpee pour la generation
automatique des exterieurs de batiments. Notre methode est basee sur la definition de gabarits
de batiments qui sont appliques a des descriptions de batiments. Une description est constituee
de l’embase tridimensionnelle, de la hauteur de toit et de la hauteur des murs du batiment.
113
Chapitre 3. Generation de facades
Ces informations sont stockees au sein d’un Systeme d’Information Geographique (SIG). La
repetition de textures est la methode la plus souvent utilisee par les infographistes pour creer
des facades batiments. La texture est repetee de facon a couvrir la facade, mais les dimensions
de la facade ne sont pas forcement des multiples de celles de la texture, certains elements de la
texture peuvent etre coupes aux bordures de la facade. Nous avons remarque que le manque de
flexibilite de cette methode limite le degre de realisme des resultats generes. C’est en partant de
ce constat que nous avons souhaite developper une nouvelle technique de generation de batiments
aussi facile a utiliser que la repetition de texture, mais permettant d’atteindre un plus haut ni-
veau de realisme ainsi qu’une plus grande diversite dans les batiments produits. Nos facades
de batiments sont composees en utilisant une grammaire de murs tridimensionnelle isometrique
basee sur un ensemble de regles. Ces regles peuvent etre simples ou egalement tres detaillees
en fonction des besoins de l’utilisateur. Dans ce chapitre, nous decrirons essentiellement notre
methode de generation de facades.
Ce chapitre est organise de la facon suivante. Apres une breve introduction et une presentation
des travaux connexes, nous exposerons tout d’abord la grammaire de murs utilisee pour generer
nos facades dans la section 3.2. Nous detaillerons ensuite nos gabarits de toits et de fondations
dans la section 3.3, avant de presenter nos resultats dans la section 3.4 que nous commenterons
ensuite dans la section 3.5. Enfin nous conclurons ce chapitre par la section 3.6 dans laquelle
nous detaillerons nos conclusions ainsi que les perspectives de ces recherches.
3.1 Introduction
Dans ce chapitre, nous analysons l’etape qui traite de la generation des exterieurs de batiments
et nous proposons une methode pour traiter cette etape par le biais de gabarits de batiments. Ce
mecanisme est constitue de trois differents ensembles de gabarits (de toits, de fondations et de
facades). La generation des fondations cree des polygones connectant l’embase tridimensionnelle
du batiment avec ses facades alors que la generation des toits fait appel a l’algorithme du squelette
droit [FO98, EE98] afin de creer differents types de toits. Enfin la generation des facades utilise
une grammaire de murs qui est une grammaire de formes tridimensionnelles isometriques. Les
deux premieres etapes etant une application de methodes existantes (que nous avons enrichies
pour nos besoins specifiques), nos recherches ont principalement porte sur la generation des
facades et la grammaire de murs associee.
114
L’objectif des travaux decrits dans ce chapitre est dans un premier temps de concevoir un systeme
qui importe des embases de batiments definies par un polygone tridimensionnel, une hauteur par
rapport au sol (pour les murs) et une hauteur de toit. Ce systeme utilise ensuite ces donnees pour
generer un modele tridimensionnel de batiments, tout en satisfaisant aux besoins enonces par
l’utilisateur. Un cas d’utilisation typique debute avec la definition d’un modele tridimensionnel
de terrain au sein d’un Systeme d’Information Geographique (SIG). La seconde phase consiste
en la creation des contours de batiments et des hauteurs ; cette etape pouvant etre automatique,
semi-automatique (seules les hauteurs sont obtenues automatiquement) ou manuelle au sein du
SIG (c’est le cas de l’exemple present dans la figure 3.23). Il faut ensuite assigner les gabarits de
batiments aux contours ; ceci peut-etre fait manuellement, de facon aleatoire ou en se basant sur
des informations socio-statistiques disponibles par le biais du SIG pour une zone donnee. Une
fois la preparation des donnees accomplie, notre systeme genere la geometrie des batiments en
tenant compte des informations prealablement mises a disposition.
Les travaux presentes dans ce chapitre s’inspirent initialement de ceux proposes par Wonka
dans [WWSR03]. Dans cet article, Peter Wonka decrit un systeme capable de generer dans leurs
moindres details des facades de batiments. Ce systeme permet de prendre facilement en compte
les repetitions et alignements horizontaux et verticaux que l’on retrouve dans presque toutes
les constructions humaines. Le mecanisme de split grammar, qui a ete developpe pour atteindre
ces objectifs, cree des resultats impressionnants, mais l’obligation de decrire chaque decoration
de facade par ses proprietes geometriques rend son utilisation peu intuitive et son apprentis-
sage delicat. Ces inconvenients sont principalement dus a la genericite de cette approche qui
ne beneficie pas de l’utilisation des proprietes et informations presentes au sein des facades de
batiments. C’est pour ces raisons que nous avons souhaite creer un systeme specifique, base sur
des grammaires de murs, qui soit capable de reproduire les resultats presentes dans [WWSR03].
Afin de simplifier son utilisation et de tirer parti des specificites des constructions, notre gram-
maire a ete uniquement specifiee pour des facades de batiments. Un autre objectif de nos travaux
a ete de faciliter le recours aux schemas de repetition sur toutes les parties de nos facades ainsi
que l’utilisation de modeles tridimensionnels precedemment generes (comme des balcons ou cor-
niches).
115
Chapitre 3. Generation de facades
Figure 3.2. Details du batiment decrit dans la Figure 3.1.
Figure 3.3. Diagramme de classes de notre systeme de generation de facades
116
3.2 Gabarits de Facades
Gabarit : Un gabarit est la description abstraite d’un objet. Cette description contient les pa-
rametres necessaires a l’instanciation geometrique de cet objet sur une courbe, un contour
ou une forme tri-dimensionnelle. Il existe des gabarits de routes, forets et a present de
batiments.
Cette section constitue la contribution majeure de notre travail de recherche sur l’etape de
generation des exterieurs de batiments. Un gabarit de facades contient une liste de mots-clefs,
un mur primaire et potentiellement un materiau par defaut. Un gabarit de facades peut etre
choisi pour une facade donnee si et seulement si il est compatible geometriquement avec cette
facade (i.e. ses hauteurs et largeurs maximales et minimales sont compatibles avec celles de
la facade). Parmi les gabarits qui correspondent a la facade en cours de traitement, le choix
depend des mots-clefs stockes dans les donnees de l’embase du batiment et au sein du gabarit.
Par exemple, l’utilisateur peut definir le mot-clef aveugle pour une facade sans ouverture, ou
bien le mot-clef porte d’entree pour la partie frontale de l’embase d’un batiment. Dans ces cas
de figure, les gabarits de facades contenant les mot-clefs correspondants seront appliques de
facon preferentielle. Les murs du gabarit de facades pour lesquels aucun materiau de fond n’a
ete defini font appel au materiau par defaut. Ce mecanisme est utilise de facon a assurer la
coherence graphique du batiment.
3.2.1 Grammaire de murs
Nous avons choisi une representation a base de grammaire formelle pour decrire nos facades de
batiments. En prenant en compte les resultats impressionnants trouves dans [WWSR03], nous
avons voulu proposer un systeme aussi efficace, mais plus simple a apprehender et a utiliser.
Nous avons decide de travailler sur une grammaire de murs qui peut etre definie comme une
split grammar qui utiliserait des murs comme constituants (plutot que des formes geometriques).
Nous avons atteint un ensemble minimum de cinq regles : une regle terminale (voir 3.2.1.2),
deux regles de positionnement (voir 3.2.1.3 et 3.2.1.4) et deux regles de repetition (voir 3.2.1.6
et 3.2.1.5). Ce choix nous permet de gerer aisement les instanciations et repetitions de n’importe
quel mur donne.
Grammaire formelle : une grammaire formelle est composee d’un ensemble fini de symboles
terminaux (les lettres du langage formel), d’un ensemble fini de symboles non-terminaux,
117
Chapitre 3. Generation de facades
d’un symbole initial et d’un ensemble fini de regles de production avec une partie gauche
formee d’une lettre du langage et une partie droite composee d’un mot du langage (forme
de symboles terminaux et non terminaux).
A −→ B
Chaque regle (mur) est a meme de determiner la place dont elle a besoin (i.e. dimensions
minimales et maximales dans les directions horizontales et verticales) par un simple calcul
recursif sur elle-meme et ses regles filles. Parmi les regles geometriquement possibles (gaba-
rit de facades), une regle est selectionnee pour la facade courante, ce choix etant guide par les
mot-clefs eventuellement presents au sein du gabarit et de la description du batiment.
3.2.1.1 Mur abstrait (W )
La classe abstraite Wall stocke les informations qui sont partagees par les differentes regles (cf.
Figure 3.3 pour le diagramme de classe associe). Elle contient le materiau de fond ainsi que
les dimensions finales du mur (horizontale et verticale). Les dimensions minimales et maximales
sont calculees en fonction des dimensions des elements internes du mur. De plus, l’utilisateur
peut definir des dimensions preferentielles qui seront automatiquement employees si elles sont
geometriquement valides.
Dans les descriptions suivantes, W peut representer n’importe quelle instance d’une classe fille
d’un mur abstrait.
3.2.1.2 Pan de mur (WP )
Le pan de mur (ou Wall Panel) est l’element le plus simple de notre systeme et, actuellement,
notre unique symbole terminal. En plus des informations stockees dans le mur abstrait, un pan de
mur peut referencer un objet tridimensionnel ou un materiau de decoration comme par exemple,
une texture de fenetre. Dans le premier cas, l’objet tridimensionnel sera instancie au centre de
la surface du pan de mur. Quand un tel objet est instancie, l’utilisateur peut decider de creer
les faces du polygone du pan de mur.
Grace a ces choix, un certain nombre de cas problematiques peut etre gere. Ce mecanisme est
utile par exemple dans le cas d’emploi d’objets modelisant des halls d’entree : si les faces du
118
pan de mur etaient generees, elles masqueraient l’objet instancie a l’interieur du batiment (cf.
Figure 3.4).
Figure 3.4. Un exemple de suppression des faces de fond d’un pan de mur
3.2.1.3 Mur a bordures (BW )
Un mur a bordures (Bordered Wall) est un mur avec quatre marges (gauche, droite, haut et
bas) et un element central qui reference un mur (cf. Figure 3.5-gauche). Chaque marge possede
une taille et une politique de redimensionnement qui peut etre minimum, maximum ou fixe. La
valeur par defaut d’une marge est minimum, ce qui signifie que la bordure associee ne peut pas
etre plus petite que la valeur de sa taille.
BW −→ W
3.2.1.4 Mur extrude (EW )
Un mur extrude (Extruded Wall) est un mur qui extrude selon une certaine profondeur le mur
qu’il reference (cf. Figure 3.5-droite et 3.7). Cette profondeur peut etre positive (resp. negative) :
le mur fils et les faces de profondeurs seront places devant le plan de la facade (resp. derriere).
La Figure 3.6 illustre l’utilisation de la profondeur. Quatre booleens sont utilises pour definir si
les faces de profondeur doivent etre generees. De plus, un mur extrude peut referencer un objet
tridimensionnel qui sera instancie a sa surface (i.e. avec une profondeur nulle). Cet objet est
utilise a des fins decoratives comme la rambarde de la Figure 3.5.
EW −→ W
119
Chapitre 3. Generation de facades
Figure 3.5. Exemple de mur a bordures.
120
Figure 3.6. Mur extrude avec une profondeur negative.
Figure 3.7. Un exemple de mur extrude referencant un objet tridimensionnel (les piliers
au premier plan).
3.2.1.5 Grille de mur (WG)
Une grille de mur contient un unique mur qui sera repete dans une ou deux directions (verti-
calement et/ou horizontalement). Pour chacune de ces directions, le nombre de repetitions est
controle par les cardinalites maximales et minimales (h fois dans la direction horizontale et v
fois dans la direction verticale).
121
Chapitre 3. Generation de facades
WG −→ W (1−h)(1−v)
Figure 3.8. Un exemple de grille de mur horizontale.
Figure 3.9. Un exemple de grille de mur bidirectionelle.
3.2.1.6 Liste de murs (WL)
Une liste de murs (Wall List) contient plusieurs murs ainsi qu’une orientation qui peut etre ho-
rizontale ou verticale. Les murs contenus dans la liste de murs seront instancies de la gauche vers
la droite (pour une orientation horizontale) ou de bas en haut (pour une orientation verticale)
afin de couvrir la zone de facade affectee a la liste de murs. La repartition de l’espace dedie
a la liste de murs entre ses differents composants prend en compte les dimensions maximales,
minimales et preferentielles de chacun des composants. l’algorithme choisi est decrit dans le
paragraphe 3.2.2.
WL −→ W1W2...Wn
3.2.2 Mise en œuvre
Le diagramme de classes de la Figure 3.3 presente la hierarchie de classes de notre systeme de
regles. Les fonctions les plus complexes sont celles qui calculent la taille des murs derives d’un
122
Figure 3.10. Un exemple de liste de mur.
mur donne. Cette fonction de redimensionnement est definie de facon virtuelle au sein de la
classe qui gere les murs abstraits, puis redefinie pour chacune des classes filles. L’Algorithme
3.11 detaille la mise en œuvre de cette fonction pour la regle liste de murs.
Dans cet algorithme, R est la regle liste de murs, F est la zone de facade au sein de laquelle
on essaye d’instancier la liste de murs et les W sont les murs contenus dans cette liste de
murs. Les valeurs WHmin, WHmax et WHpref representent les dimensions minimales, maximales
et preferees de chacun des murs fils. Ces trois dimensions ont ete calculees prealablement par
chacun de ces murs. Le redimensionnement s’effectue de facon a selectionner pour chacun des
murs une dimension aussi proche que possible de la dimension preferentielle.
3.3 Gabarits de toits et de fondations
3.3.1 Gabarits de fondations
La generation des fondations est necessaire a la coherence visuelle des resultats atteints. Les
fondations sont utilisees pour ajuster chaque batiment avec le sol sur lequel il est construit. Une
embase de batiment peut etre un polygone non plan mais le sol d’un batiment est suppose plat
123
Chapitre 3. Generation de facades
//Test de la validite horizontale
for each W ∈ R
if (WHmin > FH and WHmax < FH) then return FALSE
end for
//Test de la validite verticale
if (ΣWV min > FV and ΣWV max < FV ) then return FALSE
//Nous essayons d’utiliser les Vpref
if (ΣWV min ≤ FV − ΣWV pref and ΣWV max ≥ FV − ΣWV pref) then
//Si W possede un V pref , nous l’utilisons
WV = WV pref
//Si W ne possede pas de V pref ,
nous utilisons un ratio pour partager l’espace restant
p = (FV − ΣWV pref )/ΣWV min
WV = p× ΣWV min
end if
//Pour les cas non resolus precedemment,
nous favorisons les V pref
while ∃W uninstantied
if (ΣWV min > FV − ΣWV pref or ΣWV max < FV − ΣWV pref)
then WV = WV min × FV /ΣWV min
end if
else
if ∃WV pref then WV = WV pref
else WV = WV min × FV /ΣWV min
end else
end while
Figure 3.11. Regle de redimensionnement pour une liste de murs verticales.
124
et horizontal. Un gabarit de fondations contient un type de fondation, ainsi que un materiau de
fondation.
Les differents types de fondations actuellement disponibles sont :
Z min les murs du batiment sont generes a l’altitude minimale des sommets de l’embase, il n’y
a pas de faces generees pour les fondations, mais une partie des murs peut etre enterree
(certaines ouvertures peuvent etre sous terre). Ce type de gabarit de fondations est prin-
cipalement utilise lorsque les variations d’altitude sont localement faibles, ou lorsque le
gabarit a ete concu pour gerer ces variations (cas d’un chalet ou d’une maison sur pilotis).
Z max les murs du batiments sont generes a l’altitude maximale des sommets de l’embase, il n’y
a pas de faces generees pour les fondations. Dans ce cas, certains murs du batiment flottent
dans le vide au-dessus du sol. Ce type de fondation est interessant lorsque l’utilisateur
souhaite traiter lui-meme les fondations (i.e. les retoucher de facon manuelle).
Extrude les murs du batiment sont generes a l’altitude maximale des sommets de l’embase
et des faces de fondations sont crees afin d’assurer la liaison entre les murs et le sol.
Pour chaque segment de l’embase du batiment, des faces verticales sont generees entre ce
segment et l’embase originale en dessous.
Figure 3.12. Les trois differents types de gabarits de fondations. De gauche a droite, z min,
z max et extrude.
La figure 3.12 montre ces differents types de fondations. Il est a noter que seul le type extrude
genere des fondations. Dans ce cas, les fondations sont representees par un polyedre dont la
partie superieure est constituee d’un seul polygone plan horizontal (le sol du batiment) qui est
raccorde uniquement a des polygones verticaux qui rejoignent la surface du terrain. La partie
inferieure du polyedre representant les fondations est donc constituee de l’intersection entre le
125
Chapitre 3. Generation de facades
contour du batiment et la surface du terrain. Le polygone tridimensionnel resultant n’est donc
pas plan au contraire de celui constituant la partie superieure des fondations.
Le materiau de fondation est utilise uniquement dans le cas de fondations extrudees. Si ce
materiau n’est pas defini dans le gabarit de fondations, ces faces utiliseront le materiau par
defaut du gabarit de batiments, ceci permettant d’assurer la coherence graphique du batiment.
3.3.2 Gabarits de toits
L’un des objectifs de nos travaux est d’essayer ne pas limiter la creativite de l’utilisateur.
L’objectif sous-jacent est de lui permettre de se consacrer librement a sa modelisation, sans
qu’il ait a prendre en compte les limitations du systeme. Cet objectif se concretise par la vo-
lonte d’accepter le plus grand nombre d’embases de batiment comme postulat de depart. Dans
la realite, les batiments peuvent avoir des contours concaves, convexes et peuvent egalement
presenter des cours interieures (cas du polygone a trou). Nous avons donc souhaite etre a meme
de traiter tous ces cas. La seule restriction actuelle consiste en l’interdiction des polygones auto-
intersectants (en forme de huit par exemple), ce genre de polygones etant impossible a utiliser
pour decrire un batiment. Cette reflexion nous a mene a l’utilisation de la methode du squelette
droit [FO98, EE98] sur les polygones qui decrivent nos embase de batiments.
Squelette droit Le squelette droit d’un polygone simple est defini comme le retrecissement du
polygone, obtenu en translatant chacun de ses segments a une vitesse constante. Le sque-
lette droit est le resultat de l’union des segments parcourus pas les sommets du polygone
a chaque etape de retrecissement.
Le squelette droit est assez proche de l’axe median (comme le montre la Figure 3.13), les deux
techniques fournissent meme un resultat identique dans le cas de polygones convexes. Neanmoins,
le squelette droit d’un polygone non convexe contient moins de bords que l’axe median et tous
ses bords sont des segments de droite alors que l’axe median presente des bords paraboliques.
Cet algorithme etant valide sur les types de polygones que nous utilisons, nous sommes en
mesure de proposer differents types de toits qui seront toujours applicables a nos descriptions
de batiments.
Les types de toits disponibles peuvent etre classes en 4 categories distinctes : les toits plats, les
toits a une pente, les toits a deux pentes et les toits a quatre pentes. Les deux premieres categories
ne contiennent actuellement qu’un type de toit. Les toits plats peuvent avoir un rebord, dont la
126
Figure 3.13. Axe median (au centre) et squelette droit (a droite) d’un polygone simple
hauteur est donnee par la hauteur du toit. Les toits a une pente sont obtenus en placant le plus
grand segment du contour du batiment a la hauteur du toit et le segment du contour qui en est
le plus eloigne a la hauteur des murs. Comme nos embases de batiments ne sont pas restreintes a
des quadrilateres, la principale difference entre les toits a deux pentes et les toits a quatre pentes
est la presence de pignon au sein des toits generes : en effet, seuls les toits a deux pentes en
contiennent. Nous allons a present detailler nos gabarits de toits a deux et quatre pentes. Les
developpements effectues pour ces gabarits s’inspirent initialement des propositions sur les toits
a deux pentes que l’on peut trouver dans les travaux de Laycock [LD03]. Afin de clarifier les
distinctions entre les gabarits, nous introduisons la notion de pan de toit. En partant du sommet
du toit, un pan de toit est une surface plane d’une inclinaison donnee. Chaque changement
d’inclinaison definit un nouveau pan de toit.
Nous allons commencer par decrire les differents types de gabarits de toits a deux pentes dont
un exemple est present dans la Figure 3.17 :
Deux pentes standard : ce type de gabarit de toits cree des faces verticales de pignon pour
les plus petits cotes de l’embase du batiment. Ces faces sont texturees avec le materiau par
defaut du gabarit de batiments afin d’assurer un aspect coherent au batiment. Elles sont
creees en deplacant des points du squelette droit vers une arete de l’embase du batiment
(en prolongeant la direction du segment du squelette). Les faces de toit regulieres (celles
qui ne sont pas des pignons) sont creees d’un seul tenant, avec un seul pan de toit. Ce type
de gabarit de toits est presente par une vue de profil dans la Figure 3.14.
Mansarde : ce type de gabarit cree des toits a deux pentes dont les faces regulieres sont
composees de deux pans. Le pan inferieur presente une pente plus forte que le pan superieur.
Ce type de gabarit de toits est presente par une vue de profil dans la Figure 3.15.
127
Chapitre 3. Generation de facades
Grange : ce type de gabarit cree des toits a deux pentes dont les faces regulieres sont composees
de trois pans. Il peut etre decrit comme l’ajout d’un pan de toit quasi horizontal sous un
toit mansarde. Ce type de gabarit de toits est presente par une vue de profil dans la Figure
3.16.
Figure 3.14. Vue de profil d’un toit a deux pentes standard.
Figure 3.15. Vue de profil d’un toit a deux pentes mansarde.
Figure 3.16. Vue de profil d’un toit a deux pentes de type grange.
A present, nous allons detailler les types de gabarits de toits a quatre pentes que l’on peut
trouver dans la Figure 3.20 :
Quatre pentes standard : ce type de gabarit de toits cree uniquement des faces regulieres,
avec une inclinaison constante (i.e. un seul pan par face).
Mansarde : ce type de gabarit de toits peut etre considere comme une extension du type de
gabarit de toits a deux pentes mansarde. Chaque face est composee de deux pans, le pan
inferieur presentant une pente plus forte que le pan superieur.
Pagode : ce type de gabarit de toits peut etre considere comme une extension du type de
gabarit de toits a deux pentes grange. Il peut etre decrit comme l’ajout d’un pan de toit
quasi horizontal sous un toit mansarde.
128
Figure 3.17. Exemples de toits generes par differents gabarits de toits a deux pentes. De
gauche a droite : deux pentes standard, mansarde, grange.
129
Chapitre 3. Generation de facades
Porche : chaque face de ce type de gabarit de toits contient deux pans, le pan superieur
presentant une pente plus forte que le pan inferieur. Ce type de gabarit de toits est presente
par une vue de profil dans la Figure 3.18.
Alsacien : les toits crees par ce type de gabarit sont des toits hybrides composes de deux
parties. La partie superieure est constituee d’un toit quatre pentes standard pose sur un
toit deux pentes standard (donc avec pignons). Ce type de gabarit de toits est presente
par une vue de profil dans la Figure 3.19.
Figure 3.18. Vue de profil d’un toit a quatre pentes de type porche.
Figure 3.19. Vue de profil d’un toit a quatre pentes de type alsacien.
Un gabarit de toits est defini par la donnee d’un type de toit, d’un type de debord de toit, de
support et par des materiaux (pour les faces de toit, pignon, debord et support). Le support
consiste en des faces verticales construites en prolongement des murs du batiment. Les debords
et supports peuvent etre utilises pour chacun de nos types de toits. Lorsque l’utilisateur souhaite
creer des toits plus larges que l’embase du batiment, il fait appel aux debords de toit. Il peut
ensuite decider si ces debords seront ouverts, fermes ou avec support.
La prochaine evolution de nos gabarits de toits visera a proposer a l’utilisateur la possibilite de
creer des toits plus detailles contenant des references externes a des objets : fenetres, cheminees,
etc.
130
Figure 3.20. Exemples de toits pour divers gabarits de toits a quatre pentes. De gauche a
droite : quatre pentes standard, mansarde, pagode, porche, alsacien.
3.4 Resultats
3.4.1 Format de fichier et mode operatoire
Notre systeme a ete mis en œuvre en C++, tandis que nos gabarits de batiments sont decrits
et stockes grace a une structure XML. Ce projet a ete developpe dans le but de creer une
geometrie abstraite afin de pas dependre directement d’un logiciel ou d’une librairie particuliere.
Actuellement, deux mises en œuvre sont disponibles.
La premiere est l’integration au sein du modeleur de terrain multisenseur AGETIM v2 de la
societe Oktal SE. Ce modeleur de terrain est base sur un Systeme d’Information Geographique
(actuellement Geoconcept [Geo]). Cette integration nous permet d’importer divers types de
donnees d’entree comme les formats VMap, DTED, DFAD SEDRIS ou DXF. Cette mise en
œuvre a pour objectif la generation de larges zones (actuellement jusqu’a plusieurs centaines de
milliers de kilometres carres).
La seconde mise en œuvre est une version en ligne de commande que nous avons developpe afin
de realiser facilement nos tests de validite et de performance. Cette version cree des scenes qui
peuvent etre parcourues avec un outil de visualisation base sur OpenGL Performer.
Apres avoir concu et realise notre systeme de gabarits de batiments, nous avons souhaite offrir
a l’utilisateur une interface intuitive pour lui permettre de creer ses propres gabarits. En effet,
l’edition directe de la structure XML demande des connaissances informatiques et reste assez
131
Chapitre 3. Generation de facades
En haut : un building hausmanien avec un toit alsacien (94 faces).
Au centre : un batiment vitre, avec deux references externes pour les entrees et un toit plat (350 faces).
En bas : un batiment faisant massivement appel a l’extrusion, couvert d’un toit a quatre pentes (5600 faces)
Figure 3.21. Trois batiments generes a partir de la meme embase.
132
fastidieuse. La Figure 3.22 presente l’etat actuel de notre editeur de gabarits de batiments.
Le panneau situe dans le coin superieur gauche contient le gabarit de batiments en cours de
definition. Celui situe au centre de l’editeur sur la gauche montre les murs disponibles : ils
peuvent appartenir au gabarit courant, ou avoir ete importes de gabarits precedemment generes.
Le panneau inferieur gauche contient, quant a lui, la liste des materiaux disponibles. Enfin, le
panneau situe en haut a droite presente un apercu tridimensionnel du gabarit courant.
Figure 3.22. Etat actuel de notre editeur de gabarit de batiments.
3.4.2 Performance et complexite
L’une de nos scenes de test contient 17362 batiments. Les embases de batiments ont ete ren-
seignees a partir d’un fichier de planimetrie IGN (Institut Geographique National), la donnee
geometrique ainsi que la hauteur de chaque embase ont ete renseignees manuellement par un
infographiste. Ensuite, cet utilisateur a cree ses propres gabarits de batiments et les a appliques
aux batiments definis. Un apercu de la scene finale est propose dans la Figure 3.23. La generation
des batiments a demande moins de huit minutes, pour un total de 920 182 faces generees.
Afin d’evaluer les performances de notre systeme, nous avons utilise deux configurations differentes
de gabarits de batiments sur cette meme scene. En utilisant le plus simple de nos gabarits (com-
parable a ceux presentes dans la partie superieure de la Figure 3.21), nous avons obtenu une
scene contenant 618 050 faces en 6 minutes et 51 secondes. Nous avons ensuite applique l’un
133
Chapitre 3. Generation de facades
Figure 3.23. Zone urbaine constituee de 17 362 batiments, la generation s’effectue en 7mn
55 sec pour 920 182 faces
de nos gabarits les plus complexes (comparable a ceux presentes dans la partie inferieure de la
Figure 3.21). Dans ce cas, la generation s’est effectuee en 3 heures et 27 minutes pour un total
de 25 449 776 faces.
Ces resultats ont ete obtenus sur une plate forme basee sur un AMD Ahtlon 64 cadence a 2Ghz.
Les vues presentes dans ce chapitre ont ete realisees a l’aide d’un moteur de lancer de rayon
multisenseur (Figure 3.1, 3.17, 3.20 et 3.21) et d’un outil de visualisation temps reel base sur
OpenGL Performer (Figure 3.2 et 3.23).
3.4.3 Exemple de gabarit de facades
La Figure 3.24 presente un exemple de l’application de la grammaire enoncee en 3.25. Par souci
de clarte, nous nommons chaque regle par sa partie gauche dans le paragraphe suivant.
La regle ω fait deriver le symbole initial ω en la premiere liste de murs. La regle WL↑1 definit
celle-ci comme une liste de murs verticale composee de trois elements : la regle WL→2 en charge
du rez-de-chaussee, la regle WL→3 qui gere les etages suivants et un mur extrude qui cree la
corniche en haut de la facade.
134
Figure 3.24. Exemple de batiment genere a partir du gabarit de facades decrit en 3.4.3.
La regle WL→2 entoure la porte d’entree (decrite par un mur a bordure) par deux instances d’une
grille de mur horizontale decrite par la regle WG→2 . Celle-ci contient une liste de murs verticale
faite de deux mur a bordure. Le premier contient une fenetre, tandis que le second contient une
corniche.
La regle WL→3 est une liste de murs qui contient quatre murs. Les premiers et derniers murs de
cette liste sont des instances de la meme liste de murs verticale WL↑5. Celle-ci est composee de
deux grilles de mur, l’une bidirectionnelle WG↑→5 , l’autre horizontale WG→
6 .
Le second element de la regle WL→3 est la grille de murs verticale WG↑3 qui contient un mur
extrude (pour l’escalier) compose d’une grille de mur horizontale. Le troisieme element de la
regle WL→3 est une grille de murs verticale.
3.5 Discussions
Nombre de regles. Meme s’il est theoriquement possible de creer un unique gabarit de batiments
qui contiendrait tous les gabarits de facades presents dans une ville donnee, notre systeme a
essentiellement ete concu pour decrire un seul type de batiment par gabarit. Une approche
distincte, basee sur l’utilisation d’une seconde base de regle, permet aux utilisateurs de decrire
135
Chapitre 3. Generation de facades
ω −→ WL1
WL↑1 −→ WL2 WL3 WG1
WL→2 −→ WG2 BW1 WG2
WG→2 −→ WL4
WL↑4 −→ BW2 BW3
WL→3 −→ WL5 WG3 WG4 WL5
WL↑5 −→ WG5 WG6
WG↑→5 −→ BW4
WG→6 −→ BW5
WG↑3 −→ EW3
EW3 −→ WG7
WG→7 −→ BW4
WG↑4 −→ BW5
WG→1 −→ WP1
Figure 3.25. Exemple de grammaire utilisee pour generer le batiment presente dans la
Figure 3.24.
136
Figure 3.26. Details des differents pas de derivations necessaires a la creation du batiment
presentes dans la Figure 3.25 .
137
Chapitre 3. Generation de facades
leurs batiments en utilisant uniquement des attributs de plus haut niveau (cf. [WWSR03]).
Cependant, les auteurs de cette approche lui reprochent une grande complexite d’apprentissage
et d’utilisation. C’est cette complexite du systeme base sur deux bases de regle (dont une base
de regles abstraites) qui nous fait preferer une approche plus specialisee.
Facilite d’utilisation du systeme. Plusieurs des gabarits de batiments presentes dans ce chapitre
ont ete cree par un infographiste. Une fois qu’un utilisateur a apprehende un gabarit existant,
il peut commencer a creer ses propres gabarits en modifiant les materiaux. Il peut ensuite
approfondir son apprentissage en procedant a des modifications des parametres de ce gabarit
(dimensions, cardinalites d’une grille de murs, taille et politique de redimensionnement pour un
mur a bordure, etc.). Une fois ces deux phases d’apprentissage accomplies, l’utilisateur connaıt
les cinq differentes sortes de regles ainsi que leurs parametres. A partir de la, il est capable de
creer lui-meme ses propres gabarits.
Complexite geometrique. Comme montre dans la Figure 3.21, nous sommes en mesure de
controler le nombre de faces d’un batiment. Puisque l’utilisateur peut definir la complexite
geometrique des gabarits, notre systeme peut aussi bien etre utilise pour generer des cites
realistes (i.e. precises et detaillees) que pour creer de vastes zones urbaines pour la simula-
tion aerienne. En effet, dans ce domaine, les details s’averent moins importants que la capacite
de la simulation a assurer un survol en temps reel. Le controle de la complexite geometrique
s’effectue par l’utilisation de niveaux de detail ainsi qu’en simplifiant la geometrie lors de la
generation (en fusionnant des faces coplanaires) et en definissant de maniere adequate les gaba-
rits appropries. Il est egalement possible de controler la complexite en instanciant plus souvent
les plus vastes morceaux de facade i.e. ceux contenant moins de polygones par unite de surface.
3.6 Conclusions et travaux futurs
Dans ce chapitre, nous avons presente un nouveau systeme pour generer des batiments a partir
de leurs embases. Les principaux avantages de nos travaux sont :
– Generation a partir de n’importe quelle embase de batiment, convexe ou non, meme trouee
– Creation de gabarits simples ou complexes, en fonction des besoins de l’utilisateur.
– Mise a disposition de types de toits varies, independamment de la complexite de l’embase.
– Technique deja mise en œuvre (et utilisee) au sein d’un modeleur de terrain base sur un
Systeme d’Information Geographique.
138
– Possibilite de recreer des facades de batiments existants (a partir de photographies).
Un exemple d’utilisation actuelle de notre systeme est la generation de modeles tridimensionnels
de villes pour la calibration de radar a ouverture synthetique (SAR), telles que celles decrites
dans [SMTS05]. La possibilite de faire varier la complexite geometrique de nos modeles permet
d’evaluer les performances puis de valider les resultats de ce type de simulation.
Notre approche possede de nombreux avantages par rapport aux travaux anterieurs.
Nous pouvons generer tout types de batiments, sans etre restreint a un type de batiment donne
comme le projet Lahave House [RMS96] ou le Castle Construction Kit [GBHF05, Hav05]. Cette
amelioration est rendue possible par le fait qu’il est facile de creer un nouveau gabarit de
batiments.
Notre methode etend les capacites de GenVillage [LLGC+05] en introduisant des raffinements
geometriques (derochements, balcons, etc.) et la capacite a ne pas avoir qu’une texture par
facade. Nous sommes aussi en mesure de fournir plusieurs versions de nos batiments afin d’au-
tomatiser la gestion des niveaux de detail par batiment.
Enfin, notre approche reprend les qualites d’Instant Architecture [WWSR03] concernant la qua-
lite du resultat final et la diversite des batiments generables. Notre systeme presente l’avantage
d’etre facile a utiliser et rapide a apprehender, alors que le systeme de double grammaires et
d’une base de donnees regroupant tout les batiments rend Instant Architecture delicat a mani-
puler.
139
Conclusions et perspectives
Contributions
Dans ce memoire de these, nous avons presente un etat de l’art de la modelisation de maquettes
virtuelles de zones urbaines ainsi que deux nouvelles approches pour traiter des etapes de cette
modelisation.
Dans l’etat de l’art, nous avons decompose la modelisation de zones urbaines en un ensemble
de sept etats et de six etapes de generation. Pour chacune des etapes de generation, nous
avons detaille plusieurs approches qui permettent de traiter ces etapes. Il est interessant de
noter que ces approches sont souvent issues de domaines de recherche differents, Si certains
travaux couvrent plusieurs etapes, aucun des projets actuels n’est en mesure de traiter dans son
integralite la chaıne de traitement consistant a passer de la definition vague d’une zone urbaine,
a une zone urbaine complete et credible, integrant jusqu’a l’interieur des batiments. Il nous pa-
rait necessaire d’etre en mesure de coupler au sein de chaque etape de generation des methodes
generant des maquettes geotypiques et geospecifiques. L’etape de generation du reseau routier
illustre cette necessite. En effet, un outil de modelisation capable de recreer un reseau routier
existant a partir de cartes ou de photos satellites, et d’autre part apte a constituer un nouveau
reseau routier a partir des donnees de la zone urbaine, couvrirait tous les besoins exprimables
pour cette etape.
La premiere etape de generation que nous avons approfondie est celle qui realise le place-
ment d’objets au sein des interieurs de batiments. Afin de traiter ce probleme de placement
defini par des contraintes, nous avons etudie l’interet d’un solveur de contraintes basees sur les
metaheuristiques issues de la recherche locale, et plus particulierement la recherche tabou. Pour
141
Conclusions et perspectives
realiser cette etude, nous avons developpe DEMONS LE, un modeleur declaratif qui tire partie
des specificites de notre solveur de contraintes de maniere a proposer une utilisation la plus in-
teractive possible. Les methodes stochastiques utilisees au sein de DEMONS LE ont donne lieu
a une creation de scenes plus realistes que les scenes generees grace aux approches precedentes
basees sur les CSP.
Les differents outils existants traitent cette etape, soit en inventant le placement des objets, soit
en proposant a l’utilisateur de placer les objets virtuels a la meme place que les objets reels.
L’etape de placement des meubles (et dans une moindre mesure celle de definition des cloisons
interieures) peut etre grandement acceleree si on accepte de faire des compromis sur la diversite
du monde. Par exemple, dans le cas d’un immeuble, on peut decider de ne generer que le rez-
de-chaussee (etage particulier a cause de ses ouvertures de communication avec l’exterieur) et
un seul etage. Cet etage pourra ensuite etre duplique autant de fois qu’on le souhaite dans la
direction verticale. Les ouvertures (interieures et exterieures), les cloisons et le mobilier seront
donc identiques d’un etage a l’autre.
Il est egalement possible de simplifier cette etape en regroupant de facon logique certains objets
afin de n’avoir a placer que l’objet les regroupant. Une table et ses chaises, ou encore un lit
et deux tables de nuit se pretent bien a ce genre de simplification. Par contre, cette methode
complique le placement lorsque la piece est de petite taille ou lorsque la presence de nombreuses
ouvertures reduit l’espace de placement disponible (cf. Figure 1) ; un objet ne peut pas etre
positionne devant une porte ou une fenetre.
Figure 1. Cette image montre l’espace perdu a cause des ouvertures pour le placement des
meubles
142
La seconde etape de generation que nous avons etudie est celle portant sur la generation des
exterieurs de batiments. Nous avons developpe une approche capable de generer rapidement
des batiments complexes tout en etant simple d’apprentissage et d’utilisation. Notre approche
est basee sur la notion de gabarits de batiments et nous permet de creer des batiments reels
ou imaginaires avec une complexite geometrique fixee par l’utilisateur. Au sein d’un gabarit de
batiments, nous avons regroupe des gabarits de facades, de toits et de fondation, ce qui nous
permet de proposer la creation de batiments varies et adaptes au terrain sur lequel ces batiments
seront positionnes. Nous proposons egalement un editeur de gabarits permettant de concevoir
et modifier facilement nos gabarits de batiments.
C’est la qualite des modeles tridimensionnels generes lors de cette etape qui conditionne la
qualite finale de la zone urbaine. Dans le cas de la modelisation de zones urbaines reelles, les
travaux permettant de creer automatiquement un gabarit de batiment a partir de photographies
[MZWG07] presentent un interet certain pour accelerer la creation des gabarits de batiments.
La derniere version du logiciel de mappemonde virtuel Google Earth integre la technologie Street
View qui propose des vues panoramiques (en orange dans la Figure 2) ainsi que des photographies
classiques (en bleu dans la Figure 2) au sein de l’affichage 3D du logiciel. Ces photographies
detaillees, dont le nombre croıt tres rapidement, permettent d’envisager de creer les gabarits
de batiments sans avoir a realiser une campagne photographique pour chaque nouvelle zone a
modeliser. Le couplage des methodes automatiques de generation de batiments avec ces nouvelles
sources de donnees locales semble etre une evolution logique pour cette etape de generation.
Figure 2. Exemple des donnees multimedia disponibles pour la place du Capitole a Toulouse
au sein du logiciel Google Earth
143
Conclusions et perspectives
Perspectives
Au cours de cette these, nous avons cherche a determiner quelle etait la meilleure approche pour
chacune des six etapes de generation. La reponse a cette question depend de criteres dependant
du but a atteindre. Selon que l’on cherche a reproduire une zone urbaine existante ou plutot a
creer une zone urbaine virtuelle credibles, les approches selectionnees ne sont pas les memes.
Nous presentons ici les methodes que nous trouvons les plus pertinentes pour la generation d’une
zone urbaine virtuelle. Les travaux les plus significatifs sur l’etape de generation de reseaux rou-
tiers sont bases sur les L-System [PM01], il parait donc naturel d’utiliser cette approche (cf.
Figure 3). L’etape de generation des blocs peut etre traitee de facon complete par de simples
Figure 3. Exemple de zones urbaines genere en couplant notre systeme de generation de
batiments avec le prototype de notre methode de generation de reseau routier.
calculs geometriques et ne presente pas d’interet particulier en terme de recherche. A partir
des blocs, la generation des parcelles se prete bien au recours a des methodes geometriques
avancees, basees sur les diagrammes de Voronoı, l’axe median et les squelettes droits. Les tra-
vaux presentes dans [Per06] utilisent ces methodes, mais doivent etre approfondis de facon a ne
generer que des parcelles valides (un post traitement adapte devrait suffire a regler ce probleme).
La methode que nous presentons au Chapitre 3 permet de traiter de facon efficace l’etape de
generation des exterieurs de batiments et permet de creer aisement des batiments varies. Les
methodes existantes pour l’etape de generation des cloisons interieures font appel a des solveurs
144
de contraintes bases sur l’approche CSP. Le recours a ces solveurs limite la taille maximale des
batiments auxquels on peut appliquer ces methodes a cause de la complexite exponentielle de
ce probleme, c’est pour cette raison que nous utilisons un decoupage de l’espace par dichoto-
mie pour cette etape. Meme si les resultats sont moins varies que ceux des autres approches,
nous sommes en mesure d’obtenir un resultat correct de maniere rapide (cf. Figure 4). Pour
Figure 4. Exemple de partition d’un etage de batiment en pieces par notre methode.
finir, les approches basees sur les metaheuristiques semblent les plus a meme de traiter l’etape
de placement des meubles au sein des pieces. Elles sont, en outre, facilement parallelisables, ce
qui presente un avantage certain lorsque l’on souhaite traiter toutes les pieces d’une zone urbaine.
Si nous sommes a present a meme de proposer une solution pour chacune des etapes de generation,
la mise en œuvre de toutes ces methodes au sein d’une unique application necessite cependant
des moyens depassant le cadre de cette these. La realisation de cette application implique d’etre
capable de resoudre des problemes non triviaux en terme de volumes de donnees a stocker,
analyser et utiliser. La seule specification de l’interface d’un systeme a meme de manipuler des
entites de dimensions aussi differentes qu’un reseau routier et un meuble donne un apercu de
l’etendue du travail a effectuer.
La realisation complete d’une application permettant de generer automatiquement une zone
urbaine reste donc un probleme ouvert, mais qui ne semble pas pour autant hors de portee.
145
Annexe A
Oktal Synthetic Environment
A.1 Identite
OKTAL-SE fait partie du Groupe SOGECLAIR, specialisee dans les environnements synthetiques
et la simulation multi senseurs. Creee le 2 Fevrier 2001 a Toulouse, OKTAL-SE possede un ca-
pital de 754 k¿, et un chiffre d’affaire de 2,2 M¿ en 2004.
OKTAL-SE est une petite structure reactive specialisee dans la simulation a forte valeur ajoutee
scientifique basee sur les technologies de synthese d’images appliquee au domaine de la simulation
multi senseurs et de la modelisation de l’environnement synthetique.
OKTAL-SE est un acteur engage dans le marche de la realite virtuelle et la simulation. Au sein
de cet enorme domaine technique, OKTAL-SE adresse tout particulierement le segment de niche
des logiciels de simulation multi-senseurs d’environnements synthetiques. L’offre d’OKTAL-SE
cible les domaines de l’optronique, de l’electromagnetisme et de l’acoustique et se compose d’un
ensemble d’outils logiciels associes a des prestations de services d’accompagnement (i.e. conseil,
etudes, maintenance, support technique, etc.).
A.2 Competences generales
L’offre OKTAL SE s’adresse aux secteurs de la Defense ainsi qu’aux marches de l’automobile, des
telecommunications, du spatial, de l’amenagement du territoire et de l’aviation civile. Dans ce
segment, OKTAL SE est reconnu comme un acteur possedant un savoir faire pointu et fortement
differencie.
OKTAL-SE possede aujourd’hui 3 noyaux de competence forts et reconnus :
147
Annexe A. Oktal Synthetic Environment
1. Logiciels de simulation senseurs
– Catalogue de produits sur etagere
– Formation sur mesure
– Etudes basees sur ses produits
– Session de formation generale
– Maintenance
2. Services specialises
– Etudes scientifiques sur la simulation
– Regie a haute valeur ajoutee
– Developpement logiciels specifiques
– Integration logicielle
– Integration materielle
3. Modelisation d’environnement synthetique
– Catalogue de terrains et d’objets 3D
– Production de terrains 3D sur demande
– Production de terrains 3D sur demande
– Modelisation de l’atmosphere
A.3 Les clients d’OktalSE
Il existe quatre types de clients :
1. Les grands industriels (de la defense ou civils) : Ils interviennent comme integrateur de
leurs solutions dans des systemes complexes et a forte valeur ajoutee :
– France Telecom RD
– Renault Recherche
– MBDA (fournisseur de systemes d’armes)
– SAGEM (fournisseurs de senseurs)
– Dassault
– SNECMA
– EADS
– OKTAL
– BGT
148
– LFK
2. Les ministeres de la Defense francais ou etrangers a travers leurs centres d’expertise tech-
nique et leurs services programme :
– SPART
– SPAe
– SPOTI
– CELAR,ETBS, ETAS, CTA, CEG, LRBA,CEV
– WTD81
– FMV
– MOD Coree du Sud
3. Les societes ou centres de recherche civils ou militaires francais et etrangers :
– ONERA
– FOI
– FGAN
– CEA
– CNES
– ISL
4. Les organismes pouvant prendre en charge des programmes de recherche francais ou eu-
ropeens :
– L’ESA/ESTEC
– La communaute europeenne a travers ses programmes FP
– Le ministere de la recherche a travers des procedures types RNRT, RNTL
– Le ministere des transports au travers des procedures PREDIT
149
Annexe A. Oktal Synthetic Environment
150
Annexe B
Approche CSP
La programmation par contraintes designe a la fois la representation des problemes par un en-
semble de contraintes, ainsi que la resolution de ces problemes par satisfaction de ces memes
contraintes. L’approche probleme de satisfaction de contraintes (CSP) est une famille de tech-
niques constructives generales. Elle permet la resolution de differents problemes (numerique,
symbolique, geometrique, etc.) avec une structure de graphe quelconque. Cette approche est
constructive : la solution est construite graduellement. Comme ces algorithmes sont bases sur
un processus d’enumeration, ils sont deterministes et exhaustifs. Cette approche a prouvee son
efficacite pour resoudre des problemes sous-contraints ou sur-contraints.
B.1 Definition
Un CSP est un triplet P = (V,D,C) defini par :
– un ensemble de variables V = X1, ..., Xn.
– un ensemble de domaines D = D1, ..., Dn, ou Di un ensemble de valeurs, est le domaine associe
a la variable Xi.
– un ensemble de contraintes C = C1, ..., Cm, ou Ci est une contrainte definie par une relation
sur un sous-ensembles des variables.
A tout probleme P, on peut associer un graphe appele graphe de contraintes, dont les noeuds
representent les variables et les arcs les contraintes. Une solution d’un CSP, P = (V,D, C),
est une assignation de chacune des variables de V (dans son domaine respectif) qui satisfait
l’ensemble des contraintes.
151
Annexe B. Approche CSP
B.2 Resolution
La resolution d’un CSP combine deux phases. Une phase effectue un filtrage afin de reduire le
plus possible les domaines de depart selon les possibilites de la technique de filtrage employee.
Une autre phase consiste en une recherche de solution satisfaisant les contraintes, de facon a
fournir une valeur a l’ensemble des variables du probleme, dans les domaines de validite produits
par la phase de filtrage.
Les techniques de recherche de solution s’appuient sur un backtracking intelligent, continuant a
effectuer un filtrage tout au long de la phase de recherche de solution, dans le but d’ameliorer
les performances.
B.3 Filtrage
Les techniques de filtrage cherchent a etablir une coherence totale ou partielle en transformant
le CSP initial en un CSP equivalent, dont ont ete supprimes les elements inconsistants. Le choix
d’une technique de filtrage depend du type de l’application. Un premier algorithme realisant
une propagation de contraintes par arc-consistance a ete propose par Waltz puis ameliore par
Mackworth pour donner l’algorithme AC-3. Par la suite plusieurs ameliorations de AC-3 ont ete
proposees afin de reduire la complexite de la technique [Tsa93].
L’algorithme de Waltz de filtrage par arc-consistance a ete modifie pour prendre en compte les
contraintes numeriques pour aboutir a la propagation d’intervalles. Il utilise les proprietes de
l’arithmetique d’intervalles [Sny92] en permettant de calculer directement la projection d’une
contrainte sur une variable pour restreindre son domaine [Hyv92, Lho93]. Les travaux de [DB01]
presentent de plus amples developpements concernant la resolution des CSP.
B.4 Types de CSP
B.4.1 CSP numeriques
Un NCSP est un CSP dont les variables sont numeriques, les domaines sont des intervalles de
valeurs numeriques et les contraintes sont des relations numeriques entre les variables. Cette
categorie particuliere de CSP est tres interessante car elle permet de modeliser des problemes
formules a partir de variables continues. Pour envisager la resolution d’un NCSP, les techniques
de consistance partielle (notamment arc-consistance) s’averent inutilisables car il n’est pas en-
152
visageable, lorsqu’on filtre le domaine d’une variable continue, de tester tous les elements de ce
domaine.
Dans un NCSP, les contraintes sont donnees sous forme d’equations ou d’inequations et les
variables peuvent en theorie prendre un nombre infini de valeurs. En pratique, les domaines
sont representes par des intervalles de flottants dont seulement les bornes sont memorisees. La
reduction d’un domaine consiste a rapprocher les bornes inferieures et superieures en eliminant
de l’intervalle les parties non consistantes, c’est-a-dire les sous-intervalles dont on est sur qu’ils
ne contiennent aucune solution.
B.4.2 CSP hierarchiques
La hierarchisation des contraintes va fournir un mecanisme permettant de traiter les problemes
sur-contraints en relachant les contraintes les plus faibles en cas de conflit. Le concepteur va
pouvoir exprimer des priorites sur les contraintes pour signifier quelles sont les contraintes qui
doivent toujours etre satisfaites et les contraintes secondaires qui peuvent ne pas etre satisfaites.
La flexibilite dans les CSP a ete etudiee par [FW92]. Helene Fargier a propose un modele
de contraintes flexibles s’appuyant sur la notion de relation floue [SFV95] ou la preference
entre valeurs est representee par un degre de satisfaction proche de la fonction d’appartenance
permettant de definir un ensemble flou. L’algorithme de Waltz [Wal75] a ainsi ete etendu aux
contraintes floues.
B.4.3 CSP dynamiques
La notion de CSP dynamiques a ete proposee par [DM89]. Un DCSP equivaut a une sequence de
CSP, chacun differant du precedent par l’ajout ou le retrait de contraintes. Plusieurs algorithmes
permettant d’etablir l’arc-consistance d’un DCSP fini et discret ont ete proposes [Bes91] et
[Jeg91]. D’autres etudes se sont dirigees vers la recherche d’une nouvelle solution apres ajout de
contraintes [Ber92].
B.5 Conclusion
La difficulte principale, rencontree lors de la resolution d’un CSP, vient de la tres forte combi-
natoire du probleme. Le nombre d’assignations possibles de l’ensemble des variables est egal au
cardinal du produit cartesien de tous les domaines. Plus precisement on montre que la resolution
153
Annexe B. Approche CSP
d’un CSP est un probleme NP-Complet. Il n’existe donc pas d’algorithmes qui s’executent en
temps polynomial, capables de resoudre un tel probleme. En revanche, la verification d’une so-
lution s’effectue en un temps polynomial. La consequence directe est que les CSP sont insolubles
des que le nombre de variables et/ou la taille des domaines deviennent trop importants.
En pratique, cette consequence tres facheuse n’est pas redhibitoire :
– les problemes de petite taille (peu de variables) peuvent etre resolus en des temps acceptables
pour le concepteur ;
– la palette d’outils aujourd’hui disponibles permet de resoudre des problemes recemment inen-
visageables ;
– la plupart des problemes poses par la modelisation declarative ne sont pas des problemes
durs :
– ils sont fortement sous-contraints et le nombre de solutions est important, ce qui facilite la
recherche d’une scene respectant les proprietes initiales ;
– ou bien ils sont sur-contraints, ce qui est generalement aisement detectable par les techniques
de filtrage ;
– si la completude n’est pas necessaire pour le type d’application, les techniques stochastiques
permettent d’envisager des problemes d’une plus grande complexite.
L’approche CSP est complete : la methode peut potentiellement explorer tout l’espace de so-
lution, ce qui lui permet de garantir de trouver l’optimum global si il existe ou a contrario de
prouver qu’il n’existe pas de solution.
154
Annexe C
L-System
Un L-System ou Lindenmayer system est la grammaire formelle (un ensemble de regles et de
symboles) la plus couramment utilisee pour modeliser les processus de croissance des plantes.
Un L-system est aussi capable de modeliser la morphologie d’une variete d’organismes. Les L-
System peuvent aussi etre utilises pour generer des fractales. Ils ont ete introduits et developpes
en 1968 par le biologiste et botaniste Aristid Lindemayer (1925-1989) de l’Universite d’Utrecht
[Lin68].
Basee sur une forme recursive de grammaire generative, cette grammaire a ete approfondie et
mise en œuvre graphiquement par Przemyslaw Prusinkiewicz [PL91] dans les annees 1980.
C.1 Origine (sic)
En tant que biologiste, Lindenmayer a travaille sur les levures et les champignons filamenteux et
a etudie les schemas de croissance de differents types d’algues. A l’origine, les L-System ont ete
concus pour fournir une description formelle de l’elaboration de ces organismes multicellulaires
simples, et illustrer les relations de voisinage entre les cellules vegetales. Plus tard, ce systeme a
ete etendu pour decrire les plantes plus evoluees et les structures a branchements complexes.
C.2 Structure
Le caractere recursif des L-system a conduit a l’autosimilarite et par consequent les formes proche
des fractales sont faciles a decrire avec un L-system. Les modeles de plantes et les organismes
presentant des formes organiques sont egalement faciles a definir : en augmentant le nombre
155
Annexe C. L-System
d’iterations, le niveau de recursivite s’accroıt et la forme devient plus complexe, simulant un
processus de croissance. Ces systemes sont aussi souvent utilises pour la generation de la vie
artificielle.
Les grammaires des L-System sont proches des grammaires de Chomsky. Un L-System est decrit
par un quadruplet G = (V, S, ω, P ) dans lequel :
V (l’alphabet) est un ensemble de symboles qui contient les symboles non-terminaux, i.e. qui
peuvent etre remplaces, V + represente l’ensemble des mots construits a base des symboles de
V ,
S est un ensemble de symboles contenant des elements qui restent fixes (symboles terminaux ),
ω (debut, axiome ou initiateur) est une chaıne de symboles de {V} definissant l’etat initial du
systeme
P est un ensemble de regles de derivation definissant comment des symboles non-terminaux
peuvent etre remplaces par une combinaison d’elements terminaux et non-terminaux. Une
regle de production est constituee d’une partie gauche (predecesseur) et d’une partie droite
(successeur).
Les regles de la grammaire d’un L-System sont appliquees de facon iterative a partir d’un etat
initial. Le fait que chaque iteration derive autant de regles que possible distingue les L-system
d’un langage formel genere par une grammaire. Si les regles de production etaient appliquees les
unes a la suite des autres, le resultat serait un langage et non un L-System. Les L-System sont
donc un sous ensemble strict des langages.
Un L-System est context-free si chaque regle de production se refere uniquement a un symbole
individuel, et pas a ses voisins. Les L-System context-free sont ainsi souvent specifies par une
grammaire reguliere.
Si une regle ne depend pas seulement d’un unique symbole, mais aussi de ses voisins, alors il
s’agit d’un L-System context-sensitive.
S’il existe une unique regle de production pour chaque symbole non-terminal, alors le L-System
est dit deterministe. Dans le cas inverse, et si le choix d’une regle repose a chaque iteration sur
une probabilite, alors le L-System est dit stochastique.
C.3 Exemple
La Figure C.1 presente un exemple de plante generee par le L-System suivant :
156
G = (V, S, ω, P ) avec
V contient X et F ,
S contient + et −,
ω est X,
P contient 2 regles de derivation : X → F − [[X] + X] + F [+FX]−X) et (F → FF )
Dans cet exemple, F signifie dessine droit, − tourne a gauche de 25 degres, + tourne a droite de
25 degres. X ne correspond pas une action de dessin, mais est utilise pour controler l’evolution
de la courbe. Enfin, le symbole [ declenche une sauvegarde des valeurs de position et d’angle
courants, qui sont restaurees par l’execution de la commande ].
157
Annexe C. L-System
Figure C.1. Plante generee par un L-System simple
158
Annexe D
Modelisation declarative
D.1 Presentation generale
La modelisation declarative propose des moyens de s’affranchir des defauts de la modelisation
classique (dite imperative). Elle est une voie de recherche relativement recente, initiee par M.
Lucas en 1989 qui la definit de la sorte :
L’objectif de la modelisation declarative de formes est de permettre d’engendrer
des formes (ou des ensembles de formes) par la simple donnee d’un ensemble de
proprietes ou de caracteristiques. L’ordinateur est charge d’extrapoler l’univers des
formes potentielles, afin de selectionner celles correspondantes a la definition donnee.
Le concepteur n’a plus qu’a choisir, a l’aide d’outils appropries, la ou les formes qui
lui conviennent.
Cette definition correspond bien aux travaux menes a Nantes sous la direction de M. Lucas
(projet ExploFormes) et a Limoges sous celle de D. Plemenos (projet MultiFormes). Elle a ete
etendue par V. Gaildrat [Gai03] qui la formule ainsi :
Le but de la modelisation declarative est d’offrir a un concepteur la possibi-
lite de decrire une entite ou une scene a modeliser, non plus en fournissant des
donnees numeriques, mais en exprimant l’image mentale qu’il a de la scene grace
a un ensemble de proprietes enoncees dans un langage quasi-naturel. Le concepteur
donne les proprietes geometriques, photometriques et physiques de l’environnement
en enoncant les caracteristiques des differents elements de la scene ainsi que les
relations entre ces elements.
159
Annexe D. Modelisation declarative
Ces proprietes permettent, a l’aide d’un ordre (instruction) unique, de realiser
une operation complexe qui aurait implique un nombre important d’actions elementaires
avec un modeleur geometrique imperatif.
La modelisation declarative a pour but d’ajouter de la semantique dans un domaine qui etait
jusqu’a present uniquement mathematique. Cette approche rejoint une tendance majeure de l’in-
formatique actuellement, qui est de deleguer les taches ingrates a l’ordinateur pour que l’utilisa-
teur n’ait plus qu’a effectuer les taches nobles ou creatives. L’utilisateur ayant preferentiellement
acces a un haut niveau d’abstraction32, on peut faire un parallele en associant les modeleurs
declaratifs aux langages a objets tandis que les modeleurs imperatifs seraient plutot les langages
d’assemblage [LR99]. En outre, on est en droit d’attendre d’un modeleur declaratif qu’il detecte
et mette en exergue les incoherences potentielles de la description fournie en entree.
Le groupe de travail GEODE33 a decrit les differences entre modelisation declarative et modelisation
effectuee a l’aide d’un modeleur imperatif (cf tableau D.1).
Une consequence evidente des definitions precedentes est que le developpement d’un modeleur
declaratif doit faire appel a des competences exterieures au seul domaine de la synthese d’images
(cf figure D.1) :
– de nombreuses etudes ont montre l’interet des interactions multimodales34 pour un modeleur
declaratif et de leurs apports dans la conception d’une interface conviviale, ces techniques
sont issues du domaine de l’IHM,
– la possibilite d’expression orale doit s’appuyer sur une reconnaissance et une analyse du lan-
gage,
– les differents principes de generation employes reposent sur des techniques developpees en
intelligence artificielle et en recherche operationelle,
– enfin, un modeleur declaratif ou non peut etre considere comme un outil de conception assistee
par ordinateur.32si il le desire, rien ne l’empeche d’acceder aux donnees de bas niveau.33GEODE est une equipe du GDR-PRC AMI. Elle est constituee de l’equipe MGII de l’IRIN, du CERMA
de l’ecole d’architecture de Nantes, et de l’equipe synthese d’images de l’Ecole des Mines de Nantes
(www.emn.fr/dept info/GEODE).34Multimodal : combinant souris, clavier, geste, reconnaissance parole, casque de RV pour construire un seul
evenement multimodal a partir de divers evenements monomodaux.
160
Modeleur imperatif Modeleur declaratif
Le concepteur a une idee d’objet a
modeliser
A partir de l’idee : description d’une scene
ou de la forme d’un objet a partir de ses
proprietes
Un processus mental doit amener de l’idee
a un ensemble d’operations elementaires
fournies par le modeleur
L’image mentale de l’objet solution n’est
pas directement utilisee pour la concep-
tion
Construction de l’objet par planification
mentale des operations elementaires
Le modeleur fournit les solutions a partir
de proprietes ⇒ pas necessaire de verifier
la validite
Realisation des operations elementaires,
pas a pas
A partir des solutions obtenues : pro-
cessus incremental de modification des
specifications
Tests de validite negatifs ⇒ reprendre la
decomposition
Le concepteur peut se concentrer sur des
taches de haut niveau d’abstraction
Modification a apporter ⇒ reprendre le
processus de conception depuis le debut
Le modeleur declaratif fournit un modele
de solutions a partir desquelles il est pos-
sible d’obtenir une a une, plusieurs ou l’en-
semble des solutions.
Le modele geometrique sous-jacent est to-
talement cache au concepteur
Table D.1. Comparaison entre modeleur imperatif et declaratif (GEODE)
161
Annexe D. Modelisation declarative
Figure D.1. La modelisation declarative : un domaine pluri-disciplinaire. Schema initial
par Champciaux [Cha98], etendu par Gaildrat [Gai03]
D.2 Les trois phases de la modelisation declarative
Les travaux realises au sein de l’equipe GEODE [CDMM97] ont mis en evidence la presence
de 3 phases successives au sein d’un modeleur geometrique (cf figure D.2). Ces trois phases se
succedent au cours d’un processus iteratif qui permet, par affinage successif de la description,
d’obtenir une solution qui satisfait l’utilisateur. Il est interessant de preciser que la solution
generee peut-etre totalement differente de l’image mentale initiale de l’utilisateur, tout en cor-
respondant pourtant a la description qu’il avait fournie (ceci est particulierement vrai dans
[EV01]).
L’un des avantages que tire la modelisation declarative de ce processus iteratif, est la possibilite
pour l’utilisateur (ou pour le modeleur lui-meme) de detecter des incoherences ou des problemes
tres tot dans le processus de conception. Ceci est rendu possible par la capacite d’un modeleur
declaratif a presenter des scenes tres tot (des esquisses) alors que tous les parametres ne sont
pas fixes.
D.2.1 La phase de description
Durant cette phase, l’utilisateur decrit la scene ou modifie une description anterieure apres
visualisation. Le principal probleme de cette phase consiste a utiliser un systeme permettant
162
Figure D.2. Les trois phases de la modelisation declarative [CDMM97].
d’eviter autant que possible toute ambiguıte dans la description. Notamment, la notion de gauche
et de droite n’est pas a priori clairement definie si on ne precise pas que l’on parle de la gauche de
l’utilisateur ou de celle de l’objet concerne (on parle d’orientation deictique35 ou intrinseque36).
Une phase de description peut proposer divers moyens d’interaction a l’utilisateur :
– interface graphique a base de menus deroulants et de boıtes de dialogue [Kwa98, Cha95],
– langage interprete,
– langage naturel [BGC94].
Il est aussi possible d’utiliser divers peripheriques d’interaction pour cette phase. On peut ima-
giner une interface multimodale combinant :
– clavier,
– souris,
– parole,
– geste (par camera ou gants de donnees),
– peripheriques a retour d’effort.35Deictique : element de linguistique qui sert a montrer, a designer un objet singulier determine dans la situation.36Par exemple, la gauche intrinseque d’un objet est fixe (ou inexistante dans le cas d’un objet sans direction
privilegiee, ex : une boule), alors que sa gauche deictique depend de la position d’un referent.
163
Annexe D. Modelisation declarative
Figure D.3. Interaction multimodale.
D.2.2 La phase de generation
Durant cette phase, le modeleur tente de generer les scenes correspondant a la description de
l’utilisateur. Si la description est incoherente, il peut n’y avoir aucune solution, auquel cas le
modeleur devra etre capable de detecter la partie de la description qui pose probleme pour
proposer a l’utilisateur des methodes qui evitent le blocage. Si la description est coherente, mais
encore imprecise, il peut y avoir une enorme quantite de solutions, et, dans ce cas, le traitement
varie selon les approches :
– generation d’une unique solution (generalement la premiere meme si elle est rarement equilibree),
– generation de toutes les solutions,
– generation d’un echantillon de solutions.
Ces variantes ont un cout tres variable en terme d’occupation memoire et de temps de calcul. En
fonction de la complexite du probleme et dans une optique visant des temps interactifs, on peut
envisager que le modeleur choisisse la variante adequate. Pour effectuer cette phase, differentes
techniques ont ete envisagees :
– arbres de parcours explicite,
– grammaires generatives,
– approche procedurale specifique [CS01, XSF02],
– transformation de la description en un ensemble de regles et utilisation d’un moteur d’inference
capable de creer de nouveaux faits et de deduire des caracteristiques geometriques [Ple91],
– transformation de la description en un ensemble de contraintes et utilisation d’un algorithme
numerique ou d’un solveur de contraintes pour la resolution du systeme [BP99, Ruc01, Kwa98,
LR99, LRG03, Cha95],
– application de techniques stochastiques [San00, SRGL03],
164
– application d’un optimiseur numerique [DH93].
Comme pour les moyens de description, la meilleure facon de realiser un modeleur declaratif
generique serait qu’il integre le plus de techniques possibles, neanmoins le choix de la technique
adequate par rapport au probleme est loin d’etre un probleme trivial.
D.2.3 La phase de visualisation
Si aucune scene n’a pu etre generee, alors le modeleur doit communiquer a l’utilisateur ses
recommandations afin de trouver une solution (quels objets ou contraintes posent probleme). Si
au contraire de nombreuses scenes ont ete generees, alors plusieurs solutions sont possibles :
– filtrer l’ensemble des solutions en rajoutant des contraintes (instancier certaines valeurs numeriques
par exemple),
– trier et classer l’ensemble des solutions de facon a presenter a l’utilisateur un individu representatif
de chaque classe [Cha98], probleme tres vaste et a priori quasiment impossible a appliquer a
un modeleur generique,
– comparer les differentes solutions en mettant en valeur les similitudes et les differences (meme
remarque que pour la classification).
On est en droit d’attendre de la part d’un modeleur 3D une visualisation dans l’espace des
resultats. Pour cela, des travaux de recherche ont porte sur une presentation des resultats en
placant le point de vue [Dor01] et le chemin eventuel de la camera de facon automatique ; ici
encore la recherche de la genericite pour le modeleur entraıne l’abandon de cette voie. Pour aider
le concepteur a visualiser les scenes generees, il est envisageable de reutiliser les peripheriques
de la phase de description pour naviguer dans l’espace des solutions, puis a l’interieur meme
des solutions. Une utilisation des peripheriques de realite virtuelle comme les casques 3D et les
gants de donnees paraıt particulierement adaptee.
165
Annexe D. Modelisation declarative
166
Annexe E
Approches manuelles
Figure E.1. Plan et vue crystal view d’une maison cree par Architecte 3D (Punch Software)
Il existe de nombreux logiciels grand public ayant pour vocation de permettre a tout un cha-
cun de (re)creer son habitation. On peut citer trois principaux logiciels : 3D Architecte edite
par Micro Application (Figures E.3 et E.4), Architecte 3D edite par Punch Software (Figure
E.1) et Architecte et construction 3D edite par Anuman Interactive (Figure E.2). Chacun de
ces produits est decline en un grand nombre de variantes (parfois plus d’une vingtaine) allant
de la modelisation d’une chambre a celle d’une maison de campagne en passant par la version
specifiquement dediee aux piscines.
Ces dernieres annees, les interfaces de ces logiciels ont progresse (voir Figure E.3), et les versions
les plus completes de chaque suite savent gerer les demi-niveaux, terrasses ou amenagement des
jardins.
167
Annexe E. Approches manuelles
Figure E.2. Plan et facade d’une maison cree par Architecte et Construction 3D (Anuman
Interactive)
Figure E.3. Exemple d’interface graphique, 3D Architecte Expert CAD 2008 (edite par
Micro Application)
168
Ces outils proposent a present la possibilite d’obtenir un rendu final incluant les ombres portees,
la prise en charge de conditions atmospheriques et des eclairages d’interieurs (cf Figure E.4).
Figure E.4. Exemple de rendu final, 3D Architecte Expert CAD 2008 (edite par Micro
Application)
169
Annexe E. Approches manuelles
170
Bibliographie
[Ber92] P. Berlandier. Etude des mecanismes d’interpretation de contraintes et de leur
integation dans un systeme a base de connaissance. PhD thesis, Universite de Nice,
Sophia-Antipolis, 1992.
[Bes91] C. Bessiere. Arc-consistency in dynamic constraint satisfaction problems. In 9th
National conference on artificial intelligence (AAAI’93), Washington DC, pages
211–226, 1991.
[BGC94] O. Balet, V. Gaildrat, and R. Caubet. Composed dynamic links for declarative
modeling. International Journal of CADCAM and Computer Graphics, Vol 9, 1994.
[Bon99] Pierre-Francois Bonnefoi. Techniques de satisfactions de contraintes pour la
modelisation declarative. Application a la generation concurrentes de scenes. PhD
thesis, Universite de Limoges, 1999.
[BP99] Pierre-Francois Bonnefoi and Dimitri Plemenos. Object oriented constraint satis-
faction for hierarchical declarative scene modeling. WSCG’99, 1999.
[BR64] P. Bertier and B. Roy. Procedure de resolution pour une classe de probleme pou-
vant avoir un caractere combinatoire. In Cahiers du Centre d’Etudes de Recherche
Operationnelle, 6 :202-208. ., 1964.
[BR75] J.R. Bitner and E.M. Reingold. Backtracking programming techniques. In Com-
munications of the ACM 18(11) :651-656, 1975.
[CDMM97] C. Colin, E. Desmontils, J. Martin, and J-P. Mounnier. Working modes with a
declarative modeler. Compugraphics’97, 1997.
[CH93] I. Charon and O. Hudry. The noising method : a new method for combinational
optimization. In Operations Research Letters, 14 :133-137, 1993.
171
Bibliographie
[Cha95] Philippe Charman. Gestion des contraintes geometriques pour l’aide a
l’amenagement spatial. PhD thesis, Ecole Nationale des Ponts et Chaussees, 1995.
[Cha98] Laurent Champciaux. Gestion des contraintes geometriques pour l’aide a
l’amenagement urbain. PhD thesis, Ecole des Mines de Nantes, 1998.
[CML01] J. Chanussot, G. Mauris, and P. Lambert. Fuzzy fusion techniques for linear features
detection in multitemporal sar images. IEEE Trans. on Geoscience and Remote
Sensing, 37(3) :1292–1305, 2001.
[CS01] B. Coyne and R. Sproat. Wordseyes : an automatic text-to-scene conversion system.
SIGGRAPH’01, 2001.
[DB01] R. Debruyne and C. Bessiere. Domain filtering consistencies. Journal of AI research,
2001.
[DG02] F. Dell’Acqua and P. Gamba. Extaction and fusion of street networks from fine
resolution sar data. In IEEE Proc. IGARSS’02, International Conference on Geos-
cience and Remote Sensing, Toronto, Canada, 2002.
[DH93] D. Donikian and G. Hegron. A declarative design method for 3d scenes sketch
modeling. Eurographics’93, pp 223-236, 1993.
[DM89] R. Dechter and I. Meiri. Experimental evaluation of pre-processing techniques in
csp. In 11eme Joint Conference on Artificial Intelligence (IJCAI’89), Detroit, pages
271–277, 1989.
[Don97] Stephane Donikian. Vuems : a virtual urban environment modeling system. Com-
puter Graphics International, pages 84–92, 1997.
[Don04] Stephane Donikian. Modelisation, controle et animation deagents virtuels auto-
nomes evoluant dans des environnements informes et structures. PhD thesis, Uni-
versite de Rennes 1, IFSIC (Habilitation a diriger des recherches), 2004.
[Dor01] G. Dorme. Etude et realisation de techniques de prise de connaissance de scenes
tridimensionnelles. PhD thesis, These de doctorat, Universite de Limoges, juin
2001., 2001.
[DS90] G. Ducek and T. Scheuer. Threshold accepting : a general purpose optimization
algorithm. In Journal of Computational Physics, 90 :161-175, 1990.
172
[EE98] David Eppstein and Jeffrey Gordon Erickson. Raising roofs, crashing cycles, and
playing pool : applications of a data structure for finding pairwise interactions. In
Proc. 14th Symp. Computational Geometry, pages 58–67. ACM, 1998.
[EV01] C. Essert-Villard. Selection dans l’espace des solutions engendrees par un plan de
construction geometrique. PhD thesis, These de doctorat, Universite Louis Pasteur
de Strasbourg, novembre 2001., 2001.
[Flo56] M.M. Flood. The traveling-talesman problem. In Operation research, 4 :61-7, 1956.
[FO98] Petr Felkel and Stepan Obdrzalek. Straight skeleton implementation. In Laszlo Szir-
may Kalos, editor, SCCG 98 : Proceedings of the 14th Spring Conference on Com-
puter Graphics, pages 210–218. Comenius University. Bratislava, 6 1998.
[FR89] T.A. Feo and M.G.C. Resende. A probabilistic heuristic for a computationally
difficult set covering problem. In Operations Research Letters, 8 :67-71, 1989.
[Fri03] Pascale Fribault. Modelisation declarative d’espaces habitables. PhD thesis, Univer-
site de Limoges, 2003.
[FW92] E. Feuder and R. Wallace. Partial constraint satisfaction. Artificial Intelligence,
58 :21–71, 1992.
[Gai03] Veronique Gaildrat. Modelisation declarative d’environnements virtuels : Creation
de scenes et de formes complexes par l’enonce de proprietes et l’emploi d’interac-
tions gestuelles. PhD thesis, Habilitation a diriger des recherches, Universite Paul
Sabatier, janvier 2003., 2003.
[GBHF05] Bjorn Gerth, Rene Berndt, Sven Havemann, and Dieter W. Fellner. 3d modeling for
non-expert users with the castle construction kit v0.5. In Ryan et Scopigno Mudge,
editor, Proceedings of ACM/EG VAST 2005, pages 49–57, 2005.
[Geo] Geoconcept. Geographic information system developped by the geoconcept sa com-
pany.
[Gho90] P. K. Ghosh. A solution of polygon containment, spatial planning, and other rela-
ted problems using minkowski operators. Computer Vision, Graphics and Images
Processing, 49 :1-35, 1990.
[GJ79] M.R. Garey and D.S. Johnson. Computers and intractability : a guide to the theory
of NP-completeness. W.H. Freeman and Company, 1979.
173
Bibliographie
[GJ96] D. Geman and B. Jedynak. An active testing model for tracking roads in satellite
images. IEEE Trans. on Pattern Analysis and Machine Intelligence, 18(1), 1996.
[GL95] A. Gruen and H. Li. Road extraction from aerial and satellite images by dynamic
programming. ISPRS Journal of Photogrammetry and Remote Sensing, 50(4) :11–
20, 1995.
[Glo86] Fred Glover. Future paths for integer programming and links to artificial intelli-
gence. Computers and Operations Research, 13 :533-549, 1986.
[Han86] P. Hansen. The steepest ascent mildest descent heuristic for combinatioral pro-
gramming. Congress on Numerical Methods in Combinatioral Optimization, 1986.
[Hav05] Sven Haveman. Generative Mesh Modeling. PhD thesis, TU Braunshweig, Germany,
2005.
[HGH99] J-K Hao, P. Galinier, and M. Habib. Metaheuristiques pour l’optimisation combi-
natoire et l’affectation sous contraintes. Revue d’Intelligence Artificielle, 1999.
[HL01] R. Huber and K. Lang. Road extraction from high resolution airborne sar using
operator fusion. In Proc. IGARSS’01, International Conference on Geoscience and
Remote Sensing, Sydney-Australia, 2001.
[Hol75] J. H. Holland. Adaptation in natural and artificials systems. The University of
Michigan Press, 1975.
[How68] W. E. Howden. The sofa problem. Computer Journal, 11 :299–301, 1968.
[Hyv92] E. Hyvonen. Constraint reasoning based on interval arithmetic’s : the tolerance
propagation approach. Artificial Intelligence, 58 :71–112, 1992.
[Jeg91] P. Jegou. Contribution a l’etude des problemes de satisfaction de contraintes. PhD
thesis, Universite Montpellier des sciences et techniques du Languedoc, 1991.
[KGC97] Ghassan Kwaiter, Veronique Gaildrat, and Rene Caubet. Oranos : Un solveur
dynamique de contraintes hierarchiques et geometriques. In MICAD, 1997.
[KGV83] S. Kirkpatrick, C.D. Gelatt, and P.M. Vecchi. Optimization by simulated annealing.
Science, 220 :671–680, 1983.
[Kwa98] Ghassan Kwaiter. Modelisation declarative de scenes : etude et realisation de sol-
veurs de contraintes. PhD thesis, Universite Paul Sabatier, Toulouse, 1998.
174
[LD03] R. G. Laycock and A. M. Day. Automatically generating roof models from building
footprints. In WSCG, 2003.
[LDG05] Mathieu Larive, Yann Dupuy, and Veronique Gaildrat. Automatic generation of
urban zones. WSCG’2005, pages 9–12, 2005.
[LH97] Sylvain Liege and Gerard Hegron. An incremental declarative modelling applied to
urban layout and design. WSCG’97, 1997.
[Lho93] O. Lhomme. Consistency techniques for numeric csp. In 13th International Joint
Conference on IA, 1993.
[Lie96] Sylvain Liege. La Modelisation Declarative Incrementale : Application a la Concep-
tion Urbaine. PhD thesis, Ecole des Mines de Nantes, 1996.
[Lin68] Aristide Lindenmayer. Mathematical models for cellular interaction in development.
Journal of Theoretical Biology 18 :280-289, 1968.
[LLGC+05] Jean Latger, Alain Le Goff, Nicolas Champseix, Thierry Cathala, and Mathieu La-
rive. Automatic 3d virtual scenes modeling for multi sensors simulation. to appear.
In Proceedings of SPIE Defense and Security Symposium, 2005.
[LR99] Olivier Le Roux. Solveur de contrainte pour la modelisation declarative : Etude
du probleme de l’amenagement spatial de scenes tridimensionelles sous contraintes.
Master’s thesis, Universite Paul Sabatier, Toulouse, 1999.
[LR03] Olivier Le Roux. Modelisation declarative d’environnements virtuels : contribution
a l’etude des techniques de generation par contraintes. PhD thesis, Universite Paul
Sabatier, 2003.
[LRG03] Olivier Le Roux and Veronique Gaildrat. Constraint-based 3d isothetic object
layout for declarative scene modeling. CISST’03, 2003.
[Mac77] A. Mackworth. Consistency in networks of relations. Artificial intelligence, 1977.
[Mac91] Robert Maculet. Archipel : intelligence artificielle et conception assistee par ordi-
nateur en architecture. PhD thesis, Universite Paris 6, 1991.
[MBST01] Xavier Marsault, Christophe Bertrand, Renato Saleri, and Joelle Thollot. Bases
de donnees urbaines 3d complexes. modelisation et restitution. Technical report,
MAP-Aria, equipe iMAGIS/GRAVIR, 2001.
[Min97] H. Minkowski. Allgemein lehrsatze uber konvexe polyeder. Nach. Ges. Wiss. Gottin-
gen :198 :219, 1897.
175
Bibliographie
[Mit90] William J. Mitchell. The Logic of Architecture : Design, Computation,and Cogni-
tion. MIT Press., 1990.
[Moo79] R. Moore. Methods and Applications of Interval Analysis. Ed. SIAM, 1979.
[Mos89] P. Moscato. On evolution, search, optimization, genetic algorithms and martial arts :
towards memetic algorithms. Technical report, Caltech Concurrent Computation
Program, C3P Report 826, 1989.
[MRR+53] N. Metropolis, A. Rosenbluth, M. Rosenbluth, A. H. Teller, and E. Teller. Equation
of state calculation by fast computing machines. J. Chem. Phys., vol. 21, 1953.
[MWS+06] Pascal Muller, Peter Wonka, Haegler Simon, Andreas Ulmer, and Luc Van Gool.
Procedural modeling of buildings. In SIGGRAPH, 2006.
[MY01] B. Medjoub and B. Yannou. Dynamic space ordering at a topological level in space
planning. Artificial Intelligence in engineering, 15 :47-60, 2001.
[MZWG07] Pascal Muller, Gang Zeng, Peter Wonka, and Luc Van Gool. Image-based procedural
modeling of facades. In Proceedings of ACM SIGGRAPH 2007 / ACM Transactions
on Graphics, 2007.
[O’R98] J. O’Rourke. Computational Geometry in C second edition. Cambridge University
Press, 1998.
[Per06] Julien Perret. Modelisation d’environnements urbains virtuels. PhD thesis, Univer-
site de Rennes 1, 2006.
[PL91] P. Prusinkiewicz and A. Lindenmayer. The Algorithmic Beauty of Plants. Springer
Verlag, 1991.
[PM01] Y. Parish and P. Muller. Procedural modeling of cities. ACM SIGGRAPH, 2001.
[Pur07] Arnaud Puret. Projet HM2PH, Generation automatique de plan et visite virtuelle
d’habitats adaptes pour personnes handicapees. PhD thesis, Univerite Francois Ra-
belais de Tours, 2007.
[Rec73] I. Rechenberg. Evolutionasstrategie : optimierung technisher systeme nach prinzi-
pien der biologischen evolution. Frommann-Holzboog, 1973.
[RMS96] A. RauChaplin, B. MacKayLyons, and P. Spierenburg. The lahave house project :
Towards an automated architectural design service. Cadex’96, pp. 24-31, 1996.
176
[RP02] William Ruchaud and Dimitri Plemenos. Multiformes : a declarative modeller as a
3d scene sketching tool. ICCVG’2002, 2002.
[Ruc01] Wiiliam Ruchaud. Etude et realisation d’un moteur de resolution de contraintes
geometriques pour la modelisation declarative. PhD thesis, Universite de Limoge,
2001.
[San00] Stephane Sanchez. Solveur de contraintes geometriques pour la modelisation
declarative, resolution d’un probleme d’amenagement spatial a l’aide d’un algo-
rithme’. Master’s thesis, Universite Paul Sabatier, Toulouse, 2000.
[SFV95] T. Schiex, H. Fargier, and G. Verfaillie. Valued constraint satisfaction problems :
Hard and easy problems. In Morgan Kaufmann, editor, 14th Inter. Joint Conf. on
Artificial Intelligence (IJCAI’95), 1995.
[SMTS05] U. Soergel, E. Michaelsen, U. Thoennessen, and U. Stilla. Potential of high-
resolution sar images for urban analysis. In URBAN, 2005.
[Sny92] J. M. Snyder. Interval analysis for computer graphics. In SIGGRAPH’9, Computer
Graphics, 1992.
[SRGL03] Stephane Sanchez, Olivier Le Roux, Veronique Gaildrat, and Herve Luga.
Constraint-based 3d-object layout using a genetic algorithm. 3IA’03, 2003.
[Sti75] Georges Stiny. Pictorial and formal aspects of shape and shape grammars : on
computer generation of aesthetic objects. Birkhauser, 1975.
[Sto01] R. Stoica. Processus ponctuels pour l’extraction de reseaux lineiques dans les images
satellitaires et aeriennes. PhD thesis, Universite de Nice-Sophia Antipolis, 2001.
[Tho99] Gwenola Thomas. Environnements virtuels urbains : modelisation des informations
necessaires a la simulation d’humanoıdes. PhD thesis, Universite Rennes I, IRISA,
Rennes, 1999.
[Tsa93] E. Tsang. Foundation of constraint satisfaction. Academic press, London, 1993.
ISBN 0-12-701610-4.
[Tup97] F. Tupin. Reconnaisance de formes et analyse de scenes en imagerie radar a ouver-
ture synthetique. PhD thesis, Ecole Nationale Superieure des Telecommunications
de Paris, 1997.
[Van86] Claude Vandeloise. L’espace en francais. Le Seuil, 1986.
177
Bibliographie
[VMC+02] N. Vassilas, G. Miaoulis, D. Chronopoulos, E. Konstantinidis, I. Ravani, and D. Ple-
menos. Multicad-ga : A system for the design of 3d forms based on genetic algo-
rithms and human evaluation. SETN, pp. 203-214, 2002.
[Wal75] D. Waltz. Understanding line drawings of scenes with shadows. The psychology of
computer vision, pages 19–91, 1975.
[WHMJ98] C. Wiedemann, C. Heipke, H. Mayer, and O. Jamet. Empirical evaluation methods
in computer vision, chapter Empirical evaluation of automatically extracted road
axes, pages 172–187. K.J. Bowyer and P.J. Phillips Eds., 1998.
[WWSR03] Peter Wonka, Michael Wimmer, Francois Sillion, and William Ribarsky. Instant ar-
chitecture. ACM Transactions on Graphics, 4(22) :669–677, july 2003. Proceedings
of ACM SIGGRAPH 2003.
[XSF02] K. Xu, J. Stewart, and E. Fiume. Constraint-based automatic placement for scene
composition. Graphics Interface’02, 2002.
178