Modélisation de la vision humaine

Université Montpellier II UFR Sciences 2007 / 2008 FMIN 200 - TER Modélisation de la vision humaine MARIE Sylvain NANARD Marc Encadrants Auteurs CLERC Mickaël DELFOUR Jonathan JULIA Matthieu POTHIN Olivier

Remerciements Nous tenons à remercier nos encadrants, Monsieur Marc Nanard du LIRMM et Monsieur Sylvain Marie de NexGen, qui nous ont permis de réaliser ce projet. Nous voulons également remercier un de nos anciens camarades aujourd'hui à l'ens de Lyon. Modélisation de la vision humaine 2/144

Table des matières Table des matières 1 Introduction 6 1.1 Généralités....................................... 6 1.2 Public visé....................................... 6 1.3 Cahier des charges................................... 7 1.3.1 Les ltres.................................... 7 1.3.2 Répartition des tâches............................. 7 1.3.3 Diagramme de GANTT............................ 8 2 Organisation du projet 9 2.1 Organisation du travail................................. 9 2.1.1 Organisation interne.............................. 9 2.1.2 Organisation du développement........................ 9 2.2 Contraintes techniques................................. 10 2.2.1 Plate-forme................................... 10 2.3 Technologies....................................... 10 2.3.1 Logiciel d'édition de texte et langage..................... 10 2.3.2 Manipulation de scènes en 2 ou 3 dimensions................ 10 2.3.3 Interface Graphique.............................. 10 2.3.4 Documentation................................. 11 3 Analyse du projet 12 3.1 Open Scene Graph (OSG)............................... 12 3.1.1 Qu'est ce qu'un Scene Graph?........................ 12 3.1.2 Les pointeurs intelligents........................... 13 3.2 OpenGL......................................... 13 3.3 Le langage GLSL : OpenGL Shading Language................... 13 3.3.1 Un shader? Mais pourquoi?.......................... 13 3.3.2 Le Vertex Shader................................ 14 3.3.3 Le Fragment Shader.............................. 14 3.3.4 Les types.................................... 15 3.3.5 Les qualicateurs : attribute, uniform, varying............... 15 3.4 Liaison GLSL-OSG................................... 16 3.4.1 Le glshader................................... 16 3.4.2 Le glprogram.................................. 16 3.4.3 La liaison.................................... 16 3.5 Petit imprécis sur la physiologie de l' il....................... 16 3.5.1 Rétine...................................... 16 Modélisation de la vision humaine 3/144

Table des matières 3.5.2 Cristallin & Pupille.............................. 17 3.5.3 Champ de vision................................ 18 4 Développement 19 4.1 Petit imprécis sur la modélisation de la vision humaine avec OpenSceneGraph, OpenGL et le GLSL.................................. 19 4.1.1 Render To Texture............................... 19 4.2 Modele-Vue-Controleur................................. 20 4.2.1 Modèle..................................... 20 4.2.2 Vue....................................... 20 4.2.3 Controleur................................... 21 4.3 Flou Gaussien...................................... 21 4.3.1 Première Approche............................... 22 4.3.2 Premiers Résultats............................... 23 4.3.3 Solutions.................................... 23 4.3.4 Les phénomènes d'accomodation....................... 23 4.4 La projection sphérique................................ 26 4.4.1 La projection non linéaire........................... 26 4.4.2 L'assemblage de projections non linéaires.................. 29 5 Manuel d'utilisation 35 6 Perspectives et conclusions 36 6.1 Perspectives....................................... 36 6.2 Accommodation..................................... 36 6.2.1 Evolution possible............................... 36 6.3 Conclusions....................................... 37 6.3.1 Fonctionnement de l'application....................... 37 6.3.2 Fonctionnement du groupe de travail..................... 37 6.3.3 Problèmes rencontrés............................. 37 6.3.4 Notre sentiment sur ce projet......................... 37 A Images 39 B Documents d'analyse 43 C Compte rendus de séances 50 C.1 Séance 1......................................... 50 C.2 Séance 2......................................... 51 C.3 Séance 3......................................... 51 C.4 Séance 4......................................... 51 C.5 Séance 5......................................... 51 C.6 Séance 6......................................... 51 C.7 Séance 7......................................... 52 D Organigrammes 53 Modélisation de la vision humaine 4/144

Table des matières E Bibliographie 56 E.1 OpenGL......................................... 56 E.2 OpenGL Shaders.................................... 56 E.3 OpenSceneGraph.................................... 56 E.4 Vision humaine et couleurs.............................. 57 E.5 Physiologie de L'oeil.................................. 57 F Documentation 58 Modélisation de la vision humaine 5/144

Chapitre 1 : Introduction Chapitre 1 Introduction 1.1 Généralités Aujourd'hui, que ce soit dans les jeux vidéos ou dans les simulateurs, la modélisation de la vision humaine n'est pas, ou peu faite. Le problème ne se pose pas pour les premiers, car une modélisation dèle de la vision humaine serait restrictive au niveau de la jouabilité. En revanche, dans les simulations de l'être humain pour la conception de postes de travail (poste d'ouvrier dans une usine, poste de pilotage d'un avion), ou en situation réelle (automobiliste), les simulateurs ne tiennent en général pas compte d'éléments tels que la profondeur de champ, les déformations à la périphérie du champ de vision ou encore d'une éventuelle pathologie, ce qui pose problème dans la mesure où cela peut entraîner une situation radicalement diérente de celle prévue par le logiciel. 1.2 Public visé Ce genre d'application peut se voir utilisée dans plusieurs domaines. Cette application a pour nalité d'être intégrée au logiciel existant de la société canadienne NexGen Ergonomics 1. NexGen Ergonomics est un leader dans le domaine des logiciels d'instrumentations utilisés pour étudier l'ergonomie, la biomécanique,... Leurs produits sont utilisés dans un large panel d'organisations mondiales : les universités, compagnies d'assurances, agences gouvernementales et divers consultants. Notre application apportera un côté réel à une partie de leur application. Par exemple, dans leur logiciel la vision est actuellement représentée par un trait qui indique si l'on voit ou pas. Il existe simplement deux états distincts : objet visible ou non visible. Cet exemple permet d'expliquer la nalité de notre développement. L'objet pourra être nettement visible, perceptible, ou car en arrière plan, non visible... Il permettra d'améliorer une application existante an de la rendre complète et proche de la réalité. Pour réaliser ce genre d'application, nous avons besoin de connaître un minimum la physiologie de l' il. 1 http ://www.nexgenergo.com Modélisation de la vision humaine 6/144

Chapitre 1 : Introduction 1.3 Cahier des charges Pour modéliser le plus dèlement la vision humaine, notre logiciel prendra en entrée une image et appliquera diérents ltres sur celle-ci an de faire apparaître ce que verrait réellement une personne. Voici une liste des principaux ltres que nous allons réaliser suivi de la manière dont nous nous sommes répartit les tâches. 1.3.1 Les ltres Pour réaliser notre objectif nous avons introduit la notion de ltre. Voici la dénition d'un ltre tirée de wikipédia : L'action du ltre consiste à retenir, supprimer, rediriger ou modier les éléments indésirables du ux et, à en laisser passer librement les éléments utiles. Dans notre projet, un ltre sera donc un algorithme permettant de passer d'un état à un autre en enlevant, modiant ou ajoutant des eets. 1. Tâche de Mariotte : Le ltre devra simuler la reconstruction de la zone non visible par l' il. 2. Filtres géométriques : (a) Champ de vision : Ce ltre devra cacher ce qui n'est pas visible par l' il. 3. Filtres rétiniens : (a) Profondeur de champ : La modélisation de la profondeur de champ consiste à rendre ou toutes les choses qui ne sont pas à la distance d'accommodation de l' il. (b) Intensité lumineuse : Comment s'adapte la rétine suivant qu'il y ait beaucoup de lumière ou très peu? (c) Projection sphérique : Consiste à étirer fortement l'image au centre et pas du tout ou très peu sur les côtés. (d) Projection en perspective (e) Vision périphérique : C'est la vision de ce que l'on voit ou, vision qui détecte les mouvements. (f) Perception des couleurs et du contraste 1.3.2 Répartition des tâches Le sujet se divise en deux parties, comprendre la vision humaine et la modéliser. La première partie est essentielle pour la suite du sujet, c'est pourquoi nous devons tous nous documenter abondamment sur ce sujet an de le maîtriser. Pour la partie modélisation, la répartition des tâches se fera en fonction des forces et faiblesses de chacun. Nous avons fait des estimations en durée sur le travail à faire sachant que nous disposons à ce jour d'environ trois mois. Le développement étant itératif, les mises à jour et modules supplémentaires seront nombreux. Nous avons choisit d'utiliser un framework Décorateur an de pouvoir ajouter les ltres à l'image. Notre connaissance en modélisation 2D/3D étant légère, il nous est dicile d'estimer exactement la durée que nous passerons par module. Modélisation de la vision humaine 7/144

Chapitre 1 : Introduction Suite aux premières réunions avec nos tuteurs, nous avons deux ltres à créer, et ne connaissant encore pas trop les bibliothèques, nous avons fait deux groupes de deux an de travailler en extrême programming. Le premier ltre consiste à reproduire le cercle noir de l' il que l'on ne perçoit pas (tâche de Mariotte). Cette zone aveugle se positionne au centre de l' il, et n'est pas perceptible lorsque nous regardons un objet. Un algorithme sera donc établit an d'en reproduire au mieux les caractéristiques. Pour l'instant, l'idée sommaire est de faire la moyenne des couleurs du cercle entourant la tâche aveugle et de reproduire ces couleurs vers l'intérieur. Le deuxième a pour objectif de reproduire les zones de ou. Ces zones de ou apparaissent en arrière plan lorsque nous regardons un objet en premier plan. Pour obtenir une première idée de l'application, nous nirons par déformer l'image rendue an d'en obtenir une vision proche de notre vue. Nous allierons au mieux vue planaire et sphérique an d'obtenir un dosage sans déformation importante et avec un rendu très proche de notre vue. Ces paramètres seront réglables via l'interface mise en place. Ensuite nous ferons diérents ltres sur la déformation, le champ de vision, la profondeur de champ, etc. Tous ces ltres sont décrits dans le chapitre précédent. Nous espérons ces étapes largement terminées pour n mars. Nous souhaitons reproduire les eets de persistance rétinienne que nous pouvons rencontrer lorsque nous regardons un point très lumineux comme le soleil, puis basculons dans une zone avec un éclairage normal. Ces eets temporels sont très important au niveau de la vision humaine. Une autre application serait de voir comment l' il s'habitue à une zone sombre (nuit noire). Est-ce que celui-ci s'adapte au noir? Si le temps nous l'autorise, nous implémenterons toutes sortes d'algorithmes permettant d'améliorer notre rendu visuel, d'appliquer d'autres ltres (vision nocturne, etc), de reproduire certaines maladies de l' il (glaucome, daltonisme, etc). Les applications sont multiples et variées. Nous préférons privilégier des modules de qualité à la quantité. 1.3.3 Diagramme de GANTT (cf. gure en page 55). Modélisation de la vision humaine 8/144

Chapitre 2 : Organisation du projet Chapitre 2 Organisation du projet 2.1 Organisation du travail Notre groupe de travail est constitué de 4 personnes plus nos 2 encadrants. Nous nous sommes réunis avec M. Nanard toutes les semaines sauf lorsque nous avions des empêchements, an de vérier l'avancement du projet et d'exposer de nouvelles idées quand à la direction que devait prendre le développement de l'application. Lors de nos diérents réunions nous avons écrit des comptes rendus que vous pouvez consulter en page 50. 2.1.1 Organisation interne An de faciliter la communication entre les membres du groupe, nous avons mis en place un forum 1. Les courriers électroniques, les applications d'instant messaging (Skype, MSN,...), et accessoirement VNC ont été des méthodes de communications annexes entre les membres du groupe. Nous avons utilisé un outil de versionnage an de se partager les sources. Cet outil de versionnage a été utilisé en combinaison avec un système de gestion de billets via Trac 2 permettant d'assigner des tâches. 2.1.2 Organisation du développement Nous avons décidé d'utiliser le pattern Décorateur dont nous expliciterons les détails dans la partie Développement. Nous avons tout d'abord créé deux sous groupes, un travaillant sur la tâche de Mariotte, l'autre sur l'accommodation. Puis, comme la tâche de Mariotte n'était qu'une étape préliminaire à la découverte du traitement d'images, le groupe qui faisait la tâche de Mariotte s'est attaché à réaliser un ltre pour la projection sphérique. Une fois que ces deux ltres furent terminés, nous avons décidé de nous attacher au débuggage et à l'optimisation de l'application an de traquer les éventuelles erreurs de programmation, bugs et autres fuites de mémoire. 1 http ://vision.frbb.net 2 http ://trac2.assembla.com/vision Modélisation de la vision humaine 9/144

Chapitre 2 : Organisation du projet 2.2 Contraintes techniques 2.2.1 Plate-forme Les étapes du développement se feront en majeure partie sur Windows mais l'application ayant pour but nal d'être intégrée à un logiciel déjà existant, nous devons nous assurer qu'elle sera portable. Nous réaliserons donc cette application de telle sorte qu'elle soit exécutable pour la majeure partie des plates-formes (Windows, Unix, MAC). Nous pourrons fournir si besoin avec la version nale, une version compilée en 64 bits. 2.3 Technologies 2.3.1 Logiciel d'édition de texte et langage Le développement sera eectué en C++ et OpenGL Shader Language (GLSL), nous utiliserons l'ide Microsoft Visual Studio qui ore un puissant débuggeur. GLSL est le langage de programmation des pipelines des cartes graphiques 3D intégrées à OpenGL, cela permet de travailler directement sur le processeur graphique et notamment sur les Pixels Shaders et sur les Vertex Shaders (cf. gure en page 40). Les Fragment Shaders sont des programmes de transformation que nous pouvons appliquer à un pixel, essentiellement liés aux calculs des couleurs. Ces calculs sont eectués directement par le processeur graphique (GPU) ce qui permet de décharger le processeur (CPU). Les Vertex shaders sont des programmes également eectués par le GPU, ils s'occupent essentiellement des transformations géométriques des objets (changement de taille, rotation, translation,...) en agissant sur les attributs des vertex (sommets du triangle). 2.3.2 Manipulation de scènes en 2 ou 3 dimensions Nous utiliserons l'api OpenSceneGraph 3. OpenSceneGraph est un toolkit OpenSource, multi plate-forme pour le développement des applications graphiques de haute performance telles que des simulateurs de vol, des jeux, la réalité virtuelle et la visualisation scientique. Basé autour du concept d'un SceneGraph, il fournit un framework sur OpenGL 4 permettant au programmeur de s'abstraire de la couche bas-niveau d'opengl ainsi que d'optimiser les appels graphiques (cf. gure en page 41). Un SceneGraph ou Graphe de Scène en français, est une structure générale de données utilisée communément par les outils de modélisation 3D et les jeux vidéo actuels. Un graphe de scène est une collection de n uds renfermée dans un graphe ou une structure d'arbre. Un n ud peut avoir plusieurs parents et un parent plusieurs enfants ; ceci est très important car lorsque qu'une opération est créée sur un parent, celle-ci est propagée à tout le groupe de n uds ls. Dans notre programme, OpenSceneGraph va donc nous servir à eectuer ces opérations sur des groupes d'objets. OpenSceneGraph possède plusieurs avantages, outre l'abstraction du bas-niveau d'opengl, il est gratuit et portable. 2.3.3 Interface Graphique Une interface graphique sera créée en wxwidget 5, permettant de visionner, manipuler et régler les paramètres de l'application. Utilisant des librairies open source portables, la licence de 3 http ://www.openscenegraph.org 4 http ://www.opengl.org 5 http ://www.wxwidgets.org Modélisation de la vision humaine 10/144

