Modélisation de la vision humaineleclere/enseignements/TER/2008/Rapport/41.pdf · (e)Vision périphérique : C'est la vision de ce que l'on voit ou, vision qui détecte les mouvements

Université Montpellier IIUFR Sciences

2007 / 2008

FMIN 200 - TER

Modélisation de la vision humaine

MARIE Sylvain EncadrantsNANARD Marc

Auteurs CLERC MickaëlDELFOUR JonathanJULIA MatthieuPOTHIN Olivier

Remerciements

Nous tenons à remercier nos encadrants, Monsieur Marc Nanard du LIRMM et MonsieurSylvain Marie de NexGen, qui nous ont permis de réaliser ce projet. Nous voulons égalementremercier 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.2 Public visé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Cahier des charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Les �ltres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.2 Répartition des tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Diagramme de GANTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Organisation du projet 9

2.1 Organisation du travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.1 Organisation interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Organisation du développement . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Contraintes techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Plate-forme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Logiciel d'édition de texte et langage . . . . . . . . . . . . . . . . . . . . . 102.3.2 Manipulation de scènes en 2 ou 3 dimensions . . . . . . . . . . . . . . . . 102.3.3 Interface Graphique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Analyse du projet 12

3.1 Open Scene Graph (OSG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.1 Qu'est ce qu'un Scene Graph ? . . . . . . . . . . . . . . . . . . . . . . . . 123.1.2 Les pointeurs intelligents . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Le langage GLSL : OpenGL Shading Language . . . . . . . . . . . . . . . . . . . 13

3.3.1 Un shader ? Mais pourquoi ? . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.2 Le Vertex Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.3 Le Fragment Shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.4 Les types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.5 Les quali�cateurs : attribute, uniform, varying . . . . . . . . . . . . . . . 15

3.4 Liaison GLSL-OSG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.1 Le glShader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.2 Le glProgram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.4.3 La liaison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.5 Petit imprécis sur la physiologie de l'÷il . . . . . . . . . . . . . . . . . . . . . . . 163.5.1 Rétine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16


Table des matières

3.5.2 Cristallin & Pupille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.1 Render To Texture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Modele-Vue-Controleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.1 Modèle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.2 Vue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2.3 Controleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 Flou Gaussien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.1 Première Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.2 Premiers Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.3 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3.4 Les phénomènes d'accomodation . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 La projection sphérique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.1 La projection non linéaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.4.2 L'assemblage de projections non linéaires . . . . . . . . . . . . . . . . . . 29

5 Manuel d'utilisation 35

6 Perspectives et conclusions 36

6.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Accommodation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6.2.1 Evolution possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.3.1 Fonctionnement de l'application . . . . . . . . . . . . . . . . . . . . . . . 376.3.2 Fonctionnement du groupe de travail . . . . . . . . . . . . . . . . . . . . . 376.3.3 Problèmes rencontrés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50C.2 Séance 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.3 Séance 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.4 Séance 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.5 Séance 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.6 Séance 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.7 Séance 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

D Organigrammes 53


Table des matières

E Bibliographie 56

E.1 OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56E.2 OpenGL Shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56E.3 OpenSceneGraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56E.4 Vision humaine et couleurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57E.5 Physiologie de L'oeil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

F Documentation 58


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 lavision humaine n'est pas, ou peu faite. Le problème ne se pose pas pour les premiers, car unemodé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 (posted'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, cequi pose problème dans la mesure où cela peut entraîner une situation radicalement di�érentede 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 Ergonomics1. NexGenErgonomics est un leader dans le domaine des logiciels d'instrumentations utilisés pour étudierl'ergonomie, la biomécanique, ... Leurs produits sont utilisés dans un large panel d'organisationsmondiales : les universités, compagnies d'assurances, agences gouvernementales et divers consul-tants. 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 oupas. Il existe simplement deux états distincts : objet visible ou non visible. Cet exemple permetd'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 a�n dela rendre complète et proche de la réalité. Pour réaliser ce genre d'application, nous avons besoinde connaître un minimum la physiologie de l'÷il.

1http ://www.nexgenergo.com



1.3 Cahier des charges

Pour modéliser le plus �dèlement la vision humaine, notre logiciel prendra en entrée uneimage et appliquera di�érents �ltres sur celle-ci a�n de faire apparaître ce que verrait réellementune personne. Voici une liste des principaux �ltres que nous allons réaliser suivi de la manièredont 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 modi�er 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 autreen enlevant, modi�ant ou ajoutant des e�ets.

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èrepartie est essentielle pour la suite du sujet, c'est pourquoi nous devons tous nous documenterabondamment sur ce sujet a�n de le maîtriser. Pour la partie modélisation, la répartition destâ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 modulessupplémentaires seront nombreux. Nous avons choisit d'utiliser un framework Décorateur a�nde pouvoir ajouter les �ltres à l'image. Notre connaissance en modélisation 2D/3D étant légère,il nous est di�cile d'estimer exactement la durée que nous passerons par module.



Suite aux premières réunions avec nos tuteurs, nous avons deux �ltres à créer, et neconnaissant encore pas trop les bibliothèques, nous avons fait deux groupes de deux a�n detravailler en extrême programming.Le premier �ltre consiste à reproduire le cercle noir de l'÷il que l'on ne perçoit pas (tâche deMariotte). Cette zone aveugle se positionne au centre de l'÷il, et n'est pas perceptible lorsquenous regardons un objet. Un algorithme sera donc établit a�n d'en reproduire au mieux lescaractéristiques. Pour l'instant, l'idée sommaire est de faire la moyenne des couleurs du cercleentourant 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 appa-raissent 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 ren-due a�n d'en obtenir une vision proche de notre vue. Nous allierons au mieux vue planaire etsphérique a�n d'obtenir un dosage sans déformation importante et avec un rendu très proche denotre 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 profon-deur 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 e�ets de persistance rétinienne que nous pouvons rencontrerlorsque nous regardons un point très lumineux comme le soleil, puis basculons dans une zoneavec un éclairage normal. Ces e�ets 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 (nuitnoire). Est-ce que celui-ci s'adapte au noir ?Si le temps nous l'autorise, nous implémenterons toutes sortes d'algorithmes permettantd'améliorer notre rendu visuel, d'appliquer d'autres �ltres (vision nocturne, etc), de reproduirecertaines maladies de l'÷il (glaucome, daltonisme, etc).Les applications sont multiples et variées. Nous préférons privilégier des modules de qualité à laquantité.

1.3.3 Diagramme de GANTT

(cf. �gure en page 55).


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 sommesréunis avec M. Nanard toutes les semaines sauf lorsque nous avions des empêchements, a�n devéri�er l'avancement du projet et d'exposer de nouvelles idées quand à la direction que devaitprendre le développement de l'application. Lors de nos di�érents réunions nous avons écrit descomptes rendus que vous pouvez consulter en page 50.

2.1.1 Organisation interne

A�n de faciliter la communication entre les membres du groupe, nous avons mis en placeun 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 membresdu groupe. Nous avons utilisé un outil de versionnage a�n de se partager les sources. Cet outilde versionnage a été utilisé en combinaison avec un système de gestion de billets via Trac2

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 dansla partie Développement. Nous avons tout d'abord créé deux sous groupes, un travaillant surla tâche de Mariotte, l'autre sur l'accommodation. Puis, comme la tâche de Mariotte n'étaitqu'une étape préliminaire à la découverte du traitement d'images, le groupe qui faisait la tâchede 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 del'application a�n de traquer les éventuelles erreurs de programmation, bugs et autres fuites demémoire.

1http ://vision.frbb.net2http ://trac2.assembla.com/Vision



2.2 Contraintes techniques

2.2.1 Plate-forme

Les étapes du développement se feront en majeure partie sur Windows mais l'applicationayant pour but �nal d'être intégrée à un logiciel déjà existant, nous devons nous assurer qu'ellesera portable. Nous réaliserons donc cette application de telle sorte qu'elle soit exécutable pourla 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 e�ectué en C++ et OpenGL Shader Language (GLSL), nous utilise-rons l'IDE Microsoft Visual Studio qui o�re 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 lesPixels Shaders et sur les Vertex Shaders (cf. �gure en page 40).Les Fragment Shaders sont des programmes de transformation que nous pouvons appliquer à unpixel, essentiellement liés aux calculs des couleurs. Ces calculs sont e�ectués directement par leprocesseur graphique (GPU) ce qui permet de décharger le processeur (CPU).Les Vertex shaders sont des programmes également e�ectués par le GPU, ils s'occupent essen-tiellement des transformations géométriques des objets (changement de taille, rotation, transla-tion,...) 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 OpenSceneGraph3. OpenSceneGraph est un toolkit OpenSource, multiplate-forme pour le développement des applications graphiques de haute performance telles quedes simulateurs de vol, des jeux, la réalité virtuelle et la visualisation scienti�que. Basé autourdu concept d'un SceneGraph, il fournit un framework sur OpenGL4 permettant au programmeurde 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éecommunément par les outils de modélisation 3D et les jeux vidéo actuels. Un graphe de scèneest une collection de n÷uds renfermée dans un graphe ou une structure d'arbre. Un n÷ud peutavoir plusieurs parents et un parent plusieurs enfants ; ceci est très important car lorsque qu'uneopération est créée sur un parent, celle-ci est propagée à tout le groupe de n÷uds �ls. Dans notreprogramme, OpenSceneGraph va donc nous servir à e�ectuer ces opérations sur des groupes d'ob-jets. 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 wxWidget5, permettant de visionner, manipuler etrégler les paramètres de l'application. Utilisant des librairies open source portables, la licence de

3http ://www.openscenegraph.org4http ://www.opengl.org5http ://www.wxwidgets.org



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 donccommenté avec un style proche de la javadoc.Voici une petite explication de Doxygen tirée de wikipédia : Doxygen est un logiciel informatiquelibre permettant de créer de la documentation à partir du code source d'un programme. Pourcela, il tient compte de la grammaire du langage dans lequel est écrit le code source, ainsi quedes commentaires s'ils sont écrits dans un format particulier.

6http ://www.stack.nl/ dimitri/doxygen


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 grandepartie la compréhension des outils de développement que sont OpenSceneGraph, OpenGl et leGLSL 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 : Ungraphe de scène est une structure générale de données utilisée communément par les outils demodélisation 3D et les jeux vidéos actuels. Le graphe de scène structure de manière logiquela 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, plusparticuliè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 den÷uds renfermée dans un graphe ou une structure d'arbre. Ceci signi�e qu'un n÷ud peut avoirplusieurs enfants. Ainsi, un e�et appliqué sur un n÷ud se répercute sur ces descendants, cequi 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'unpoint de vue mathématiques, un graphe de scène est un graphe orienté acyclique qui établit unehié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'esttechniquement 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. Lesclasses �lles sont nombreuses, ici nous verrons les classes osg : :Geode et osg : :Group. Lesobjets qui peuvent être graphiquement représentés sont des instances de osg : :Drawable. Maisles osg : :Drawable ne sont pas des n÷uds, on ne peut pas les attacher directement au graphe descè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 e�et, il n'est possible d'ajouter des �ls à un n÷ud que s'ils sont instances de osg : :Group oud'une de ses sous classes.



Maintenant, pour gérer tous ces objets, il est nécessaire de disposer d'une mémoire permettantde créer ces ressources. OpenSceneGraph intègre une gestion de pointeurs référencés que nousallons expliciter.

3.1.2 Les pointeurs intelligents

Une mauvaise gestion des ressources mémoires engendre des fuites mémoires et une forteutilisation de mémoire par l'application. Le but est de détruire les pointeurs dès qu'ils ne sontplus utilisés. Par dé�nition, une ressource mémoire est quelque chose qui doit être alloué avantutilisation 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'autresréférences vers cet objet (lorsqu'un n÷ud est attaché à deux parents par exemple). Ainsi, leprincipe d'un pointeur référencé met en jeu un compteur interne associé à chaque objet quireprésente le nombre de références pointant vers cet objet. Plus précisemment, les objets qui ontce compteur intégré sont les instances de classes qui héritent de la classe osg : :Referenced. Laressource 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 comp-teurs. En OpenSceneGraph, ces pointeurs intelligents sont implémentés comme une classe tem-plate 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 a�cher une scène. Notreconnaissance en OpenGL est intimement liée à celle que nous avons d'OpenSceneGraph. OpenS-ceneGraph permet d'abstraire la couche bas niveau d'OpenGL, ainsi une méthode d'OpenSce-neGraph correspond à une autre méthode dans OpenGL, voire à un rassemblement de plusieursmé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 langagepermettant 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 stan-dardisation d'OpenGL. La programmation de notre processeur graphique (que nous appelleronsGPU 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 (avecles méthodes inhérantes aux shaders évidemment). Un vertex shader est un programme qui vaagir directement sur les sommets de la scène, quand au fragment, il va agir sur tous les pixels dela scène. Nous parlerons tout le long de fragment shader et non de pixel shader, car les fragmentsont 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 essentiel-lement jouer sur les e�ets de lumières et sur les couleurs de la scène. Or il s'agit typiquement



du type d'opérations que l'on va pouvoir réaliser en utilisant le processeur graphique. Amélio-rer le réalisme d'un rendu, rajouter des e�ets de �ou ou d'antialiasing (anticrénelage) sont unavant-goût des possibilités qu'o�rent 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éesaux vertex en entrée. Les vertex shaders sont exécutés sur ce processeur. Voici quelques opérationsréalisables depuis ce processeur : transformation sur les vertex, transformation des normales etnormalisation 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 unvertex 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 variablesmodi�ent 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 aune variable qui doit être forcément a�ecté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 uneunité programmable qui opère sur les valeurs et données associées aux fragments en entrée. Voiciquelques opérations réalisables depuis ce processeur : opération sur des valeurs interpolées, accèsaux 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 valeurspassées en entrée.



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 variablesmodi�ent directement les attributs du pixel de la scène.

1. gl_FragColor :Couleur �nale du pixel.

2. gl_FragDepth :Profondeur du pixel dans le bu�er de profondeur (depth bu�er).

A la di�érence d'un vertex, on ne peut pas modi�er la position à l'écran du pixel via lefragment shader, cependant la possibilité de pouvoir modi�er la couleur et la transparence dechaque pixel d'une scène constitue une force remarquable pour la gestion 'microscopique' d'unescène.

3.3.4 Les types

Comme chaque langage, le GLSL possède des types et des fonctions prédé�nies qui lui sontpropres même s'il a tendance à ressembler fortement au C. Ce langage procédural de haut niveauest riche en types : il inclue, outre les types hérités du C, des vecteurs et des matrices quipermettent de rendre le code plus concis pour des opérations 3D graphiques. Nous ne feronspas 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, equalou greaterThan, pour lire dans les sampler2D les couleurs d'un pixel par exemple, il existe lafonction texture*D.

3.3.5 Les quali�cateurs : attribute, uniform, varying

Ces trois quali�cateurs sont très importants, ils permettent au programme GLSL de récupererdes variables du programme principal, mais également aux vertex shader de passer des variablesaux fragment shaders.

attribute Une variable quali�ée attribute est une variable qui peut être uniquement lue par levertex shader.

uniform Une variable quali�ée uniform dans le code d'un vertex et/ou d'un fragment shaderest une variable a�ectée par le programme principal sur le processeur (CPU) que pourront lireles vertex et fragment shaders. Cette variable est déclarée dans le code du vertex ou du fragmentglobalement.

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 ellepermet au fragment de donner des informations sur des paramètres au fragment.



3.4 Liaison GLSL-OSG

Pour mieux comprendre comment fonctionne un shader et son modèle de construction, faisonsune 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 estcompilé en temps réel (runtime) pour devenir un �chier '.obj', et doit être recompilé dès que lecode 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 êtreréé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 dis-ponible 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 leursconséquences sur la vision humaine, conséquences que nous aurons donc à modéliser dans notreapplication.

3.5.1 Rétine

La rétine est une surface (couvrant 75% de la surface du globe oculaire) d'environ 0,5mm d'épaisseur située au fond de chaque ÷il tapissée de cellules photo réceptrices permettantde transformer en signaux bioélectrique les signaux lumineux reçus et les transmettre au cerveau.



Cônes et Bâtonnets

Ces cellules sont de deux types, les cônes ("verts", "bleus" et "rouges") réceptifs aux couleursmais 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 demanière hétérogène sur l'ensemble de la rétine ; les cônes étant beaucoup plus nombreux dansla fovéa (zone centrale de la rétine) et les bâtonnets dans la rétine périphérique (Voir Fig. 1 enannexe).La conséquence de cette répartition est une division de la vision humaine en une vision centraleet 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 lesvariations de luminosité en périphérie. De même, la vision centrale est plus nette le jour tandisque l'on voit mieux la nuit si l'on regarde légèrement à coté de l'objet ciblé. De plus, la zonefovéale est la seule zone où l'acuité visuelle est vraiment signi�cative, cette dernière est mêmeconsidérée comme médiocre en dehors de cette zone, qui ne correspond qu'à un angle de 3 degrésenviron. Lors de la simulation de la vision humaine à un instant t, la netteté de l'image n'estdonc pas homogène. 1En�n, les cellules photo réceptrices ont besoin d'un certain temps pour e�ectuer le traitementbiochimique 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 optiqueainsi que les vaisseaux sanguins de l'÷il. En ce point, nommé tâche de Mariotte, la rétine estcomplètement dépourvue de cellules photo réceptrices, l'÷il est donc totalement aveugle. Nousne nous apercevons de rien car le cerveau compense cette "tâche blanche". Cependant, l'absenced'information en ce point est réelle et il est donc important de la prendre en compte dans unsimulateur.

3.5.2 Cristallin & Pupille

Cristallin

Le cristallin de l'÷il peut se ramener à une lentille convergente complexe. En e�et, des musclesmodi�ent les rayons de courbure des deux faces du cristallin permettant le phénomène d'accom-modation, c'est à dire modi�er quels seront les rayons lumineux à atterrir sur la rétine et ainsipourvoir voir de près comme de loin.Il existe diverses pathologies ou malformations qui peuvent entraver ce processus, le temps d'ac-commodation 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 lorsqueplongé 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, lespupilles s'ouvrent largement la nuit a�n de permettre le passage d'un maximum de lumière, cequi fait perdre en netteté de profondeur de champ.



3.5.3 Champ de vision

Le champ visuel humain peut être décomposé en deux : la vision centrale et la vision péri-phé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é visuellecorrespond à 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 dedétecter le mouvement "ce qui bouge", de sentir "qu'il se passe quelque chose" sur les côtés. Lavision périphérique nous permet de voir ou de détecter des mouvements sur les cotés jusqu'à aumoins 90�par rapport à la vision centrale, et environ 70�en haut et en bas. Même si nous ne leressentons pas au quotidien, la vision périphérique est une vision qui déforme les objets présentsà notre alentour.


Chapitre 4 : Développement

Chapitre 4

Développement

4.1 Petit imprécis sur la modélisation de la vision humaineavec 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 lamaniè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 pourpouvoir ensuite y appliquer nos �ltres. L'utilisation d'OpenScenegraph nous a permis de réa-liser cela assez simplement. En e�et, il nous su�t de spéci�er à 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 unetexture :

camera->attach(COLOR_BUFFER,texture);

Cette caméra sera utilisée avant le rendu à l'écran, et elle même n'a�chera donc rien, du fait duRTT. Il nous faut donc ensuite a�cher à l'écran la texture que l'on a créée, et pour cela nousutilisons une deuxième caméra, qui "passera" après la première et qui place cette texture sur unrectangle de taille de notre canvas.



4.2 Modele-Vue-Controleur

Nous avons utilisé le patron Modele-Vue-Controleur pour gérer notre application (cf. �gureen page 46). A�n de mieux comprendre comment tout cela est articulé, nous avons égalementfourni un diagramme de classe d'analyse permettant de se rendre compte de la hiérarchie descomposants 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) carcelui-ci correspond exactement à ce que nous voulions faire. Nous avions une scène de base à la-quelle 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 lesfonctions nécessaires aux modi�cations sur la scène, puis une classe abstraite DécorateurScenede laquelle hérite nos �ltres. Ainsi nous pouvons ajouter des �ltres comme bon nous semble etles a�ecter à 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 uneinterface simple d'utilisation tout en essayant de rendre celle-ci la plus attrayante possible. Pourcela nous avons donc décidé de créer un certain nombre de barre d'outils et de fenêtre d'optionsqui permettent à l'utilisateur d'ajouter d'actionner des �ltres, de les personnaliser de façon trèssimple. Nous avons aussi choisi de créer une interface dans laquelle, l'utilisateur pourra ouvrirplusieurs 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 wxAppqui est la classe permettant de créer une application. À la création de l'application, unefenêtre principale (MainFrame) dérivant d'une wxFrame est créée. Cette fenêtre est gérée parun wxAuiManager qui nous permet de choisir un style particulier à celle-ci. En combinantwxAuiManager et wxAuiPaneInfo nous pouvons choisir les options des objets à inclure à cettefenêtre telles l'emplacement, la taille, l'a�chage d'une croix pour fermer la sous fenêtre, lapossibilité de déplacer les fenêtres. La classe MainFrame possède des barres d'outils d'activationou de désactivation des �ltres via des boutons, des fenêtres pour gérer les options des �ltres, unebarre de menu et un gestionnaire d'onglets. La barre de menu (wxMenuBar) contient un certainnombre 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 laclasse wxToolbar, ce qui nous permet de personnaliser chaque barre d'outils, chaque boutonpar une image (au format xpm) ou du texte. Certains boutons comme les boutons des �ltresson sélectionnables a�n que la personne qui utilise le programme puisse savoir à tout momentquel(s) �ltre(s) elle a appliqué sur la scène courante. Nous avons rendus les barres d'outilsdé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));



