Contribution à l`élaboration de modèles urbains virtuels - MAP-ARIA

Diplôme Universitaire Technologique
Spécialité informatique
Juin/septembre 2001
RAPPORT DE STAGE
Goenaga Julien
Contribution à l’élaboration de modèles
urbains virtuels 3D.
Laboratoire MAP – ARIA
Ecole d’architecture de Lyon
3, rue Maurice Audin
BP 170
69512 Vaulx-en-Velin cedex
Université Claude Bernard Lyon 1
Institut Universitaire de Technologie A
Département informatique
71, rue Peter Fink – 01000 Bourg-en-Bresse
Téléphone : 04 74 45 50 50
Télécopie : 04 74 45 50 51
Courriel : [email protected]
Web : http://iutbourg.univ-lyon1.fr
Résumé en francais :
Mon stage, qui se déroule à l’école d’architecture de Lyon, a pour but la réalisation
de deux taches distinctes concernant la création de modèles 3D urbains. La première
est la création d’une interface, avec la librairie Qt, permettant de gérer les
algorithmes de génération de modèles urbains du laboratoire par compression
fractale d’une image. Il faut pouvoir en choisir les paramètres et les images.
Le deuxième projet, plus complexe, a pour but la réalisation de scènes en 3D à partir
d’images de villes en 2D, niveaux de gris. La partie analyse est importante, car il
s’agit , en plus de créer la scène en 3D, d’en optimiser la géométrie, pour pouvoir
l’explorer avec un navigateur temps réel, sans ralentissement.
En ce qui concerne le premier projet, un rapport d’utilisation de Qt expliquant les
bases de son fonctionnement doit être rendu à ARIA.
Résumé en anglais :
The goal of my training course, in Lyon architecture high school, is the realisation of
two tasks concerning the creation of two and three-dimensional urban models. The
first task is an interface, with Qt library, which includes ARIA’ s algorithms. We will
be able to choose our parameters for the different algorithms.
The second project, more complex, has to convert a two dimensional picture into a
three-dimensional scene in VRML format. The analysing part is important because I
have to simplify the picture before creating the three dimensional scene. Indeed we
must obtain scenes that can be explored easily in real time without latency.
Concerning the first project, I must make a report which explains how to use the Qt
library.
Mots clés :
VRML : Virtual Reality Modelling Language. Langage informatique utilisé pour
représenter des scènes 3D surtout sur Internet.
Pixel : Point élémentaire d’un écran. Une image est composée de pixels.
Modèle 3D urbain : modèle géométrique d’une ville représentée en 2D par une
image, ou en 3D grâce au format VRML par exemple.
BMP : format d’image (bitmap) sous Windows.
Matériel / logiciel / méthode(s) utilisée(s) :
Matériel :
Développement sous PC PIII 800Mhz en réseau (100Mbits)
Logiciels :
Environnement Windows 2000, Microsoft Visual C++ 6, librairie Windows QT (de
Troll Tech), Paint Shop Pro
2
SOMMAIRE
I-
Introduction
1- Objectifs du stage
2- Présentation du sujet.
3- Plan
II-
Présentation de l’environnement du stage
1- Le laboratoire
2- Les chercheurs
3- Aspects techniques
4- Relations avec le laboratoire durant le stage
III-
Travaux effectués
1 -Projet n°1. (création d’une interface graphique)
A –Description
Origine du projet
Cahier des charges
Champ d’investigation et contraintes
Matériel et logiciels utilisés
B -Analyses des besoins
Définition des phases
Conception des phases
C -Réalisation
Structure des programmes
Problèmes rencontrés
3
2 -Projet n°2. (programme de conversion d’images 2D en 3D)
A –Description
Origine du projet
Cahier des charges
Champ d’investigation et contraintes
Matériel et logiciels utilisés
B -Analyses des besoins
Définition des phases
Conception des phases
C -Réalisation
Structure des programmes
Problèmes rencontrés
IV- Conclusion
V-
Annexes
VI- Bibliographie
VII- Remerciements
Fin du sommaire.
4
I-
Introduction
1- Objectifs du stage
Les objectifs sont multiples.
Dans un premier temps, avant même de parler de l’aspect conception, il est impératif
de s’introduire et de s’adapter à l’environnement de travail. Sans cela, il serait très
dur de développer quelque chose de correct car nous sommes juste le traducteur
entre les idées de l’utilisateur et le programme lui même. Mais cela s’acquiert
progressivement. Le but final est donc de comprendre la structure de « l’entreprise »,
son mode de fonctionnement et les processus qui la font avancer. Dans mon cas je
dois me familiariser avec tous les membres du laboratoire, connaître ce que chacun
apporte au projet global, pour pouvoir demander en temps voulu des explications sur
certains points et pour voir comment ils fonctionnent entre eux pour mettre au point
leur projet.
En ce qui concerne la conception plusieurs points sont à prendre en compte.
D’abord il est question d’analyser avec attention le sujet proposé, en étant à l’écoute
de l’utilisateur. En effet il n’est pas envisageable de se mettre à créer sans réflexion
un programme qui ne conviendrait pas à l’utilisateur. Cela serait une perte de temps.
De plus il faut rester à l’écoute de l’utilisateur en le conseillant si nécessaire. De plus
il faut assurer une fonction de conseil, et s’assurer tout au long du développement de
l’adéquation avec ses besoins. En ce qui me concerne, mon objectif minimum est de
créer une interface graphique sous Windows avec la librairie Qt, permettant de gérer
au moins un algorithme de gestion d’images, et dans un second temps, de réaliser
un programme convertissant des images en niveaux de gris en images 3D comme
nous allons le voir dans la section suivante.
2- Présentation du sujet.
Contexte :
Le laboratoire de recherche, ARIA, participe à un projet régional : DEREVE1.
Celui-ci est bâti autour de trois thèmes de recherche phares de la réalité virtuelle
aujourd’hui :
- les performances de scènes,
- la génération de mondes et de décors virtuels,
- l’interaction multisensorielle.
L’implication dans ce projet du laboratoire, est à l’heure actuelle , de composer un
rapport complet sur le « texturage NPR2 multi échelles » mais aussi, en vertu de la
spécificité du laboratoire, de proposer des travaux touchant aux deuxième et
1
2
DEREVE: Développement d’un Environnement logiciel de REalité Virtuelle Elaboré.
NPR: Non Photo Réaliste.
5
troisième axes, par exemple dans le domaine de la création des décors urbains de
type NPR et de la génération automatique de tissus urbains.
Sujet du laboratoire, en cours de développement :
Le sujet est à placer dans le cadre d’une recherche d’un modèle fractal généralisé
pour les tissus urbains, qui ne soit pas un modèle de croissance à base de règles,
mais un générateur à l’instant t. L’idée de départ repose donc sur :
- l’association à un tissu urbain tridimensionnel d’une image en niveaux de gris
représentant dans le plan (x, y) la position du bâti par rapport au sol, et le long de la
coordonnée z la hauteur du bâti par rapport au sol (ce qui autorise donc la
représentation des toitures). La surface non-bâtie ne nous intéresse pas dans un
premier temps : nous portons notre attention uniquement sur la distribution spatiale
du bâti en (x, y).
- le codage fractal des images par les IFS3. De nombreux travaux ont été menés
avec succès depuis 12 ans sur leur application à la compression des images. Ici, ce
n’est pas l’aspect compression qui nous intéresse mais plutôt le modèle de codage
fractal.
- la reconstruction d’un modèle 3D : c’est l’étape inverse de la première, où l’on
associe l’image générée par IFS une scène 3D unique, obtenu après filtrage( car il y
a des éléments de détails à éliminer dans une phase de pré traitement, dus à des
approximations dans les calculs).
Mon sujet :
Mon intervention dans ce projet ce fait au niveau des étapes 1 et 2 dans un premier
temps, et peut-être au niveau de l’étape 3 s’il reste assez de temps.
Je dois développer deux parties indépendantes.
La première consiste à créer une interface graphique sous Windows pour pouvoir
manipuler et appliquer les algorithmes de traitement des images de tissus urbains.
L’utilisateur doit pouvoir choisir ses paramètres sans difficulté et pouvoir visualiser
les points importants du déroulement de l’algorithme choisi.
La deuxième étape consiste à développer un logiciel permettant de convertir des
images 2D en niveau de gris en images 3D (l’intensité du gris représentant la hauteur
de l’objet). Celles-ci pourront être visionnées à partir soit d’une interface sous
Windows, soit directement dans une fenêtre d’un explorateur de pages web.
Mais bien sur nous étudierons ces deux étapes du projet plus en détail dans le
paragraphe III.
3
IFS: Iterated Functions Systems.
6
3- Plan
Mon rapport va donc être développé autour des thèmes suivants :
1. Dans un premier temps, je vais décrire l’environnement de mon stage, les
chercheurs et le lieu de travail, et ensuite l’aspect technique (matériel utilisé,
logiciels…).
2. Dans un second temps je développerai la partie du travail réalisé. J’expliquerai
mon sujet en définissant le cahier des charges (pour chacune des deux
parties). Nous en verrons les objectifs ainsi que les contraintes.
3. Toujours dans « travail réalisé », je définirai les différentes phases et leurs
buts, et pour terminer j’expliquerai le travail que j’ai effectué en décrivant tous
les points difficiles rencontrés et les solutions apportées. Les résultats seront
présentés grâce à des captures d’écran et des commentaires.
4. Pour terminer, je développerai les
bibliographie, remerciements et annexes.
Fin de l’introduction
7
parties
suivantes :
conclusion,
II-
Présentation de l’environnement du stage
1-Le laboratoire
ARIA est un laboratoire appartenant à l’un des sites de l’Unité Mixte de Recherche
MAP (Modèles et simulations pour l’Architecture, l’urbanisme et le Paysage). L’UMR
MAP associe le CNRS et le Ministère de la Culture et de la Communication. La
problématique centrale de l’UMR recouvre l’élaboration de modèles et d’outils de
simulation en architecture, celle-ci étant considérée dans ses dimensions
patrimoniales, constructives, urbaines et paysagères.
2- Les chercheurs
Le laboratoire ARIA est composé de chercheurs et d’enseignants chercheurs de
l’école d’architecture. Il y a trois membres permanents : MM Hervé Lequay, Xavier
Marsault et Renato Saleri, chercheurs et enseignants. De plus, à ce groupe viennent
se joindre, à mi-temps, d’autres personnes pour accomplir des tâches auxiliaires.
Ajoutons que certains élèves viennent de temps à autres aider les chercheurs dans
la réalisation de modèles 3D par exemple ou pour la réalisation de sites.
3- Aspects techniques
Le laboratoire se situe à l’intérieur de l’école d’architecture dans une salle
aménagée. Sont à la disposition de l’équipe une dizaine de machines, comme des
Pc, Macintosh, ou même des Silicon Graphics. Ce matériel se révèle assez puissant
pour les travaux qui sont effectués. De plus, toutes ces machines sont reliées en
réseau (100Mbits) et à Internet pour pouvoir disposer de toutes les données
souhaitées à n’importe quel moment.
4- Relations avec le laboratoire durant le stage
Comme nous l’avons vu, l’équipe du laboratoire est constituée de 3 personnes
(enseignants, chercheurs ) à plein temps, et de plusieurs autres personnes
(étudiants) qui viennent pendant certaines périodes. La taille du laboratoire, qui ne
contient qu’une dizaine de machines, confère une atmosphère agréable et amicale.
Dès que l’on commence a y travailler, on ne peut que se sentir à l’aise. La pression
des résultats à obtenir ne se fait pas trop sentir pour moi et je pense que les
relations ne peuvent qu’en être améliorées. De plus, la majeure partie de l’équipe
étant constituées de chercheurs, la communication, tant au point de vue purement
relationnel, qu’au point de vue technique, s’en trouve grandement améliorée. Ils sont
aptes à comprendre les termes techniques utilisés en informatique et comme ils sont
pour la plupart professeurs ils peuvent plus facilement aider un élève à s’exprimer.
8
Je peux dire aussi, sans aucun sous entendu, que grâce à la jeunesse relative de
l’équipe travaillant sur le projet, les échanges d’informations entre eux et moi sont
grandement facilités. Je dois avouer que l’on ose plus les déranger pour demander
un service que s’il s’agissait de personnes plus âgées.
III-
Travaux effectués.
1-Projet n°1. (création d’une interface graphique)
A –Description
Origine du projet
Comme nous l’avons vu dans l’introduction, le laboratoire MAP – ARIA participe à un
projet régional : DEREVE. Le but du laboratoire dans ce projet est, entre autre de
créer des tissus urbains (des images) avec des algorithmes basés sur les fractals4.
Ces algorithmes servent à générer des images originales de tissus urbains. Pour
cela, il faut posséder des modèles compressés sous forme fractale. Ensuite, on peut
appliquer les différents algorithmes à l’image obtenue. Par exemple, l’algorithme de
croisement permet, à partir de deux images d’en générer une nouvelle comportant
certaines caractéristiques de la première et de la deuxième image. Nous obtenons
un nouveaux modèle urbain qui va être analysé par la suite pour en déterminer les
points forts et les points faibles.
La laboratoire ARIA se charge de concevoir ces algorithmes (une dizaine environ
comme la compression fractale, la mutation…). Cependant, étant développés sous
DOS, ils ne sont pas très faciles à manipuler car il faut rentrer certains paramètres
que seul le concepteur connaît. Mon rôle est donc de créer une interface graphique
sous Windows, regroupant tous les algorithmes développés, pour pouvoir les utiliser
presque intuitivement. En effet pour chacun d’entre eux, leur fonction est expliquée
ainsi que leurs paramètres. Mais nous allons voir cela dans le cahier des charges qui
suit.
4
Fractals: ce sont des figures géométriques dans lesquelles on peut observer des similitudes à différentes
échelles.
9
Cahier des charges
• Analyser les paramètres d’entrée des programmes ainsi que les résultats que
l’on souhaite afficher. (textes, images…)
•
Concevoir l’application sous Windows : grâce à son interface elle doit
permettre, entre autre, de sélectionner un des algorithmes, et pour chacun
d’eux afficher les paramètres d’entrée et les résultats (mis en évidence dans le
premier point).
• Développer l’interface avec la librairie Qt, et montrer sur au moins un exemple
son utilisation pour faire fonctionner un programme.
• Développer un outil permettant de connaître à tout moment le temps écoulé
jusqu’à la fin de l’algorithme.
• Rédiger une note précise et brève sur l’utilisation de Qt pour parvenir aux
résultats demandés dans l’étape 3. Les fichiers sources seront commentés
largement. Les difficultés ou les astuces seront désignées et commentées de
la même manière.
Champ d’investigation et contraintes
Pour arriver au terme de ce projet, il est donc nécessaire d’apprendre à utiliser la
librairie de développement sous Windows Qt. Cette tâche est d’autant plus
intéressante que toute sa syntaxe et son aide, fournies avec le logiciel, sont en
anglais. Pour cela, il me faut étudier les exemples fournis avec la librairie (eux aussi
en anglais). Heureusement ceux ci sont clairs et nous apprennent à utiliser les
différents objets disponibles de manière progressive.
Premier exemple
de l’aide :
Un bouton dans
une fenêtre.
10
Dernier exemple
de l’aide:
Jeu ou l’on doit
tirer sur une
cible en ajustant
l’angle et la
force.
On constate ici la différence de complexité entre les deux exemples !
Je dois aussi me renseigner sur le format des images que l’interface gèrera : en effet,
pour la plupart des algorithmes, une ou deux images sont nécessaires en entrée ou
en sortie. Il faut donc les afficher et les manipuler. Pour cela je cherche des
indications sur Internet, sur les formats existant.
Enfin je dois aussi me pencher sur le problème de la gestion du temps pour pouvoir
calculer le temps restant pendant l’exécution d’un algorithme. Là encore je vais me
renseigner sur Internet et je demande conseil à mon maître de stage.
Matériel et logiciels utilisés
Pour ce projet, j’utilise un ordinateur PC 800Mhz, avec Windows 2000.
Pour le développement, il faut bien sûr la librairie Qt mais les fichiers sources seront
édités avec Visual C++ 6. La compilation de l’exécutable sera effectuée grâce à
« Nmake » , compilateur que l’on trouve sur Internet, indispensable pour compiler le
code contenant des objets Qt.
11
B -Analyses des besoins
Définition des phases.
Phase 1 :
Mon premier travail consiste en l’étude des algorithmes déjà réalisés pour en extraire
les paramètres d’entrée et de sortie nécessaires à la conception de l’interface.
Phase 2 :
Apprentissage des concepts de base de la librairie Qt. Je m’entraîne d’abord sur des
exemples sans rapport apparent avec le projet.
Phase 3 :
Création du squelette de l’interface avec les fenêtres principales. Mise en forme
avant d’intégrer les algorithmes.
Phase 4 :
Intégration d’un algorithme (compression fractale) dans l’interface, puis adaptation de
cet algorithme à l’environnement de Windows.
Phase 5 :
Liaison des différents objets dans l’interface. Notion des « SIGNALS / SLOTS »
propre à Qt et amélioration de la manipulation des images par l’ajout de ScrollBars5.
Phase 6 :
Ajout dans le menu déroulant permettant de choisir une image, toutes celles
disponibles dans un répertoire donné. Images nécessaires pour le bon déroulement
de l’algorithme.
Phase 7 :
Programmation d’une fonction estimant le temps restant avant la fin de l’exécution
d’un algorithme. Certains peuvent tourner pendant plusieurs jours ou plus encore.
Conception des phases.
Le cahier des charges impose de créer une interface pouvant gérer au moins un
algorithme réalisé par Xavier Marsault. Nous intégrons donc le plus important,
« compression fractale » car les fichiers fractals sont à la base de tous les autres
algorithmes.
Phase 1 : Etude de l’algorithme de compression fractale.
Cet algorithme a pour but de créer un fichier fractal (*.fra) à partir d’une image
graphique Bitmap représentant le plan d’une ville ou d’un quartier. Les fichiers *.fra
ne sont pas visionnables directement car ils ne sont pas codés en fonction de pixels6
5
6
ScrollBar : Barre de défilement qui permet par exemple de faire défiler une image.
Pixel: sur un écran d’ordinateur un pixel est un point d’une couleur définie. Tous ces points forment une image.
12
mais de blocs fractals (des fonctions mathématiques). Le déroulement proprement
dit de l’algorithme n’est pas pour moi le point essentiel à étudier. Je dois juste étudier
ses entrées et sorties.
Comme nous l’avons donc vu, le premier paramètre indispensable est une image
Bitmap (nous verrons plus tard comment je gère ces images). La hauteur et la
largeur de cette image doivent impérativement être une puissance de 2 pour que
l’algorithme puisse fonctionner. Cependant il n’y a pas de maximum imposé, seul les
capacités de la machine utilisée pourront restreindre ces tailles. De plus l’image doit
être au format 8bits pour pouvoir coder 256 niveaux de gris. En effet ces 256 niveaux
de gris ont une importance durant la conversion en image 3D dans un autre
programme.
Après avoir sélectionné une image, il reste trois paramètres à choisir : la taille des
« blocs Range », la taille des « blocs Domain » et la contrainte de collage. Ces trois
paramètres sont indispensables, mais nous ne rentrerons pas plus dans les détails
car il faudrait alors décrire l’algorithme lui même.
Phase 2 : Familiarisation avec la librairie Qt.
Connaissant maintenant les paramètres, donc les éléments dans l’interface qui
permettront de modifier ces paramètres, je peux donc commencer à me familiariser
avec la librairie graphique sous Windows Qt. Au cours de ma recherche, je
sélectionne donc les objets adéquats pour créer mon interface. Je regarde le premier
exemple proposé et j’essaie de le reproduire pour obtenir un fichier exécutable. Mais
là un premier problème se pose. Après avoir écrit le code en C++, j’essaie de le
compiler sous Visual Studio mais celui ci ne reconnaît pas les objets Qt. J’ai donc
parcouru l’aide pour trouver la manipulation, et petit à petit j’ai trouvé les différentes
phases à effectuer. Voici la démarche à suivre :
Etape 1: Dans un éditeur de texte créer le fichier « nomprog.pro ». Celui ci donne les
indications pour créer un « Makefile ». Il doit avoir la forme suivante :
TEMPLATE = app
CONFIG += qt_warn_on release
HEADERS = header1.h, header2.h
…tous les fichiers *.h du projet.
SOURCES = source1.cpp, source2.cpp
…tous les fichiers sources du projet.
TARGET = nomprogFinal
… nom du programme après compilation.
DEPENDPATH = ./include
… répertoire où se trouvent les fichier *.h de Qt.
REQUIRES = large_config
Etape 2 : Créer un fichier makefile à partir du fichier *.pro dans le répertoire du projet.
Taper :
Tmake nomprog.pro –o Makefile
Etape 3: Créer l’exécutable.
Taper à partir du répertoire où se trouve le projet et le fichier Makefile :
nmake
Cette méthode est valable si on écrit nous même le fichier *.h comportant la classe
décrivant la fenêtre Windows que l’on veut créer. Cette technique étant assez
complexe, un éditeur Qt permet de mettre en forme notre fenêtre comme dans Visual
Basic, et sauve le projet en *.ui. Ce fichier n’est pas du code C++. Il faut donc passer
par les étapes suivantes :
13
Etapes préliminaires pour la compilation d’un exécutable.
Etape 1: Création du fichier *.h à partir du projet *.ui. Taper :
Uic –o prog.h projet.ui
Etape 2: Création du fichier *.cpp. Taper :
Uic –i prog.h –o prog.cpp projet.ui
Après avoir compilé un exemple, j’ai recherché grâce à Qt Designer, les éléments
que je vais incorporer dans mon programme. Voici la liste d’objets disponibles dans
la libraire Qt qui me serviront, mais d’autres objets seront sûrement ajoutés.
•
La liste déroulante servira pour le
choix de l’algorithme et le choix
des images.
•
La spin Box servira à donner une
valeur aux différents paramètres
de l’algorithme.
•
Les PushButton… pour confirmer
des commandes.
•
Les séparateurs… à votre
avis ☺ ?
•
Les zones de textes pour donner
des informations à l’utilisateur sur
la fonction du programme, la
signification des options…
Phase 3 :Mise en forme de l’interface.
Comme je l’ai expliqué, il existe un éditeur créant des projets Qt. Celui ci se présente
sous une forme proche de Visual Basic (Annexe 1) mais en moins complexe car
toute la partie programmation, liens entre les différents objets, n’est pas gérée.
Cette étape n’est donc pas très difficile à réaliser car il suffit de placer les objets au
bon endroit. De plus il reste à tout moment possible de modifier cette interface en
manipulant le fichier cpp créé comme nous l’avons vu précédemment. En effet dans
14
ce fichier se trouve le constructeur7 de la fenêtre, il est donc très facile de modifier
une ligne codant par exemple la taille ou la position d’un bouton.
Cependant il faut veiller à ce que la disposition des boutons et fenêtres reste
cohérente pour l’utilisateur.
Après plusieurs tentatives, et quelques conseils des utilisateurs potentiels, j’ai mis au
point une première interface. Celle-ci est classique, mais je l’espère compréhensible
par tous. Vous pouvez la voir en annexe 2.
Elle est composée de 3 parties principales et d’une barre centrale comportant
quelques indicateurs comme nous le verrons par la suite.
- la première partie, en haut à gauche, est une zone comprenant une liste
déroulante et une boite de texte. La liste déroulante servira à sélectionner un
algorithme et la boite de texte expliquera à quoi sert cet algorithme.
- la deuxième partie, en haut à droite, est une zone comportant tous les
paramètres et leur commentaire. Pour la compression fractale il y a trois
paramètres à rentrer : B, D, C.
- la dernière partie, en bas, est réservée à l’affichage des images que l’on charge
et des images obtenues. Au maximum il y aura trois images à afficher : 2 images
en entrée et 1 image en sortie.
- la barre centrale comporte des outils comme une ligne de texte affichant des
messages ou bien une barre de défilement indiquant l’avancement de
l’algorithme.
Nous verrons comment tous ces éléments interagissent dans la phase 5.
Phase 4 :Intégration de l’algorithme « compression fractale ».
A l’origine, les algorithmes développés par Xavier Marsault étaient écrits en C.
Mon but à donc été de les modifier pour les adapter à la syntaxe C++.
Cette tâche a été minime car il a juste fallu faire des modifications pour l’allocation, et
la libération de mémoire.
En effet la syntaxe est différente en C et C++ :
Ex :
entiers = (int *) malloc(sizeof(int) * 50 ) ;
en C.
int *entiers ; entiers = new int[50] ;
en C++.
Ensuite pour intégrer cet algorithme dans l’interface, il faut déclarer la fonction en
tant que méthode de la classe de l’application. Il ne peut pas venir d’un fichier *.h
externe car celui ci ne serait pas reconnu par l’interface. Il suffit donc de rajouter une
ligne dans le fichier .h de l’application.
7
Constructeur: en C++ c’est la fonction qui initialise, qui définit tous les paramètres d’un nouvel objet.
15
Phase 5 : Liaison des différents objets. Notion de SIGNAL / SLOT
Qt Designer est, comme nous l’avons vu, un programme permettant de mettre en
forme l’application que l’on veut créer. Pourtant cela n’est, dans 90% des cas, pas
suffisant pour créer une application complète car on a besoin de créer de nouvelles
fonctions, inexistantes dans Qt.
Cependant Qt Designer introduit une nouvelle notion : les SLOTS et les SIGNALS
qui permet de lier des objets.
Une application Qt est composée d’objets (boites de dialogue, boites de texte,
boutons…). Ce qui est intéressant c’est que, à chaque objet, sont associés des
SLOTS et des SIGNALS. Les SLOTS et les SIGNALS sont des méthodes
appartenant aux objets, mais qui sont utilisées seulement pour relier deux objets.
En fait on associe un SIGNAL d’un objet à un SLOT d’un ou d’autres objets. Dès
qu’un SIGNAL est activé tous les SLOTS que l’on avait préalablement liés sont
exécutés. Par exemple on peut lier un bouton « quit » avec la fonction exit(), donc
quand on appuiera sur le bouton l’application en cours s’arrêtera.
Il existe quelques SLOT et SIGNALS prédéfinis pour chaque objet mais
heureusement il nous est tout à fait possible d’en rajouter autant que l’on désire. Par
exemple, une SpinBox qui permet de choisir une valeur numérique, renvoie un
SIGNAL valueChanged() donc on peut vérifier, à chaque fois que l’on modifie la
valeur si celle ci est valable. Mais on aurait très bien pu créer un SIGNAL
valeurDepassee() qui se déclenche dès que la valeur est supérieure à 100.
Je vais donc décrire les différentes liaisons entre les SIGNALS et SLOTS de mon
application :
•
On a tout d’abord une liaison entre le SIGNAL clicked() du bouton QUIT et le
SLOT exit() de l’application. Le résultat est évident, quand on clique sur ce
bouton on sort du programme.
•
Ensuite nous avons un SIGNAL activated() de la liste déroulante du choix de
l’algorithme associé à 2 SLOTS : affiche_indic() et update_choix_algo(). Le
premier lit dans un fichier choisi selon l’algorithme, les informations le
concernant et les affiche dans la boite de texte de la première zone. Le
deuxième, selon l’algorithme choisi, active ou désactive les options
nécessaires.
•
Dans la deuxième zone, il est possible grâce à deux boites déroulantes de
sélectionner les images que l’on va traiter. J’ai donc associé leur SIGNAL
activated() à deux slots que j’ai créés : update_image1(), update_image2().
Ces SLOTS, dès que l’on choisit une image, les affichent dans les cadres
prédéfinis dans la troisième zone.
•
Dans la troisième zone, comme nous l’avons dit, nous affichons les images.
Cependant certaines peuvent être assez grandes (4092*4092 pixels), donc
elles ne tiennent pas en entier dans les cadres. C’est pourquoi j’ai rajouté des
ScrollBars. Il m’a donc fallu créer des de nouveaux SLOTS qui affichent
l’image selon la position des ScrollBars. (voir ci dessous).
16
Scroll Bar 1.
•
•
Scroll Bar 2.
J’ai ensuite créé des slots (verify_optb(), verify_optc() …) qui pour chaque
option vérifient si elle est correcte quand on la change.
Enfin j’ai créé un SLOT run_algo(), qui, quand on appuie sur le bouton Go se
situant dans la barre du milieu, exécute l’algorithme choisi.
Phase 6 :Remplissage de la boite déroulante des images.
Pour pouvoir utiliser un algorithme il faut au moins une image. Mais comment la
sélectionner ? J’ai pour cela créé une boite déroulante où se trouve tous les noms
des images disponibles dans un répertoire donné. Et c’est là que se trouvait la petite
difficulté.
Pour y parvenir j’ai utilisé de nouveaux objets que j’ai découvers dans la librairie QT.
Il s’agit de QfileInfo et Qdir principalement. Ces objets sont très pratiques. Qdir par
exemple permet de renvoyer le répertoire courant dans une chaîne de caractères. Il
suffit alors de rajouter le répertoire où se trouve les images(ex : .\images) ainsi on à
déjà le chemin. Ensuite grâce à QfileInfo et QfileInfoListe il nous est alors possible de
composer un filtre pour la sélection des fichiers(ex : « *.bmp ; *.jpg » ). Donc, tant
qu’il existe des fichiers de ce type, je les ajoute dans la boite déroulante. ( nomim1>insertItem( nomfichier ) ; ).
Phase 7 : Calcul du temps restant de l’algorithme en cours
Certains calculs, étant donnée la taille des images, peuvent devenir très longs. On
peut facilement atteindre 7 ou 8 jours de calcul pour la compression fractale par
exemple. Nous avons donc décidé d’intégrer dans l’interface une barre de défilement
indiquant le pourcentage de calcul effectué et une barre de message indiquant une
estimation en jours, heures, minutes, secondes du temps qu’il reste avant la fin de
17
l’application. Cela permet de rassurer l’utilisateur et de savoir combien de temps il va
attendre. Je vais expliquer leur réalisation :
Barre de défilement : Pour connaître le pourcentage de calcul effectué ce n’est pas
très complexe. L’algorithme est composé de trois boucles principales dans
lesquelles sont effectuées diverses opérations. Donc il est facile au départ de
connaître le nombre totale de boucles (nbBoucle1 * nbBoucle2 * nbBoucle3). Ainsi
dès que l’on en finit une on regarde où on est par rapport au total et on obtient
facilement le pourcentage.
Temps restant : Pour estimer le temps restant, cela est plus difficile. J’ai développé
une première méthode qui fonctionne correctement, que nous avons modifiée par la
suite pour obtenir des résultats plus précis.
Première méthode : Comme je l’ai dit, le programme de compression fractale
est développé autour de trois boucles. Cependant, par la nature de l’algorithme, le
temps d’une boucle pourra être totalement différent de celui de la boucle suivante.
On ne peut donc pas multiplier le nombre de boucles restantes par le temps écoulé
dans la première boucle par exemple. J’ai donc décidé de calculer le temps passé
dans la boucle de plus haut niveau à chaque tour pour la multiplier par le nombre de
boucles restantes. Donc il y a réactualisation de l’estimation à chaque fois que l’on
passe dans la boucle de plus haut niveau. Pour plus de précision, j’aurais réactualisé
à chaque boucle de plus bas niveau , mais cela prend un certain temps, donc le
programme en est ralenti, ce qui devient indésirable.
Deuxième méthode : Réalisée pour la plus grande partie par Xavier Marsault,
cette méthode s’appuie sur une évaluation du temps restant selon une prédiction. Au
début de l’algorithme, on évalue le temps moyen à passer dans une boucle ; celui ci
peut être totalement différent dans la boucle suivante. On fait donc apparaître un
modèle de prédiction pour les différentes valeurs du paramètres D (taille des blocs
Domain). Pour cela il faut connaître la complexité de l’algorithme en fonctions des
différents paramètres. Dès que l’on a ce modèle de prédiction (en fonction de D) on
fait la somme des multiplications entre le temps moyen, calculé au départ, et une
estimation du temps de la boucle en cours, donnée par le modèle trouvé
précédemment.
Nous obtenons des estimations un largement plus précises qu’avec la première
méthode.
18
C –Réalisation
Structure du programme
Le programme réalisé se compose en fait de deux fichiers. Le premier fichier,
« prog.h » a été créé lors de la première compilation pour passer du projet Qt au
fichier source en C ; il définit la classe de l’application créée, c’est à dire tous les
objets Qt présents dans l’interface, les prototypes de leurs fonctions ainsi que les
SIGNALS et les SLOTS. Cependant, au fur et à mesure du développement de
l’application, c’est à nous de rajouter les éléments souhaités.
Le second fichier est le programme proprement dit. Il contient la définition de toutes
les méthodes de l’application, des SIGNALS et SLOTS ainsi que le constructeur8 et
le destructeur9 de l’application. Dans la fonction main(), il y a seulement quelques
lignes pour appeler l’interface. Ensuite, tant que nous ne quittons pas, ce sont les
SIGNALS et SLOTS qui agissent. J’ai donc intégré les algorithmes de Xavier
Marsault en tant que SLOTS. Ainsi, pour les déclencher, il faudra appuyer sur le
bouton « go » qui enverra un SIGNAL. Bien sur, il faudra auparavant avoir rempli les
champs des options correctement. Le listing peut être fourni aux membres du jury
uniquement, sur simple demande à [email protected] (il contient près
de 2000 lignes de code).
Problèmes rencontrés
Le premier problème rencontré, a été la compilation d’un projet Qt en un
exécutable. Comme nous l’avons vu pour y parvenir, nous sommes obligés de
passer par plusieurs étapes dont la création de fichier Makefile. Ce n’est pas
instantané comme sous Visual C++ où il suffit de cliquer sur compiler. Heureusement
dans l’aide de Qt était décrite la création de petits programmes donc, la compilation
était abordée. Ainsi grâce à deux ou trois exemples, j’ai pu faire la synthèse de la
compilation d’un exécutable.
J’ai rencontré un deuxième problème durant la programmation. Après avoir choisi un
algorithme, nous devons choisir l’image ou les images que nous allons traiter. La
liste des images se trouve dans une ListeBox. Le problème a été de créer cette
liste. En effet le premier problème a été de lire les fichiers présents sur le disque
dans un certain répertoire, puis le second d’isoler les fichiers BMP10 pour les mettre
dans la ListeBox. Heureusement, un objet de Qt permet de « pointer » un fichier
dans un répertoire voulu. Il est alors plus facile de lire le nom du fichier et son
extension pour pouvoir l’ajouter dans la ListeBox. Cependant, l’utilisation de cet objet
n’est pas très aisée, c’est pourquoi l’aide de Qt reste indispensable.
Un troisième problème s’est posé à la fin. Quand nous avons testé des algorithmes
avec de grandes images, nous nous sommes rendu compte qu’il était impossible de
faire autre chose en même temps car l’application était alors cachée et ne
réapparaissait qu’à la fin du programme. Donc, quand on manipule de grandes
8
Constructeur: fonction permettant l’initialisation de tous les éléments de l’application (allocation de mémoire).
Destructeur: fonction qui termine l’application par la libération de mémoire.
10
BMP: extension des fichiers Bitmap. Les fichiers Bitmap sont des images Windows.
9
19
images, on ne peut plus savoir combien de temps il reste. Aucune solution n’a
encore été trouvée car cela reste un problème mineur, mais je chercherai une
solution après avoir terminé la deuxième phase. En attendant, nous exécutons le
programme sur une machine libre, c’est-à-dire totalement dédiée à ces calculs.
Fin de la partie 1.
20
2-Projet n°2. (création d’un moteur 3D)
A –Description
Origine du projet
La première phase servait à obtenir des modèles urbains originaux en 2 dimensions
et en 256 niveaux de gris. Cependant, l’objectif global de l’équipe est la réalisation de
modèles urbains en 3 dimensions. En effet, pour se rendre compte des points forts
ou des points faibles des modèles générés il est plus facile de les examiner dans un
environnement en 3 dimensions plutôt que 2. Il manquait donc un programme
réalisant la conversion entre les images 2D et les images 3D. C’est là le but de la
2eme phase.
Quel format 3D allons nous utiliser ?
Nous avons choisi de créer les fichiers 3D sous format VRML. Il existe plusieurs
raisons à cela. D’abord ce format est simple à comprendre et à mettre en œuvre
comme nous le verrons dans l’explication des phases. De plus celui ci est accessible
par tous (avec des « plugin » ), et son point fort est qu’il est interactif, c’est à dire
que l’on peut faire des rotations et des zooms sur les objets créés. Ainsi on est
capable d’analyser le modèle sous tous les angles en temps réel.
Bien sur, il existe sûrement des programmes proposant déjà de telles fonctions de
conversion, mais dans notre cas il faut prendre en compte certains paramètres, et les
ajuster à la demande précisée par X. Marsault. De plus cela fournit un sujet
intéressant de réflexion et d’analyse.
Cahier des charges
• Apprendre les bases du format VRML pour extruder des faces.
• Créer une petite interface pour choisir un fichier 2D et le convertir en 3D.
• Créer le fichier sous format VRML à partir de Visual C++.
• Simplifier autant que possible les fichiers 3D.
Champ d’investigation et contraintes
Pour la partie VRML, il est nécessaire de se renseigner soit dans des livres soit sur
Internet. En ce qui concerne la partie de la création de l’image en 3D il faut s’inspirer
d’algorithmes qui trouvent les contours des polygones dans une image ; pour cela je
vais chercher sur Internet et je demande à Xavier Marsault des renseignements.
Matériel et logiciels utilisés
Le matériel utilisé sera le même que pour la première partie, mais en ce qui concerne
le programme nous le compilerons maintenant avec Visual C++ car la partie
importante n’est pas l’interface mais le codage des algorithmes pour la détection de
contours, par exemple.
21
B -Analyses des besoins
Définition des phases
Phase 1 :
Apprentissage du format VRML pour pouvoir créer des fichiers 3D depuis Visual
C++. Description de la syntaxe de base.
Phase 2 :
Analyse préliminaire, pour savoir de quelle manière je vais sauvegarder les contours.
Phase 3 :
Recherche d’une technique de passage des polygones 2D en objets 3D.
Phase 4 :
Mise en œuvre de la 1ere méthode de la création d’un fichier VRML en C++ à partir
d’une image 2D. Pas de simplification.
Phase 5 :
2eme méthode : simplification des fichiers 2D (économie de mémoire, gain de
vitesse dans l’exploration du fichier 3D).
Conception des phases
Phase 1 : Apprentissage du format VRML
VRML est un langage de modélisation de scène 3d principalement destiné à être
exploité sur le Web.
Pour modéliser une scène, on fabrique des objets, on les positionne dans la scène,
on ajoute éventuellement des sources de lumière... Pour modéliser des objets en 3d,
on les décrit au moyen de formes de bases ou par des méthodes plus complexes, on
leur applique des matériaux, des textures ... Comme VRML est destiné au Web, il y a
en plus des analogies avec HTML, comme la possibilité d'ajouter des ancres (href en
HTML) : en cliquant sur un objet, on appelle alors un document qui peut être une
page Web ... La version 1.0 de VRML permet de décrire des scènes 3d statiques.
Avec VRML 2.0 la description de scènes animées devient possible. Cependant cela
ne nous intéresse pas dans notre cas, car nous ne voulons pas créer d’animations
mais juste observer une scène 3D créée.
Je vais donc expliquer la syntaxe que j’ai apprise grâce à des livres et tutoriaux.
• La première ligne d'un fichier VRML 1.0 doit toujours être la suivante:
#VRML V1.0 ascii.
• Pour écrire une ligne de commentaire, il faut la commencer par #.
22
•
•
Un fichier VRML est syntaxiquement composé de nœuds. Un nœud est un
mot clé suivit d'un champ entre accolades { ... }. Si le champ peut être vide,
les accolades doivent toujours être présentes.
Par convention, les repères spatiaux sont orthonormés directs, et l'utilisateur
fait face au plan (X,Y). Donc par défaut, on a l'axe X vers la droite, l'axe Y vers
le haut, et l'axe Z vers soi.
•
En VRML il existe différentes primitives de bases (objets 3D). Dans la version
1 on peut trouver : Cube, Sphère, Cylinder, Cône, mais pour nous cela n’est
pas intéressant car nous créerons nous même nos objets par extrusion
(Phase 4). Pour créer une de ces primitives, il faut taper le mot clé puis ouvrir
des accolades, écrire les paramètres de création et refermer les accolades.
Ex : Cube { width float height float depth float }.
•
Après avoir crée un objet, il est possible de le manipuler grâce à certains
nœuds comme : Rotation, Translation, Scale… La syntaxe est la même que
pour créer un objet. Mot clé { paramètres }. Ex : Translation { translation 0 0 0 }.
•
Cependant quand une scène contient plusieurs objets comment appliquer
une manipulation à un seul d’entre eux ? Pour cela il faut utiliser le nœud
« separator ».
Separator {
Translation { translation -2 0 0 }
Rotation { rotation 0 0 1 0.8 }
Scale { scaleFactor 1 2 1 }
Rotation { rotation 0 0 1 -0.8 }
Cube { width 2 }
}
Separator {
Translation { translation 2 0 0 }
Rotation { rotation 1 0 0 0.8 }
Scale { scaleFactor 1 0.5 1 }
Rotation { rotation 1 0 0 0.8 }
Cone { height 2 }
}
En effet, dans nos scènes 3D nous aurons des centaines d’objets, ainsi il sera
possible de déterminer l’apparence de chacun.
•
Enfin, le dernier nœud qui pourrait nous intéresser est le nœud « Material ».
Celui ci permet d’appliquer une couleur, une texture, de la réflexion et d’autres
paramètres à un objet. Grâce à ce nœud, nous pourrons définir différents
types d’objets, grâce à leur couleur et peut être des textures.
Material {
ambientColor 0.2 0.2 0.2
diffuseColor 0.8 0.8 0.8
specularColor 0 0 0
emissiveColor 0 0 0
shininess 0.2
transparency 0 }
23
En VRML il existe beaucoup d’autres nœuds, permettant de créer des scènes
complexes mais nous ne les voyons pas car nous n’en aurons pas besoin pour le
but que nous nous sommes fixé.
Phase 2 :Analyse préliminaire
Avant de commencer la recherche des contours dans une image, il faut définir ce
qu’on entend par contours. Dans une image il n’y a pas uniquement de beaux
polygones fermés qui ne se chevauchent pas. Il y a aussi des pixels isolés ou des
lignes de pixels formant parfois des figures complexes à analyser (exemple ci
dessous).
Comme dans la réalité, l’existence de tels bâtiments est peu probable, une analyse a
montrée qu’il était plus judicieux de prendre les pixels, non comme des points mais
comme des cubes. On obtient ainsi des formes plus réalistes que de simples faces.
Ainsi pour les polygones fermés on a toujours des polygones fermés, mais pour les
autres cas, voilà ce qui en résulte :
A partir de cette constatation, nous pouvons maintenant regarder comment s’effectue
le passage en 3D.
Phase 3 :Technique de passage du 2D en3D.
Comment peut-on, à partir d’une image 2D, créer une image 3D ?
Plusieurs techniques sont imaginables mais je vais expliquer le principe des deux
méthodes que j’ai utilisées. La première est la plus simple et la plus rapide à mettre
24
en œuvre mais elle est la plus « gourmande » en mémoire et temps de calcul. Elle ne
servira qu’à savoir si la création d’un fichier VRML à partir de Visual C++ est
efficace.
La seconde méthode est beaucoup plus complexe, mais elle réduit considérablement
la taille des fichiers 3D. Ainsi la navigation dans de grandes villes en 3D sera
envisageable. Je la mettrai en place une fois que la création d’un fichier VRML
depuis VC++ aura été testée.
Cependant pour chacune de ces méthodes, le principe de création d’un objet 3D
sera le même. Nous allons donc l’étudier dans un premier temps.
Le principe de l’extrusion de faces :
Une image 2D peut être assimilée à un ensemble de polygones (voir figure ci
dessous). En effet elle est constituée de groupes de pixels de même niveau de gris
(les polygones). Il faut donc trouver ces faces.
Pourquoi avons nous besoin de polygones ?
Comme nous l’avons vu le format VRML permet de créer des scènes 3D avec des
objets prédéfinis et paramétrables.
Cependant, plusieurs autres techniques
permettent de créer ses propres objets. Nous allons donc utiliser l’une d’entre elles :
l’extrusion. Pour cette technique, nous avons besoin de faces définies par des points
dans un espace 2D. Cet justement ce que l’on a dans une image !
Qu’est ce que l’extrusion ?
C’est en fait un procédé qui permet de passer d’une surface 2D en un objet 3D. La
surface de départ subit une translation par un vecteur de dimension 3. La surface de
départ n’est pas effacée et sert de base à l’objet 3D. La surface d’arrivée quant à elle
sert de couvercle (voir exemple ci dessous)
En VRML nous ferons simplement une extrusion sur l’axe des Y de tous les
polygones détectés.
25
Exemple d’extrusion d’un objet :
Comment sait-on de quelle hauteur on va extruder les faces ?
L’une des conditions de la réalisation de ce projet, était qu’on possédait uniquement
des images en NIVEAUX DE GRIS, c’est-à-dire qu’il n’y a pas de couleur mais
seulement différentes teintes de gris. Comme nous travaillons avec des images
codées sur 8 bits, il y a donc 2^8 soit 256 niveaux de gris. Ainsi il va nous être très
facile de savoir la hauteur de l’extrusion d’une face. Celle ci sera en fait
proportionnelle au niveau de gris de la face !
Voilà un petit exemple :
Le principe est là, passons maintenant à la mise en œuvre.
Phase 4 : Première méthode de conversion 2D-3D
Je pense que cette technique est la plus simple que l’on puisse envisager. Elle
consiste à assimiler chaque pixel de l’image à un polygone (un cube). C’est pour cela
que cette technique est très coûteuse en mémoire. En effet pour une image de base
(256 * 256 pixels soit environ 65500 pixels) qui ne sera pas la taille maximum, il y
aura dans le fichier 3D 65500*2 triangles = 131000 triangles pour les bases des
objets 3D fois (4 * 2), pour les quatre cotés de chaque cube, soit 1 048 000 triangles
au plus ! Ce nombre déborde les capacités des cartes graphiques actuelles.
26
Cependant grâce à cette méthode nous sommes sûr de ne pas perdre de détails.
Nous nous en servons donc, pour de petites images, pour tester et ajuster la
sauvegarde du fichier VRML depuis VC++ décrite ci dessous :
Sauvegarde du fichier VRML depuis VC++ :
Pour constituer le fichier 3D final, il faut passer par 3 étapes. Mais avant tout, au
début du programme nous ouvrons le fichier 3D en mode écriture-texte. La première
étape consiste à écrire l’entête (vu précédemment). La deuxième étape consiste à
écrire un nœud VRML que je n’ai pas mentionné avant, le nœud Viewpoint. Il permet
de placer une « caméra » qui sera le point de vue de départ lors de l’exploration.
Enfin la troisième étape inscrit dans le fichier VRML les points permettant de décrire
les polygones que l’on trouve dans un nœud « Shape ».
Phase 5 : Deuxième méthode de conversion, avec simplifications de l’image
Cette méthode est plus complexe que la première mais permet de décrire une même
scène avec beaucoup moins de données. On gagne ainsi de la mémoire et de la
rapidité dans l’exploration de la scène 3D.
Cette méthode repose sur la simplification de l’image 2D de départ. Comme je l’ai dit
précédemment, une image peut être assimilée à un ensemble de polygones. Le but
de la simplification la plus importante est de trouver ces polygones dans l’image.
Ainsi nous n’extruderons plus chaque pixel mais seulement la base de chaque
polygones codée par quelques pixels.
Ex : Extrusion d’un objet avec la première et la deuxième méthode ;
Comment trouver les polygones ?
Dans un premier temps il faut trouver les contours des polygones. Le reste n’est
d’aucune utilité car toutes les informations nécessaires à la création de l’objet 3D
(hauteur, forme du polygone) se trouvent sur les contours. Pour cela j’ai utilisé une
méthode qui permet de savoir combien de voisins de même couleur a un pixel
donné, c’est à dire de savoir si il est à l’intérieur du polygone ou non. De plus elle
permet de connaître leur disposition dans l’espace. Ces deux informations sont
retournées codées sous forme d’un entier.
27
Pour plus de clarté, j’ai créé deux fonctions, l’une qui teste les voisins horizontaux et
verticaux, l’autre les voisins en diagonale. On peut ainsi combiner les deux pour
savoir si un pixel est totalement entouré par des pixels de même couleur.
Voisins horizontaux et verticaux.
Voisins en diagonale.
La fonction 1 retourne 3, on sait alors
que le pixel testé est dans un coin
haut gauche.
La fonction 2 retourne 12.
Donc, pour chaque pixel de l’image, on teste s’il est entouré de voisins de même
couleur que lui. Si c’est le cas, on le supprime de l’image. On obtient donc à la fin de
ce premier traitement une image contenant juste les contours des polygones désirés.
Cette méthode est efficace pour toutes les images possibles. Dans le cas où un pixel
est isolé, celui ci ne sera alors pas effacé. Donc dans les phases suivantes il sera
considéré comme un polygone .
Dans un second temps, après avoir décelé tous les pixels de contour, il faut scanner
une deuxième fois l’image (de gauche à droite et du haut vers le bas) pour les
associer à un polygone. Dès que l’on tombe sur un pixel non blanc (sol = blanc), on
le sauvegarde dans une liste. A partir de là on cherche les pixels suivants du même
polygone. Pour sauver le contour en VRML, il faut rentrer des points définissant une
surface dans un certain ordre (sens des aiguilles d’une montre). J’ai donc instauré
une règle de parcours des pixels qui est la suivante :
• On teste le voisinage du pixel sur lequel on se trouve.
28
•
Si des voisins ont été trouvés, on va sur le premier pixel indiqué par l’ordre
suivant : haut, droite, bas, gauche. Cependant on ne peut pas aller dans le
sens inverse duquel on vient.
•
Au fur et à mesure que l’on teste les pixels on les sauvegarde dans un
tableau. On répète cette opération jusqu’à ce que la boucle soit bouclée.
•
Ensuite nous envoyons le tableau de pixels (qui contient les coordonnées de
chaque pixel du contour) à une fonction qui le traite pour sauvegarder le
polygone trouvé dans le fichier VRML.
•
Cette fonction extrait du tableau de pixels, ceux dont on se sert pour créer la
face à extruder en VRML. Ces pixels, si on observe bien (l’image ci dessus
par exemple) sont ceux qui sont dans un coin. C’est là qu’il y a un
changement de direction. En donnant ces points au VRML dans le bon ordre,
il créera automatiquement les segments reliant chaque point à son
successeur, donc on obtiendra bien une surface licite.
•
Cependant rappelons nous de l’analyse préliminaire pour trouver les contours.
Ceux ci ne sont pas définis par les pixels mais par leurs bords. Nous ne
rentrons donc pas directement leurs coordonnées. Il faut interpréter les
quelques cas envisageables. Exemple du coin haut gauche ci dessous :
29
•
Il ne reste plus qu’à indiquer la hauteur de l’extrusion de cette face. Celle ci
est fonction de la couleur du polygone.
Cette technique est efficace, mais laisse apparaître quelques petits problèmes,
par exemple lorsque l’on a des segments de droites formants des
embranchements mais aucune boucle. C’est pourquoi dans une seconde
analyse, et avec l’aide de Xavier Marsault j’ai modifié l’algorithme de parcours des
contours qui maintenant fonctionne correctement.
- Amélioration de la deuxième méthode -
Recherche des contours :
C’est cette phase qui a été changée. Nous l’avons vu dans certains cas le précédent
algorithme se bloquait, par exemple dans les lignes d’épaisseur de 1 pixel qui
forment des embranchements. Maintenant avec la nouvelle méthode ces cas sont
corrigés car l’algorithme sait revenir d’où il vient
Le parcours des contours a donc été modifié. Nous utilisons, pour nous déplacer, la
notation de Freeman, presque similaire à la méthode que j’ai utilisée en premier.
DIRECTION DE FREEMAN
La technique qui suit constitue une variante de celle de PAVLIDIS (1982). A chaque
fois que l’on se déplace on sauvegarde la direction D de laquelle on vient. Le
déplacement change et de : haut, droite, bas, gauche, devient D+2, D, D-2, D-4.
C’est à dire que si on arrive sur un pixel avec la direction 0, on test alors en premier
le voisin 2 puis le 0 le 6 et le 4. La condition d’arrêt étant de retomber sur le pixel de
départ. Dans les cas où l’on a une ligne de pixels, on repart en arrière sur les pixels
déjà testés mais comme nous prenons les contours en considérant un pixel comme
un cube, on traite le coté opposé du contour que l’on vient de tester.
A partir de là, la suite de l’algorithme (sauvegarde des polygones dans le fichier 3D..)
ne change pas. Nous rencontrons seulement quelques cas en plus à analyser en ce
qui concerne la création de contours à partir des lignes de un pixel de largeur.
Des essais sur plusieurs exemples ont montré l’efficacité de ce nouvel algorithme.
Fin de la partie 2.
30
C -Réalisation
Structure des programmes
Le programme de conversion est assez simple. Il est en fait constitué d’un unique
fichier c. Celui ci est composé des fonctions suivantes :
- voisinage4() qui renvoie le nombre et la disposition des voisins verticaux et
horizontaux d’un pixel d’une certaine couleur.
- voisinage8() qui est la même fonction que la précédente mais pour les voisins en
diagonales.
- SaveFace(), qui sauvegarde dans le fichier VRML une face trouvée.
- La fonction Main(), dans laquelle est initialisé le fichier VRML et dans laquelle se
déroule l’algorithme de détection des contours.
On a donc dans l’ordre :
1. initialisation du fichier VRML(écriture de l’entête)
2. tracé des contours de l’image.
3. parcours de l’image :
- détection d’un polygone
- sauvegarde du polygone
4. tant que l’on ne se trouve pas à la fin de l’image.
Problèmes rencontrés
L’analyse de l’image n’est pas un domaine facile à contrôler. J’ai pu le constater à
plusieurs reprises dans l’analyse et dans la programmation de cette phase. En effet,
bien qu’on pourrait penser le contraire (par exemple on peut se dire qu’un pixel est
négligeable parmis tous les autres), c’est un domaine dans lequel il est nécessaire
d’être précis. Il ne faut rien négliger.
Le premier problème a donc été de trouver une technique permettant d’obtenir les
contours. La première méthode que j’ai utilisée, assez complexe, permettait de
sauvegarder dans un tableau de faces chaque face que je rencontrais. Je faisais
donc simultanément recherche des contours et sauvegarde de la face trouvée. Cette
méthode fonctionnait bien mais nécessitait beaucoup de mémoire et était assez
longue. J’ai donc, après une analyse secondaire, opté pour une nouvelle méthode.
Celle-ci sépare la détection des contours et la sauvegarde du polygone. (méthode
expliquée plus haut). Pour cela, j’ai du analyser les nombreux schémas représentant
les différents cas possibles de contours que l’on pouvait trouver.
31
Cependant un nouveau problème se posait lors de la sauvegarde des polygones.
Comme je l’ai expliqué, il y a des cas de contours très difficiles à analyser, en
particulier les lignes d’épaisseur de 1 pixel qui ne se referment pas (ex ci dessous).
Dans ce cas, comme on assimile un pixel à un cube(1*1), il faut créer les contours de
cette ligne, ce qui nous donnera par exemple un mur d’épaisseur de 1 unité. Pour
des pixels isolés ou des lignes droites cela reste aisé mais quand on a des multiples
croisements par exemple, cela devient vite complexe. Une analyse secondaire a
donc permis de trouver un algorithme prenant en compte ces cas. Celui ci fonctionne
maintenant sans problèmes, même s’il est un peu plus complexe que le premier.
Fin de la partie 2.
32
IV- Conclusion
Mon stage, ayant pour but la réalisation d’outils pour la conception de modèles
urbains virtuels, s’est déroulé d’une manière très convenable. En effet l’équipe,
attachante, était là pour me conseiller en cas de besoin. Ainsi j’ai pu me rendre
compte, tout au long des 10 semaines, des différentes étapes nécessaires à la mise
en œuvre d’un projet. L’analyse y tient une part importante ; cependant les
méthodes apprises au cours de l’IUT ne m’ont apporté que peu d’aide. Je pense que
ces méthodes sont beaucoup trop générales et ne peuvent pas convenir tout le
temps du fait que l’informatique se répand dans une multitude de domaines. En ce
qui concerne la technique pure, je n’ai rencontré aucun problème. Je me rends
compte que l’enseignement que j’ai reçu m’a beaucoup aidé mais je pense que le
véritable moteur à la réalisation d’un projet est la motivation. Au final, je remets donc
à l’équipe du laboratoire deux programmes qui fonctionnent, et qui, pour l’instant, lui
conviennent.
En ce qui concerne l’intégration dans le laboratoire, celle-ci c’est très bien passée
peut-être du fait de la taille du laboratoire. L’équipe de chercheurs étant très amicale,
il n’y a eu aucun problème.
Cependant un laboratoire de recherche n’est pas une entreprise, et donc le travail a
effectuer ne se réalise pas de la même manière ni dans les mêmes conditions. Un
stage dans une vraie entreprise serait donc une bonne expérience.
33
V- Bibliographie
• VRML 2 Source Book.
Andréa L. Ames, David Nadeau, John Moreland
John Wiley & Sons, Inc
( Livre en anglais )
• Sébastien Marlier: Tutorial VRML 2, http://www.?
• Exemples VRML: http://www.multimania.com/grandm
• Informations sur Qt : http://trolltech.com/qt/
34
Je tiens à remercier sincèrement :
Toute l’équipe du laboratoire ARIA
En particulier mon maître de stage, Xavier Marsault pour son aide et sa
patience ainsi que Hervé Lequay pour m’avoir proposé ce stage.
Mr Baskurt,
Mr Alain Fournier pour ses conseils avisés tout au long de l’année.
Mon camarade Valère Forel pour ses renseignements.
35
VII- Annexes
ANNEXE 1
Qt Designer, permet de créer l’aspect graphique de l’ébauche de l’interface.
36
ANNEXE 2
L’interface après plusieurs essais.
37