Chapitre 2 : Organisation du projet l'application sera libre. 2.3.4 Documentation Une documentation de l'application sera générée au format Doxygen 6, le code sera donc commenté avec un style proche de la javadoc. Voici une petite explication de Doxygen tirée de wikipédia : Doxygen est un logiciel informatique libre permettant de créer de la documentation à partir du code source d'un programme. Pour cela, il tient compte de la grammaire du langage dans lequel est écrit le code source, ainsi que des commentaires s'ils sont écrits dans un format particulier. 6 http ://www.stack.nl/ dimitri/doxygen Modélisation de la vision humaine 11/144

Chapitre 3 : Analyse du projet Chapitre 3 Analyse du projet Nous développerons dans cette partie notre analyse detaillée du sujet qui comprend en grande partie la compréhension des outils de développement que sont OpenSceneGraph, OpenGl et le GLSL d'une part, et d'autre part les mécanismes inhérents à la physiologie de l' il humain. 3.1 Open Scene Graph (OSG) Commençons par étudier les termes d'openscenegraph avant d'expliquer les bases. 3.1.1 Qu'est ce qu'un Scene Graph? L'équivalent français serait un graphe de scène. Voici la dénition tirée de Wikipédia : Un graphe de scène est une structure générale de données utilisée communément par les outils de modélisation 3D et les jeux vidéos actuels. Le graphe de scène structure de manière logique la représentation spatiale d'une scène graphique. La dénition d'un graphe de scène est oue, puisque les programmeurs qui implémentent les graphes de scènes dans les applications, plus particulièrement dans l'industrie du jeu vidéo, reprennent les principes généraux et les adaptent à leurs besoins particuliers. D'une manière générale, un graphe de scène est une collection de n uds renfermée dans un graphe ou une structure d'arbre. Ceci signie qu'un n ud peut avoir plusieurs enfants. Ainsi, un eet appliqué sur un n ud se répercute sur ces descendants, ce qui permet de propager l'opération à un groupe de n uds. Dans de nombreux programmes, l'utilisation typique vise à appliquer une transformation géométrique à un groupe d'objets. L'idée principale est qu'une scène est décomposée en plusieurs parties, qui peuvent être liées. D'un point de vue mathématiques, un graphe de scène est un graphe orienté acyclique qui établit une hiérarchie entre les n uds qui la composent. Un n ud dans OpenSceneGraph est représenté par la classe osg : :Node. Même si c'est techniquement possible (niveau langage) d'instancier un n ud, il n'est pas de très grande utilité de le faire. Pour cela, il est intéressant d'étudier les classes qui héritent de osg : :Node. Les classes lles sont nombreuses, ici nous verrons les classes osg : :Geode et osg : :Group. Les objets qui peuvent être graphiquement représentés sont des instances de osg : :Drawable. Mais les osg : :Drawable ne sont pas des n uds, on ne peut pas les attacher directement au graphe de scène : il est nécessaire d'utiliser un osg : :Geode pour lier l'objet au graphe. Cependant, tous les n uds d'un graphe de scène ne peuvent pas avoir des n uds comme ls. En eet, il n'est possible d'ajouter des ls à un n ud que s'ils sont instances de osg : :Group ou d'une de ses sous classes. Modélisation de la vision humaine 12/144

Chapitre 3 : Analyse du projet Maintenant, pour gérer tous ces objets, il est nécessaire de disposer d'une mémoire permettant de créer ces ressources. OpenSceneGraph intègre une gestion de pointeurs référencés que nous allons expliciter. 3.1.2 Les pointeurs intelligents Une mauvaise gestion des ressources mémoires engendre des fuites mémoires et une forte utilisation de mémoire par l'application. Le but est de détruire les pointeurs dès qu'ils ne sont plus utilisés. Par dénition, une ressource mémoire est quelque chose qui doit être alloué avant utilisation et désalloué lorsque l'utilisation est terminée. Dans un graphe de scène, une ressource ne doit pas être désallouée tant qu'il existe d'autres références vers cet objet (lorsqu'un n ud est attaché à deux parents par exemple). Ainsi, le principe d'un pointeur référencé met en jeu un compteur interne associé à chaque objet qui représente le nombre de références pointant vers cet objet. Plus précisemment, les objets qui ont ce compteur intégré sont les instances de classes qui héritent de la classe osg : :Referenced. La ressource sera donc détruite lorsque ce compteur vaudra zéro. Le mot 'intelligent' entre alors en action : ce n'est pas aux programmeurs de gérer ces compteurs. En OpenSceneGraph, ces pointeurs intelligents sont implémentés comme une classe template nommée osg : :ref_ptr<t>. Ces bases acquises, il est alors possible de commencer à utiliser OpenSceneGraph. 3.2 OpenGL OpenGL est le moteur graphique utilisé par OpenSceneGraph pour acher une scène. Notre connaissance en OpenGL est intimement liée à celle que nous avons d'openscenegraph. OpenSceneGraph permet d'abstraire la couche bas niveau d'opengl, ainsi une méthode d'openscenegraph correspond à une autre méthode dans OpenGL, voire à un rassemblement de plusieurs méthodes. 3.3 Le langage GLSL : OpenGL Shading Language Comme nous l'avons présenté dans les premières parties de ce rapport, GLSL est un langage permettant la programmation par le processeur graphique de scènes OpenGL. Il a été développé par 3D Labs et approuvé par l'arb (Architecture Review Board), l'organisme chargé de la standardisation d'opengl. La programmation de notre processeur graphique (que nous appellerons GPU par la suite) se pratique au moyen de deux éléments : le vertex shader et le fragment shader. Les shaders sont des chaînes de caractère que l'on peut écrire comme un programme en C (avec les méthodes inhérantes aux shaders évidemment). Un vertex shader est un programme qui va agir directement sur les sommets de la scène, quand au fragment, il va agir sur tous les pixels de la scène. Nous parlerons tout le long de fragment shader et non de pixel shader, car les fragment sont propres à OpenGL tandis que les pixels sont propres à Direct3D. 3.3.1 Un shader? Mais pourquoi? L'utilisation des shaders vient entre autres du fait que certains de nos ltres vont essentiellement jouer sur les eets de lumières et sur les couleurs de la scène. Or il s'agit typiquement Modélisation de la vision humaine 13/144

Chapitre 3 : Analyse du projet du type d'opérations que l'on va pouvoir réaliser en utilisant le processeur graphique. Améliorer le réalisme d'un rendu, rajouter des eets de ou ou d'antialiasing (anticrénelage) sont un avant-goût des possibilités qu'orent un shader. 3.3.2 Le Vertex Shader Le processeur vertex est une unité programmable qui opère sur les valeurs et données associées aux vertex en entrée. Les vertex shaders sont exécutés sur ce processeur. Voici quelques opérations réalisables depuis ce processeur : transformation sur les vertex, transformation des normales et normalisation de vecteurs, génération/transformation de coordonnées de textures, éclairage. Entrée Voici une liste non exhaustive des variables d'entrée d'un vertex shader. 1. gl_vertex : Position du sommet. 2. gl_color : Couleur du sommet. 3. gl_normal : Normale du sommet. 4. gl_multitexcoordx : Coordonnées de l'unité de texture x. 5. gl_secondarycolor : Couleur secondaire du sommet. 6. gl_fogcooord : Coordonnées du brouillard. Ces variables sont en entrées, c'est à dire, qu'à partir du moment où nous sommes dans un vertex shader, nous pouvons les utiliser sans aucune autre déclaration, OpenGL nous les fournit. Cependant, lorsque nous écrivons un vertex shader, nous ne sommes pas forcés de les utiliser. Sortie Voici une liste non exhaustive des variables de sortie d'un vertex shader. Ces variables modient directement les attributs du sommet de la scène. 1. gl_position : Position en coordonnées écran du sommet. 2. gl_frontcolor : Couleur du côté avant de la face à laquelle est rattaché le sommet. 3. gl_pointsize : Taille du point du sommet. Les variables de sorties sont évidemment diérentes des variables d'entrées, cependant il y a une variable qui doit être forcément aectée sinon le vertex shader est invalide : gl_position. 3.3.3 Le Fragment Shader Ce type de shader est exécuté sur le 'fragment processor'. Le 'fragment processor' est une unité programmable qui opère sur les valeurs et données associées aux fragments en entrée. Voici quelques opérations réalisables depuis ce processeur : opération sur des valeurs interpolées, accès aux textures, brouillard (fog), opération sur les couleurs, zoom sur pixel, redimensionnement, bias, convolution... Un fragment shader produit des valeurs de sorties basées sur les valeurs passées en entrée. Modélisation de la vision humaine 14/144

Chapitre 3 : Analyse du projet Entrée Voici une liste non exhaustive des variables d'entrée d'un fragment shader. 1. gl_fragcoord : Coordonnées écran du pixel. 2. gl_color : Couleur du pixel. Ces variables d'entrées sont utilisables de la même façon que celles du vertex shader. Sortie Voici une liste non exhaustive des variables de sortie d'un fragment shader. Ces variables modient directement les attributs du pixel de la scène. 1. gl_fragcolor : Couleur nale du pixel. 2. gl_fragdepth : Profondeur du pixel dans le buer de profondeur (depth buer). A la diérence d'un vertex, on ne peut pas modier la position à l'écran du pixel via le fragment shader, cependant la possibilité de pouvoir modier la couleur et la transparence de chaque pixel d'une scène constitue une force remarquable pour la gestion 'microscopique' d'une scène. 3.3.4 Les types Comme chaque langage, le GLSL possède des types et des fonctions prédénies qui lui sont propres même s'il a tendance à ressembler fortement au C. Ce langage procédural de haut niveau est riche en types : il inclue, outre les types hérités du C, des vecteurs et des matrices qui permettent de rendre le code plus concis pour des opérations 3D graphiques. Nous ne ferons pas un listing complet de ces types et fonctions mais en voici quelques unes comme les vec2, vec3, vec4 qui sont des vecteurs de 2 à 4 éléments, sampler2d, sampler3d qui sont des textures à 2 ou 3 dimensions. Pour comparer des vecteurs il existe des fonctions comme lessthan, equal ou greaterthan, pour lire dans les sampler2d les couleurs d'un pixel par exemple, il existe la fonction texture*d. 3.3.5 Les qualicateurs : attribute, uniform, varying Ces trois qualicateurs sont très importants, ils permettent au programme GLSL de récuperer des variables du programme principal, mais également aux vertex shader de passer des variables aux fragment shaders. attribute Une variable qualiée attribute est une variable qui peut être uniquement lue par le vertex shader. uniform Une variable qualiée uniform dans le code d'un vertex et/ou d'un fragment shader est une variable aectée par le programme principal sur le processeur (CPU) que pourront lire les vertex et fragment shaders. Cette variable est déclarée dans le code du vertex ou du fragment globalement. varying Une variable dite varying est déclarée globalement dans le vertex et dans le fragment. Elle peut être lue et écrite par le vertex et uniquement lue par le fragment. Typiquement elle permet au fragment de donner des informations sur des paramètres au fragment. Modélisation de la vision humaine 15/144

Chapitre 3 : Analyse du projet 3.4 Liaison GLSL-OSG Pour mieux comprendre comment fonctionne un shader et son modèle de construction, faisons une simple analogie avec le système de compilation du C. 3.4.1 Le glshader Un glshader correspondrait à un chier objet. Il contient le code source du shader. Il est compilé en temps réel (runtime) pour devenir un chier '.obj', et doit être recompilé dès que le code source change. 3.4.2 Le glprogram Un glprogram correspondrait plus à un chier exécutable. Il contient la liste des shaders à exécuter, il subit une édition de liens (link) pour devenir un chier '.exe' et les liens doivent être réédités dès qu'un shader est modié. Un glprogram doit avoir au moins un glshader attaché. Comme en C, un chier objet (shader) peut être partagé entre plusieurs chiers exécutables (program) 3.4.3 La liaison Voici les correspondances d'utilisation de ces types en OpenSceneGraph : glshader -> osg : :Shader glprogram-> osg : :Program gluniform*() -> osg : :Uniform Exemple Un exemple d'utilisation pourrait être : osg::program *pgm = new osg::program; gmpgm->setname("simple"); pgm->addshader(new osg::shader( osg::shader::vertex, vsrc)); pgm->addshader(new osg::shader(osg::shader::fragment, fsrc)); osg::stateset *ss = getorcreatestateset(); ss->setattributeandmodes(pgm, osg::stateattribute::on); ss->adduniform(new osg::uniform("color", osg::vec3(1.0f, 0.0f, 0.0f))); ss->adduniform(new osg::uniform("val1", 0.0f)); Un document très complet sur le langage GLSL et sa liaison avec OpenSceneGraph est disponible ici : http ://mew.cx/osg_glsl_july2005.pdf. 3.5 Petit imprécis sur la physiologie de l' il Nous allons énumérer un certain nombre de propriétés physiologiques de l' il et voir leurs conséquences sur la vision humaine, conséquences que nous aurons donc à modéliser dans notre application. 3.5.1 Rétine La rétine est une surface (couvrant 75% de la surface du globe oculaire) d'environ 0,5 mm d'épaisseur située au fond de chaque il tapissée de cellules photo réceptrices permettant de transformer en signaux bioélectrique les signaux lumineux reçus et les transmettre au cerveau. Modélisation de la vision humaine 16/144

Chapitre 3 : Analyse du projet Cônes et Bâtonnets Ces cellules sont de deux types, les cônes ("verts", "bleus" et "rouges") réceptifs aux couleurs mais peu sensibles à l'intensité lumineuse et les bâtonnets, très sensibles à l'intensité lumineuse (environ 500 fois plus que les cônes) mais imperméables aux couleurs. Elles sont réparties de manière hétérogène sur l'ensemble de la rétine ; les cônes étant beaucoup plus nombreux dans la fovéa (zone centrale de la rétine) et les bâtonnets dans la rétine périphérique (Voir Fig. 1 en annexe). La conséquence de cette répartition est une division de la vision humaine en une vision centrale et une vision périphérique. Nous ne nous en rendons pas compte mais nous sommes en réalité "aveugles" aux couleurs en dehors de la vision centrale, et pouvons distinguer plus facilement les variations de luminosité en périphérie. De même, la vision centrale est plus nette le jour tandis que l'on voit mieux la nuit si l'on regarde légèrement à coté de l'objet ciblé. De plus, la zone fovéale est la seule zone où l'acuité visuelle est vraiment signicative, cette dernière est même considérée comme médiocre en dehors de cette zone, qui ne correspond qu'à un angle de 3 degrés environ. Lors de la simulation de la vision humaine à un instant t, la netteté de l'image n'est donc pas homogène. 1 Enn, les cellules photo réceptrices ont besoin d'un certain temps pour eectuer le traitement biochimique du signal optique, ainsi l' il superposera l'image en cours aux images vues précédemment. Tâche de Mariotte De plus,légèrement excentré par rapport au centre de la rétine vient se brancher le nerf optique ainsi que les vaisseaux sanguins de l' il. En ce point, nommé tâche de Mariotte, la rétine est complètement dépourvue de cellules photo réceptrices, l' il est donc totalement aveugle. Nous ne nous apercevons de rien car le cerveau compense cette "tâche blanche". Cependant, l'absence d'information en ce point est réelle et il est donc important de la prendre en compte dans un simulateur. 3.5.2 Cristallin & Pupille Cristallin Le cristallin de l' il peut se ramener à une lentille convergente complexe. En eet, des muscles modient les rayons de courbure des deux faces du cristallin permettant le phénomène d'accommodation, c'est à dire modier quels seront les rayons lumineux à atterrir sur la rétine et ainsi pourvoir voir de près comme de loin. Il existe diverses pathologies ou malformations qui peuvent entraver ce processus, le temps d'accommodation et sa qualité peuvent donc varier selon les individus. En outre, un il fatigué, ou exposé pendant longtemps à beaucoup de lumière aura plus de mal à s'accommoder lorsque plongé dans le noir. Ce sont là autant de pistes qu'il nous faudra explorer dans notre application. Pupilles Les pupilles de l' il peuvent s'ouvrir ou se fermer en fonction de la luminosité. Ainsi, les pupilles s'ouvrent largement la nuit an de permettre le passage d'un maximum de lumière, ce qui fait perdre en netteté de profondeur de champ. Modélisation de la vision humaine 17/144

Chapitre 3 : Analyse du projet 3.5.3 Champ de vision Le champ visuel humain peut être décomposé en deux : la vision centrale et la vision périphérique. Vision centrale La vision centrale, aussi appelée acuité visuelle, permet de distinguer les détails de l'espace, en vision éloignée et en vision rapprochée. C'est une vision nette et précise. L'acuité visuelle correspond à un angle de vision de 3 environ ; en dehors de cette zone, la vision est médiocre. Vision périphérique La vision périphérique est la vision de la sécurité. C'est une vision oue qui permet de détecter le mouvement "ce qui bouge", de sentir "qu'il se passe quelque chose" sur les côtés. La vision périphérique nous permet de voir ou de détecter des mouvements sur les cotés jusqu'à au moins 90 par rapport à la vision centrale, et environ 70 en haut et en bas. Même si nous ne le ressentons pas au quotidien, la vision périphérique est une vision qui déforme les objets présents à notre alentour. Modélisation de la vision humaine 18/144

Chapitre 4 : Développement Chapitre 4 Développement 4.1 Petit imprécis sur la modélisation de la vision humaine avec OpenSceneGraph, OpenGL et le GLSL Nous ne reprendrons pas ici les explications données dans la partie analyse, nous les compléterons par : - quelques mots du vocabulaire du programmmeur OSG, GLSL. - quelques techniques utilisées. Vecx (x = 2..4) est un vecteur à x éléments. Geometry est l'attribut qui contient les coordonnées de la gure dans un canvas, ainsi que la manière de colorer la gure, et les coordonnées de la texture (s'il y en a) dans cette gure. Un QUAD est une structure géométrique composée de 4 points (vertex) 4.1.1 Render To Texture Comme son nom l'indique, il s'agit de récupérer le rendu d'une scène dans une texture pour pouvoir ensuite y appliquer nos ltres. L'utilisation d'openscenegraph nous a permis de réaliser cela assez simplement. En eet, il nous sut de spécier à une caméra donnée que son "COLOR_BUFFER", c'est à dire le rendu nal de la scène que la caméra observe sera une texture : camera->attach(color_buffer,texture); Cette caméra sera utilisée avant le rendu à l'écran, et elle même n'achera donc rien, du fait du RTT. Il nous faut donc ensuite acher à l'écran la texture que l'on a créée, et pour cela nous utilisons une deuxième caméra, qui "passera" après la première et qui place cette texture sur un rectangle de taille de notre canvas. Modélisation de la vision humaine 19/144

