Mémoire : Modélisation de zones urbaines virtuelles

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


– 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


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


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


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


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


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


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


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


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


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


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


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


//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


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


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


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


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


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


ω −→ 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


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


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


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


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


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


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

Mémoire : Modélisation de zones urbaines virtuelles

Technology

Transcript of Mémoire : Modélisation de zones urbaines virtuelles