m_mgr est le wxAuiManager de la fenêtre principale et tbFiltres est la barre d'outils quel'on souhaite ajouter. Ensuite on peut voir que grâce au wxAuiPaneInfo on choisit la positionde la barre d'outil mais aussi l'endroit ou l'on peut déposer la barre d'outil ainsi que sont styled'a�chage (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 dela matrice de calcul du �ou et d'autres encore. Nous avons également choisit d'ajouter un boutonupdateShader 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 e�et, pourconstruire chaque onglet nous mettons en titre le chemin du dossier pour lire la scène et dansl'onglet une classe qui hérite de wxWindow : Projet (cf. �gure en page 45). Cette classe estla classe qui va nous permettre d'a�cher une scène et la console associée à cette scène. Laconsole est une simple boite de texte dans laquelle nous lisons et écrivons selon nos di�érentesactions. Pour a�cher la scène nous avons plusieurs classes, tout d'abord SceneFrame qui héritede 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 lequelnous mettons au centre la classe SceneFrame et en bas la console. Le canvas est contenu dans lafenêtre de la scène. Lorsque nous créons la fenêtre de la scène, nous lui a�ectons un canvas sansscène. Puis le programme a�ecte un viewer au canvas a�n que le viewer utilise le canvas commemoyen d'a�chage. Le canvas gère lui-même les évènements comme le clique gauche ou le cliquedroit sur lui, il met à jour la scène en fonction ; sachant que le clique gauche vous permet de fairepivoter la scène alors que le clique droit vous permet de faire un zoom. Ces fonctions sont géréespar la classe osgViewer : :Viewer. Pour nos di�érents �ltres la classe SceneFrame possède despointeurs vers le modèle de la scène a�n 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 ex-terne 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 modi�cation soit prise encompte. C'est lui qui e�ectue la gestion des onglets, lorsqu'une action est détectée, si celle-ciconcerne un onglet, alors c'est par le contrôleur que l'action sera envoyée au projet actif. Lorsd'un évènement de chargement c'est lui qui lance la boîte de dialogue qui permet de parcourirles dossiers pour choisir une scène à ouvrir. Le contrôleur connait tous les éléments de la fenêtreplus ou moins directement et grâce à cela, il permet d'assurer la liaison entre chaque élément del'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 decréer un �ltre pour illustrer les phénomènes d'accommodation. Il existe diverses techniques detraitement d'images permettant de réaliser ce type de �ltre. Comme nous l'avons vu dans lapartie Analyse, nous avons choisi d'utiliser un algorithme de convolution appliqué sur l'ensemble