Chapitre 4 : Développement 4.2 Modele-Vue-Controleur Nous avons utilisé le patron Modele-Vue-Controleur pour gérer notre application (cf. gure en page 46). An de mieux comprendre comment tout cela est articulé, nous avons également fourni un diagramme de classe d'analyse permettant de se rendre compte de la hiérarchie des composants utilisée dans notre logiciel (cf. gure en page 48). 4.2.1 Modèle Nous avons décidé d'utiliser le patron de conception décorateur (cf. gure en page 47) car celui-ci correspond exactement à ce que nous voulions faire. Nous avions une scène de base à laquelle nous voulions pouvoir ajouter diérents attributs (nos ltres). Nous avons donc commencé par créer une classe MScene qui correspond à notre scène chargée via l'interface avec toutes les fonctions nécessaires aux modications sur la scène, puis une classe abstraite DécorateurScene de laquelle hérite nos ltres. Ainsi nous pouvons ajouter des ltres comme bon nous semble et les aecter à la scène très simplement. 4.2.2 Vue L'interface est la partie qui relie l'utilisateur et l'application. Nous avons voulu créer une interface simple d'utilisation tout en essayant de rendre celle-ci la plus attrayante possible. Pour cela nous avons donc décidé de créer un certain nombre de barre d'outils et de fenêtre d'options qui permettent à l'utilisateur d'ajouter d'actionner des ltres, de les personnaliser de façon très simple. Nous avons aussi choisi de créer une interface dans laquelle, l'utilisateur pourra ouvrir plusieurs projets en même temps, indépendant les uns des autres sans ouvrir plusieurs fenêtres, c'est pourquoi nous avons crée un système d'onglets. Notre interface se compose d'une classe App (cf. gure en page 44) dérivant de wxapp qui est la classe permettant de créer une application. À la création de l'application, une fenêtre principale (MainFrame) dérivant d'une wxframe est créée. Cette fenêtre est gérée par un wxauimanager qui nous permet de choisir un style particulier à celle-ci. En combinant wxauimanager et wxauipaneinfo nous pouvons choisir les options des objets à inclure à cette fenêtre telles l'emplacement, la taille, l'achage d'une croix pour fermer la sous fenêtre, la possibilité de déplacer les fenêtres. La classe MainFrame possède des barres d'outils d'activation ou de désactivation des ltres via des boutons, des fenêtres pour gérer les options des ltres, une barre de menu et un gestionnaire d'onglets. La barre de menu (wxmenubar) contient un certain nombre de menus (wxmenu) tel que le menu chier qui contient lui même des (wxmenuitem) pour charger une nouvelle scène ou fermer la fenêtre. Les barres d'outils sont dérivés de la classe wxtoolbar, ce qui nous permet de personnaliser chaque barre d'outils, chaque bouton par une image (au format xpm) ou du texte. Certains boutons comme les boutons des ltres son sélectionnables an que la personne qui utilise le programme puisse savoir à tout moment quel(s) ltre(s) elle a appliqué sur la scène courante. Nous avons rendus les barres d'outils déplaçables grâce au wxauimanager. m_mgr.addpane(tbfiltre, wxauipaneinfo(). Name(wxT("ToolBarFiltre")).Caption(wxT("ToolBar des différents filtres.")). ToolbarPane().Top().Row(1).Position(1).TopDockable(true).CloseButton(false). DestroyOnClose(true).BottomDockable(false)); Modélisation de la vision humaine 20/144

Chapitre 4 : Développement m_mgr est le wxauimanager de la fenêtre principale et tbfiltres est la barre d'outils que l'on souhaite ajouter. Ensuite on peut voir que grâce au wxauipaneinfo on choisit la position de la barre d'outil mais aussi l'endroit ou l'on peut déposer la barre d'outil ainsi que sont style d'achage (ToolbarPane()). Nous avons également choisit d'ajouter une fenêtre à part entière permettant de gérer les diérentes options sur les ltres. Cette fenêtre (OptionFlous) permet de gérer les options sur diérents ltres grâce à de nombreux sliders permettant de régler la distance d'accommodation, la taille de la matrice de calcul du ou et d'autres encore. Nous avons également choisit d'ajouter un bouton updateshader qui permet de mettre à jour le shader de la scène que l'on utilise grâce à ce qui est écrit dans la console. Cette fenêtre agit directement grâce au contrôleur sur l'onglet actif courant. Les onglets sont la partie la plus importante de la fenêtre principale. En eet, pour construire chaque onglet nous mettons en titre le chemin du dossier pour lire la scène et dans l'onglet une classe qui hérite de wxwindow : Projet (cf. gure en page 45). Cette classe est la classe qui va nous permettre d'acher une scène et la console associée à cette scène. La console est une simple boite de texte dans laquelle nous lisons et écrivons selon nos diérentes actions. Pour acher la scène nous avons plusieurs classes, tout d'abord SceneFrame qui hérite de wxscrolledwindow et Canvas qui hérite de wxglcanvas et d'osgviewer : :GraphicsWindow. Dans projet il y a un nouveau gestionnaire de fenêtre au moyen de wxauimanager dans lequel nous mettons au centre la classe SceneFrame et en bas la console. Le canvas est contenu dans la fenêtre de la scène. Lorsque nous créons la fenêtre de la scène, nous lui aectons un canvas sans scène. Puis le programme aecte un viewer au canvas an que le viewer utilise le canvas comme moyen d'achage. Le canvas gère lui-même les évènements comme le clique gauche ou le clique droit sur lui, il met à jour la scène en fonction ; sachant que le clique gauche vous permet de faire pivoter la scène alors que le clique droit vous permet de faire un zoom. Ces fonctions sont gérées par la classe osgviewer : :Viewer. Pour nos diérents ltres la classe SceneFrame possède des pointeurs vers le modèle de la scène an de savoir si celle-ci est oue par exemple. Lorsqu'un évènement est détecté sur les sliders, il faut que le contrôleur puisse savoir si la scène est oue ou non. 4.2.3 Controleur Le contrôleur est l'articulation du système, c'est vers lui que chaque requête interne ou externe est transmise (sauf pour le canvas). C'est lui qui va appeler les bonnes fonctions selon les évènements du menu, c'est lui qui va choisir si lorsque l'utilisateur bouge un slider, si selon le ltre appliqué en ce moment sur la scène, s'il faut ou non que cette modication soit prise en compte. C'est lui qui eectue la gestion des onglets, lorsqu'une action est détectée, si celle-ci concerne un onglet, alors c'est par le contrôleur que l'action sera envoyée au projet actif. Lors d'un évènement de chargement c'est lui qui lance la boîte de dialogue qui permet de parcourir les dossiers pour choisir une scène à ouvrir. Le contrôleur connait tous les éléments de la fenêtre plus ou moins directement et grâce à cela, il permet d'assurer la liaison entre chaque élément de l'interface. 4.3 Flou Gaussien La réalisation d'une synthèse de ou en temps réel sur une scène donnée va permettre de créer un ltre pour illustrer les phénomènes d'accommodation. Il existe diverses techniques de traitement d'images permettant de réaliser ce type de ltre. Comme nous l'avons vu dans la partie Analyse, nous avons choisi d'utiliser un algorithme de convolution appliqué sur l'ensemble Modélisation de la vision humaine 21/144

Chapitre 4 : Développement de la scène 3D au moyen d'un shader GLSL. La réalisation du ltre se fait en trois étapes : Eectuer un Render To Texture de la scène Plaquage de la texture sur un QUAD Application du shader sur la texture Nous ne détaillerons ici que la troisième étape du procédé, car les deux premières sont détaillées dans le petit imprécis. 4.3.1 Première Approche Entrées : I une image, M un masque Résultat : Y l'image résultante de l'application du masque M à l'image I Dans notre cas, l'image I correspondante à la scène totale est transmise au shader sous la forme d'une texture à deux dimensions au moyen d'une variable de type uniform. Le masque M correspond à une matrice de rayon variable, dont les valeurs ottantes sont calculées de manière à obtenir une distribution gaussienne. Le principe de la convolution est le suivant : pour chaque pixel de l'image, calculer la combinaison linéaire de la valeur rgba de chaque pixel adjacent avec les coecients de la matrice lui correspondant, sachant que la valeur centrale de la matrice correspond au pixel courant. On remplace ensuite la valeur du pixel courant par la valeur de la combinaison linéaire normalisée an de revenir dans les domaines de variation de l'image. Nous eectuerons dans un premier temps les calculs de la matrice à l'intérieur du shader, mais il nous a vite semblé évident que cela était aberrant, nous avons donc décidé de calculer le shader à la volée lors de l'exécution du programme, en eectuant notamment le calcul du noyau sur le CPU. De plus cela nous permet de pouvoir changer le code source du shader pendant l'exécution du programme et ainsi pouvoir faire varier les diérents paramètres gérant l'accommodation en temps réel. Comme il s'agit de traiter chaque pixel, cet algorithme sera implémenté dans le Pixel Shader. Algorithme 1 Convolution Entrées: Kernel une matrice contenant les coecients, Oset une matrice contenant les modicateurs de coordonnées pour chaque coecient de Kernel,colorMap un sampler2d,gltexcoord[0] un vec4 contenant les coordonnées de texture par vertex, Total un ottant Sorties: Valeur un vec4 représentant la valeur du pixel en cours 1: pour inti = 0 to taille de Kernel faire 2: Accéder à la valeur des texels adjacents au texel correspondant au pixel en cours 3: vec4temp = texture2d(colormap, gl T excoord[0].st + Offset[i]); 4: valeur+ = temp Kernel[i]; 5: n pour 6: valeur = valeur/t otal 7: return valeur Du fait de la distribution gaussienne de notre matrice, les coecients qui ont le plus d'inuences, c'est à dire une valeur plus importante, se situent au niveau du centre, et leur inuence décroit avec leur distance au centre. Ainsi, cette convolution revient à atténuer les changements brusques d'intensité de l'image, ce qui rejoint la dénition du ou. Modélisation de la vision humaine 22/144

Chapitre 4 : Développement 4.3.2 Premiers Résultats Nous avons constaté que les ous "produits" par ce shader ne devenaient vraiment conséquents qu'à partir d'un rayon de matrice supérieur ou égal à 3, ce qui est également la limite supérieure de nos cartes graphiques de tests en terme de puissance de calcul, le nombre d'images par secondes chutant spectaculairement entre une matrice de rayon 2 (60 images par secondes) et une matrice de rayon 3 (entre 5 et 15 images par secondes selon les GPU) sur une scène de dimension 800*600. Ces résultats ne sont pas surprenants dans la mesure où l'implémentation brute de la convolution tel que nous l'avons implémentée est en O(n 2 ). Fig. 4.1 Avion net à gauche et oué à droite par une matrice de rayon 2 4.3.3 Solutions Une première solution envisagée consistait à réduire le nombre de texels sur lesquels on appliquait la convolution, en eectuant un RTT vers une texture de taille inférieure que l'on plaquait ensuite sur un QUAD ayant gardé la taille d'origine. Le problème résultant de cette opération fut l'apparition d'une pixellisation de la scène rendue ou, et plus grave, des parties non oues de la scène. La seconde solution que nous avons nalement retenue consiste à utiliser un paramètre optionnel de la fonction GLSL texture2d de spécier un niveau de detail pour une valeur dans une texture donnée. En eet, une texture peut posséder plusieurs niveaux de détails, dits MIP map levels qui ont l'avantage d'éviter une pixellisation la texture, ainsi que de réduire le nombre de texels à traiter. Cette utilisation du Mip-Mapping est rendu possible du fait de l'extrapolation linéaire de la texture sur le QUAD, ce qui évite les eets d'escaliers lorsque l'on va traiter un texel sur deux par exemple. L'idée est donc d'appliquer une convolution de matrice de rayon moindre sur une image à un niveau de détail moindre, ce qui a pour eet d'obtenir un ou conséquent sans demander beaucoup de calculs au GPU. 4.3.4 Les phénomènes d'accomodation Nous avons choisit de pouvoir faire varier la distance à laquelle "l'humain" regarde la scène an d'illustrer les phénomènes d'accommodation. C'est pourquoi il nous a fallu récupérer la Modélisation de la vision humaine 23/144

