\documentclass[a4paper, 12pt]{report}
\usepackage{latexsym}
\usepackage[latin1]{inputenc}
\usepackage{francais}
\begin{document}

\frenchspacing

\title{Modeleur 3D}
\author{Ghalleb ~Khelidj - Maîtrise MIME - INE 148895}
\date{Février 2001}
\maketitle

\begin{abstract}
Réalisation d'un modeleur 3D dans le cadre du cours de C++ du premier semestre
\end{abstract}

\tableofcontents

\chapter{Le cahier des charges.}


Pour cette première partie, le modeleur, il s'agit de réaliser un programme qui:

\begin{itemize}
\item soit capable de créer des objets en 3D à l'aide de 3 vues en 2D,
\item permette d'enregistrer l'objet ainsi créé,
\item puisse modifier des modèles pré-enregistrés.
\end{itemize}
    
L'utilisateur peut créer, enlever ou déplacer des points sur l'une des 3 vues proposées.
A partir de ces points, il peut fabriquer des facettes et en choisir la couleur.
La création de faces comportant plus de trois points est en développement mais ne fonctionne pas encore dans cette version du modeleur.

Une fois l'objet créé, il peut être sauvegardé pour être ensuite visualisé à l'aide du moteur 3D.

Après avoir exposé les choix techniques, dans la partie suivante, nous étudierons les différents modules qui composent le programme.



\chapter{Les choix techniques.}

  Il n'existe pas à l'heure actuelle de toolkit graphique C++ stable pour les systèmes Unix. Le portage de GTK+ en C++ (GTK-- --) ne l'est pas du tout; je l'ai appris à mes dépends.
  L'interface est donc écrite en C structuré objet. C'est à dire qu'à la place des classes, on trouve des structures qui incorporent des pointeurs sur fonction. 
De plus, GTK+ est un toolkit structuré objet très proche du C++.
  La gestion des fenêtres et des évènements est entièrement supportée par la librairie GDK et la plupart des variables non classiques sont issues de la Glib.

En ce qui concerne la mémoire, dès que l'on utilise du graphique, on en consomme beaucoup. Comme nous transportons les pixmaps via réseau, de Nickel jusqu'aux terminaux X, et que cela prend beaucoup de temps, l'utilisateur n'aurait pas une interface confortable sans les optimisations. La gestion des tailles de pixmap est donc minimale, nous verrons cela plus loin.


\chapter{L'interface.}
  
  Pour ne pas gaspiller de ressources matérielles et logicielles inutilement, les handlers sur les évènements sont réduits au strict minimum et l'on n'envoie que les données vraiment necessaires:

\begin{itemize}
\item Gestion du clic de la souris		
\item Gestion du mouvement de la souris quand au moins un bouton est appuyé, car sinon on réafficherait à chaque déplacement de la souris ce qui entrainerait une saturation du réseau. De plus, nous utilisons un ``\emph{motion\_hint\_mask}'' qui permet de ne récuperer les évènements que quand on a traité les précédents. Par exemple, quand on clique sur un bouton de la souris et qu'on la déplace, un évènement intervient, on le traite, et seulement aprés, un autre évènement peut intervenir. Si l'on utilisait pas ce masque, tous les evénements s'empileraient et l'on aurait beaucoup de traitement inutil. 
\item Réaffichage partiel des fenêtres si elles sont partiellement cachés. Pourquoi réafficher une fenêtre entière quand on a seulement besoin d'une partie? voila le but de cette stratégie (économiser le transport réseau).
\item Réaffichage total en cas d'ajout ou de modification d'élément. Quand on modifie l'objet, on doit bien sûr tout retraiter et tout réafficher
\end{itemize}


  L'interface est simple, conviviale et ne possède que quelques options:
\begin{itemize}
\item Le magnétisme de la grille
\item Le réglage de la taille de la grille
\end{itemize}
  
  De plus une barre d'outils est présente, qui permet de changer le mode d'édition en fonction des boutons de la souris. Par exemple, si l'on clique avec le bouton droit sur la case ajout de point, à l'avenir, le bouton droit servira à ajouter des points (ie. il aura été configuré dynamiquement). 
  


\chapter{La réalisation.}

   La réalisation de ce modeleur comporte trois parties:
   
   Développement d'interface utilisateur, c'est-à-dire ce que l'utilisateur a devant les yeux, donc les trois vues: coté, face, et dessus. Pour aider à la modélisation une grille est disponible. L'interface est la plus fonctionnelle possible, pour que même le novice puisse commencer à créer sans avoir à réfléchir. La prise en main est immédiate.

   
   Ensuite, la gestion complète des handlers et des callbacks, qui constitue le coeur du modeleur. A chaque clic de souris ou évènement externe au programme, on traite les informations en fonction des paramètres d'entrée. Nous ne traitons que les évenement qui sont utils et ceux qui permettent une amélioration des performances, comme le réaffichage partiel.
   
   La troisième partie qui fait directement le lien avec le moteur, c'est le format de fichier et donc le traitement d'entrée/sortie des données. Nous verrons un exemple dans le chapitre suivant. 

   
\chapter{Format de fichier.}
 
 Le fichier pour être lisible et simple à créer sans utiliser le modeleur, est au format ascii; c'est un format très simple qui permet à n'importe qui de le comprendre au premier coup d'oeil, sans connaître le programme. Le but est de pouvoir passer les fichiers créés dans le modeleur au moteur, c'est le lien direct entre les deux parties.
 
 Voyons l'exemple d'un cube :

\begin{verbatim}
<--- debut du fichier cube.3D --->

   Visu3D ASCII
   POINT 0
    -40.000000
    -40.000000
    40.000000
   POINT 1
    40.000000
    -40.000000
    40.000000
   POINT 2
    40.000000
    40.000000
    40.000000
   POINT 3
    -40.000000
    40.000000
    40.000000
   POINT 4
    -40.000000
    -40.000000
    -40.000000
   POINT 5
    40.000000
    -40.000000
    -40.000000
   POINT 6
    40.000000
    40.000000
    -40.000000
   POINT 7
    -40.000000
    40.000000
    -40.000000
   TRIANGLE 0
    POINTS
     2
     0
     1
    COULEURS
     100
     100
     100
   TRIANGLE 1
    POINTS
     3
     0
     2
    COULEURS
     100
     100
     100
   TRIANGLE 2
    POINTS
     7
     5
     4
    COULEURS
     100
     100
     100
   TRIANGLE 3
    POINTS
     6
     5
     7
    COULEURS
     100
     100
     100
     .
     .
     .
     . 
    .
   TRIANGLE 11
    POINTS
     4
     5
     0
    COULEURS
     100
     100
     100
   END Visu3D
<--- fin du fichier cube.3D --->   
\end{verbatim}

On s'aperçoit très bien du fonctionnement:
\begin{itemize}
\item D'abord une entête pour identifier le format,
\item La description des points avec leur coordonnées,
\item Puis chaque triangle constitué de points décrits précédemment, ainsi que les composantes en RVB de sa couleur.
\item Enfin, un identifiant de fin de fichier. 
\end{itemize}   

Une fois les modèles créés (en théorie et si l'on est patient, on peut modéliser n'importe quel forme), il ne nous reste plus qu'à les incorporer dans le moteur et les visualiser sous différents angles et dans différentes positions, voire même, les modifier si le résultat ne nous plaît pas.
   
\chapter{Le code source.}
\label{sec:Annexe}


\end{document}
 
   
   
   