de la scène 3D au moyen d'un shader GLSL.La réalisation du �ltre se fait en trois étapes :

� E�ectuer 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éesdans 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 formed'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éesde 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 pixeladjacent avec les coe�cients de la matrice lui correspondant, sachant que la valeur centrale dela matrice correspond au pixel courant. On remplace ensuite la valeur du pixel courant par lavaleur de la combinaison linéaire normalisée a�n de revenir dans les domaines de variation del'image.Nous e�ectuerons dans un premier temps les calculs de la matrice à l'intérieur du shader, mais ilnous 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 e�ectuant notamment le calcul du noyau sur leCPU. De plus cela nous permet de pouvoir changer le code source du shader pendant l'exécutiondu programme et ainsi pouvoir faire varier les di�érents paramètres gérant l'accommodation entemps réel. Comme il s'agit de traiter chaque pixel, cet algorithme sera implémenté dans le PixelShader.

Algorithme 1 ConvolutionEntrées: Kernel une matrice contenant les coe�cients, O�set une matrice conte-

nant les modi�cateurs de coordonnées pour chaque coe�cient de Kernel,colorMap unsampler2D,glTexCoord[0] un vec4 contenant les coordonnées de texture par vertex, Totalun �ottant

Sorties: Valeur un vec4 représentant la valeur du pixel en cours1: pour inti = 0 to taille de Kernel faire2: Accéder à la valeur des texels adjacents au texel correspondant au pixel en cours3: vec4temp = texture2D(colorMap, glT exCoord[0].st + Offset[i]);4: valeur+ = temp ∗Kernel[i];5: �n pour