Chapitre 4 : Développement Fig. 4.2 Illustration mipmap distance de l' il par rapport à l'objet an de déterminer une première partie de la scène dont les rayons lumineux n'arrivent pas sur la fovéa car n'étant pas à la distance pour laquelle l' il s'accommode. Pour toute cette partie de la scène, nous réalisons alors une interpolation entre une image ou de la scène et une image nette (avec la proportion d'image oue variant selon l'âge, l'acuité visuelle, etc..). Nous avions dans un premier temps tenté de récupérer un buer contenant des informations sur la profondeur d'une scène appelé Depth Buer. Pour cela, nous avons réalisé une capture de ce buer au moyen d'un "render to texture", puis nous avons transmis cette texture au Fragment Shader comme s'il s'agissait d'une texture quelconque. Nous avons ensuite réalisé qu'il n'etait pas nécessaire d'utiliser ce procédé. En eet, un Vertex Shader permet de redénir toutes les transformations géométriques nécessaires à l'achage d'un objet en 3 dimensions sur un ecran, c'est à dire sur une surface en 2 dimensions. Ainsi, nous avons donc écrit un Vertex Shader dans lequel nous transposons les coordonnées de chaque point, qui sont dans le "Model Space" i.e. les coordonnées objet, dans le Eye Space i.e. le système de coordonnées ayant l' il pour origine. Ceci s'eectue en appliquant successivement les deux matrices de transformations que sont la "Model Transformation Matrix" et la "Viewing Matrice" aux coordonnées du point : vec4 positionineyespace = gl_vertex * gl_modelviewmatrix; float depth = - positionineyespace.z / positionineyespace.w; Il ne nous reste plus qu'à passer cette information au shader sous la forme d'un varying et de calculer l'interpolation voulue selon une courbe. Le calcul de cette courbe fût simple, il susait de trouver une courbe variant entre 0 et 1 en fonction de la profondeur. 0 signiant une zone parfaitement nette, 1 une zone la plus oue possible et entre 0 et 1 une zone de plus en plus oue. La zone nette se trouve exactement à la distance d'accommodation de l' il de l'humain et les zones oues à des distances inférieures et supérieures à cette distance d'accomodation. Nous avons utilisé la fonction suivante : f(x) = min(1 ; abs(0.06 * (distance d'accomodation - x ))) Ce résultat aurait pu être satisfaisant cependant dans la réalité l' il humain ne s'accommode pas seulement à une distance précise mais plutôt à une zone plus ou moins grande selon les individus. C'est pour cette raison que nous avons décidé d'ajouter un slider permettant de dénir la taille de cette zone en fonction des individus. Une fois cette fonction calculée, il nous susait d'utiliser ce résultat an de calculer la couleur à acher. Pour cela nous avons utilisé le calcul suivant : Modélisation de la vision humaine 24/144

Chapitre 4 : Développement Fig. 4.3 Courbes de l'interpolation entre les zones nettes et oues ou = couleur du pixel ou net = couleur du pixel net coef = résultat du calcul précédent gl_fragcolor = coef*flou + (1 - coef)*net; Une fois la réalisation du ou correcte en fonction de la profondeur des objets de la scène, nous nous sommes attaqués à une modélisation plus ne, qui tient compte de "l'angle de netteté" de la vision. Modélisation de la vision humaine 25/144

Chapitre 4 : Développement 4.4 La projection sphérique La projection sphérique va nous permettre de simuler la projection de la lumière sur l' il humain ainsi que les limites du champ visuel. L' il humain permet de voir, pour une personne non déciente, de 94 à 110 degrés environ horizontalement et de 110 à 120 degrés verticalement ; ces chires peuvent varier selon les personnes. Avec nos deux yeux, nous pouvons donc voir à au moins 188 degrés horizontalement, c'est-à-dire que nous pouvons voir légèrement derrière nous. Au niveau de la programmation cela constitue un dé de taille, car aucun logiciel ne vous ore une vue à plus de 180 degrés. Cela est techniquement impossible avec une projection en perspective. Dans notre recherche de la simulation de la vision humaine, nous sommes tout d'abord partis sur une unique projection non linéaire, puis ayant compris qu'il était impossible de résoudre ce problème de cette manière, nous avons entrepris d'assembler plusieurs projections non linéaires an d'en obtenir une projection sphérique d'un angle de vue supérieur à 180 degrés. 4.4.1 La projection non linéaire La projection linéaire est la projection automatiquement réalisée par opengl. Cette projection ne subit aucune déformation, même minime. Notre objectif ici est de pouvoir simuler les déformations que subit l'image lors de sa projection sur l' il, c'est-à-dire que celle-ci soit peu déformée au centre et à contrario très déformée sur les côtés. Pour eectuer cette modélisation, nous avons recherché une courbe de déformation quasiment idéale, c'est-à-dire qui déforme peu la scène au centre an de laisser celle-ci "lisible" et fortement sur les côtés. Nous avons cherché un compromis entre la ressemblance physiologique et la lisibilité du modèle. Le processus se déroule en 3 étapes, la capture du color buer dans une texture, le calcul des positions de placage de la texture et le placage de la texture. Modélisation de la vision humaine 26/144

Chapitre 4 : Développement Algorithme 2 Déformation d'une texture 1: Capturer le color buer dans une texture tex 2: int nosteps = 50 3: Position des sommets : cursor = Vec3(0,0,0) 4: Position des points de la texture : texcoords = Vec2(0,0) 5: Vecteur des positions nales des points de la texture : texcoord. 6: Vecteur des positions nales des points de la gure : vertices. 7: pour int i = 0 to nosteps faire 8: Incrément de cursor en y. 9: Incrément de texcoords en y. 10: pour int j = 0 to nosteps faire 11: Vec2 coords = calculcoords(texcoords.x(), texcoords.y()) ; 12: Empiler coords dans texcoord. 13: Empiler cursor dans vertices. 14: Incrémenter cursor en x. 15: Incrémenter texcoords en x. 16: n pour 17: n pour 18: Création de l'attribut geometry de la scène. 19: Aectation de l'attribut vertices à geometry. 20: Aectation de l'attribut texcoord à geometry. 21: Création d'une scène. 22: Application de geometry à la scène. 23: Placage de la texture tex sur la scène. 24: Création d'une caméra qui ache la nouvelle scène au dessus de la précédente après la caméra principale. Ici nosteps dénit le nombre d'étapes que l'on va faire pour calculer les positions, un nombre trop petit peut rendre la vue complètement inutilisable alors qu'un nombre trop grand peut faire chuter le nombre d'images par seconde. Le calcul des positions de la gure est simple, il sut de recouvrir toute la fenêtre, c'est pourquoi on pose directement cursor dans le tableau de vecteur des nouvelles coordonnées. Cependant pour les points de la texture, on ne calcule pas des coordonnées à l'écran ou sur un canvas, mais des coecients qui varient entre 0 et 1 et dont le centre est en 0,5. Cette diérence explique pourquoi on n'incrémente pas de la même manière cursor et texcoords. calculcoords est une fonction qui prend les deux coordonnées x et y en paramètres et qui renvoie un Vec2 dans lequel on a appliqué la fonction de déformation telle que décrite ci-dessous. Modélisation de la vision humaine 27/144

Chapitre 4 : Développement Fig. 4.4 Graphique des diérentes déformations La courbe bleue représente la fonction identité, celle qui n'applique aucune déformation à l'image. Nous avons commencé nos essais avec la courbe (sin(x (pi 0.5)) + 1)/2 mais celleci ne nous donnait pas satisfaction car la déformation n'était pas assez importante nous avons donc cherché et trouvé les autres courbes, nous donnant chacune une déformation bien plus importante. Modélisation de la vision humaine 28/144

Chapitre 4 : Développement Fig. 4.5 Déformation d'une scène représentant une vache avec la fonction (sin(x (pi 0.5)) + 1)/2 Finalement, ces déformations faisaient sortir ce que l'on voyait de l'écran en déformant énormément la texture sur les côtés. C'est alors que nous avons vu que la vision humaine s'étendait sur un angle de 188 degrés. Cette étape nous avait donc permis de toucher à la déformation d'une texture tirée du color buer mais elle n'était cependant pas satisfaisante dans le but de simuler la projection de la lumière sur l' il. 4.4.2 L'assemblage de projections non linéaires Pour simuler la projection sphérique, nous avons dû assembler plusieurs panneaux constituant chacun une projection linéaire. Ces panneaux sont capturés par le biais de 3 caméras qui regardent la scène avec un même angle d'ouverture mais les caméras de gauche et de droite ont subit une rotation de cette angle dans le sens inverse (respectivement dans le sens) des aiguilles d'une montre. Nous avons choisit de n'utiliser que 3 panneaux dans le plan horizontal, et de ne pas ajouter de panneaux verticalement car au niveau du champ visuel on ne voit pas à 180 degrés en hauteur. Ces 3 caméras permettent donc de capturer la scène avec ce que l'on voit au centre, ce que l'on voit à gauche et ce que l'on voit à droite. Modélisation de la vision humaine 29/144

Chapitre 4 : Développement Algorithme 3 Capture des 3 vues 1: Créer 3 textures vides diérentes. 2: Dénition d'un angle de rotation ang. 3: Création de matrices de transformations m1, m2, m3 de la caméra principale. 4: m1 est la matrice identité. 5: m2 est la matrice identité sur laquelle on applique une rotation ang sur l'axe des y. 6: m3 est la matrice identité sur laquelle on applique une rotation -ang sur l'axe des y. 7: pour tout matrice faire 8: Création d'une nouvelle caméra. 9: Utilisation du Frame Buer Object lorsque cela est possible sur la caméra. 10: Création d'un Render To Texture avec cette caméra et la texture tx [où x représente le numéro de la caméra]. 11: Aectation de la caméra comme esclave de la caméra principale avec les arguments mx. 12: n pour 13: pour tout texture faire 14: Création d'un n ud. 15: Calcul de la geometry du n ud tel que décrite dans l'algorithme de calcul de la déformation. 16: Application de la geomtry au n ud. 17: Application de la texture au n ud. 18: n pour 19: Création d'une caméra de visualisation. 20: Création d'un n ud aura pour ls les 3 précédents. 21: Aectation de ce groupe de n ud à la caméra de visualisation. 22: Aectation de la caméra comme esclave de la caméra principale. Si on assemble ces 3 panneaux sans déformation, nous pouvons obtenir une vue de plus de 180 degrés, mais sans déformation. An de calculer les déformations sur chacun des panneaux, nous sommes passés par deux approches. La première, mathématiques, consistait à analyser le problème entièrement sous forme d'angles, de tangentes et de bissectrices. La seconde approche, plus pragmatique, consistait à placer à la main les points permettant de déformer l'image. L'approche mathématiques Le but de cette approche était de déterminer la manière de déformer les images capturées par les caméras du centre, de droite et de gauche. Nous avons placé le panneau du centre comme étant celui qui subit le moins de déformation, voir aucune au début, puis les panneaux de droite et de gauche qui subissent de fortes déformations plus on s'excentre. Pour placer les panneaux de droite et de gauche, nous avons décidé de les placer sur la bissectrice entre le panneau central et eux-mêmes. Modélisation de la vision humaine 30/144

Chapitre 4 : Développement Fig. 4.6 Disposition des panneaux Pour éviter un problème de continuité en bordure de panneaux, il nous fallait utiliser la même déformation à la n du panneau du centre et de celui de droite (et inversement, au début de celui du centre et à la n de celui de gauche). Si on considère juste la surface de l' il comme un cercle, on s'aperçoit alors qu'il faut projeter les plans sur cette surface en utilisant l'arc tangente. Fig. 4.7 La fonction arc tangente Si on considère ce schéma, O correspond à l' il humain, A au centre de la projection eectuée par le logiciel, et T au point dont on cherche la nouvelle cordonnée. Nous avons donc appliqué la fonction arctan (voir gure 4.8 - courbe atan) sur nos calculs de déformation et nous avons pu voir apparaître une déformation mais nous nous sommes retrouvés avec des cassures très importantes entre les diérents panneaux. An de réduire ces cassures, nous avons décidé de prendre un angle correspondant à 1 radian, c'est à dire 57 degrés. Sachant que tan 1 = 1.06 nous avons déterminé un coecient à appliquer sur notre calcul de déformation puis par tatonnement, nous avons xé une valeur à 1.09 de telle sorte qu'il y ait une déformation et qu'il n'y ait pas de cassure (voir gure 4.8 - courbe orange). Modélisation de la vision humaine 31/144

Chapitre 4 : Développement Fig. 4.8 Graphique des diérentes déformations par l'approche mathématiques Finalement, nous avions 3 panneaux, représentants ce que nous voyions à gauche, au centre et à droite mais avec une déformation tellement faible qu'elle n'était presque pas visible. An de vérier cela, nous avons pris un cube avec des lignes et nous avons vu qu'en eet le cube ne subissait aucune déformation. Nous avons alors entrepris de construire à la main les points an de déformer manuellement les images. L'approche pragmatique Lors de notre calcul des points de la texture, nous avons choisi de n'eectuer que 50 itérations, il nous fallait donc trouver 50 points qui nous donneraient une déformation et pas de cassure entre les panneaux. Nous avons commencé par calculer une déformation selon l'axe des x. Cette courbe montre clairement que la déformation est bien plus importante que la fonction y = x originale et que la fonction arc tangente. De plus comme elle est entièrement calculée à la main, nous pouvons la remodeler à notre guise. Une fois cette fonction trouvée, nous n'avions plus qu'à rentrer chaque point dans un tableau contenant les points de la texture, cependant et an de garantir un collage entre les panneaux, cette fonction n'est pas appliquée dès le départ mais après les deux premiers points de collage de la texture, ainsi les panneaux se soudent bien entre eux. Modélisation de la vision humaine 32/144

