Table des matières

1 Présentation 2 1.0.1 But du projet . . . . . . . . . . . . . . . . . . . . . . . 2 1.0.2 Méthode de travail . . . . . . . . . . . . . . . . . . . . 2 1.0.3 Objectifs atteints . . . . . . . . . . . . . . . . . . . . . 2 1.0.4 Structure des fichiers . . . . . . . . . . . . . . . . . . . 3 1.0.5 Structure des données . . . . . . . . . . . . . . . . . . 3 1.0.6 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . 5 1.0.7 Problèmes rencontrés et Solutions choisies . . . . . . . 6

Chapitre 1

Présentation

1.0.1 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 RenderWare 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 ^etre portable à des mondes sous-marins, marins et terrestres.

1.0.2 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 RenderWare 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.

1.0.3 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).

1.0.4 Structure des fichiers

Les principaux éléments qui composent les scènes graphiques de l’application sont les caméras et l’objet (ou plut^ot terrain) visualisé. Dans cette optique, le code source a été distribué en 3 parties principales :

• Interface : frontend.[ch] popup.[ch] Ces modules contiennent toutes les fonctions et procédures seulement liés à Motif.

• 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.

• RenderWare : cb_camera.[ch] cb_object.[ch] rw_camera.[ch] rw_object.[ch] viewer.[ch] Enfin, ces modules se raccrochent directement aux objets RenderWare et implémentent les callbacks et routines appelées par l’application et affectant ces m^emes objets.

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.

1.0.5 Structure des données

La librairie RenderWare 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 RenderWare . 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^ur 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 1.1).

Figure 1.1: Différence de repères

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.

Début
Si la camera recule
   alors
       la faire tourner de 180 degrés horizontalement
       pour qu'elle fasse face aux obstacle potentiels;
   finsi
Trouver le polygone le plus proche de la camera et face
à elle;
Calculer la distance qui le sépare de cette dernière;
Si la camera recule
   alors
       la faire tourner de - 180 degrés horizontalement
       pour qu'elle reprenne son sens initial;
finsi
Si la distance calculée est plus petite que celle dont
   on veut avancer
  alors
      Retourner Collision := VRAI;
  sinon
      Retourner Collision := FAUX
finsi
fin

Figure 1.2: algorithme de collision en rendu 3D

1.0.6 Algorithmes

Le plus complexe des algorithmes de ce projet est celui de gestion des collisions. Cependant, ce dernier est différent suivant que l’on utilise la caméra de visualisation 3D (figure 1.2) ou celle d’édition du terrain “2D” (figure 1.4) .

En ce qui concerne les autres algorithmes, il est interessant de voir celui qui permet d’eviter que les caméras ne sortent du terrain qu’elles visualisent (figure 1.5).

Il est toutefois évident qu’il est nécessaire pour mener a bien un déplacement de caméra que les deux algorithmes, collision et sortie de terrain soit

Figure 1.3: Principe d’évitement de collision en rendu 3D

combinés pour obtenir un résultat cohérent. L’organigramme des decisions de la figure 1.6 présente ce type de liaisons.

1.0.7 Problèmes rencontrés et Solutions choisies

Malheureusement, RenderWare impose pour implémenter ces types de tests des contraintes incontournables. La première est évidemment : comment se repérer dans le monde vis-à-vis des objets environnants. Cette librairie graphique offre deux fonctions permettant de le faire, mais de prime abord, une seule a été suffisante : RwPickScene. D’un clic sur un des polygones de la scène affichée par une caméra, on récupère un grand nombre de caractéristiques correspondantes (par exemple, le polygone en question, mais aussi le vertex le plus proche, la distance qui le sépare du clic...). Un paradoxe apparait alors. Avant de l’ennoncer, voyons une donnée imposée non pas par RenderWare , cette fois-ci, mais par toutes les librairies graphiques qui disposent de caméras. Pour afficher, on définit des plans de clipping (un "far" ainsi qu’un "near") qui sont, en résumé, les distances entre lesquelles la caméra est capable de distinguer des objets. Cependant, et ceci est à imputer à la version 1.3 de RenderWare , il n’est possible de fixer que la

Commentaire : Ne pas perdre de l'esprit que la camera est
           toujours perpendiculaire à son déplacement
Début
Commentaire : On fait en sorte que la caméra fasse face aux
           obstacles potentiels