6: valeur = valeur/Total7: return valeur

Du fait de la distribution gaussienne de notre matrice, les coe�cients qui ont le plus d'in�uences,c'est à dire une valeur plus importante, se situent au niveau du centre, et leur in�uence décroitavec leur distance au centre. Ainsi, cette convolution revient à atténuer les changements brusquesd'intensité de l'image, ce qui rejoint la dé�nition du �ou.



4.3.2 Premiers Résultats

Nous avons constaté que les �ous "produits" par ce shader ne devenaient vraiment conséquentsqu'à partir d'un rayon de matrice supérieur ou égal à 3, ce qui est également la limite supérieurede nos cartes graphiques de tests en terme de puissance de calcul, le nombre d'images par secondeschutant spectaculairement entre une matrice de rayon 2 (60 images par secondes) et une matricede 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 convolutiontel que nous l'avons implémentée est en O(n2 ).

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 onappliquait la convolution, en e�ectuant un RTT vers une texture de taille inférieure que l'onplaquait ensuite sur un QUAD ayant gardé la taille d'origine. Le problème résultant de cetteopération fut l'apparition d'une pixellisation de la scène rendue �ou, et plus grave, des partiesnon �oues de la scène.La seconde solution que nous avons �nalement retenue consiste à utiliser un paramètre optionnelde la fonction GLSL texture2D de spéci�er un niveau de detail pour une valeur dans une texturedonnée. En e�et, 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éairede la texture sur le QUAD, ce qui évite les e�ets d'escaliers lorsque l'on va traiter un texel surdeux par exemple. L'idée est donc d'appliquer une convolution de matrice de rayon moindre surune image à un niveau de détail moindre, ce qui a pour e�et d'obtenir un �ou conséquent sansdemander 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ènea�n d'illustrer les phénomènes d'accommodation. C'est pourquoi il nous a fallu récupérer la



Fig. 4.2 � Illustration mipmap