Chapitre 4 : Développement Fig. 4.9 Courbes de déformation en x selon les vues Ensuite nous n'avions plus qu'à trouver une courbe de déformation pour l'axe des y. Nous avions, lors de nos diérents tests sur la projection linéaire, cherché de nombreuses courbes pouvant nous donner satisfaction, une des courbes était totalement inutilisable lors de cette projection, cependant avec notre assemblage de panneau et ce que nous voulions faire, nous avons pu la réutiliser. Pour simuler la déformation en haut et en bas, il nous fallait une courbe qui ressere la scène en haut et en bas et qui l'étende au centre, au niveau graphique cela correspond à être très près du 0,5 (du centre de l'image) et très éloigné du 0 et du 1 puisque ceux ci sont les extrémités du collage de notre texture. Modélisation de la vision humaine 33/144

Chapitre 4 : Développement Fig. 4.10 Courbes de déformation en y. Au nal, grâce à nos approches successives nous avons réussi à créer un modèle de projection sphérique an de simuler la projection de la lumière sur l' il et les limites du champ visuel. Nous avons deux courbes et 3 panneaux qui nous permettent cette simulation. Modélisation de la vision humaine 34/144

Chapitre 5 : Manuel d'utilisation Chapitre 5 Manuel d'utilisation Tout d'abord lancer le logiciel, une fenêtre appairaît alors. Dans cette fenêtre, faites charger une scène à partir du menu ou de la barre d'outils. Une nouvelle fenêtre s'ouvre vous demandant de choisir la scène à charger. Si vous faites annuler aucune scène ne se chargera, sinon vous allez voir apparaître un nouvel onglet intitulé du chemin par lequel la scène a été chargée. Les formats acceptés sont les chiers avec une extension en.osg ou.3ds. La scène chargée et l'onglet créé, vous allez voir deux parties, la scène et une console. Dans cet onglet vous pouvez faire bouger la scène avec la souris ; en appuyant avec le bouton gauche et en bougeant la souris vous pouvez faire pivoter la scène, avec le clique droit vous pouvez zoomer ou dézoomer de la scène, avec les boutons droit et gauche pressés en même temps vous pouvez modier la position de la scène dans le viewer, avec la barre d'espace vous pouvez remettre la scène dans sa position initiale, vous pouvez activer/désactiver des ltres via le menu ou la barre d'outils, vous pouvez modier les options de ces ltres via la fenêtre de gestion des options. Une fois que vous avez ni avec une scène, vous pouvez en charger une autre ou quitter le logiciel. Modélisation de la vision humaine 35/144

Chapitre 6 : Perspectives et conclusions Chapitre 6 Perspectives et conclusions 6.1 Perspectives Notre application est fonctionnelle et relativement simple d'utilisation, cependant nous n'avons réalisé que deux ltres et aurions aimé en faire beaucoup plus, notamment des ltres traitants des maladies comme le glaucome et le daltonisme. Nous aurions également aimé pouvoir montrer l'eet d'un ash de radar lorsque nous sommes au volant, de montrer à quel point cela perturbe la vision humaine. 6.2 Accommodation Un petit nombre de sliders liés à la détermination de la zone peuvent sembler inadéquats dans la mesure où l'on souhaite simuler la vision humaine, cependant leur suppression pose de serieux problèmes de paramétrage car la réalité physiologique de l' il est telle que cette zone dépend d'un nombre de paramètres assez conséquents. Nous ne sommes pas sûr d'avoir réussi à tous les cerner dans nos tentatives de suppression de ces sliders, tels que la luminosité ambiante, l'âge du sujet, etc... 6.2.1 Evolution possible Nous avons bien entendu tenté de concevoir plus de ltres que ceux réalisés. La tâche de mariotte La tâche de Mariotte ou point aveugle est le premier ltre que nous avons tenté de réaliser. Nous avons commencé par ce problème car il devait nous faire découvrir le traitement d'images et la manipulation de scène en 3 dimensions. La tâche de Mariotte correspond à la partie où le nerf optique est connecté à la rétine, ce qui nous donne une petite partie démunie de photorécepteurs et donc complètement aveugle. Pour simuler cette tâche nous devions réaliser deux convolutions sur deux zones précises de taille xée. Cependant nous ne savions pas comment réaliser une convolution ni comment récupérer un pixel sans faire chuter le nombre d'images par seconde. C'est en travaillant sur la réalisation des autres ltres que nous avons trouvé comment faire une convolution et comment faire des render to texture. Nous avons donc entrepris de continuer cette partie, mais comme les autres parties n'étaient pas terminé, après en avoir parlé avec notre Modélisation de la vision humaine 36/144

Chapitre 6 : Perspectives et conclusions tuteur, nous avons décidé de nous concentrer sur nos ltres courants et de ne pas trop nous éparpiller. Eblouissement A l'heure actuelle de la réalisation de ce rapport, le ltre sur l'éblouissement n'est pas nalisé. Nous ne pouvons prédire à l'avance s'il sera terminé pour le jour de la soutenance. C'est pourquoi nous le notons en tant qu'évolution possible de notre projet... Ce ltre qui n'a pas pu voir le jour par manque de temps consistait à simuler un éblouissement dû à un ash, ou à une exposition soudaine à une lumière vive. Il aurait permis de reproduire les facteurs qui entrent en jeu lors de la réadaptation de l' il à la lumière. Pour ce ltre, il aurait fallu, récupérer la luminosité courante, l'augmenter jusqu'à simulation d'un éblouissement, et la réinitialiser à son état initial en fonction d'un facteur temporel (le temps d'adaptation). Nous n'avons pas eu le temps de gérer le facteur temps an de vraiment reproduire la reprise de la vue initiale. 6.3 Conclusions 6.3.1 Fonctionnement de l'application Notre application fonctionne correctement, les ltres se chargent et se cumulent correctement, leur suppression est également possible, ce qui permet vraiment de choisir ce que l'on désire simuler au niveau de la vision humaine. 6.3.2 Fonctionnement du groupe de travail Le groupe de travail a bien fonctionné grâce au fait que nous nous connaissions depuis au moins 5 ans, mais aussi car nous étions très motivés et que le sujet était très interressant. La communication entre chaque membre du groupe s'est ainsi trouvée accrue et bien plus ecace. La division du travail a été faite de manière ecace, selon les forces et faiblesses. 6.3.3 Problèmes rencontrés Lors de la réalisation de ce projet, nous nous sommes heurtés à plusieurs problèmes. D'une manière générale, notre connaissance en OpenGL et OpenSceneGraph était initialement nulle. Ceci a été une première barrière de taille à franchir. En eet, la documentation sur OpenScene- Graph est quasimment inexistante ou obsolète lorsqu'elle existe. Ce manque de documentation a posé un problème important. Nous avons donc tenté d'obtenir de l'aide sur les listes publiques et forums d'openscenegraph et tiré prot des exemples fournis avec l'api. D'une autre part, les bases d'openscenegraph plus ou moins en mains, il nous a fallu de plus en plus repousser nos limites an d'en apprendre plus. La compréhension d'un shader et la prise en main des techniques propres à OpenGL sont des exemples de ce que nous avons appris. 6.3.4 Notre sentiment sur ce projet Nous nirons ce rapport par exprimer en quelques lignes ce que ce rapport nous a apporté. Au niveau technique, ce projet nous apporté énormément de connaissances sur la visualisation graphique (2d et 3d). En eet, en partant d'une connaissance nulle dans ce domaine, nous avons, entre autres, manipulé et appris les bases d'opengl, nous avons utilisé OpenSceneGraph et Modélisation de la vision humaine 37/144

Chapitre 6 : Perspectives et conclusions tous les avantages qu'il présente et enn nous avons mené à bien l'utilisation avancée du langage GLSL pour manier les shaders. Au niveau relationnel, même si les membres de notre groupe se connaissent depuis assez longtemps, c'est toujours un dé de réaliser un projet dicile. La diculté est d'autant plus accrue si personne ne manie le sujet et le langage à utiliser. Ainsi les techniques d'organisation (cycle de développement, partage de sources, communication, répartition des tâches) n'ont été que renforcées. Nous garderons ce projet dans nos mémoires pour avoir été un projet des plus intéressants et passionnants. Il nous a permis de lier le monde informatique à la réalité de ce que nous vivons tous les jours : la vision humaine. Modélisation de la vision humaine 38/144

Chapitre A : Images Annexe A Images Modélisation de la vision humaine 39/144

Chapitre A : Images Fig. A.1 Schéma d'un pipeline de carte 3D classique représentant la position des unités de traitement des shaders Modélisation de la vision humaine 40/144

Chapitre A : Images Fig. A.2 Pile d'application 3D Modélisation de la vision humaine 41/144

Chapitre A : Images Fig. A.3 Organisation temporelle du travail. Modélisation de la vision humaine 42/144

Chapitre B : Documents d'analyse Annexe B Documents d'analyse Modélisation de la vision humaine 43/144

Chapitre B : Documents d'analyse Fig. B.1 Diagramme de classe pour l'interface. Modélisation de la vision humaine 44/144

Chapitre B : Documents d'analyse Fig. B.2 Diagramme de classe pour l'achage d'une scène dans un onglet. Modélisation de la vision humaine 45/144

Chapitre B : Documents d'analyse Fig. B.3 Diagramme de classe d'analyse pour l'utilisation du pattern Modele-Vue-Controleur. Modélisation de la vision humaine 46/144

Chapitre B : Documents d'analyse Fig. B.4 Diagramme de classe pour l'utilisation du pattern decorateur. Modélisation de la vision humaine 47/144

Chapitre B : Documents d'analyse Fig. B.5 Diagramme de classe d'analyse de la hiérarchie de composants. Modélisation de la vision humaine 48/144

Chapitre B : Documents d'analyse Fig. B.6 Diagramme de séquence pour la création d'un nouveau projet. Modélisation de la vision humaine 49/144

Chapitre C : Compte rendus de séances Annexe C Compte rendus de séances Nous avons pris l'initiative de réaliser, pour chaque réunion eectuée avec notre tuteur, un petit compte rendu qui nous permettait de ne pas perdre de vue les diverses orientations du projet. Elle sont recopiées ici en "brut de corage" (ou presque) pour vous faire une idée de notre organisation. C.1 Séance 1 Prise de contact avec M. Marie et découverte du projet à proprement parler avec dénition des objectifs et méthodes. Les dits objectifs sont donc de concevoir, une application permettant de simuler la vision humaine. Le traitement se fera directement à partir d'une scène 3D qui sera modiée au niveau du GPU à l'aide de shaders et le but avoué du TER est que ce traitement se fasse en temps réel (aux environs de 60 fps). La première partie du TER consistera donc à apprendre à utiliser les shaders OpenGl au moyen du langage GLSL et de la librairie OpensceneGraph. Un des aspects primordiaux de ce travail est le fait qu'il consistera à tester et calibrer au mieux les diérentes méthodes possibles pour simuler un rendu le plus proche de la réalité an d'en retenir la/les meilleure(s), et ce à diérents niveaux : Angle de vue Qualité de la vision Prise en compte de la sphéricité de l' il Prise en compte des altérations dûes à l'ouverture de l'iris et réactions de ce dernier face aux changements de lumière, etc.. Une fois ce premier travail accompli, on s'intéressera à simuler les diérentes pathologies possibles aectant la vision, tel que la cataracte, strabisme, etc.. Lors de cette scéance, nous avons décidés de la méthode à employer pour réaliser ce projet : nous voulions une méthode de travail ecace, nous permettant de montrer des résultats rapides à nos tuteurs. Ainsi, ces derniers pouvaient évaluer l'état d'avancement du projet lors de chaque scéance mais aussi nous aider à améliorer notre travail grâce à leur expérience. C'est pourquoi nous nous sommes orientés vers un cycle de développement itératif en accord avec nos tuteurs. Modélisation de la vision humaine 50/144

Chapitre C : Compte rendus de séances C.2 Séance 2 Nous avons discuté du rapport ainsi que d'une éventuelle charte de programmation. Nous avons formé deux groupes, le premier s'occupant de réaliser les eets de ous, le second de la tâche de Mariotte. Il s'agit dans un premier temps de se faire la main sur de la 2D. C.3 Séance 3 Nous avons discuté des modications à eectuer sur le cahier des charges (que nous ne citerons pas ici) ainsi que des nouvelles orientations à prendre, à savoir : Passer aux choses essentielles de la 3D, ne pas rester sur la tâche de mariotte Trouver comment accéder aux pixels (en dehors de la méthode glreadpixel qui est trop lente) Trouver comment eectuer une transformation de rgb vers hsl et travailler avec les couleurs C.4 Séance 4 Nous avons tout d'abord commencé la séance par un récapitulatif des progrès fait en opengl et sur l'utilisation d'openscenegraph, puis sur les parties du projet en cours de traitement. Nous avons ensuite réalisé un découpage stratégique des diérentes tâches à eectuer en les séparant en deux familles, celles nécessitant l'utilisation d'un buer de profondeur (Depth-Buer) et les autres. [...] Avant cette scéance nous avions déjà rééchit à quelques techniques d'implémentations possibles pour certaines parties, notamment pour la déformation : Nous pensions utiliser un système multi-caméra sur une scène 3D, chaque caméra ne s'occupant que d'une partie de l'image et y réalisant une transformation géométrique propre à la partie regardée par la caméra. Le problème soulevé lors de cette séance est celui des eets non voulus qui risqueraient de se produire aux lisières des diérentes caméras. De plus, 2 méthodes possibles de l'implémentation du ous ont été degagées, une première consiste à "découper" la scène en plusieurs images planes en fonction de la profondeur relative des diérents objets de la scène. En pratique, cela signie que l'on va recopier plusieurs matrices de pixels correspondantes à plusieurs niveaux de profondeurs pour une seule scène. Cela revient donc à avoir plusieurs images planes. La seconde consiste à utiliser un shader pour eectuer des matrices de convolutions diérentes en fonction de la profondeur. C.5 Séance 5 Durant cette réunion, il nous a été recommandé de rechercher des exemples de déformation, ainsi que des shaders réalisés par de grands groupes tel que ATI ou NVIDIA an de s'inspirer d'un modèle fonctionnel et d'essayer d'en apprendre les techniques. Une idée est survenue pour ce ltre : elle consiste à réaliser un balayage en partant du centre. Un point (x,y) correspond à un point plus éloigné. C.6 Séance 6 Nous avons discuté des avancées réalisées, le ou est maintenant fonctionnel et ne coûte plus très cher en temps de calcul, cependant il nous faut trouver un moyen ecace de gérer la profondeur. Pour ce qui est de la projection sphérique, il faut réaliser les 3 panneaux dans le Modélisation de la vision humaine 51/144

Chapitre C : Compte rendus de séances plan horizontal et non pas dans le plan vertical. Ceci est dû à une reexion simple, au niveau du champ visuel, on n'a que 125 degrés d'angle dans le plan vertical. On a donc 2 étapes à réaliser : Diviser l'écran en 3 panneaux. Triturer les textures selon des lois de variations an que celles-ci s'étendent diérement sur les panneaux. Faut il transmettre ces lois de variation aux shaders, ou régler le problème à un niveau supérieur, i.e. OpenSceneGraph Enn, en ce qui concerne la gestion de la luminosité, il faut ajouter un paramètre temporel pour l'éblouissement/perte d'éblouissement. C.7 Séance 7 Pour ce qui est de l'accommodation, nous avons passé l'essentiel de la séance à essayer de comprendre pourquoi la valeur de la profondeur vallait à la fois zéro et une valeur diérente de 0. Nous avons nalement réussi à outrepasser ce bug en utilisant un stratagème consistant à rendre la scène inchangée dans le cas d'une profondeur égale à zéro. Ce bug viendrait en fait d'un double appel au Fragment Shader qui a pour eet d'eectuer une première fois les tests avec une valeur correcte, puis une seconde avec des valeurs incorrectes. Pour la projection sphérique, les déformations horizontales sont correctes, il nous faut maintenant des déformations verticales correctes. Modélisation de la vision humaine 52/144

Chapitre D : Organigrammes Annexe D Organigrammes Modélisation de la vision humaine 53/144

Chapitre D : Organigrammes Fig. D.1 Organisation du développement Modélisation de la vision humaine 54/144

Chapitre D : Organigrammes Fig. D.2 Organisation interne pour la rédaction et la présentation Modélisation de la vision humaine 55/144

Chapitre E : Bibliographie Annexe E Bibliographie E.1 OpenGL GameDev : Portail pour la 3D - http ://www.gamedev.net/reference/programming/features/imageproc/page2.as Site de nehe sur GameDev - http ://nehe.gamedev.net/ The Red Book - http ://y.srk.fer.hr/ unreal/theredbook/ http ://www.linuxgraphic.org/section3d/opengl/ http ://helios.univ-reims.fr/labos/leri/membre/bittar/03opengl/index.html http : //techpubs.sgi.com/library/tpl/cgi bin/browse.cgi?coll = 0650&db = bks&cmd = toc&pth = /SGI D eveloper/p erf_p G http ://y.srk.fer.hr/ unreal/theredbook/ http ://jerome.jouvie.free.fr/opengl/ http ://www.evl.uic.edu/aej/594/lecture03.html E.2 OpenGL Shaders Addison Wesley - OpenGL Shading Language, Second Edition (Jan 2006) Site LighHouse3D - http ://www.lighthouse3d.com/opengl/glsl/ Présentation sur les shaders - http ://developer.3dlabs.com/documents/presentations/osg_glsl_july2005.zip E.3 OpenSceneGraph Site ociel d'openscenegraph - http ://www.openscenegraph.org/projects/osg Divers tutoriels pour OSG v1.0 - http ://www.nps.navy.mil/cs/sullivan/osgtutorials/ Listes publiques d'openscenegraph - http ://lists.openscenegraph.org/listinfo.cgi/osgusers-openscenegraph.org http ://www.openscenegraph.org/projects/osg/wiki/support/tutorials http ://www.cs.unc.edu/ ho/techrep/ http ://www.sm.luth.se/ david/classes/smm009/slides/ http ://cheveche4.developpez.com/tutoriels/openscenegraph/ Modélisation de la vision humaine 56/144