Cas déplacement
nord  : Tourner la camera de 90 degrés horizontalement;
sud   : Tourner la camera de 90 degrés horizontalement;
est   : Tourner la camera de 90 degrés horizontalement;
        Tourner la camera de 90 degrés latéralement;
ouest : Tourner la camera de - 90 degrés horizontalement;
        Tourner la camera de - 90 degrés latéralement;
finCas
Trouver le polygone le plus proche de la camera et face à elle;
Calculer la distance qui le sépare de cette dernière;
Cas déplacement
nord  : Tourner la camera de - 90 degrés horizontalement;
sud   : Tourner la camera de - 90 degrés horizontalement;
est   : Tourner la camera de - 90 degrés latéralement;
        Tourner la camera de - 90 degrés horizontalement;
ouest : Tourner la camera de 90 degrés latéralement;
        Tourner la camera de 90 degrés horizontalement;
finCas
Si la distance calculée est plus petite que celle dont on veut
avancer,
alors
    Retourner Collision := VRAI;
sinon
    Retourner Collision := FAUX
finsi

fin

Figure 1.4: Algorithme d’évitement de collision en rendu 2D

Début
On récupère les points qui forment les deux angles inferieur
arrière et supèrieur avant de la bo^ıte englobante du terrain
pour connaitre les limites de celui-ci.
Cas Caméra
Camera 2D :
Si la distance qui sépare l'extrémité qu'atteint la
   caméra
   et
   que cette m^eme distance  est plus petite que celle
   dont on veut se déplacer
  alors
    On bloque la camera
  sinon
     On effectue le déplacement
Finsi
Caméra 3D :
On duplique la Caméra, on effectue le déplacement désiré,
Si plus rien n'est en dessous de ce cl^one, on est sorti
  alors
      On est sorti, la Camera 3D restera immobile
sinon
      On effectue le déplacement
Finsi
fin

Figure 1.5: Test de débordement du terrain visualisé distance à partir de laquelle la caméra n’est plus "aveugle". A ajouter à cela, il apparait que dans cette m^eme version, nous soyons contraints d’^etre légèrement astygmate. En effet, il est impossible de préciser que l’on veut repérer tout ce qui est à proximité immédiate. Voici donc notre paradoxe : Comment savoir que l’on est trop près d’une paroi si l’on ne voit pas cette m^eme paroi. Lors de déplacements rectilignes, ceci ne pose pas de problèmes (figure 1.3), puisqu’avant d’avancer, on cherche à savoir si l’on n’atterrira pas trop près ou au delà du décor. Cependant, si il vient à l’utilisateur l’idée de s’arr^eter , cette fois-ci, rien ne garanti que s’il fait tourner la caméra, elle ne se retrouvera pas nez collé au sol, ou en se placant au niveau des plans de clipping avec une distance objectif-sol plus petite que la valeur minimale autorisée par la caméra.

Pour régler ceci, il aurait été possible de maintenir les mouvements à une distance minimale et suffisante du sol. Inconvénient alors, obtenir des écartements trop grands, éloignant de la réalité.

Une autre solution possible, et c’est celle que nous avons retenu, est de tester une collision de déplacement m^eme lors des rotations statiques. Si un point qui n’est pas directement sous la caméra est déja trop près, celui qui y est l’est encore plus. La caméra prend alors un mouvement de balancier arrière plus proche, selon nous, de la réalité(figure 1.7).

Dans le cas de la caméra d’édition, le problème ne se pose pas, les déplacements sont uniquement transversaux et sans rotation.

Un dernier problème directement raccroché au mouvement est : quand faut-il s’arr^eter? Nous avons décidé d’emp^echer que l’on puisse sortir du terrain que l’on visualise. A cet effet, les approches on été différentes. La caméra 2D, de par son orthogonalité permanente avec le sol, ne pose pas de problème, puisqu’il suffit de tester sa position par rapport aux limites du relief. La difficulté apparait avec la caméra de rendu 3D. Comment se repérer par rapport aux bords. Là encore, une solution envisagée, et c’est celle pour laquelle nous avons opté, est de se repérer vis-à-vis du sol immédiatement au dessous. On duplique cette caméra en une autre, "cobaye" , on lui fait effectuer le déplacement prévu (avec test de collision, bien-s^ur) et on teste si à l’arrivée, elle ne se trouve pas dans le vide. Dans ce cas, on ne fait rien, sinon, rien n’emp^eche d’avancer.

Figure 1.6: Organigramme des décisions prises lors d’un ordre de déplacement 10 Figure 1.7: Mouvement de balancier lors de rotations statiques

11