distance de l'÷il par rapport à l'objet a�n de déterminer une première partie de la scène dontles rayons lumineux n'arrivent pas sur la fovéa car n'étant pas à la distance pour laquelle l'÷ils'accommode. Pour toute cette partie de la scène, nous réalisons alors une interpolation entreune image �ou de la scène et une image nette (avec la proportion d'image �oue variant selonl'âge, l'acuité visuelle, etc..).Nous avions dans un premier temps tenté de récupérer un bu�er contenant des informations surla profondeur d'une scène appelé Depth Bu�er. Pour cela, nous avons réalisé une capture de cebu�er au moyen d'un "render to texture", puis nous avons transmis cette texture au FragmentShader comme s'il s'agissait d'une texture quelconque. Nous avons ensuite réalisé qu'il n'etaitpas nécessaire d'utiliser ce procédé. En e�et, un Vertex Shader permet de redé�nir toutes lestransformations géométriques nécessaires à l'a�chage 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 danslequel 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'e�ectue 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 etde calculer l'interpolation voulue selon une courbe.Le calcul de cette courbe fût simple, il su�sait de trouver une courbe variant entre 0 et 1 enfonction de la profondeur. 0 signi�ant une zone parfaitement nette, 1 une zone la plus �ouepossible et entre 0 et 1 une zone de plus en plus �oue. La zone nette se trouve exactement à ladistance d'accommodation de l'÷il de l'humain et les zones �oues à des distances inférieures etsupé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'accommodepas seulement à une distance précise mais plutôt à une zone plus ou moins grande selon lesindividus. C'est pour cette raison que nous avons décidé d'ajouter un slider permettant de dé�nirla taille de cette zone en fonction des individus.

Une fois cette fonction calculée, il nous su�sait d'utiliser ce résultat a�n de calculer la couleurà a�cher. Pour cela nous avons utilisé le calcul suivant :



Fig. 4.3 � Courbes de l'interpolation entre les zones nettes et �oues

�ou = couleur du pixel �ounet = couleur du pixel netcoef = 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.



4.4 La projection sphérique

La projection sphérique va nous permettre de simuler la projection de la lumière sur l'÷ilhumain ainsi que les limites du champ visuel. L'÷il humain permet de voir, pour une personnenon dé�ciente, de 94 à 110 degrés environ horizontalement et de 110 à 120 degrés verticalement ;ces chi�res 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èrenous. Au niveau de la programmation cela constitue un dé� de taille, car aucun logiciel ne vouso�re une vue à plus de 180 degrés. Cela est techniquement impossible avec une projection enperspective.Dans notre recherche de la simulation de la vision humaine, nous sommes tout d'abord partissur une unique projection non linéaire, puis ayant compris qu'il était impossible de résoudre ceproblème de cette manière, nous avons entrepris d'assembler plusieurs projections non linéairesa�n 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 projec-tion ne subit aucune déformation, même minime. Notre objectif ici est de pouvoir simuler lesdéformations que subit l'image lors de sa projection sur l'÷il, c'est-à-dire que celle-ci soit peudéformée au centre et à contrario très déformée sur les côtés. Pour e�ectuer cette modélisation,nous avons recherché une courbe de déformation quasiment idéale, c'est-à-dire qui déforme peula scène au centre a�n 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 bu�er dans une texture, le calcul despositions de placage de la texture et le placage de la texture.



Algorithme 2 Déformation d'une texture1: Capturer le color bu�er dans une texture tex2: int noSteps = 503: 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 faire8: Incrément de cursor en y.9: Incrément de texcoords en y.

10: pour int j = 0 to noSteps faire11: 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: A�ectation de l'attribut vertices à geometry.20: A�ectation 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 a�che 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 nombretrop petit peut rendre la vue complètement inutilisable alors qu'un nombre trop grand peutfaire chuter le nombre d'images par seconde. Le calcul des positions de la �gure est simple, ilsu�t de recouvrir toute la fenêtre, c'est pourquoi on pose directement cursor dans le tableaude vecteur des nouvelles coordonnées. Cependant pour les points de la texture, on ne calculepas des coordonnées à l'écran ou sur un canvas, mais des coe�cients qui varient entre 0 et 1 etdont le centre est en 0,5. Cette di�érence explique pourquoi on n'incrémente pas de la mêmemanière cursor et texcoords. calculCoords est une fonction qui prend les deux coordonnées x ety en paramètres et qui renvoie un Vec2 dans lequel on a appliqué la fonction de déformationtelle que décrite ci-dessous.



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 celle-ci ne nous donnait pas satisfaction car la déformation n'était pas assez importante nous avonsdonc cherché et trouvé les autres courbes, nous donnant chacune une déformation bien plusimportante.



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 énor-mément la texture sur les côtés. C'est alors que nous avons vu que la vision humaine s'étendaitsur un angle de 188 degrés. Cette étape nous avait donc permis de toucher à la déformation d'unetexture tirée du color bu�er mais elle n'était cependant pas satisfaisante dans le but de simulerla 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 � consti-tuant chacun une projection linéaire. Ces panneaux sont capturés par le biais de 3 caméras quiregardent la scène avec un même angle d'ouverture mais les caméras de gauche et de droite ontsubit une rotation de cette angle dans le sens inverse (respectivement dans le sens) des aiguillesd'une montre. Nous avons choisit de n'utiliser que 3 panneaux dans le plan horizontal, et de nepas ajouter de panneaux verticalement car au niveau du champ visuel on ne voit pas à 180 degrésen 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.



Algorithme 3 Capture des 3 vues1: 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 faire8: Création d'une nouvelle caméra.9: Utilisation du Frame Bu�er 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 lenuméro de la caméra].

11: A�ectation de la caméra comme esclave de la caméra principale avec les arguments mx.12: �n pour

13: pour tout texture faire14: 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: A�ectation de ce groupe de n÷ud à la caméra de visualisation.22: A�ectation 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 de180 degrés, mais sans déformation. A�n de calculer les déformations sur chacun des panneaux,nous sommes passés par deux approches. La première, mathématiques, consistait à analyser leproblè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éespar 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 droiteet de gauche qui subissent de fortes déformations plus on s'excentre. Pour placer les panneauxde droite et de gauche, nous avons décidé de les placer sur la bissectrice entre le panneau centralet eux-mêmes.



Fig. 4.6 � Disposition des panneaux

Pour éviter un problème de continuité en bordure de panneaux, il nous fallait utiliser lamême déformation à la �n du panneau du centre et de celui de droite (et inversement, au débutde 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 projeterles 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 projectione�ectué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 dedéformation et nous avons pu voir apparaître une déformation mais nous nous sommes retrouvésavec des � cassures � très importantes entre les di�érents panneaux.A�n 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 coe�cient à appliquersur notre calcul de déformation puis par tatonnement, nous avons �xé une valeur à 1.09 de tellesorte qu'il y ait une déformation et qu'il n'y ait pas de cassure (voir �gure 4.8 - courbe orange).



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 centreet à droite mais avec une déformation tellement faible qu'elle n'était presque pas visible. A�nde véri�er cela, nous avons pris un cube avec des lignes et nous avons vu qu'en e�et le cube nesubissait � aucune � déformation. Nous avons alors entrepris de construire à la main les pointsa�n de déformer manuellement les images.

L'approche pragmatique

Lors de notre calcul des points de la texture, nous avons choisi de n'e�ectuer que 50itérations, il nous fallait donc trouver 50 points qui nous donneraient une déformation et pas decassure entre les panneaux. Nous avons commencé par calculer une déformation selon l'axe desx. Cette courbe montre clairement que la déformation est bien plus importante que la fonctiony = x originale et que la fonction arc tangente. De plus comme elle est entièrement calculée à lamain, nous pouvons la remodeler à notre guise. Une fois cette fonction trouvée, nous n'avionsplus qu'à rentrer chaque point dans un tableau contenant les points de la texture, cependant eta�n de garantir un collage entre les panneaux, cette fonction n'est pas appliquée dès le départmais après les deux premiers points de collage de la texture, ainsi les panneaux se soudent bienentre eux.



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. Nousavions, lors de nos di�érents tests sur la projection linéaire, cherché de nombreuses courbespouvant nous donner satisfaction, une des courbes était totalement inutilisable lors de cetteprojection, cependant avec notre assemblage de panneau et ce que nous voulions faire, nousavons pu la réutiliser. Pour simuler la déformation en haut et en bas, il nous fallait une courbequi ressere la scène en haut et en bas et qui l'étende au centre, au niveau graphique celacorrespond à être très près du 0,5 (du centre de l'image) et très éloigné du 0 et du 1 puisqueceux ci sont les extrémités du collage de notre texture.



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 projectionsphérique a�n de simuler la projection de la lumière sur l'÷il et les limites du champ visuel. Nousavons deux courbes et 3 panneaux qui nous permettent cette simulation.


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 chargerune scène à partir du menu ou de la barre d'outils. Une nouvelle fenêtre s'ouvre vous demandantde choisir la scène à charger. Si vous faites annuler aucune scène ne se chargera, sinon vous allezvoir apparaître un nouvel onglet intitulé du chemin par lequel la scène a été chargée. Les formatsaccepté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 bougerla scène avec la souris ; en appuyant avec le bouton gauche et en bougeant la souris vous pouvezfaire pivoter la scène, avec le clique droit vous pouvez zoomer ou dézoomer de la scène, avecles boutons droit et gauche pressés en même temps vous pouvez modi�er la position de la scènedans 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 modi�erles options de ces �ltres via la fenêtre de gestion des options. Une fois que vous avez �ni avecune scène, vous pouvez en charger une autre ou quitter le logiciel.


Chapitre 6 : Perspectives et conclusions

Chapitre 6

Perspectives et conclusions

6.1 Perspectives

Notre application est fonctionnelle et relativement simple d'utilisation, cependant nousn'avons réalisé que deux �ltres et aurions aimé en faire beaucoup plus, notamment des �ltrestraitants des maladies comme le glaucome et le daltonisme. Nous aurions également aimé pouvoirmontrer l'e�et d'un �ash de radar lorsque nous sommes au volant, de montrer à quel point celaperturbe la vision humaine.

6.2 Accommodation

Un petit nombre de sliders liés à la détermination de la zone peuvent sembler inadéquatsdans la mesure où l'on souhaite simuler la vision humaine, cependant leur suppression pose deserieux problèmes de paramétrage car la réalité physiologique de l'÷il est telle que cette zonedé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 etla manipulation de scène en 3 dimensions. La tâche de Mariotte correspond à la partie où le nerfoptique est connecté à la rétine, ce qui nous donne une petite partie démunie de photorécepteurset donc complètement aveugle. Pour simuler cette tâche nous devions réaliser deux convolutionssur deux zones précises de taille �xée. Cependant nous ne savions pas comment réaliser uneconvolution 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 faireune convolution et comment faire des render to texture. Nous avons donc entrepris de continuercette partie, mais comme les autres parties n'étaient pas terminé, après en avoir parlé avec notre



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 pourquoinous le notons en tant qu'évolution possible de notre projet... Ce �ltre qui n'a pas pu voir le jourpar manque de temps consistait à simuler un éblouissement dû à un �ash, ou à une expositionsoudaine à une lumière vive. Il aurait permis de reproduire les facteurs qui entrent en jeu lors dela réadaptation de l'÷il à la lumière.

Pour ce �ltre, il aurait fallu, récupérer la luminosité courante, l'augmenter jusqu'à simulationd'un éblouissement, et la réinitialiser à son état initial en fonction d'un facteur temporel (letemps d'adaptation). Nous n'avons pas eu le temps de gérer le facteur temps a�n de vraimentreproduire 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ésiresimuler 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 aumoins 5 ans, mais aussi car nous étions très motivés et que le sujet était très interressant. Lacommunication entre chaque membre du groupe s'est ainsi trouvée accrue et bien plus e�cace.La division du travail a été faite de manière e�cace, 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'unemaniè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 e�et, la documentation sur OpenScene-Graph est quasimment inexistante ou obsolète lorsqu'elle existe. Ce manque de documentationa posé un problème important. Nous avons donc tenté d'obtenir de l'aide sur les listes publiqueset forums d'OpenSceneGraph et tiré pro�t des exemples fournis avec l'API.

D'une autre part, les bases d'OpenSceneGraph plus ou moins en mains, il nous a fallu de plusen plus repousser nos limites a�n d'en apprendre plus. La compréhension d'un shader et la priseen 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 visualisationgraphique (2d et 3d). En e�et, 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



tous les avantages qu'il présente et en�n nous avons mené à bien l'utilisation avancée du langageGLSL pour manier les shaders.

Au niveau relationnel, même si les membres de notre groupe se connaissent depuis assezlongtemps, c'est toujours un dé� de réaliser un projet di�cile. La di�culté est d'autant plusaccrue 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 etpassionnants. Il nous a permis de lier le monde informatique à la réalité de ce que nous vivonstous les jours : la vision humaine.


Chapitre A : Images

Annexe A

Images


Chapitre A : Images

Fig. A.1 � Schéma d'un pipeline de carte 3D classique représentant la position des unités detraitement des shaders


Chapitre A : Images

Fig. A.2 � Pile d'application 3D


Chapitre A : Images

Fig. A.3 � Organisation temporelle du travail.


Chapitre B : Documents d'analyse

Annexe B

Documents d'analyse



Fig. B.1 � Diagramme de classe pour l'interface.Modélisation de la vision humaine 44/144


Fig. B.2 � Diagramme de classe pour l'a�chage d'une scène dans un onglet.



Fig. B.3 � Diagramme de classe d'analyse pour l'utilisation du pattern Modele-Vue-Controleur.



Fig. B.4 � Diagramme de classe pour l'utilisation du pattern decorateur.



Fig. B.5 � Diagramme de classe d'analyse de la hiérarchie de composants.



Fig. B.6 � Diagramme de séquence pour la création d'un nouveau projet.


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 e�ectuée avec notre tuteur, unpetit compte rendu qui nous permettait de ne pas perdre de vue les diverses orientations duprojet. Elle sont recopiées ici en "brut de co�rage" (ou presque) pour vous faire une idée denotre organisation.

C.1 Séance 1

Prise de contact avec M. Marie et découverte du projet à proprement parler avec dé�nitiondes objectifs et méthodes.

Les dits objectifs sont donc de concevoir, une application permettant de simuler la visionhumaine. Le traitement se fera directement à partir d'une scène 3D qui sera modi�ée au niveaudu 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 lesshaders 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 mieuxles di�érentes méthodes possibles pour simuler un rendu le plus proche de la réalité a�n d'enretenir 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 faceaux changements de lumière, etc..

Une fois ce premier travail accompli, on s'intéressera à simuler les di�érentes pathologiespossibles a�ectant 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 e�cace, nous permettant de montrer des résultats rapidesà nos tuteurs. Ainsi, ces derniers pouvaient évaluer l'état d'avancement du projet lors de chaquescéance mais aussi nous aider à améliorer notre travail grâce à leur expérience. C'est pourquoinous nous sommes orientés vers un cycle de développement itératif en accord avec nos tuteurs.



C.2 Séance 2

Nous avons discuté du rapport ainsi que d'une éventuelle charte de programmation. Nousavons formé deux groupes, le premier s'occupant de réaliser les e�ets de �ous, le second de latâ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 modi�cations à e�ectuer sur le cahier des charges (que nous ne citeronspas 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 troplente)

� Trouver comment e�ectuer 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 openGlet sur l'utilisation d'OpenSceneGraph, puis sur les parties du projet en cours de traitement. Nousavons ensuite réalisé un découpage stratégique des di�érentes tâches à e�ectuer en les séparanten deux familles, celles nécessitant l'utilisation d'un bu�er de profondeur (Depth-Bu�er) et lesautres. [...]Avant cette scéance nous avions déjà ré�échit à quelques techniques d'implémentations possiblespour certaines parties, notamment pour la déformation : Nous pensions utiliser un systèmemulti-caméra sur une scène 3D, chaque caméra ne s'occupant que d'une partie de l'image et yréalisant une transformation géométrique propre à la partie regardée par la caméra. Le problèmesoulevé lors de cette séance est celui des e�ets non voulus qui risqueraient de se produire auxlisiè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 fonctionde la profondeur relative des di�érents objets de la scène. En pratique, cela signi�e que l'on varecopier plusieurs matrices de pixels correspondantes à plusieurs niveaux de profondeurs pourune seule scène. Cela revient donc à avoir plusieurs images planes. La seconde consiste à utiliserun shader pour e�ectuer 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 a�n de s'inspirerd'un modèle fonctionnel et d'essayer d'en apprendre les techniques. Une idée est survenue pource �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ûteplus très cher en temps de calcul, cependant il nous faut trouver un moyen e�cace de gérer laprofondeur. Pour ce qui est de la projection sphérique, il faut réaliser les 3 panneaux dans le



plan horizontal et non pas dans le plan vertical. Ceci est dû à une re�exion simple, au niveau duchamp 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 a�n que celles-ci s'étendent di�érement surles panneaux.

� Faut il transmettre ces lois de variation aux shaders, ou régler le problème à un niveausupérieur, i.e. OpenSceneGraph

En�n, en ce qui concerne la gestion de la luminosité, il faut ajouter un paramètre temporel pourl'é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 decomprendre pourquoi la valeur de la profondeur vallait à la fois zéro et une valeur di�érentede 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 faitd'un double appel au Fragment Shader qui a pour e�et d'e�ectuer une première fois les tests avecune 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 verticalescorrectes.


Chapitre D : Organigrammes

Annexe D

Organigrammes



Fig. D.1 � Organisation du développement



Fig. D.2 � Organisation interne pour la rédaction et la présentation


Chapitre E : Bibliographie

Annexe E

Bibliographie

E.1 OpenGL

� GameDev : Portail pour la 3D - http ://www.gamedev.net/reference/programming/features/imageproc/page2.asp� 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 = /SGIDeveloper/Perf_PG� 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 o�ciel 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/osg-users-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/


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 o�ciel 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 lesprincipaux 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 aussiutiles que bien réalisés.


Chapitre F : Documentation

Annexe F

Documentation


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

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

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14ConsoleFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Controleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19KeyboardEventHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25KeyHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27MainFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28MScene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

DecorateurScene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Flous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23PointLumineux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35ProjectionSpherique . . . . . . . . . . . . . . . . . . . . . . . . . . . 37TacheDeMariotte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

OptionFlous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38SceneFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41ToolBarFiltre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Data Structure Index


Chapter 3

Data Structure Index

3.1 Data Structures

Here are the data structures with brief descriptions:

AbstractScene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14ConsoleFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Controleur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19DecorateurScene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Flous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23KeyboardEventHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . 25KeyHandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27MainFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28MScene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30OptionFlous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33PointLumineux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35ProjectionSpherique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38SceneFrame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41TacheDeMariotte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44ToolBarFiltre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47AbstractScene.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48App.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49App.h (Launcher of the application ) . . . . . . . . . . . . . . . . . . . . . . 50Canvas.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Canvas.h (Paint pane to display OpenGL components ) . . . . . . . . . . . . 52Common.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53ConsoleFrame.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54ConsoleFrame.h (Text control for display message ) . . . . . . . . . . . . . 55Controleur.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Controleur.h (Window and tabPane controller ) . . . . . . . . . . . . . . . . 57DecorateurScene.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58DecorateurScene.h (Abstract class that allow creation of differents filters on

a scene ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Flous.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Flous.h (This filter computes a blur on a given Mscene ) . . . . . . . . . . . 61KeyHandler.h (EventManager (keyboard, mouse,...) for the canvas ) . . . . . 62MainFrame.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63MainFrame.h (This class permit to display the program ) . . . . . . . . . . . 64MScene.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65MScene.h (The scene model that we want to show ) . . . . . . . . . . . . . . 66OptionFlous.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67OptionFlous.h (This class gives tools to manage the blur ) . . . . . . . . . . 68PointLumineux.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69PointLumineux.h (This class adds a light point to the scene and allows

simualtion of a glare ) . . . . . . . . . . . . . . . . . . . . . . . . . 70ProjectionSpherique.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 71ProjectionSpherique.h (This filter deforms the current scene regarding de-

fined deformation curves ) . . . . . . . . . . . . . . . . . . . . . . 72

8 File Index

Projet.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Projet.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 usedin the auinotebook on the class MainFrame (p. 28) ) . . . . . . . . 74

SceneFrame.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75SceneFrame.h (This class allow to display a scene on a wxScrolledWindow ) 76TacheDeMariotte.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77TacheDeMariotte.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78ToolBarFiltre.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79ToolBarFiltre.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 tochildren.

• 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, un-signed 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 theparamater

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:



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



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>


• bool OnInit ()Main program equivalent, create the window.


5.2.1.1 bool App::OnInit ()

Initialisation function.

Returns:

Returns true if initialisation succeed


• App.h• App.cpp



5.3 Canvas Class Reference

#include <Canvas.h>


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



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]


• Canvas.h• Canvas.cpp



5.4 ConsoleFrame Class Reference

#include <ConsoleFrame.h>


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


• ConsoleFrame.h• ConsoleFrame.cpp


5.5 Controleur Class Reference 19

5.5 Controleur Class Reference

#include <Controleur.h>


• 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.1 Controleur::Controleur ()

5.5.1.2 Controleur::∼Controleur () [virtual]


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



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


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


• DecorateurScene (void)

Default Constructor.

• virtual ∼DecorateurScene (void)

Destructor.

• virtual osg::Node ∗ getScene ()

• virtual void setScene (osg::Node ∗n)


• MScene ∗ mscene

The scene to decorate.


5.6.1.1 DecorateurScene::DecorateurScene (void)

5.6.1.2 DecorateurScene::∼DecorateurScene (void) [virtual]


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



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.1 MScene∗ DecorateurScene::mscene [protected]


• DecorateurScene.h• DecorateurScene.cpp


5.7 Flous Class Reference 23

5.7 Flous Class Reference

#include <Flous.h>

Inherits DecorateurScene.


• 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.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.1 void Flous::changeFragShader (int w, int h, int depthLimite, intrayonFocal, 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



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



• Flous.h• Flous.cpp


5.8 KeyboardEventHandler Class Reference 25

5.8 KeyboardEventHandler Class Reference

#include <KeyHandler.h>


• KeyboardEventHandler (MScene ∗s)• virtual bool handle (const osgGA::GUIEventAdapter &ea,

osgGA::GUIActionAdapter &ea1)• virtual void accept (osgGA::GUIEventHandlerVisitor &v)


• MScene ∗ scenePointer to the scene, simply cast this instance into the one you want in the decoratorsub classes to get the class methods.


5.8.1.1 KeyboardEventHandler::KeyboardEventHandler (MScene ∗ s)[inline]

Constructor

Parameters:

s the scene


5.8.2.1 virtual bool KeyboardEventHandler::handle (constosgGA::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



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



5.10 MainFrame Class Reference

#include <MainFrame.h>


• 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.1 MainFrame::MainFrame (wxFrame ∗ frame, const wxString &title, const wxPoint & pos, const wxSize & size, long style =wxDEFAULT_FRAME_STYLE)

Constructor

Parameters:

frame main windowtitle window titlepos window positionsize window sizestyle window style (default is wxDEFAULT_FRAME_STYLE)

5.10.1.2 MainFrame::∼MainFrame ()


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


• MainFrame.h• MainFrame.cpp



5.11 MScene Class Reference

#include <MScene.h>

Inherited by DecorateurScene.


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

• 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, un-signed int member=0)

• virtual void ajouterDB (const wxString &path)


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

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



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:



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:



5.11.2.8 osg::StateAttribute ∗MScene::getAttribute (osg::StateAttribute::Typetype, 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


• MScene.h• MScene.cpp


5.12 OptionFlous Class Reference 33

5.12 OptionFlous Class Reference

#include <OptionFlous.h>


• OptionFlous (Controleur ∗ctrl, wxFrame ∗parent, const wxString &ti-tle="OptionFlous", const wxPoint &pos=wxDefaultPosition, const wxSize&size=wxDefaultSize, long style=wxDEFAULT_FRAME_STYLE)

• virtual ∼OptionFlous (void)

Destructor.

Data Fields

• wxStaticText ∗ textValCoeffThe text who display the value of the slider slideCoefAug.

• wxStaticText ∗ textValLODThe text who display the value of the slider slideLOD.

• wxSlider ∗ slideLODA slider who manage the LOD for the blur.

• wxSlider ∗ slideDepthA slider who manage the depth for the blur.

• wxSlider ∗ slideRFA slider who manage the focal length.

• wxSlider ∗ slideCoefAugA slider who manage the augmentation coefficient.

• wxSlider ∗ slideLightA slider who manage the light.


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



Parameters:

ctrl the frame controller.


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


• OptionFlous.h• OptionFlous.cpp


5.13 PointLumineux Class Reference 35

5.13 PointLumineux Class Reference

#include <PointLumineux.h>



• 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.1 PointLumineux::PointLumineux (MScene ∗ s, osgViewer::Viewer ∗ v,Canvas ∗ can)

Constructor

Parameters:

s the scene in which we want to attach the spotv the viewercan the canvas

5.13.1.2 PointLumineux::∼PointLumineux (void) [virtual]


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



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 ()


• PointLumineux.h• PointLumineux.cpp


5.14 ProjectionSpherique Class Reference 37

5.14 ProjectionSpherique Class Reference

#include <ProjectionSpherique.h>



• ProjectionSpherique (MScene ∗s, osg::ref_ptr< osgViewer::Viewer >&viewer, const int w, const int h)

• virtual ∼ProjectionSpherique (void)Destructor.


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]


• ProjectionSpherique.h• ProjectionSpherique.cpp



5.15 Projet Class Reference

#include <Projet.h>


• Projet (wxWindow ∗parent, wxWindowID id, const wxString &title, constwxPoint &pos=wxDefaultPosition, const wxSize &size=wxDefaultSize, longstyle=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.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




style style of the window. (wxSUNKEN_BORDER)

5.15.1.2 Projet::∼Projet () [virtual]


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.



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.


• Projet.h• Projet.cpp


5.16 SceneFrame Class Reference 41

5.16 SceneFrame Class Reference

#include <SceneFrame.h>


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



style style of the window. (wxDEFAULT_FRAME_STYLE)


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.



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.


• SceneFrame.h• SceneFrame.cpp



5.17 TacheDeMariotte Class Reference

#include <TacheDeMariotte.h>



• 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.1 TacheDeMariotte::TacheDeMariotte (MScene ∗ s, osgViewer::Viewer∗ viewer, int rayon)

5.17.1.2 TacheDeMariotte::∼TacheDeMariotte (void) [virtual]


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


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



• TacheDeMariotte.h• TacheDeMariotte.cpp



5.18 ToolBarFiltre Class Reference

#include <ToolBarFiltre.h>


• ToolBarFiltre (wxWindow ∗parent, wxWindowID id=-1, const wx-Point &pos=wxDefaultPosition, const wxSize &size=wxDefaultSize, longstyle=wxTB_VERTICAL|wxNO_BORDER)

• virtual ∼ToolBarFiltre ()Destructor.


5.18.1.1 ToolBarFiltre::ToolBarFiltre (wxWindow ∗ parent, wxWindowIDid = -1, const wxPoint & pos = wxDefaultPosition,const wxSize & size = wxDefaultSize, long style =wxTB_VERTICAL | wxNO_BORDER)

Constructor

Parameters:



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]


• 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



6.4 App.h File Reference

Launcher of the application.

Data Structures

• class App

6.4.1 Detailed DescriptionAuthor:

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)



6.6 Canvas.h File Reference

Paint pane to display OpenGL components.

Data Structures

• class Canvas



Version:

0.1

Date:

20/04/2008


6.7 Common.h File Reference 53

6.7 Common.h File Reference



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



Version:

0.1

Date:

23/04/2008



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



Version:

0.1

Date:

20/04/2008



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



Version:

0.1

Date:

27/02/2008



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



Version:

0.1

Date:

23/01/2008



6.16 KeyHandler.h File Reference

EventManager (keyboard, mouse,...) for the canvas.

Data Structures

• class KeyboardEventHandler



Version:

0.1

Date:

02/03/2008

See also:

http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/BasicKeyboardInput


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.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::OnNoteBookCloseEVT_AUINOTEBOOK_PAGE_CHANGED (ID_NOTEBOOK,MainFrame::OnPageChange)



6.18 MainFrame.h File Reference

This class permit to display the program.

Data Structures

• class MainFrame



Version:

0.1

Date:

23/04/2008


6.19 MScene.cpp File Reference 65

6.19 MScene.cpp File Reference



6.20 MScene.h File Reference

The scene model that we want to show.

Data Structures

• class MScene



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, Op-tionFlous::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::changeSlideEVT_BUTTON (ID_BUTTON_UPDATE, OptionFlous::updateShader) END_-EVENT_TABLE() OptionFlous


6.21.1.1 BEGIN_EVENT_TABLE (OptionFlous, wxWindow)

6.21.1.2 OptionFlous::changeSlide OptionFlous::changeSlideOptionFlous::changeSlide EVT_BUTTON (ID_BUTTON_UPDATE,OptionFlous::updateShader)

6.21.1.3 OptionFlous::changeSlide OptionFlous::changeSlideEVT_COMMAND_SCROLL (ID_SLIDE_COEFAUG,OptionFlous::changeSlide)

6.21.1.4 OptionFlous::changeSlide EVT_COMMAND_SCROLL(ID_SLIDE_RF, OptionFlous::changeSlide)



6.22 OptionFlous.h File Reference

This class gives tools to manage the blur.

Data Structures

• class OptionFlous



Version:

0.1

Date:

22/04/2008


6.23 PointLumineux.cpp File Reference 69

6.23 PointLumineux.cpp File Reference



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



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



6.26 ProjectionSpherique.h File Reference

This filter deforms the current scene regarding defined deformation curves.

Data Structures

• class ProjectionSpherique



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() Pro-jet


6.27.1.1 BEGIN_EVENT_TABLE (Projet, wxWindow)



6.28 Projet.h File Reference

This class permits to create a window who contains a scene and a text control foreach instance of Projet (p. 38). The projet are used in the auinotebook on the classMainFrame (p. 28).

Data Structures

• class Projet



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.1 BEGIN_EVENT_TABLE (SceneFrame, wxWindow)



6.30 SceneFrame.h File Reference

This class allow to display a scene on a wxScrolledWindow.

Data Structures

• class SceneFrame



Version:

0.1

Date:

23/04/2008


6.31 TacheDeMariotte.cpp File Reference 77

6.31 TacheDeMariotte.cpp File Reference



6.32 TacheDeMariotte.h File Reference

Data Structures

• class TacheDeMariotte


6.33 ToolBarFiltre.cpp File Reference 79

6.33 ToolBarFiltre.cpp File Reference



6.34 ToolBarFiltre.h File Reference

Data Structures

• class ToolBarFiltre



Version:

0.1

Date:

22/04/2008