Chapitre E : Bibliographie E.4 Vision humaine et couleurs Site de M. Nanard avec des cours sur les couleurs - http ://www.lirmm.fr/ mnanard/m2pro-07/couleurs/ Site ociel gouvernemental - http ://vision.arc.nasa.gov/personnel/al/papers/64vision/17.htm Présentation des couleurs - http ://www.gpa.etsmtl.ca/cours/sys844/documents/document11.pdf E.5 Physiologie de L'oeil http ://www.ophtalmo.net/bv/gp/indexgp/g/recherche/recherche.htm http ://www.cvm.qc.ca/artsplastiques/510_a14/3_physiologie.htm http ://culturesciencesphysique.ens-lyon.fr/xml/db/csphysique/metadata/lom_csp_defautsoeil.xml http ://www.rennes.supelec.fr/ren/perso/jweiss/tv/perception/percept3.html#_toc432324836 http ://vision.arc.nasa.gov/personnel/al/papers/64vision/17.htm Beaucoup d'autres liens nous ont aidé à mener à bien ce projet. Nous ne répertorions ici que les principaux pointeurs vers les documents qui nous ont parus les plus intéressants et les plus utiles. Nous remercions d'ailleurs ces personnes pour la réalisation de ces tutoriaux et documents aussi utiles que bien réalisés. Modélisation de la vision humaine 57/144

Chapitre F : Documentation Annexe F Documentation Modélisation de la vision humaine 58/144

Human vision simulation Generated by Doxygen 1.5.5 Thu Apr 24 16:34:47 2008

Contents 1 Presentation page 1 2 Data Structure Index 3 2.1 Class Hierarchy............................. 3 3 Data Structure Index 5 3.1 Data Structures............................. 5 4 File Index 7 4.1 File List................................. 7 5 Data Structure Documentation 9 5.1 AbstractScene Class Reference..................... 9 5.2 App Class Reference.......................... 13 5.3 Canvas Class Reference......................... 14 5.4 ConsoleFrame Class Reference..................... 18 5.5 Controleur Class Reference....................... 19 5.6 DecorateurScene Class Reference................... 21 5.7 Flous Class Reference.......................... 23 5.8 KeyboardEventHandler Class Reference................ 25 5.9 KeyHandler Class Reference...................... 27 5.10 MainFrame Class Reference...................... 28 5.11 MScene Class Reference........................ 30 5.12 OptionFlous Class Reference...................... 33 5.13 PointLumineux Class Reference.................... 35 5.14 ProjectionSpherique Class Reference.................. 37 5.15 Projet Class Reference......................... 38

ii CONTENTS 5.16 SceneFrame Class Reference...................... 41 5.17 TacheDeMariotte Class Reference................... 44 5.18 ToolBarFiltre Class Reference..................... 46 6 File Documentation 47 6.1 AbstractScene.cpp File Reference................... 47 6.2 AbstractScene.h File Reference..................... 48 6.3 App.cpp File Reference......................... 49 6.4 App.h File Reference.......................... 50 6.5 Canvas.cpp File Reference....................... 51 6.6 Canvas.h File Reference........................ 52 6.7 Common.h File Reference....................... 53 6.8 ConsoleFrame.cpp File Reference................... 54 6.9 ConsoleFrame.h File Reference..................... 55 6.10 Controleur.cpp File Reference..................... 56 6.11 Controleur.h File Reference....................... 57 6.12 DecorateurScene.cpp File Reference.................. 58 6.13 DecorateurScene.h File Reference................... 59 6.14 Flous.cpp File Reference........................ 60 6.15 Flous.h File Reference......................... 61 6.16 KeyHandler.h File Reference...................... 62 6.17 MainFrame.cpp File Reference..................... 63 6.18 MainFrame.h File Reference...................... 64 6.19 MScene.cpp File Reference....................... 65 6.20 MScene.h File Reference........................ 66 6.21 OptionFlous.cpp File Reference.................... 67 6.22 OptionFlous.h File Reference...................... 68 6.23 PointLumineux.cpp File Reference................... 69 6.24 PointLumineux.h File Reference.................... 70 6.25 ProjectionSpherique.cpp File Reference................ 71 6.26 ProjectionSpherique.h File Reference................. 72 6.27 Projet.cpp File Reference........................ 73 6.28 Projet.h File Reference......................... 74 6.29 SceneFrame.cpp File Reference.................... 75

CONTENTS iii 6.30 SceneFrame.h File Reference...................... 76 6.31 TacheDeMariotte.cpp File Reference.................. 77 6.32 TacheDeMariotte.h File Reference................... 78 6.33 ToolBarFiltre.cpp File Reference.................... 79 6.34 ToolBarFiltre.h File Reference..................... 80

Chapter 1 Presentation page This project involves in reproducing the human vision. This project was realized by four students of the university of Montpellier (France). Don t hesitate to contact us for any questions. CLERC Mickael DELFOUR Jonathan JULIA Matthieu POTHIN Olivier

2 Presentation page

Chapter 2 Data Structure Index 2.1 Class Hierarchy This inheritance list is sorted roughly, but not completely, alphabetically: AbstractScene.................................. 9 App....................................... 13 Canvas...................................... 14 ConsoleFrame.................................. 18 Controleur.................................... 19 KeyboardEventHandler............................. 25 KeyHandler................................... 27 MainFrame................................... 28 MScene..................................... 30 DecorateurScene.............................. 21 Flous................................... 23 PointLumineux............................. 35 ProjectionSpherique........................... 37 TacheDeMariotte............................ 44 OptionFlous................................... 33 Projet...................................... 38 SceneFrame................................... 41 ToolBarFiltre.................................. 46

4 Data Structure Index

Chapter 3 Data Structure Index 3.1 Data Structures Here are the data structures with brief descriptions: AbstractScene................................. 9 App....................................... 13 Canvas..................................... 14 ConsoleFrame................................. 18 Controleur................................... 19 DecorateurScene............................... 21 Flous...................................... 23 KeyboardEventHandler........................... 25 KeyHandler.................................. 27 MainFrame.................................. 28 MScene..................................... 30 OptionFlous.................................. 33 PointLumineux................................ 35 ProjectionSpherique............................. 37 Projet...................................... 38 SceneFrame.................................. 41 TacheDeMariotte............................... 44 ToolBarFiltre................................. 46

6 Data Structure Index

Chapter 4 File Index 4.1 File List Here is a list of all files with brief descriptions: AbstractScene.cpp............................... 47 AbstractScene.h................................ 48 App.cpp.................................... 49 App.h (Launcher of the application )...................... 50 Canvas.cpp................................... 51 Canvas.h (Paint pane to display OpenGL components )............ 52 Common.h................................... 53 ConsoleFrame.cpp.............................. 54 ConsoleFrame.h (Text control for display message )............. 55 Controleur.cpp................................. 56 Controleur.h (Window and tabpane controller )................ 57 DecorateurScene.cpp............................. 58 DecorateurScene.h (Abstract class that allow creation of differents filters on a scene )................................ 59 Flous.cpp.................................... 60 Flous.h (This filter computes a blur on a given Mscene )........... 61 KeyHandler.h (EventManager (keyboard, mouse,...) for the canvas )..... 62 MainFrame.cpp................................ 63 MainFrame.h (This class permit to display the program )........... 64 MScene.cpp.................................. 65 MScene.h (The scene model that we want to show ).............. 66 OptionFlous.cpp................................ 67 OptionFlous.h (This class gives tools to manage the blur ).......... 68 PointLumineux.cpp.............................. 69 PointLumineux.h (This class adds a light point to the scene and allows simualtion of a glare )......................... 70 ProjectionSpherique.cpp........................... 71 ProjectionSpherique.h (This filter deforms the current scene regarding defined deformation curves )...................... 72

8 File Index Projet.cpp................................... 73 Projet.h (This class permits to create a window who contains a scene and a text control for each instance of Projet (p. 38). The projet are used in the auinotebook on the class MainFrame (p. 28) )........ 74 SceneFrame.cpp................................ 75 SceneFrame.h (This class allow to display a scene on a wxscrolledwindow ) 76 TacheDeMariotte.cpp............................. 77 TacheDeMariotte.h.............................. 78 ToolBarFiltre.cpp............................... 79 ToolBarFiltre.h................................ 80

Chapter 5 Data Structure Documentation 5.1 AbstractScene Class Reference #include <AbstractScene.h> Public Member Functions virtual AbstractScene (void) virtual osg::node getscene ()=0 virtual void addfilter (osg::node n) virtual osg::stateset getorcreatestate () virtual void setstate (osg::stateset s) virtual void removeattribute (osg::stateattribute s) virtual void setattribute (osg::stateattribute s, osg::stateattribute::overridevalue value=osg::stateattribute::off) Override is used to specify the override behavior of StateAttributes from parent to children. virtual void setattributeandmodes (osg::stateattribute s, osg::stateattribute::glmodevalue value=osg::stateattribute::on) GLModeValue is used to specify whether a mode is enabled (ON) or disabled (OFF). virtual osg::stateattribute getattribute (osg::stateattribute::type type, unsigned int member=0) virtual void ajouterdb (const wxstring &path) Protected Attributes osg::ref_ptr< osg::group > scene

10 Data Structure Documentation 5.1.1 Constructor & Destructor Documentation 5.1.1.1 AbstractScene:: AbstractScene (void) [virtual] 5.1.2 Member Function Documentation 5.1.2.1 virtual osg::node AbstractScene::getScene () [pure virtual] Getter: Returns the decorated scene Returns: the decorated scene 5.1.2.2 void AbstractScene::addFilter (osg::node n) [virtual] Setter: Set the current decorated scene to a new one represented by the paramater n Parameters: n the new scene 5.1.2.3 osg::stateset AbstractScene::getOrCreateState () [virtual] Getter: Returns the StateSet associated to the scene Returns: the scene s StateSet 5.1.2.4 void AbstractScene::setState (osg::stateset s) [virtual] Setter: Changes the StateSet associated with the scene with the one specified in the paramater Parameters: s the StateSet 5.1.2.5 void AbstractScene::removeAttribute (osg::stateattribute s) [virtual] Remove an attribute from the stateset attached to the scene Parameters: s the StateSet to remove

5.1 AbstractScene Class Reference 11 5.1.2.6 void AbstractScene::setAttribute (osg::stateattribute s, osg::stateattribute::overridevalue value = osg::stateattribute::off) [virtual] Apply an override mode to the state: Parameters: s the StateSet to turn on or off value to apply to the stateset: (OFF, ON, OVERRIDE, PROTECTED, INHERIT) 5.1.2.7 void AbstractScene::setAttributeAndModes (osg::stateattribute s, osg::stateattribute::glmodevalue value = osg::stateattribute::on) [virtual] Turn on or off an attribute Parameters: s the StateSet to turn on or off value to apply to the stateset: (OFF, ON, OVERRIDE, PROTECTED, INHERIT) 5.1.2.8 osg::stateattribute AbstractScene::getAttribute (osg::stateattribute::type type, unsigned int member = 0) [virtual] Get specified StateAttribute for specified type. Parameters: type the type we want to get the StateAttribute member default value is NULL Returns: Returns NULL if no type is contained within StateSet. 5.1.2.9 void AbstractScene::ajouterDB (const wxstring & path) [virtual] Add a folder to the osgdb database. Parameters: path Folder to add

12 Data Structure Documentation 5.1.3 Field Documentation 5.1.3.1 osg::ref_ptr<osg::group> AbstractScene::scene [protected] The documentation for this class was generated from the following files: AbstractScene.h AbstractScene.cpp

5.2 App Class Reference 13 5.2 App Class Reference #include <App.h> Public Member Functions bool OnInit () Main program equivalent, create the window. 5.2.1 Member Function Documentation 5.2.1.1 bool App::OnInit () Initialisation function. Returns: Returns true if initialisation succeed The documentation for this class was generated from the following files: App.h App.cpp

14 Data Structure Documentation 5.3 Canvas Class Reference #include <Canvas.h> Public Member Functions Canvas (wxwindow parent, wxwindowid id=wxid_any, const wxpoint &pos=wxdefaultposition, const wxsize &size=wxdefaultsize, long style=0, const wxstring &name=wxt("testglcanvas"), int attributes=0) Canvas () Destructor. void init () Initialisatio function. void OnPaint (wxpaintevent &event) void OnSize (wxsizeevent &event) void OnEraseBackground (wxeraseevent &event) void OnKeyDown (wxkeyevent &event) void OnKeyUp (wxkeyevent &event) void OnMouse (wxmouseevent &event) void grabfocus () Grab the focus. void grabfocusifpointerinwindow () Grab the focus if the mouse pointer is in the window. void usecursor (bool cursoron) bool makecurrentimplementation () Make the current canvas the current one. void swapbuffersimplementation () Swap the buffers. virtual bool valid () const virtual bool realizeimplementation () virtual bool isrealizedimplementation () const virtual void closeimplementation () virtual bool releasecontextimplementation ()

5.3 Canvas Class Reference 15 5.3.1 Constructor & Destructor Documentation 5.3.1.1 Canvas::Canvas (wxwindow parent, wxwindowid id = wxid_any, const wxpoint & pos = wxdefaultposition, const wxsize & size = wxdefaultsize, long style = 0, const wxstring & name = wxt("testglcanvas"), int attributes = 0) Constructor Parameters: parent the parent window. id the window identifier. pos position of the canvas. size size of the canvas. style style of the canvas.(wxdefault_frame_style) name the name of the canvas. attributes an array of the attributes of the canvas. 5.3.1.2 Canvas:: Canvas () 5.3.2 Member Function Documentation 5.3.2.1 void Canvas::init () 5.3.2.2 void Canvas::OnPaint (wxpaintevent & event) Invoked on a on paint event Parameters: event the event 5.3.2.3 void Canvas::OnSize (wxsizeevent & event) Invoked on a OnPaint event Parameters: event the event 5.3.2.4 void Canvas::OnEraseBackground (wxeraseevent & event) Invoked on a OnEraseBackground event Parameters: event the event

16 Data Structure Documentation 5.3.2.5 void Canvas::OnKeyDown (wxkeyevent & event) Invoked on a OnKeyDown event Parameters: event the event 5.3.2.6 void Canvas::OnKeyUp (wxkeyevent & event) Invoked on a OnKeyUp event Parameters: event the event 5.3.2.7 void Canvas::OnMouse (wxmouseevent & event) Invoked on a OnMouse event Parameters: event the event 5.3.2.8 void Canvas::grabFocus () 5.3.2.9 void Canvas::grabFocusIfPointerInWindow () 5.3.2.10 void Canvas::useCursor (bool cursoron) Specifies if we should use the cursor Parameters: cursoron if true, set the cursor use to on

5.3 Canvas Class Reference 17 5.3.2.11 bool Canvas::makeCurrentImplementation () 5.3.2.12 void Canvas::swapBuffersImplementation () 5.3.2.13 virtual bool Canvas::valid () const [inline, virtual] 5.3.2.14 virtual bool Canvas::realizeImplementation () [inline, virtual] 5.3.2.15 virtual bool Canvas::isRealizedImplementation () const [inline, virtual] 5.3.2.16 virtual void Canvas::closeImplementation () [inline, virtual] 5.3.2.17 virtual bool Canvas::releaseContextImplementation () [inline, virtual] The documentation for this class was generated from the following files: Canvas.h Canvas.cpp

