%*
%* -------------------------------------------------------
%*
%* Projet de Maitrise - Annee 1996 - Generateur de terrain
%* Xavier AUGROS - Christophe BIGINI - David CHAPEAU
%*
%* Presentation
%* il s'agit en fait d'un petit resume
%* de la soutenance intermediaire 
%*
%* --------------------------------------------------------
%*

\chapter{Présentation}

\subsection{But du projet}
Le but de ce projet était, en tout premier lieu,  de développer une application
X11 / Motif, en s'appuyant sur la librairie graphique \RW de Criterion Software
et capable de visualiser et éditer des représentations de reliefs
réalistes. Pour cela, il nous était demandé, à partir des fonctionnalités de
rendu en 3 dimensions et en temps réel de cette librairie, de faire en sorte
que ce programme puisse être portable à des mondes sous-marins, marins et
terrestres.

\subsection{Méthode de travail}
La première action a été de séparer la partie code entre les 3 membres du
projet, c'est à dire, l'analyse syntaxique des fonctions mathématiques,
l'interfaçage avec Motif, et enfin la programmation \RW proprement dite, pour
tout relier lors de réunions hebdomadaires.
Par la suite, une coopération entre groupes de projets directement liés à cette
librairie s'est avérée nécessaire. En effet, il a été très fréquent, au cours
de son apprentissage, de se rendre compte qu'une nouvelle fonction pouvait à
elle seule effectuer le travail de toute une portion de code déjà écrite et
opérationnelle.

\subsection{Objectifs atteints}
Lors de ce travail, la majeure partie du cahier des charges a été
atteinte. Nous regrettons cependant un seul choix, celui de l'algorithme de
génération du prototype de terrain utilisé à l'ouverture de l'application,
lourd et mal adapté à l'édition des caractéristiques d'un point quelconque du
décor. Toutefois, ce dernier ayant été inspiré par la constitution des fichiers
d'objets livrés avec la librairie, il a semblé, au premier abord, le mieux
adapté.
Pour ce qui est des aspects positifs, ils sont nombreux. Il nous était imposé
qu'une caméra se déplace dans le décor ne heurte jamais la moindre partie de ce
dernier, et ce point important a été réussi. De plus, une vue de ``dessus'',
que nous avons injustement nommée ``vue 2D'' permet à tout moment de pratiquer
des modifications immédiatement répercutées sur une ``vue 3D''.
L'interface est entièrement interactive, surtout dédiée aux déplacement en
temps-réel, et à tout moment, l'utilisateur peut appliquer des textures
ponctuellement sur le relief qu'il aperçoit, tout comme modifier ce dernier à
l'aide de fonctions mathématiques de son choix (en respectant toutefois
certaines conditions liées au fait qu'on ne peut avoir de points situés à
l'infini par exemple).

\subsection{Structure des fichiers}

Les principaux éléments qui composent les scènes graphiques de
l'a\-ppli\-ca\-tion sont les caméras et l'objet (ou plutôt terrain)
visualisé. Dans cette optique, le code source a été distribué en 3 parties
principales :
\begin{itemize}
\item Interface : frontend.[ch] popup.[ch]\\
Ces modules contiennent toutes les fonctions et procédures seulement liés à
Motif.
\item Gestion mathématique : cb\_function.[ch] tree\_fct.[ch] analyse.yacc\\
Ces derniers concernent l'analyse et l'évaluation d'expression mathématique
avec utilisation d'arbre syntaxique.
\item \RW : cb\_camera.[ch] cb\_object.[ch] rw\_camera.[ch] rw\_object.[ch]\\
viewer.[ch]
Enfin, ces modules se raccrochent directement aux objets \RW et implémentent
les callbacks et routines appelées par l'application et affectant ces mêmes objets.
\end{itemize}

Enfin, 
Si l'on entre plus dans les détails, on s'aperçoit qu'il est nécessaire de posséder deux fichiers pour la gestion des caméras, et deux autres pour le terrain. La raison en est simple, à chaque fois, l'un propose les fonctions et procédures adéquates à l'entité, et l'autre les callbacks déclenchées par l'interface MOTIF.

\subsection{Structure des données}

La librairie \RW répondant à la norme C ANSI, la totalité de l'application à été codée à l'aide de ce langage. Vu le grand nombre de structures que cette librairie propose, il n'a nullement été nécessaire d'en créer de nouvelles.
Principalement, pour mener à bien notre travail, nous n'avons utilisé que des
de base de \RW. En tout et pour tout, il nous aura fallut, 2 caméras, un objet
(le terrain ) et une lumière ponctuelle,  le tout regroupé dans une scène, sans
bien-sûr oublier les textures, éléments essentiels à la réalisation du projet
du point de vue de l'édition.
Un problème se pose cependant, il s'agit des repères différent selon que l'on
se place par rapport à une caméra ou un objet. L'origine de ce problème réside
dans le fait que le repère spacial de la caméra la suit dans ses déplacements,
c'est à dire qu'elle en est toujours le centre et que de plus, l'axe des
profondeurs (Oz en l'occurence) est toujours orienté dans le sens où regarde
cette dernière; Ce qui le rend indirect par rapport au repère mathématique
standard (figure \ref{Diffrep}).
\includeps{camera.ps}{Différence de repères\label{Diffrep}}

Les fonctions et procédures concernant les caméras (les déplacements et rotations notamment) ont donc été codées de facon à ce que ces changements de signe des coordonnées et des angles soit transparents pour l'utilisateur.

% FIN de Presentation.tex