18 Data Structure Documentation 5.4 ConsoleFrame Class Reference #include <ConsoleFrame.h> Public Member Functions ConsoleFrame (wxwindow parent, wxwindowid id=-1, const wxpoint &pos=wxdefaultposition, const wxsize &size=wxdefaultsize, long style=0) void settext (const wxstring &txt) 5.4.1 Constructor & Destructor Documentation 5.4.1.1 ConsoleFrame::ConsoleFrame (wxwindow parent, wxwindowid id = -1, const wxpoint & pos = wxdefaultposition, const wxsize & size = wxdefaultsize, long style = 0) Constructor Parameters: parent the parent window. id the window identifier. pos position of the text control. size size of the text control. style style of the text control.(wxdefault_frame_style) 5.4.2 Member Function Documentation 5.4.2.1 void ConsoleFrame::setText (const wxstring & txt) This function set the text to print on the console. Parameters: txt the text to write into the console The documentation for this class was generated from the following files: ConsoleFrame.h ConsoleFrame.cpp

5.5 Controleur Class Reference 19 5.5 Controleur Class Reference #include <Controleur.h> Public Member Functions Controleur () Constructor. virtual Controleur () Destructor. virtual void setactiveproject (Projet p) virtual void setblurop (OptionFlous op) virtual void OnMenuClick (wxcoord id, MainFrame window) virtual void changerayonorsigmaordepth (wxscrollevent &evt) virtual void updateshader () Event invoked when user click the updateshader button. virtual void changelighten (wxscrollevent &evt) 5.5.1 Constructor & Destructor Documentation 5.5.1.1 Controleur::Controleur () 5.5.1.2 Controleur:: Controleur () [virtual] 5.5.2 Member Function Documentation 5.5.2.1 void Controleur::setActiveProject (Projet p) [virtual] Change the current project Parameters: p the new project 5.5.2.2 void Controleur::setBlurOp (OptionFlous op) [virtual] Changes the blur options Parameters: op the new options

20 Data Structure Documentation 5.5.2.3 void Controleur::OnMenuClick (wxcoord id, MainFrame window) [virtual] Event invoked when user clicks on an icon Parameters: id the point coordinate of the click window the main window 5.5.2.4 void Controleur::changeRayonOrSigmaOrDepth (wxscrollevent & evt) [virtual] Event invoked when user changes a slider Parameters: evt the event 5.5.2.5 void Controleur::updateShader () [virtual] 5.5.2.6 void Controleur::changeLighten (wxscrollevent & evt) [virtual] Event invoked when user changes a slider Parameters: evt the event The documentation for this class was generated from the following files: Controleur.h Controleur.cpp

5.6 DecorateurScene Class Reference 21 5.6 DecorateurScene Class Reference #include <DecorateurScene.h> Inherits MScene. Inherited by Flous, PointLumineux, ProjectionSpherique, and TacheDeMariotte. Public Member Functions DecorateurScene (void) Default Constructor. virtual DecorateurScene (void) Destructor. virtual osg::node getscene () virtual void setscene (osg::node n) Protected Attributes MScene mscene The scene to decorate. 5.6.1 Constructor & Destructor Documentation 5.6.1.1 DecorateurScene::DecorateurScene (void) 5.6.1.2 DecorateurScene:: DecorateurScene (void) [virtual] 5.6.2 Member Function Documentation 5.6.2.1 osg::node DecorateurScene::getScene () [virtual] Returns the decorated scene Returns: the decorated scene Reimplemented from MScene (p. 31). Reimplemented in Flous (p. 24), and TacheDeMariotte (p. 44).

22 Data Structure Documentation 5.6.2.2 void DecorateurScene::setScene (osg::node n) [virtual] Set the current decorated scene to a new one represented by the paramater n Parameters: n the new scene Reimplemented from MScene (p. 31). Reimplemented in Flous (p. 24), and TacheDeMariotte (p. 44). 5.6.3 Field Documentation 5.6.3.1 MScene DecorateurScene::mscene [protected] The documentation for this class was generated from the following files: DecorateurScene.h DecorateurScene.cpp

5.7 Flous Class Reference 23 5.7 Flous Class Reference #include <Flous.h> Inherits DecorateurScene. Public Member Functions Flous (MScene s, osgviewer::viewer viewer, const int p=50) virtual Flous () Destructor. void changefragshader (int w, int h, int depthlimite, int rayonfocal, float coef, float lod) wxstring getfragshadersource () void setshadersource (wxstring source) virtual void setscene (osg::node n) virtual osg::node getscene () 5.7.1 Constructor & Destructor Documentation 5.7.1.1 Flous::Flous (MScene s, osgviewer::viewer viewer, const int p = 50) Constructor Parameters: s the scene viewer the main viewer p 5.7.1.2 Flous:: Flous () [virtual] 5.7.2 Member Function Documentation 5.7.2.1 void Flous::changeFragShader (int w, int h, int depthlimite, int rayonfocal, float coef, float lod) Change the fragment shader source dynamically Parameters: w weight h height depthlimite the depth where there is no blur effect rayonfocal radius of the blur-free area

24 Data Structure Documentation coef coefficient for increase of blur effect lod lod used for texture lookup when doing convolution 5.7.2.2 wxstring Flous::getFragShaderSource () Get the source of the current Fragment shader Returns: wxstring the source 5.7.2.3 void Flous::setShaderSource (wxstring source) Set a new Fragment Shader source Parameters: source the source code 5.7.2.4 void Flous::setScene (osg::node n) [virtual] Set the scene to a new one Parameters: n the new scene Reimplemented from DecorateurScene (p. 22). 5.7.2.5 osg::node Flous::getScene () [virtual] Returns: the current scene Reimplemented from DecorateurScene (p. 21). The documentation for this class was generated from the following files: Flous.h Flous.cpp

5.8 KeyboardEventHandler Class Reference 25 5.8 KeyboardEventHandler Class Reference #include <KeyHandler.h> Public Member Functions KeyboardEventHandler (MScene s) virtual bool handle (const osgga::guieventadapter &ea, osgga::guiactionadapter &ea1) virtual void accept (osgga::guieventhandlervisitor &v) Protected Attributes MScene scene Pointer to the scene, simply cast this instance into the one you want in the decorator sub classes to get the class methods. 5.8.1 Constructor & Destructor Documentation 5.8.1.1 KeyboardEventHandler::KeyboardEventHandler (MScene s) [inline] Constructor Parameters: s the scene 5.8.2 Member Function Documentation 5.8.2.1 virtual bool KeyboardEventHandler::handle (const osgga::guieventadapter & ea, osgga::guiactionadapter & ea1) [inline, virtual] Invoked each time an event on the canvas occurs Parameters: ea the event ea1 not used event Returns: true if teh event has been correctly handled

26 Data Structure Documentation 5.8.2.2 virtual void KeyboardEventHandler::accept (osgga::guieventhandlervisitor & v) [inline, virtual] Intern fonction that visit nodes Parameters: v visitor for the event handlers 5.8.3 Field Documentation 5.8.3.1 MScene KeyboardEventHandler::scene [protected] The documentation for this class was generated from the following file: KeyHandler.h

5.9 KeyHandler Class Reference 27 5.9 KeyHandler Class Reference #include <KeyHandler.h> The documentation for this class was generated from the following file: KeyHandler.h

28 Data Structure Documentation 5.10 MainFrame Class Reference #include <MainFrame.h> Public Member Functions MainFrame (wxframe frame, const wxstring &title, const wxpoint &pos, const wxsize &size, long style=wxdefault_frame_style) MainFrame () Destructor. virtual Projet createproject (const wxstring &n) virtual void closeproject () virtual ToolBarFiltre gettbfilter () 5.10.1 Constructor & Destructor Documentation 5.10.1.1 MainFrame::MainFrame (wxframe frame, const wxstring & title, const wxpoint & pos, const wxsize & size, long style = wxdefault_frame_style) Constructor Parameters: frame main window title window title pos window position size window size style window style (default is wxdefault_frame_style) 5.10.1.2 MainFrame:: MainFrame () 5.10.2 Member Function Documentation 5.10.2.1 Projet MainFrame::createProject (const wxstring & n) [virtual] Creates a project from the path of the model Parameters: n the path of the model Returns: the newly created project

5.10 MainFrame Class Reference 29 5.10.2.2 void MainFrame::closeProject () [virtual] Closes a project (just a tab) 5.10.2.3 ToolBarFiltre MainFrame::getTBFilter () [virtual] Returns: Get the filters toolbar The documentation for this class was generated from the following files: MainFrame.h MainFrame.cpp

30 Data Structure Documentation 5.11 MScene Class Reference #include <MScene.h> Inherited by DecorateurScene. Public Member Functions MScene (void) Default Constructor. MScene (osg::node s) virtual MScene (void) Destructor. virtual osg::node getscene () virtual void setscene (osg::node n) virtual osg::stateset getorcreatestate () virtual void setstate (osg::stateset s) virtual void removeattribute (osg::stateattribute s) virtual void setattribute (osg::stateattribute s, osg::stateattribute::overridevalue value=osg::stateattribute::off) Override is used to specify the override behavior of StateAttributes from parent to children. virtual void setattributeandmodes (osg::stateattribute s, osg::stateattribute::glmodevalue value=osg::stateattribute::on) GLModeValue is used to specify whether a mode is enabled (ON) or disabled (OFF). virtual osg::stateattribute getattribute (osg::stateattribute::type type, unsigned int member=0) virtual void ajouterdb (const wxstring &path) 5.11.1 Constructor & Destructor Documentation 5.11.1.1 MScene::MScene (void) 5.11.1.2 MScene::MScene (osg::node s) Constructor Parameters: s Node to attach to the scene when creating the scene

5.11 MScene Class Reference 31 5.11.1.3 MScene:: MScene (void) [virtual] 5.11.2 Member Function Documentation 5.11.2.1 osg::node MScene::getScene () [virtual] Getter: Returns the node attached to the scene (the scene) Returns: the scene s node Reimplemented in DecorateurScene (p. 21), Flous (p. 24), and TacheDeMariotte (p. 44). 5.11.2.2 void MScene::setScene (osg::node n) [virtual] Setter: Changes the node attached to the scene with the one specified in the parameter Parameters: n the node to change to Reimplemented in DecorateurScene (p. 22), Flous (p. 24), and TacheDeMariotte (p. 44). 5.11.2.3 osg::stateset MScene::getOrCreateState () [virtual] Getter: Returns the StateSet associated to the scene Returns: the scene s StateSet 5.11.2.4 void MScene::setState (osg::stateset s) [virtual] Setter: Changes the StateSet associated with the scene with the one specified in the paramater Parameters: s the StateSet 5.11.2.5 void MScene::removeAttribute (osg::stateattribute s) [virtual] Remove an attribute from the stateset attached to the scene Parameters: s the StateSet to remove

32 Data Structure Documentation 5.11.2.6 void MScene::setAttribute (osg::stateattribute s, osg::stateattribute::overridevalue value = osg::stateattribute::off) [virtual] Apply an override mode to the state: Parameters: s the StateSet to turn on or off value to apply to the stateset: (OFF, ON, OVERRIDE, PROTECTED, INHERIT) 5.11.2.7 void MScene::setAttributeAndModes (osg::stateattribute s, osg::stateattribute::glmodevalue value = osg::stateattribute::on) [virtual] Turn on or off an attribute Parameters: s the StateSet to turn on or off value to apply to the stateset: (OFF, ON, OVERRIDE, PROTECTED, INHERIT) 5.11.2.8 osg::stateattribute MScene::getAttribute (osg::stateattribute::type type, unsigned int member = 0) [virtual] Get specified StateAttribute for specified type. Parameters: type the type we want to get the StateAttribute member default value is NULL Returns: Returns NULL if no type is contained within StateSet. 5.11.2.9 void MScene::ajouterDB (const wxstring & path) [virtual] Add a folder to the osgdb database. Parameters: path Folder to add The documentation for this class was generated from the following files: MScene.h MScene.cpp

5.12 OptionFlous Class Reference 33 5.12 OptionFlous Class Reference #include <OptionFlous.h> Public Member Functions OptionFlous (Controleur ctrl, wxframe parent, const wxstring &title="optionflous", const wxpoint &pos=wxdefaultposition, const wxsize &size=wxdefaultsize, long style=wxdefault_frame_style) virtual OptionFlous (void) Destructor. Data Fields wxstatictext textvalcoeff The text who display the value of the slider slidecoefaug. wxstatictext textvallod The text who display the value of the slider slidelod. wxslider slidelod A slider who manage the LOD for the blur. wxslider slidedepth A slider who manage the depth for the blur. wxslider sliderf A slider who manage the focal length. wxslider slidecoefaug A slider who manage the augmentation coefficient. wxslider slidelight A slider who manage the light. 5.12.1 Constructor & Destructor Documentation 5.12.1.1 OptionFlous::OptionFlous (Controleur ctrl, wxframe parent, const wxstring & title = "OptionFlous", const wxpoint & pos = wxdefaultposition, const wxsize & size = wxdefaultsize, long style = wxdefault_frame_style) Constructor

34 Data Structure Documentation Parameters: ctrl the frame controller. parent the parent window. title the window title pos position of the window. size size of the window. style window s style. (wxdefault_frame_style) 5.12.1.2 OptionFlous:: OptionFlous (void) [virtual] 5.12.2 Field Documentation 5.12.2.1 wxstatictext OptionFlous::textValCoeff 5.12.2.2 wxstatictext OptionFlous::textValLOD 5.12.2.3 wxslider OptionFlous::slideLOD 5.12.2.4 wxslider OptionFlous::slideDepth 5.12.2.5 wxslider OptionFlous::slideRF 5.12.2.6 wxslider OptionFlous::slideCoefAug 5.12.2.7 wxslider OptionFlous::slideLight The documentation for this class was generated from the following files: OptionFlous.h OptionFlous.cpp

5.13 PointLumineux Class Reference 35 5.13 PointLumineux Class Reference #include <PointLumineux.h> Inherits DecorateurScene. Public Member Functions PointLumineux (MScene s, osgviewer::viewer v, Canvas can) virtual PointLumineux (void) Destructor. void togglelight () Toggle the light. void setshadersource (const wxstring &source) const wxstring getfragshadersource () void createshader () Create a Fragment Shader. 5.13.1 Constructor & Destructor Documentation 5.13.1.1 PointLumineux::PointLumineux (MScene s, osgviewer::viewer v, Canvas can) Constructor Parameters: s the scene in which we want to attach the spot v the viewer can the canvas 5.13.1.2 PointLumineux:: PointLumineux (void) [virtual] 5.13.2 Member Function Documentation 5.13.2.1 void PointLumineux::toggleLight () 5.13.2.2 void PointLumineux::setShaderSource (const wxstring & source) Set a new Fragment Shader source Parameters: source the source code

36 Data Structure Documentation 5.13.2.3 const wxstring PointLumineux::getFragShaderSource () Get the source of the current Fragment shader Returns: wxstring the source 5.13.2.4 void PointLumineux::createShader () The documentation for this class was generated from the following files: PointLumineux.h PointLumineux.cpp

5.14 ProjectionSpherique Class Reference 37 5.14 ProjectionSpherique Class Reference #include <ProjectionSpherique.h> Inherits DecorateurScene. Public Member Functions ProjectionSpherique (MScene s, osg::ref_ptr< osgviewer::viewer > &viewer, const int w, const int h) virtual ProjectionSpherique (void) Destructor. 5.14.1 Constructor & Destructor Documentation 5.14.1.1 ProjectionSpherique::ProjectionSpherique (MScene s, osg::ref_ptr< osgviewer::viewer > & viewer, const int w, const int h) Constructor Parameters: s the scene viewer the main viewer of the scene w width of the canvas h height of the canvas 5.14.1.2 ProjectionSpherique:: ProjectionSpherique (void) [virtual] The documentation for this class was generated from the following files: ProjectionSpherique.h ProjectionSpherique.cpp

38 Data Structure Documentation 5.15 Projet Class Reference #include <Projet.h> Public Member Functions Projet (wxwindow parent, wxwindowid id, const wxstring &title, const wxpoint &pos=wxdefaultposition, const wxsize &size=wxdefaultsize, long style=wxsunken_border) virtual Projet () Destructor. virtual bool setscene (wxstring s) virtual bool setfilter (int id) virtual Flous getblur () virtual bool isblur () virtual PointLumineux getlight () virtual bool islight () virtual void writeconsole (const wxstring &s) virtual wxstring getconsolevalue () 5.15.1 Constructor & Destructor Documentation 5.15.1.1 Projet::Projet (wxwindow parent, wxwindowid id, const wxstring & title, const wxpoint & pos = wxdefaultposition, const wxsize & size = wxdefaultsize, long style = wxsunken_border) Constructor Parameters: parent The parent window. title the window title id the window identifier. pos position of the window. size size of the window. style style of the window. (wxsunken_border) 5.15.1.2 Projet:: Projet () [virtual] 5.15.2 Member Function Documentation 5.15.2.1 bool Projet::setScene (wxstring s) [virtual] This function load a scene from the path s.

5.15 Projet Class Reference 39 Parameters: s the path of the scene. Returns: true if the scene is load, else false. 5.15.2.2 bool Projet::setFilter (int id) [virtual] This function add a filter to the current scene. Parameters: id an identifier for the filter. Returns: true if the filter is applied, else false. 5.15.2.3 Flous Projet::getBlur () [virtual] This function give a pointer to the blur model scene. Returns: a pointer to the model scene if the scene is blur, else NULL. 5.15.2.4 bool Projet::isBlur () [virtual] Returns: true if the scene is blur, else false. 5.15.2.5 PointLumineux Projet::getLight () [virtual] This function give a pointer to the lighten model scene. Returns: a pointer to the model scene if the scene is lighten, else NULL. 5.15.2.6 bool Projet::isLight () [virtual] Returns: true if the scene is lighten, else false.

40 Data Structure Documentation 5.15.2.7 void Projet::writeConsole (const wxstring & s) [virtual] This function write a text on the console. Parameters: s the text to write to the text control. 5.15.2.8 wxstring Projet::getConsoleValue () [virtual] This function allow to get the text in the text control. Returns: the text in the console. The documentation for this class was generated from the following files: Projet.h Projet.cpp

5.16 SceneFrame Class Reference 41 5.16 SceneFrame Class Reference #include <SceneFrame.h> Public Member Functions SceneFrame (wxwindow parent, const wxstring &title, const wxpoint &pos, const wxsize &size, long style=wxdefault_frame_style) virtual osg::ref_ptr< osgviewer::viewer > getviewer () virtual void SetViewer (osg::ref_ptr< osgviewer::viewer > viewer) virtual void OnIdle (wxidleevent &event) virtual Canvas getcanvas () virtual Canvas initcanvas () virtual Flous getblur () virtual bool isblur () virtual void setblur (Flous f) virtual PointLumineux getlight () virtual bool islight () virtual void setlight (PointLumineux pt) 5.16.1 Constructor & Destructor Documentation 5.16.1.1 SceneFrame::SceneFrame (wxwindow parent, const wxstring & title, const wxpoint & pos, const wxsize & size, long style = wxdefault_frame_style) Constructor Parameters: parent The parent window. title title of the window. pos position of the window. size size of the window. style style of the window. (wxdefault_frame_style) 5.16.2 Member Function Documentation 5.16.2.1 osg::ref_ptr< osgviewer::viewer > SceneFrame::getViewer () [virtual] This function give a ref_ptr to the current viewer. Returns: a ref_ptr to the current viewer.

42 Data Structure Documentation 5.16.2.2 void SceneFrame::SetViewer (osg::ref_ptr< osgviewer::viewer > viewer) [virtual] This function set a new viewer to the frame. Parameters: viewer a ref_ptr<osgviewer::viewer> to the viewer. 5.16.2.3 void SceneFrame::OnIdle (wxidleevent & event) [virtual] Handled events of the window Parameters: event the event 5.16.2.4 Canvas SceneFrame::getCanvas () [virtual] This function give a pointer to the canvas. Returns: a pointer to the canvas. 5.16.2.5 Canvas SceneFrame::initCanvas () [virtual] This function initialise a new canvas the return a pointer to him. Returns: a pointer to the created canvas. 5.16.2.6 Flous SceneFrame::getBlur () [virtual] This function give a pointer to the blur model scene. Returns: a pointer to the model scene if the scene is blur, else NULL. 5.16.2.7 bool SceneFrame::isBlur () [virtual] Returns: true if the scene is blur, else false.

5.16 SceneFrame Class Reference 43 5.16.2.8 void SceneFrame::setBlur (Flous f) [virtual] This function set a pointer to the blur model scene. Parameters: f a pointer to the blur model scene. 5.16.2.9 PointLumineux SceneFrame::getLight () [virtual] This function give a pointer to the lighten model scene. Returns: a pointer to the model scene if the scene is lighten, else NULL. 5.16.2.10 bool SceneFrame::isLight () [virtual] Returns: true if the scene is lighten, else false. 5.16.2.11 void SceneFrame::setLight (PointLumineux pt) [virtual] This function set a pointer to the lighten model scene. Parameters: pt a pointer to the lighten model scene. The documentation for this class was generated from the following files: SceneFrame.h SceneFrame.cpp

44 Data Structure Documentation 5.17 TacheDeMariotte Class Reference #include <TacheDeMariotte.h> Inherits DecorateurScene. Public Member Functions void createsubgraph (const osg::vec4 &, int rayon) TacheDeMariotte (MScene, osgviewer::viewer viewer, int rayon) virtual TacheDeMariotte () virtual osg::node getscene () osg::ref_ptr< osg::texture2d > GetTexture () virtual void setscene (osg::node ) 5.17.1 Constructor & Destructor Documentation 5.17.1.1 TacheDeMariotte::TacheDeMariotte (MScene s, osgviewer::viewer viewer, int rayon) 5.17.1.2 TacheDeMariotte:: TacheDeMariotte (void) [virtual] 5.17.2 Member Function Documentation 5.17.2.1 void TacheDeMariotte::createSubGraph (const osg::vec4 & clearcolour, int rayon) 5.17.2.2 osg::node TacheDeMariotte::getScene () [virtual] Returns the decorated scene Returns: the decorated scene Reimplemented from DecorateurScene (p. 21). 5.17.2.3 osg::ref_ptr< osg::texture2d > TacheDeMariotte::GetTexture () 5.17.2.4 void TacheDeMariotte::setScene (osg::node n) [virtual] Set the current decorated scene to a new one represented by the paramater n Parameters: n the new scene

5.17 TacheDeMariotte Class Reference 45 Reimplemented from DecorateurScene (p. 22). The documentation for this class was generated from the following files: TacheDeMariotte.h TacheDeMariotte.cpp

46 Data Structure Documentation 5.18 ToolBarFiltre Class Reference #include <ToolBarFiltre.h> Public Member Functions ToolBarFiltre (wxwindow parent, wxwindowid id=-1, const wx- Point &pos=wxdefaultposition, const wxsize &size=wxdefaultsize, long style=wxtb_vertical wxno_border) virtual ToolBarFiltre () Destructor. 5.18.1 Constructor & Destructor Documentation 5.18.1.1 ToolBarFiltre::ToolBarFiltre (wxwindow parent, wxwindowid id = -1, const wxpoint & pos = wxdefaultposition, const wxsize & size = wxdefaultsize, long style = wxtb_vertical wxno_border) Constructor Parameters: parent the parent window. id the window identifier. pos position of the toolbar. size size of the toolbar. style style of the toolbar.(wxtb_vertical wxno_border) 5.18.1.2 ToolBarFiltre:: ToolBarFiltre () [virtual] The documentation for this class was generated from the following files: ToolBarFiltre.h ToolBarFiltre.cpp

Chapter 6 File Documentation 6.1 AbstractScene.cpp File Reference

48 File Documentation 6.2 AbstractScene.h File Reference Data Structures class AbstractScene

6.3 App.cpp File Reference 49 6.3 App.cpp File Reference

50 File Documentation 6.4 App.h File Reference Launcher of the application. Data Structures class App 6.4.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

6.5 Canvas.cpp File Reference 51 6.5 Canvas.cpp File Reference Functions BEGIN_EVENT_TABLE (Canvas, wxglcanvas) EVT_SIZE(Canvas 6.5.1 Function Documentation 6.5.1.1 BEGIN_EVENT_TABLE (Canvas, wxglcanvas)

52 File Documentation 6.6 Canvas.h File Reference Paint pane to display OpenGL components. Data Structures class Canvas 6.6.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 20/04/2008

6.7 Common.h File Reference 53 6.7 Common.h File Reference

54 File Documentation 6.8 ConsoleFrame.cpp File Reference

6.9 ConsoleFrame.h File Reference 55 6.9 ConsoleFrame.h File Reference Text control for display message. Data Structures class ConsoleFrame 6.9.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

56 File Documentation 6.10 Controleur.cpp File Reference

6.11 Controleur.h File Reference 57 6.11 Controleur.h File Reference Window and tabpane controller. Data Structures class Controleur 6.11.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 20/04/2008

58 File Documentation 6.12 DecorateurScene.cpp File Reference

6.13 DecorateurScene.h File Reference 59 6.13 DecorateurScene.h File Reference Abstract class that allow creation of differents filters on a scene. Data Structures class DecorateurScene 6.13.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 27/02/2008

60 File Documentation 6.14 Flous.cpp File Reference

6.15 Flous.h File Reference 61 6.15 Flous.h File Reference This filter computes a blur on a given Mscene. Data Structures class Flous 6.15.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/01/2008

62 File Documentation 6.16 KeyHandler.h File Reference EventManager (keyboard, mouse,...) for the canvas. Data Structures class KeyboardEventHandler 6.16.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 02/03/2008 See also: http://www.openscenegraph.org/projects/osg/wiki/support/tutorials/basick

6.17 MainFrame.cpp File Reference 63 6.17 MainFrame.cpp File Reference Functions BEGIN_EVENT_TABLE (MainFrame, wxframe) EVT_MENU(-1 MainFrame::OnMenuClick EVT_AUI_PANE_CLOSE (Main- Frame::OnPaneClose) EVT_AUINOTEBOOK_PAGE_CLOSE(ID_- NOTEBOOK MainFrame::OnMenuClick MainFrame::OnNoteBookClose EVT_- AUINOTEBOOK_PAGE_CHANGED (ID_NOTEBOOK, Main- Frame::OnPageChange) END_EVENT_TABLE() MainFrame 6.17.1 Function Documentation 6.17.1.1 BEGIN_EVENT_TABLE (MainFrame, wxframe) 6.17.1.2 MainFrame::OnMenuClick EVT_AUI_PANE_CLOSE (MainFrame::OnPaneClose) 6.17.1.3 MainFrame::OnMenuClick MainFrame::OnNoteBookClose EVT_AUINOTEBOOK_PAGE_CHANGED (ID_NOTEBOOK, MainFrame::OnPageChange)

64 File Documentation 6.18 MainFrame.h File Reference This class permit to display the program. Data Structures class MainFrame 6.18.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

6.19 MScene.cpp File Reference 65 6.19 MScene.cpp File Reference

66 File Documentation 6.20 MScene.h File Reference The scene model that we want to show. Data Structures class MScene 6.20.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 25/02/2008

6.21 OptionFlous.cpp File Reference 67 6.21 OptionFlous.cpp File Reference Functions BEGIN_EVENT_TABLE (OptionFlous, wxwindow) EVT_COMMAND_- SCROLL(ID_SLIDE_DEPTH OptionFlous::changeSlide EVT_COMMAND_SCROLL (ID_SLIDE_RF, OptionFlous::changeSlide) EVT_COMMAND_SCROLL(ID_SLIDE_LOD OptionFlous::changeSlide OptionFlous::changeSlide EVT_COMMAND_- SCROLL (ID_SLIDE_COEFAUG, OptionFlous::changeSlide) EVT_- COMMAND_SCROLL(ID_SLIDE_LIGHT OptionFlous::changeSlide OptionFlous::changeSlide OptionFlous::changeSlide EVT_BUTTON (ID_BUTTON_UPDATE, OptionFlous::updateShader) END_- EVENT_TABLE() OptionFlous 6.21.1 Function Documentation 6.21.1.1 BEGIN_EVENT_TABLE (OptionFlous, wxwindow) 6.21.1.2 OptionFlous::changeSlide OptionFlous::changeSlide OptionFlous::changeSlide EVT_BUTTON (ID_BUTTON_UPDATE, OptionFlous::updateShader) 6.21.1.3 OptionFlous::changeSlide OptionFlous::changeSlide EVT_COMMAND_SCROLL (ID_SLIDE_COEFAUG, OptionFlous::changeSlide) 6.21.1.4 OptionFlous::changeSlide EVT_COMMAND_SCROLL (ID_SLIDE_RF, OptionFlous::changeSlide)

68 File Documentation 6.22 OptionFlous.h File Reference This class gives tools to manage the blur. Data Structures class OptionFlous 6.22.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 22/04/2008

6.23 PointLumineux.cpp File Reference 69 6.23 PointLumineux.cpp File Reference

70 File Documentation 6.24 PointLumineux.h File Reference This class adds a light point to the scene and allows simualtion of a glare. Data Structures class PointLumineux Typedefs typedef unsigned int uint 6.24.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 02/03/2008 6.24.2 Typedef Documentation 6.24.2.1 typedef unsigned int uint

6.25 ProjectionSpherique.cpp File Reference 71 6.25 ProjectionSpherique.cpp File Reference

72 File Documentation 6.26 ProjectionSpherique.h File Reference This filter deforms the current scene regarding defined deformation curves. Data Structures class ProjectionSpherique 6.26.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

6.27 Projet.cpp File Reference 73 6.27 Projet.cpp File Reference Functions BEGIN_EVENT_TABLE (Projet, wxwindow) END_EVENT_TABLE() Projet 6.27.1 Function Documentation 6.27.1.1 BEGIN_EVENT_TABLE (Projet, wxwindow)

74 File Documentation 6.28 Projet.h File Reference This class permits to create a window who contains a scene and a text control for each instance of Projet (p. 38). The projet are used in the auinotebook on the class MainFrame (p. 28). Data Structures class Projet 6.28.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

6.29 SceneFrame.cpp File Reference 75 6.29 SceneFrame.cpp File Reference Functions BEGIN_EVENT_TABLE (SceneFrame, wxwindow) EVT_- IDLE(SceneFrame 6.29.1 Function Documentation 6.29.1.1 BEGIN_EVENT_TABLE (SceneFrame, wxwindow)

76 File Documentation 6.30 SceneFrame.h File Reference This class allow to display a scene on a wxscrolledwindow. Data Structures class SceneFrame 6.30.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 23/04/2008

6.31 TacheDeMariotte.cpp File Reference 77 6.31 TacheDeMariotte.cpp File Reference

78 File Documentation 6.32 TacheDeMariotte.h File Reference Data Structures class TacheDeMariotte

6.33 ToolBarFiltre.cpp File Reference 79 6.33 ToolBarFiltre.cpp File Reference

80 File Documentation 6.34 ToolBarFiltre.h File Reference Data Structures class ToolBarFiltre 6.34.1 Detailed Description Author: CLERC Mickael, DELFOUR Jonathan, JULIA Matthieu, POTHIN Olivier Version: 0.1 Date: 22/04/2008