\documentclass[12pt, french]{report-rd-info} \usepackage{float} \usepackage{wrapfig} \usepackage{url} \usepackage{sidecap} \usepackage{subfig} \usepackage{moreverb} \usepackage{color} % \usepackage[pdftex]{graphicx} % \usepackage[frenchb]{babel} \usepackage[latin1]{inputenc} \usepackage[T1]{fontenc} \title{Rapport de bibliographie} \author{Olivier Catry\\ Encadrant : Fabien Picarougne, } \begin{document} \begin{titlepage} \begin{figure}[H] \centering \includegraphics[width=0.45\textwidth]{polytech-nantes.jpg} \end{figure} \begin{center} \textsc{\LARGE École polytechnique de l'Université de Nantes}\\[1.5cm] \textsc{\Large Projet de recherche}\\[0.5cm] % Title { \huge \bfseries Etude des shaders en OpenGL : application à la visualisation dans un dôme}\\[0.4cm] \begin{minipage}{0.4\textwidth} \begin{flushleft} \large \emph{Étudiant:}\\ Olivier \textsc{Catry} \\ Polytech' Nantes \end{flushleft} \end{minipage} \begin{minipage}{0.4\textwidth} \begin{flushright} \large \emph{Encadrant:} \\ Fabien \textsc{Picarougne}\\ Laboratoire LINA \end{flushright} \end{minipage} \vfill % Bottom of the page {\large \today} \end{center} \end{titlepage} \cleardoublepage \subsection*{Preface} \addcontentsline{toc}{subsection}{Preface} \textbf{Résumé} \\ \textbf{problématique} : Comment réaliser l'affichage d'une scène en 3D sur un support de géométrie quelconque sans souffrir de déformations visuelles ? \\ La problématique est étudiée sur le sujet suivant : l'affichage sur un dôme en utilisant les Shaders. \\ L'objectif de ce projet est donc de réussir à afficher une scène 3D sur un dôme, et que, quel que soit le point de vue, l'image ne soit pas déformée. \\ La recherche a porté sur la déformation de l'image, le changement de point de vue, et pour finir, sur une technique qui regroupe les deux recherches précédentes et qui est programmable pour du temps réel. \\ La décision a été prise d'exploiter cette troisième recherche et de proposer de déformer la scène 3D à l'aide des shaders. \\ Pour cela, une recherche mathématique a été effectuée pour déterminer les transformations à opérer. \\ La phase de développement n'a toujours pas eu lieu et sera résumée en fin de projet. \\ Une idée d'ouverture vers un futur projet a été trouvée, afin de capter la forme du support en temps réel pouvoir projeter la scène 3d où l'on veut. \clearpage \textbf{Remerciements} \\ Je remercie M. Picarougne qui a eu la gentillesse de prendre sur son temps pour me faire découvrir le monde de la programmation des shaders et de me proposer ce projet de recherche sur ce thème qui me captive. \\ Je remercie également l'ensemble des professeurs de Polytech' Nantes responsables des divers cours portant de près ou de loin sur l'imagerie informatique ou tout autre thème exploité dans ce projet. \clearpage \tableofcontents \clearpage \chapter{Introduction} \section{Présentation de la problématique} \textbf{problématique} : Comment réaliser l'affichage d'une scène en 3D sur un support de géométrie quelconque sans souffrir de déformations visuelles ? \\ Il faut comprendre les enjeux de ce domaine. On se propose des les lister brièvement, mais il faudra se réferer à la partie "Etat de l'Art" pour une description plus précise. \\ L'affichage d'un rendu 3D sur un écran plat présente un inconvénient : la déformation est accentuée à mesure que l'on approche des bordures de l'écran. \\ De plus en plus de professionnels et de joueurs se sont tournés vers la multiplication des écrans afin de tendre vers un affichage à 180° \\ L'affichage sur un écran sphérique (plus généralement un dôme) est une solution qui permet de ne plus constater de déformations. \\ Il réside un inconvénient global qui se présente avec l'affichage sur un dôme : il est nécéssaire de se placer à un point particulier pour ne pas observer de déformations. \\ Ce projet a pour but de réaliser les déformations adaptées au point de vue de l'utilisateur afin de percevoir la perspective de la meilleur qualité quel que soit son emplacement dans le dôme. \section{Objectifs poursuivis} Une solution serait d'adapter alors l'image au point de vue de l'utilisateur. Dans le cas d'un film ou de tout autre rendu 2D, il n'est pas possible d'arriver à un résultat satisfaisant car l'information au delà des bordures de l'écran n'existe pas. Mais dans le cas d'un rendu 3D, l'information existe mais n'est pas affichée. De plus, il est possible de déformer à volonté ce rendu. \\ Ce projet a pour but de réaliser ces déformations afin que l'image vue par l'utilisateur ne soit pas déformée à cause de l'emplacement de son point de vue. \\ La difficulté que présente cette solution est la suivante : déformer un rendu 3D est lourd au niveau du temps de calcul. Mais les cartes graphiques récentes permettent de réaliser de nombreuses modifications sur le rendu de façon suffisamment instantanée pour du temps réel. \\ La solution envisagée est d'utiliser la carte graphique, et particulièrement les shaders, pour réaliser ces déformations. \\ Pour ce projet de recherche, nous nous concentrerons sur l'affichage sur un dôme et nous définirons arbitrairement l'emplacement du point de vue de l'utilisateur (non confondu avec le centre du dôme). \section{Travail réalisé} La recherche a porté sur un vaste domaine, et on s'est efforcé de se cantonner à des propositions précises afin de ne pas faire une étude de toutes les mathématiques de la perspective. \\ Elle a porté sur deux domaines principaux, la déformation et la perspective, et a permi d'aboutir à une alliance des deux au travers d'un procédé de transformation de la scène 3D. \\ La réalisation a débuté au mois d'Octobre, avec l'intégration des librairies Glew et Glut et la réalisations de plusieurs programmes afin d'assurer le fonctionnement des shaders. \section{Contribution} La solution issue est basée sur la déformation de la scène 3D de façon à ce qu'elle soit perçue de façon non déformée et avec les bonnes perpectives pour une point de vue en particulier, indépendant du centre du dôme. La technique est aussi indépendante de la forme du support. Pour assurer le temps réel, une solution informatique est mise en avant : la programmation des Shaders, exploitant le GPU. \section{Plan de l'étude} %------------------------------------------------------------------------------------------------------------- \chapter{\'Etat de l'art} \label{chap:EtatArt} Rappelons tout d'abord la problématique : \\ \textbf{problématique} : Comment réaliser l'affichage d'une scène en 3D sur un support de géométrie quelconque sans souffrir de déformations visuelles ? \\ Cette problématique s'inscrit dans un domaine vaste et il faut en comprendre les enjeux principaux avant d'étudier les propositions. \\ L'affichage d'un rendu 3D sur un écran plat présente un inconvénient : la déformation est accentuée à mesure que l'on approche des bordures de l'écran. C'est aujourd'hui un problème bien plus important avec la démocratisation des écrans larges. Ces derniers ont offert la possibilité d'accroitre le champs de vision, présentant des déformations sur les bordures bien plus importantes. (cf figure ~\ref{ref:ex_def}) \begin{figure}[H] \centering \subfloat[Les deux cubes colorés semblent à la même distance de l'objectif]{\includegraphics[width=0.30\textwidth]{javaw2011-10-2613-40-25-18.jpg}} \hfill \subfloat[Après rotation, le cube jaune semble plus proche]{\includegraphics[width=0.30\textwidth]{javaw2011-10-2613-41-12-88.jpg}} \hfill \subfloat[Après une autre rotation, le cube jaune semble plus éloigné]{\includegraphics[width=0.30\textwidth]{javaw2011-10-2613-41-17-01.jpg}} \caption{Un exemple visuel de déformation sur les bords} \label{ref:ex_def} \end{figure} Lors de la rotation, le centre de projection reste le même, \textbf{c'est le plan de projection qui tourne autour de ce centre en restant à la même distance de celui-ci}. Les lignes de projection restent donc également les mêmes, mais les intersections qu'elles ont avec le plan de projection sont différentes. Pour comprendre le phénomène, reproduisons-le en écrasant une dimension. (cf figure ~\ref{ref:ex_phe}) \begin{figure}[H] \centering \subfloat[Les deux projections (bleu et jaune) sont des segments de même taille]{\includegraphics[height=0.27\textwidth]{cubesjaunebleus.png}} \hfill \subfloat[Après rotation, la projection jaune est un segment plus grand que celui de la bleue]{\includegraphics[height=0.27\textwidth]{cubesjaunebleus2.png}} \hfill \subfloat[Après une autre rotation, c'est l'inverse qui se produit]{\includegraphics[height=0.27\textwidth]{cubesjaunebleus3.png}} \caption{Explication du phénomène de déformation sur les bords} \label{ref:ex_phe} \end{figure} On est en droit de remarquer que, de toute façon, les bords de l'écran se trouvent plus loin de nous que son centre, et donc qu'il est normal que les objets s'y trouvent plus grands.~\cite{fov} Seulement on entre dans la supposition selon laquelle le point de vue de l'utilisateur se trouve à une distance bien définie de l'écran. Plus on s'éloigne, et plus le rapport entre ces distances diminue, ce qui n'est pas le cas du rendu affiché. \\ \\ De plus en plus de professionnels et de joueurs se sont donc tournés vers la multiplication des écrans. Les écrans latéraux servent alors à afficher les flancs du champs de vision anciennement déformés. (cf figure ~\ref{ref:inst}) \begin{figure}[H] \centering \subfloat[L'installation de Steve Ferris ]{\includegraphics[height=0.27\textwidth]{flightsim.jpg}} \hfill \subfloat[L'installation de Luciano Napolitano]{\includegraphics[height=0.27\textwidth]{flightsim2.jpg}} \caption{Installations de plusieurs écrans en arc de cercle dans le cadre de la promotion de l'add-on WideView pour Flight Simulator X~\cite{wideview}} \label{ref:inst} \end{figure} Mais cet artifice présente toujours le problème suivant : les bordures de chaque écran admettent des déformations. Pour le comprendre, étudions le plan de l'installation de Luciano Napolitano~\cite{wideview}. (cf figure ~\ref{ref:nap}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{topview.png} \caption{Plan de l'installation de Luciano Napolitano} \label{ref:nap} \end{figure} On corrige une erreur en plaçant la caméra bien à la même distance de ces écrans, et on observe le phénomène lors de la projection d'un objet sur deux écrans à la fois. (cf figure ~\ref{ref:casdef}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{multiecran.png} \caption{Cas de déformation sur une installation de plusieurs écrans} \label{ref:casdef} \end{figure} L'objet est affiché de plus en plus proche à mesure que l'on approche de son centre et de plus en plus loin à mesure que l'on approche de ses bords. C'est un phénomène normal que l'on observe de façon naturelle. Mais ici, cette variation est linéaire, alors qu'elle devrait suivre un progression polynomiale. De ce fait, un cercle a été tracé afin de représenter le véritable volume de projection afin d'éliminer cette déformation. \\ \\ De ce fait, l'affichage sur un écran sphérique (plus généralement un dôme) est une solution qui permet de ne plus constater ces déformations. Le demi-dôme présente aussi l'avantage de couvrir le champ de vision de l'être humain. Il faut savoir que ce n'est pas tout à fait le cas, car un oeil couvre moins de 180°, mais les deux yeux couvrent un angle supérieur à 180°. Le demi-dôme couvre donc le champ de vision commun aux deux yeux.~\cite{fov} L'objectif fisheye, dans le domaine de la photographie, propose un rendu très déformé sur un écran plat mais qui s'adapte à un dôme, à condition que la couverture du dôme soit de l'angle de la prise de vue. (cf figure ~\ref{ref:fisheye}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{PeterW_zt_4.png} \caption{Objectif fisheye, prise de l'intérieur d'un tunnel en ligne droite, ouverture d'un angle proche de 180° (image de wikipedia) } \label{ref:fisheye} \end{figure} Il réside un inconvénient global qui se présente avec toutes ces techniques : il faut admettre que le point de vue de l'utilisateur se trouve à un endroit bien particulier pour ne pas percevoir de déformations.~\cite{archi} Dans le cas des écrans plats, le cerveau humain s'est habitué à une grande marge spatiale pour placer son point de vue. Par exemple, plusieurs spectateurs d'une salle de cinéma placés à des endroits différents verront une image différente, mais leur cerveau se reconstituera sensiblement la même image. \\Le dôme présente deux problèmes : \begin{enumerate} \item Il est difficile au cerveau humain de se reconstituer une image non déformée. \\ Par exemple, des personnes placés à plusieurs endroits dans un planétarium auront des expériences trop différentes les unes des autres. (cf figure ~\ref{ref:planet}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{planetarium.png} \caption{Expériences visuelles différentes dans un planétarium} \label{ref:planet} \end{figure} Nous plaçons deux individus à différentes positions dans un planétarium, nous virtualisons deux dômes de projection pour chacun (étant donné que c'est en angle que l'on raisonne, nous pouvons manier des cercles dont le centre est le point de vue, et comme cela, on perçoit plus facilement le phénomène). Si l'on place deux objets sur le dôme du planétarium, nous remarquons que l'individu 1 les verra éloignés d'une distance différente de celle vue par l'individu 2. \\ Renommons l'individu 1 en O et l'individu 2 en Q. \\ De façon mathématique, le phénomène s'explique du fait suivant : \begin{eqnarray} \widehat{A O B} \neq \widehat{A Q B} \end{eqnarray} Pour le prouver : \\ ABQO est un quadrilatère quelconque \\ AQ et BO sont ses diagonales \\ Donc à moins d'être un parallélogramme, les angles AOB et AQB ne sont pas égaux. \\ Si ABQO était un parallélogramme, les propriétés suivantes sont vrais : \begin{eqnarray} [AQ] \neq [AO] \end{eqnarray} \begin{eqnarray} [BQ] = [AO] \end{eqnarray} \begin{eqnarray} [AQ] \neq [BQ] \end{eqnarray} \\ Or on sait que pour l'individu 1, les deux objets A et B sont à la même distance de celui-ci. \\ Mais pour l'individu 2, nous venons de montrer que ce n'est pas le cas. \\ La déformation est donc également présente dans le cas du parallélogramme. \\ Donc il faut se trouver au centre du dôme pour ne pas voir de déformation. \item Il est impossible de placer le point de vue de l'utilisateur à l'emplacement idéal, puisqu'il s'agit de l'emplacement du projecteur dans le cas du dôme de Polytech et de plusieurs autres dispositifs du même type. \\ Pour ce problème d'impossibilité, une solution reviendrait à réaliser un dôme sans projecteur central. C'est un sujet pour d'autres branches de l'ingénierie, sortant du cadre de cette recherche. \end{enumerate} Avec tous ces enjeux relevés, nous pouvons étudier des propositions. \section{Proposition \textit{1} : Déformation de l'image} \subsection{Présentation} La déformation de l'image est une approche qui devrait permettre d'afficher une image non déformée sur le support. \\ Si l'on considère que le problème de la déformation provient de la projection de la scène sur un support qui n'a pas la forme de la géométrie sur laquelle a été faite la projection, alors peut-être qu'une déformation de l'image projetée peut lui faire épouser la forme sur le support. \\ De nombreuses personnes se sont penchées sur ce type de déformation~\cite{mapping} : \begin{itemize} \item Gérard Mercator, un mathématicien et géographe du XVIème siècle, a tenté d'établir une carte du monde connu et la projetant sur un cylindre tangeant à l'équateur afin de ne pas déformer les angles (le cylindre peut être vu comme un plan). Mais les distorsions sont de plus en plus importantes à l'approche des pôles, vers lesquels les proportions horizontales ne sont plus respectées.~\cite{navigation} \item Arno Peters, un historien et cartographe allemand, a proposé sa projection en 1974. Elle reprend le principe de la projection de Mercator avec la particularité de compresser et étendre verticalement la projection en fonctione de la lattitude. Ceci compense les problèmes de proportions horizontales et c'est au niveau des aires que les proportions sont alors gardées. \item La projection Eckert IV (1980) reprend la projection de Mercator, mais les parallèles sont des lignes droites non équidistantes. Ceci permet aux méridiens d'avoir une allure elliptique. Le problème de cette projection est qu'on échappe alors à la projection sur un plan. \item Il existe de très nombreuses autres projections du monde sur un plan, et chacune présente un ou plusieurs inconvénient(s). \end{itemize} \begin{figure}[H] \centering \subfloat[Mercator]{\includegraphics[width=0.30\textwidth]{mondre_proj_1.jpg}} \hfill \subfloat[Peters]{\includegraphics[width=0.30\textwidth]{mondre_proj_2.jpg}} \hfill \subfloat[Eckert IV]{\includegraphics[width=0.30\textwidth]{mondre_proj_3.jpg}} \caption{Quelques techniques de projection du monde sur un plan (images de wikipédia)} \label{ref:planis} \end{figure} \subsection{Analyse} Ces solutions présententées par la figure ~\ref{ref:planis} ont toutes un problème, mais ceci n'a pas freiné le monde du rendu 3D. En effet, dans de très nombreuses applications 3D, la scène est projetée sur un plan pour être ensuite affichée sur un plan. La projection sur un dôme est, quant à elle, rendue possible grace au rendu \textit{fisheye} qui est une proposition d'affichage sur un dôme a priori satisfaisante . Dans le même esprit que la projection Eckert IV, nous avons alors une image projetée sur un dôme, affichée déformée sur un plan, mais affichée non déformée sur un dôme. \\ Se pose alors le problème suivant : l'image projetée dans le dôme ne semble pas déformée pour un utilisateur dont le point de vue se situe au centre de projection du dôme. Mais comment faire lorsque le point de vue de l'utilisateur se situe ailleurs ? Étudions le problème à l'aide d'un schéma. (cf figure ~\ref{ref:partvis}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{angle_vue1.png} \caption{Ce schéma montre que la partie visible de la scène 3D (en rouge) n'est pas la même selon deux angles de vue} \label{ref:partvis} \end{figure} \subsection{Limites} La proposition concrète retenue est ainsi de récupérer une image au format FishEye (applicable à un dôme) ce qui la déforme déjà d'un point de vue sur un plan. L'application sur le dôme peut alors se faire sans déformation. \\ Mais la problématique pose la condition que l'utilisateur puisse avoir un différent angle de vue dans le dôme. \\ En changeant l'angle de vue, il peut y avoir création d'informations car de nouveaux éléments de la scène peuvent être vus, et d'autres peuvent être alors cachés. La déformation de l'image ne permet pas d'obtenir de tels résultats, c'est pourquoi ce n'est pas une solution que l'on peut retenir. \section{Proposition \textit{2} : Déplacer la vue} \subsection{Présentation} La première proposition impliquait de déformer l'image, mais on a vu qu'on désirait un point de vue différent sur la scène. C'est le même problème qui se pose alors qu'on regarde par une fenêtre : si l'on monte sur un tabouret, le décors vu n'est plus le même, non seulement le champ de vision est différent, mais en plus la perspective a changé. Une proposition très simple que l'on peut faire alors : pourquoi ne pas déplacer la caméra dans la scène pour s'adapter au nouveau point de vue de l'utilisateur ? \\ \\ La solution a déjà été proposée par la société NaturalPoint qui a sorti un produit nommé le Track Ir. C'est un casque qui détecte les mouvements de la tête sur six degrés de liberté. Le dispositif envoit alors l'information sur les mouvements effectués et c'est la caméra virtuelle qui bouge en fonction. On peut alors faire bouger strictement la caméra de la même façon que les mouvements de tête. Mais dans l'intérêt de ce projet, on peut aussi faire effectuer à la caméra des mouvements qui reviendraient à effectuer les transformations pour donner cette impression de voir par une fenêtre. Le détail de ces calculs est donné par la suite dans la partie "Conception détaillée". \subsection{Analyse} L'inconvénient de cette solution vient simplement des différentes formes que peut avoir le support. En effet, la projection du décors 3D se fait de la même façon sur la caméra, or, selon l'angle de vue, le support n'est plus le même. Par exemple, l'écran rectangulaire devient un trapèze, et le demi-dôme devient une forme quelconque et elliptique. \\ \\ Démonstration par un contre-exemple. (cf figures ~\ref{ref:dem1-1} ~\ref{ref:dem1-2} ~\ref{ref:dem1-3}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{prop2_diag1.png} \caption{Les deux croix noires sont projetées sur un plan pour être vues par la caméra 1. Ce sont alors les deux croix rouges. \\ Si l'on déplace la vue, on a alors la caméra 2. Les deux croix noires devraient alors être projetés sur les deux crois vertes.} \label{ref:dem1-1} \end{figure} \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{prop2_diag2.png} \caption{Or, le plan de projection de la caméra 2 n'est plus le même, il s'agit de la ligne grise. \\ les deux croix noires sont projetées sur les deux croix bleues.} \label{ref:dem1-2} \end{figure} \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{prop2_diag3.png} \caption{Nous sommes alors dans ce cas de figure.} \label{ref:dem1-3} \end{figure} Nous voulons vérifier la double égalité que l'on nomme (E2) : \begin{eqnarray} \frac{AX}{AY} = \frac{CS}{CT} \\ et \frac{BY}{BX} = \frac{BT}{BS} \end{eqnarray} En remarquant que l'on peut confondre d'abord Y avec B, puis X avec A, alors (E2) équivaut à : \begin{eqnarray} \frac{AB}{AX} = \frac{CB}{CS} \\ et \frac{AB}{AY} = \frac{CB}{CT} \end{eqnarray} D'après le théorème de Thalès : si cette double égalité était vraie, alors XS et YT seraient parallèles. \\ Or ces deux droites se coupent en un point : la caméra 2. \\ Donc (E2) est fausse \subsection{Limites} La proportion n'est pas conservée, et il y a une déformation de l'image visible à l'oeil. Et comme on cherche à supprimer les déformations visibles sur tout type de support, y compris un support plat, on ne peut pas garder cette proposition. Il faut que le changement d'angle de vue s'opère sur une scène 3D qui se déforme elle-même en fonction de ce changement, afin de conserver toutes les propriétés de la projection (perspective, distances, angles). C'est pourquoi la troisième proposition entre en jeu. \section{Proposition \textit{3} : Modifier la scène 3D} \subsection{Présentation} La première proposition impliquait de déformer l'image, mais on a vu qu'on désirait un point de vue différent sur la scène. \\ La seconde proposition impliquait de déplacer la vue, mais on a vu que cela ne corrigeait pas les déformations. \\ Mais si l'on alliait les deux propositions, si l'on modifiait la vue et que l'on tordait aussi l'image, peut-être que l'on atteindrait l'objectif posé. \\ On se proposer donc de modifier la scène 3D de façon à lui appliquer les transformatations nécéssaires à la simulation du changement de point de vue et à la torsion de l'image. \\ \\ La technique employée est issue d'une recheche relativement ancienne, puisque c'est le principe de l'anamorphose ou "horizontorium":~\cite{anamorph} ~\cite{horizontorium} \\ Le principe consiste à créer des distortions sur une figure de façon à ce qu'elle soit visible selon les bonnes proportions et les bonnes perspectives selon un point de vue en particulier. \\ L'avantage de la technique est que les distortions effectuées sur l'image prennent en compte la forme du support sur laquelle elle est appliquée. Les limites de l'anamorphose est que l'image non déformée n'est visible que depuis un unique point de vue, sinon, c'est une adaptation du cerveau qui opère la reconstitution de l'image quand on se trouve à des alentours raisonnable du point de vue voulu. Et au delà, l'image tend à être vue d'une façon totalement déformée pour l'interpréter convenablement. Ceci dit, il a été évoqué pour ce projet qu'une caméra pourrait suivre la position du point de vue de l'utilisateur. Si cette proposition débouche sur une solution technique qui admet du temps réel, l'adaptation à un point de vue mobile est alors possible. (cf figure ~\ref{ref:trompe}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{787px-Sant'Ignazio_-_affresco_soffitto_-antmoose.jpg} \caption{Le "trompe l'oeil" du plafond de l'église de Saint-Ignace-de-Loyola de Rome, peint en 1685 (image de wikipedia). \\ On remarque que la perspective de la peinture ne suit pas parfaitement la perspective de la pièce, soit à cause du point de vue qui n'est pas parfaitement celui prévu, soit parce que la peinture a elle-même des défauts mathématiques.} \label{ref:trompe} \end{figure} \subsection{Analyse} On écrase une dimension. La figure suivante (cf figure ~\ref{ref:base}) illustre la situation de base dans le monde virtuel de la projection d'un objet sur un dôme. On récupère les coordonnées de la projection sur la matrice des pixels du dôme (ce qu'on appelle un fragment) et on l'affiche aux coordonnées correspondantes sur le dôme dans le monde réel (ce qu'on appelle un pixel). \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-1.png} \caption{Situation de base dans le monde virtuel de la projection d'un objet sur un dôme} \label{ref:base} \end{figure} Imaginons maintenant que l'utilisateur a un point de vue qui n'est pas au centre du dôme. Plaçons la caméra 2 qui est l'emplacement virtuel de l'individu par rapport au centre qui est décrit par la caméra 1. L'individu voyait jusqu'ici l'objet projeté à l'emplacement que nous avions déterminé. Mais ce que nous voulons, c'est que cet objet soit projeté sur un nouvel emplacement. (cf figure ~\ref{ref:nouvelle}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-2.png} \caption{Nouvel emplacement de caméra, nouvelle projection} \label{ref:nouvelle} \end{figure} Pour que l'objet soit projeté à cet emplacement, il faudrait que la véritable caméra de notre monde virtuel, c'est à dire la caméra 1, visualise cet objet de façon à ce qu'il soit projeté sur ce nouveau point de projection. Pour se faire, il suffit de déplacer l'objet dans l'alignement de la caméra 1 et du nouveau point de projection. \\ Il reste le problème de la distance à laquelle nous le plaçons. La caméra 2 voit cet objet à une distance différente de celle vue par la caméra 1. Il faut donc que l'objet soit placé à la même distance de sa nouvelle projection. La figure ci-dessous illustre le procédé. (cf figure ~\ref{ref:deplacement}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-3.png} \caption{Déplacement de l'objet} \label{ref:deplacement} \end{figure} Il reste cependant un problème, dans des cas de figure où l'on manie des primitives de très grande taille, on se rend compte que la transformation ne peut pas s'éffectuer uniquement sur les sommets. Il faudrait pouvoir diviser de façon dichotomique la primitive de façon à obtenir plusieurs sommets qui seront alors déplacés, et la forme reconstruite ne sera alors plus une forme pouvant être représentée par une primitive. (cf figure ~\ref{ref:recons}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-3-2.png} \caption{Exemple de la reconstruction d'une primitive (un segment dans le monde 2D) et de sa transformation en n'opérant que sur les sommets.} \label{ref:recons} \end{figure} Afin de nous préparer à montrer mathématiquement que nous pouvons déterminer ce nouvel emplacement, nous allons nommer tout ce qui peut nous être utile. Nous colorisons en vert les données connues, en orange les données inconnues et en rouge la donnée inconnue que l'on cherche. (cf figure ~\ref{ref:geom}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-4.png} \caption{Simplification du problème pour une approche géométrique} \label{ref:geom} \end{figure} Nous reverrons dans le détail cette proposition et comment déterminer les nouvelles coordonnées d'un objet. \\ \\ Cette proposition n'est pas complète sans avoir présenté un moyen informatique de déplacer nos objets. \\ La méthode la plus simple serait de récupérer l'ensemble des sommets de la scène et les déplacer vers leurs nouvelles coordonnées avant de les afficher. C'est un procédé trop couteux en temps car il s'agit d'utiliser le pipeline à fonction fixe. \\Ce que propose les librairies OpenGL2.0 ou les dernières versions de Direct3D, ce sont les shaders programmables. Selon le guide officiel OpenGL2.0, le rendu graphique utilisant le pipeline fixe s'agence de la façon suivante (cf figure ~\ref{ref:pipeline}) :~\cite{opengl} \begin{figure}[H] \centering \includegraphics[height=0.80\textwidth]{agencementshaders.png} \caption{Pipeline à fonction fixe d'OpenGL.} \label{ref:pipeline} \end{figure} Dans ce livre, on décrit le fonctionnement d'OpenGL comme étant sur deux ordinateurs, un gérant les sommets et l'autre les fragments. On est capable de controler le fonctionnement des deux ordinateurs en modifiant la façon dont ils sont agencés entre eux, mais on ne peut pas modifier le fonctionnement interne de ces ordinateurs. C'était un fait qui n'est plus d'actualité désormais. On peut désormais programmer le fonctionnement de ces ordinateurs, que l'on appelle Pipeline. \\ Ce qui nous intéresse, c'est de programmer un pipeline afin de gérer nous-même les transformations à éffectuer. OpenGL 2.0 offre la possibilité d'un piepline de shading programmable via un langage : le GLSL (OpenGL Shading Language) \\ Nous pourrons utiliser deux types de shaders parmi ceux existant selon la liste donnée par les specifications du GLSL~\cite{glspec} : \begin{enumerate} \item \textbf{Le Vertex Shader} : On peut programmer le processeur de vertex pour modifier les attributs d'un vertex (sommet en français). Quand ce code est compilé, on obtient un vertex shader éxecutable qui fonctionne sur le processeur de vertex. Il fonctionne alors pour chaque vertex un par un. \item \textbf{Le Geometry Shader}: On peut programmer le processeur de géométrie pour modifier les attributs d'une primitive construite à partir de vertex. Quand ce code est compilé, on obtient un geometry shader éxecutable qui fonctionne sur le processeur de géométrie. Il est alors possible, en sortie, de trouver un nombre différent de vertex par rapport à ce qui était en entrée, car il peut y avoir une multiplication des primitives. Ces vertex et primitives passent alors par un pipeline spécial. \end{enumerate} Ainsi, avec le Vertex Shader, nous pourrons changer les coordonnées de tous les sommets, tandis qu'avec le Geometry Shader, nous pourrons transformer les primitives quand elles seront trop grandes. \subsection{Limites} La démonstration des limites a besoin de la formalisation et de l'approche mathématique. Se référer donc à la partie Proposition. \section{Récapitulatif} La première proposition consistait en une torsion de l'image. C'est un procédé qui admet de nombreuses limites, comme en témoigne la longue recherche sur l'application d'une projection sur une figure géométrique appliquée à une autre figure géométrique. Le principal problème de cette solution est que la perspective doit pouvoir changer, et la surface visible doit ne plus être la même après le changement d'angle de vue, ce qui n'est pas possible avec la déformation simple de l'image. \\ La seconde proposition consistait en un déplacement de la caméra pour suivre la vue. Cependant, la surface de projection de la caméra doit aussi pouvoir changer afin de ne pas tordre l'image aperçue après rendu. \\ La troisième proposition est finalement un mélange des deux premières mais utilisant une technique différente : il s'agit de modifier la scène 3D en fonction d'une caméra virtuelle décentrée et de la surface de projection de la véritable caméra. Elle s'appuie sur un calcule mathématique de détermination des coordonnées et sur les shaders programmables pour modifier la scène 3D. \clearpage \begin{table} \begin{center} \begin{tabular}{ |l || c | c | r | } \hline avantages & torsion image & déplacement caméra & transformation scène (shaders) \\ \hline adaptation au support & oui mais limites & non & oui \\ \hline respect de la perspective & non & oui & oui \\ \hline rapidité de rendu & très rapide & très rapide & rapide si utilisation des shaders \\ \hline \end{tabular} \end{center} \caption{Tableau comparatif des propositions.} \end{table} \clearpage %------------------------------------------------------------------------------------------------------------- \chapter{Propositions} \label{chap:Propositions} Reprenons les idées une par une afin de formaliser leur fonctionnement et les analyser. \section{Proposition \textit{1} : Déformation de l'image} \subsection{Idées préliminaires} La première idée était de déformer l'image afin qu'elle s'adapte à la surface. Pour cela, nous prenions l'exemple d'un plan appliqué à un dôme. \subsection{Formalisation} Nous avons constaté selon la recherche éffectuée qu'il n'y avait pas de moyen pertinent de déformer l'image pour l'appliquer. Cependant, grace au système de vision fisheye, on peut appliquer linéairement l'image sur le dôme. Nous pouvons faire une approche d'application en remarquant que le dôme n'est qu'une matrice de pixels. On peut alors appliquer l'algorithme suivant : \\ \emph{Pour chaque fragment de coordonnées (i;j), l'afficher au pixel de coordonnées (i,j) du dôme.} \subsection{Démonstration} Avec la vision fisheye, la scène 3D est projetée sur un dôme et est déformée sur un écran plat. \\On a donc une image qui s'adapte à un dôme. \\Or, le support sur lequel on veut appliquer l'image est un dôme. \\Donc l'affichage sur le dôme n'est pas déformé. \\ \\ La caméra se trouve au centre du dôme de projection \\ Or on considère que le point de vue de l'utilisateur se trouve au centre du dôme-écran \\ Donc selon cette considération, l'image n'est pas déformée pour son point de vue. \subsection{Analyse} Comme dit dans la partie Etat de l'Art, l'objectif est partiellement atteint car on ne souhaite pas que le point de vue de l'utilisateur se trouve au centre du dôme. Par exemple, c'est une chose impossible avec le dôme de l'école, car à son centre se trouve le projecteur. \section{Conclusion} Nous pourrons faire l'expérimentation d'un rendu fisheye pour être convaincu que l'image apparaîtra déformée sur le dôme de l'école. \section{Proposition \textit{2} : Déplacement de la caméra} \subsection{Idées préliminaires} La seconde idée était de déplacer la caméra selon l'emplacement du point de vue de l'utilisateur. \subsection{Formalisation} Soient les coordonnées du centre du dôme-écran dans le monde réel : (xr,yr) \\ Soient les coordonnées de la caméra dans le monde virtuel : (xv,yv) \\ Soient les coordonnées du point de vue de l'utilisateur dans le monde réel : (xu, yu) \\ Les coordonnées du nouvel emplacement de la caméra dans le monde virtuel sont alors : (xv+k(xu-xr),yv+k(yu-yr)) \\ avec k réel quelconque. \subsection{Analyse} La valeur de k quelconque est un premier problème. Il réside du fait que la caméra n'a pas de taille connue, c'est un point. Pour comprendre le phénomène, il faut imaginer une caméra dans une scène 3D qui représente un salon. Si la caméra simule la vue d'un individu dans ce salon, se déplacer dans le dôme reviendra à faire déplacer la tête de l'individe de quelques centimètres. Mais si la caméra simule la vue d'une fourmie dans ce salon, se déplacer dans le dôme reviendra alors à faire déplacer la tête de la fourmi de quelques milimètres. \\ Le choix de k est un problème qui est soulevé par cette idée et que nous retrouverons sur la troisième proposition. \\ \\ La limite de cette solution est la déformation de l'image comme on l'a démontré dans la partie Etat de l'Art : la surface de projection doit aussi être modifiée lors du déplacement de la caméra, or, c'est quelque chose que l'on ne peut pas implémenter sur le pipeline fixe. \section{Conclusion} Ce problème technique du changement de surface de projection est une limite à cette solution qui voit alors une déformation de l'image malgré le respect de la perspective. C'est en voulant résoudre ce problème que l'on va étudier la troisième proposition. \section{Proposition \textit{3} : Modifier la scène 3D} \subsection{Idées préliminaires} L'idée pour éffectuer cette déformation de l'image en plus du changement d'angle de vue est de déformer la scène 3D.~\cite{horizontorium} \subsection{Formalisation} Reprenons le schéma que nous avions établi dans la partie Etat de l'Art. (cf figure ~\ref{ref:geom2}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{sol3-4.png} \caption{Simplification du problème pour une approche géométrique} \label{ref:geom2} \end{figure} Le but est de déterminer les coordonnées du point B'. On connait : \begin{eqnarray} O(0,0) \\ A(xa,ya) \\ C \\ B(xb,yb) \\ D \end{eqnarray} On cherche P(xp,yp). \\ De façon mathématique, on remarque que P est une solution (il peut y en avoir 1, 2 ou aucun) du système d'équation de la droite (AB) et du cercle de centre O et de rayon C : \begin{eqnarray} yp=\frac{yb-ya}{xb-xa}\times xp + ( ya - \frac{yb-ya}{xb-xa} \times xa ) \\ \sqrt{xp²+yp²}=C \end{eqnarray} Simplifions certaines parties : \begin{eqnarray} \alpha =\frac{yb-ya}{xb-xa} \beta = ( ya - \frac{yb-ya}{xb-xa} \times xa ) \end{eqnarray} \\ On trouve la solution suivante : \begin{eqnarray} xp=\frac{2\alpha \beta \sqrt{(2\alpha \beta)² - 4(\alpha+1)(\beta - C²)}}{2(\alpha+1)} \\ yp=\frac{\frac{2\beta}{\alpha} \sqrt{(\frac{2²\beta²}{\alpha}) - 4(\frac{\alpha+1}{\alpha})(\beta² - C²)}}{2(1+\frac{1}{\alpha})} \\ \end{eqnarray} ou \begin{eqnarray} \\ xp=\frac{-2\alpha \beta \sqrt{(2\alpha \beta)² - 4(\alpha+1)(\beta - C²)}}{2(\alpha+1)} \\ yp=\frac{-\frac{2\beta}{\alpha} \sqrt{(\frac{2²\beta²}{\alpha}) - 4(\frac{\alpha+1}{\alpha})(\beta² - C²)}}{2(1+\frac{1}{\alpha})} \end{eqnarray} Une application informatique permet de savoir quelle partie de la solution nous intéresse. (Il suffit de connaître les coordonnées de l'objet et de vérifier le signe) \\ Une approche informatique permet de connaître les coordonnées de P d'une autre façon, car on travaille dans un espace discret : Plutôt que de représenter le dôme sous la forme d'une équation, on peut le représenter sous la forme d'une matrice de profondeurs. Ceci permet nottamment de construire d'autres géométries pour la surface de projection. \\Voici les grandes lignes de l'algorithme à implémenter, en trois dimensions : \\ \emph{ \\Pour chaque fragment du dôme, on a ses coordonnées X,Y et Z. \\Pour déterminer si la droite passe par ce fragment, on vérifie si elle passe par la fenêtre que ce fragment constitue avec ses voisins de coordonnées (x,y+1),(x+1,y) et (x+1,y+1). \\Si la valeure de Z trouvée à l'équation de la droite pour ces quatre coordoonnées est comprise entre la valeure minimum et la valeur maximum de de cette fenêtre, alors la droite coupe cette fenêtre. \\Si la droite coupe la fenêtre, on considère que le fragment dont est issue la fenêtre est coupé par la droite, c'est donc ce fragment qui constitue le point P(xp,yp,zp)} \\ \\ Il reste une dernière étape à la formalisation des calculs nécéssaires à l'obtention des nouvelles coordonnées d'un objet. Cette étape, c'est la détermination de ces coordonnées de B' grace aux coordonnées du point P que l'on a trouvées. \\ Comme vu dans la partie Etat de l'Art, la distance [PB] doit être égale à la distance [PB'] et OPB doivent être alignés. On peut donc en déduire que : \begin{eqnarray} \overrightarrow{OB'}=\overrightarrow{OP} \times \frac{(|\overrightarrow{OP}|+|\overrightarrow{PB}|)}{|\overrightarrow{OP}|} \end{eqnarray} \subsection{Analyse} La limite de cette solution est l'utilisation de calculs mathématiques sur un espace qui est finalement discret. On l'a vu avec la façon de déterminer les paramètres de la surface de projection par exemple. L'autre limite, c'est le parcours de chaque fragment du dôme de projection qui est lourd en calcul. Enfin, la dernière limite est le manque de preuve selon laquelle la distance de [PB] est égale à la distance de [PB']. Nous l'avons déterminé arbitrairement. Ce qui est prouvé, par contre, c'est que l'ordre est conservé, car on conserve les proportions par ce procédé. On peut donc garder cette solution avec cette démonstration manquante. \section{Conclusion} Cette proposition allie les deux premières propositions et permet d'éviter les déformations et conserver la perspective. C'est l'objectif du projet et cette proposition entre le mieux dans le cadre de cet objectif, même si elle use d'artifices, le rendu est celui voulu. Elle a le mérite d'utiliser un procédé connu pour déformer la scène 3D. Nous verrons l'utilisation technique des shaders par la suite de ce rapport. %------------------------------------------------------------------------------------------------------------- \chapter{Conclusion} \section{Résumé du travail effectué} L'état de l'art nous a révelé plusieurs points importants. D'abord, l'importance de chercher à afficher une scène 3D sur un dôme est capitale, et les écrans de type "plat" ont une limite qui nous force à nous adapter à des déformations qui paraissent trop évidentes quand on s'y concentre. Mais l'affichage sur un dôme présente lui aussi des déformations encore plus importantes du fait que le point de vue de l'utilisateur n'est pas centré sur le dôme. Nous avons donc étudié la recherche éffectuée sur l'application d'une image issue d'une sphère sur un plan, à travers les recherches éffectuées sur les planisphères. Ceci nous a permi d'aboutir à une première proposition issue de cette recherche mais elle ne résoud pas le problème du décentrage du point de vue. Nous avons alors découvert une société récente qui propose un dispositif qui adapte la caméra du monde virtuel à la tête de l'utilisateur dans le monde réel, mais cette proposition ne résoud pas le problème de la déformation sur le dôme. De ce fait, nous avons cherché une solution qui allie intelligemment les deux, et qui repose sur le principe de l'anamorphose, ce qui permet de conserver la perspective sans pour autant déformer l'image. La solution issue est basée sur la déformation de la scène 3D de façon à ce qu'elle soit perçue de façon non déformée et avec les bonnes perpectives pour un point de vue en particulier, indépendant du centre du dôme. La technique est aussi indépendante de la forme du support, on l'a vu à travers la démonstration mathématique du procédé. Pour assurer le temps réel, une solution informatique est mise en avant : la programmation des Shaders, exploitant le GPU. Nous verrons par la suite ce que l'on pourra conclure de la phase de développement. \section{Enseignements} J'ai personnellement tiré un enseignement important de ce travail grace à M. Picarougne qui a pris sur son temps pour me donner une description global du monde de la programmation des shaders et son fonctionnement. Les Vertex Shaders, les Geometry Shaders et les Fragment Shaders ont été cités et leur principe étudié. Ce travail, plus globalement, offre un enseignement sur une partie du monde du rendu 3D, et particulièrement l'OpenGL. On pourra également retenir un fragment de la recherche éffectuée sur la représentation de la perspective avec les quelques techniques étudiées. \section{Perspectives de recherche} Une perspective intéressante serait la création d'un dispositif permetant d'enregistrer en temps réel le support sur lequel est affiché la scène 3D. Puisque ce support est enregistré sous forme de matrice, un dispositif enregistrant la distance des éléments, par rapport à lui, comme le Kinect par exemple, serait capable d'assurer cette tâche. Nous pourrions alors concevoir une construction de ce type. (cf figure ~\ref{ref:idee}) \begin{figure}[H] \centering \includegraphics[width=0.50\textwidth]{ouverture.png} \caption{Schéma de proposition pour une extention à cette recherche, en se basant sur une caméra infrarouge qui enregistre en temps réel la forme du support.} \label{ref:idee} \end{figure} %--------------------------------------------------------------------------------------------------------- \section{Bibliographie} \begin{thebibliography}{9} \bibitem{msdn_pipeline} Microsoft Corporation \textit{Pipeline Stages (Direct3D 10)}, \url{http://msdn.microsoft.com/en-us/library/bb205123.aspx}, - page consultée le 5 Octobre 2011. \\ \textbf{Résumé} : Le Microsoft Developer Network (MSDN) est une section de Microsoft qui, entre autre, fournit une aide aux développeurs au travers de divers tutoriaux, manuels et documentations. Cette documentation en ligne fournit des explications sur le fonctionnement et l'utilisation du pipeline programmable. \\ \textbf{Analyse} : Cette documentation apporte des explications théoriques et des définitions. Elle se focalise sur Direct3D mais la théorie des shaders est la même en OpenGL. Il faut cependant faire attention avec certains termes qui ne sont pas les mêmes entre les deux mondes. \bibitem{mapping} Bernie Ashmore \textit{Mapping our world: an innovative approach to mapwork for ages 9-13}, \\ \textbf{Résumé} : Ce document présente aux écoliers les différentes façons de représenter la Terre ainsi qu'un survol des tenants et aboutissants de la cartographie terrestre. \\ \textbf{Analyse} : Il s'agit d'une ressource pour enfants, et pourtant elle soulève un problème important : celui de la projection sur un plan et les distortions engendrées. Le document a le mérite d'établir une liste des différents types de projections, qui sont le résultat de plusieurs siècles de recherches pour certaines. Il permet d'éliminer la proposition de déformation de l'image dans le cadre de ce projet. L'inconvénient est qu'il ne montre pas le problème d'un point de vue mathématique. \bibitem{navigation} Robert Rolland, Chercheur associé au laboratoire ERISCS et à L'Institut de Mathématiques de Luminy \textit{Quelques problèmes mathématiques liés à la navigation (version 6)}, \\ \textbf{Résumé} : Ce rapport présente la problématique d'un point de vue mathématique que pose la navigation maritime \\ \textbf{Analyse} : Une partie de ce rapport se concentre sur la représentation de Mercator et démontre mathématiquement les distortions engendrées. L'inconvénient est qu'il ne présente que cette déformation. \bibitem{wideview} Luciano Napolitano \textit{Wideview and other tools for Microsoft Flight Simulator and cockpit builders}, \url{http://www.wideview.it/index.php} - page consultée le 12 octobre 2011 \\ \textbf{Résumé} : Ce site fait la promotion d'un Add-on pour Flight Simulator X permettant aux utilisateurs de construire leur propre cockpit à la maison. \\ \textbf{Analyse} : La ressource est intéressante car elle montre ce que les utilisateurs réussissent à produire afin d'augmenter l'immersion en offrant un champs de vision très large. C'est une alternative à l'affichage sur un dôme et on peut facilement analyser les points négatifs du procédé grace aux nombreuses explications fournies. \bibitem{opengl} Mason Woo, Jackie Neider, Tom Davis, Dave Shreiner \textit{OpenGL 2.0 Guide officiel 4ème édition}, \\ \textbf{Résumé} : Ce livre explique au lecteur comment utiliser la librairie graphique OpenGL afin de créer des rendus. La version 2.0 présentée ici inclut la programmation sur le pipeline. \\ \textbf{Analyse} : La partie qui nous intéresse, celle dédiée au GLSL, a le mérite d'expliquer l'architecture et l'agencement du pipeline graphique afin de mieux comprendre comment les shaders sont traités. Il explique dans le détail comment programmer ses shaders et fournit de nombreux tableaux d'exemples de variables. Le point négatif est l'absence d'un véritable tutoriel pas-à-pas. Il est donc judicieux d'allier cette ressource avec un tutoriel. \\ \textbf{Pertinence} : Ce livre m'a été conseillé et prêté par M. Picarougne et est suffisamment récent par rapport au sujet qui nous intéresse (les shaders). Il contient également de nombreuses références à d'autres ouvrages et documentations qui permettent d'élarger le champs de recherche. \bibitem{lighthouse} Lighthouse3d.com \textit{GLSL tutorial}, \url{http://www.lighthouse3d.com/opengl/glsl/} - pages consultées régulièrement depuis le 02/10/2011 \\ \textbf{Résumé} : Ce tutoriel en ligne décrit pas à pas comment créer ses shaders avec la librairie OpenGL. \\ \textbf{Analyse} : Régulièrement, des portions de code sont fournies, voir des programmes totalement fonctionnels. On peut les comprendre grace aux explications du tutoriel, mais il est aussi judicieux de les allier avec les explications théoriques du livre cité précédemment. \\ \textbf{Pertinence} : L'auteur de ce tutoriel n'est pas connu, mais le sérieux du blog est les nombreux commentaires positifis au sujet de ce tutoriel nous permettent de conserver cette source et de l'exploiter. Comme dit, il vaut tout de même mieux l'allier avec une source plus pertinente afin de vérifier la véracité des explications données. \bibitem{glspec} John Kessenich, Dave Baldwin, Randi Rost \textit{The OpenGL® Shading Language}, \\ \textbf{Résumé} : Ce document contient les spécifications de la version 4.20 de l'openGL shading language \\ \textbf{Analyse} : Les spécifications sont complètes, on a également un rappel des fonctions dépréciées et une partie traite des geometry shaders. C'est un document de spécification et n'est pas fait pour apprendre le sujet dont il parle, mais pour être utilisé comme un boîte à outils. \\ \textbf{Pertinence} : Ce document est recommandé par le livre OpenGL 2.0 Guide officiel 4ème édition, il est très technique et est donc à allier avec d'autres documents du même sujet. \bibitem{anamorph} \textit{Saturday Magazine, Janvier-Juin 1842}, \\ \textbf{Résumé} : L'article en page 17 présente le principe de l'anamorphose et ses limites. \\ \textbf{Analyse} : L'article explique dans le détail comment créer soit-même un dessin soumis à l'anamorphose, et montre un exemple clair du procédé. On regrette cependant l'absence d'explications mathématiques. \bibitem{imagemagick} \textit{ImageMagick v6 Examples -- Distorting Images}, \url{http://www.imagemagick.org/Usage/distorts/\#affine_projection}, - page consultée le 22 Octobre 2011 \\ \textbf{Résumé} : Page de manuel des fonctions imagemagick \\ \textbf{Analyse} : La partie sur les projection montre d'un point de vue technique comment est opérée la transformation des images lorsqu'on les déforme. On peut alors mieux comprendre comment OpenGL fonctionne pour les affichages. Le document sert surtout pour les personnes désirant faire de la retouche technique d'image, puisque l'utilisation d'OpenGL nous épargne ce genre de calculs. \bibitem{fov} Andrew S. Glassner \textit{Principles of digital image synthesis, Volume 1}, \\ \textbf{Résumé} : La partie 1.5 du livre porte sur l'analyse de la perspective et du champ de vision. \\ \textbf{Analyse} : Cette partie explique avec de nombreux exemples les phénomènes de perspective et de projection des objets que nous percevons. Nous avons surtout un exemple qui justifie l'utilisation d'un dôme pour l'être humain, ainsi que quelques analyses sur les phénomènes d'objets qui apparaissent plus ou moins gros et comment on peut jouer sur ce phénomène pour faire illusion sur la distance. Cette partie pourrrait également être intéréssante dans le cadre d'un projet sur la vision en relief. \bibitem{archi} Thomas Morris \textit{A popular outline of perspective or graphic projection, 1869}, \\ \textbf{Résumé} : C'est un livre d'architecture du XIXe siècle qui traite de la recherche dans le domaine de la perspective. \\ \textbf{Analyse} : Le chapitre "pan-angulare perspective" nous fait la présentation de la projection sur un dôme et du véritable phénomène de perspective selon lequel les lignes n'apparaissent pas droites mais courbées. Le diagramme de la projection sur un dôme montre la non-parallélisation des droites du monde perçu. Cette source est à coupler avec une source plus moderne qui pourrait traiter de l'informatisation du phénomène. \bibitem{horizontorium} \textit{The Magazine of science, and schools of art, Volume 1, 1842}, \\ \textbf{Résumé} : (page 66) Ce court article traite de l'anamorphose en décrivant le phénomène observé et le principe de constuction \\ \textbf{Analyse} : L'article a le mérite de présenter un algorithme qui permet de déterminer la transformation à opérer sur un point de façon à ce que sa projection suive l'illusion donnée par l'anamorphose. D'un point de vue informatique, c'est donc plutôt intéressant. Il faut l'allier avec l''article sur l'anamorphose de Saturday Magazine. \end{thebibliography} %--------------------------------------------------------------------------------------------------------- \chapter{Planification} Figure~\ref{fig:PlanningPrevisionnel} \begin{figure*} \centering \includegraphics[width=0.50\textwidth]{gant_1_prev.png} \caption{Planification prévisionnelle (via Gant Project)} \label{fig:PlanningPrevisionnel} \end{figure*} Figure~\ref{fig:PlanningEffectif} \begin{figure*} \centering \includegraphics[width=0.50\textwidth]{gant_2_prev.png} \caption{Planning effectif (via Gant Project)} \label{fig:PlanningEffectif} \end{figure*} Ce qui est le plus flagrant comme différence entre ce qui avait été prévu et l'effectif, c'est la recherche de documents qui a duré tout le long de cette première phase. Et elle pourrait durer au cours de la seconde phase. La recherche bibliographique est quelque chose de constant qui doit s'éffectuer tout au long du projet de recherche car il n'est pas possible de récupérer l'intégralité des documents de l'humanité traitant d'un sujet en particulier, d'autant plus que le sujet portant sur un procédé relativement récent peut voir de nouvelles publications apparaître durant son développement. \chapter{Fiches de suivi} \subsection{semaine 38} Temps de travail : 7 heures. \subsubsection{Travail effectué} \begin{itemize} \item Cerner la problématique : quelle transformation faut-il effectuer ? \item Trouver l'application mathématique qui permet de passer des coordonnées d'un vertex aux nouvelles coordonnées. Difficulté : vérifier que l'application mathématique est juste. \item Transformer toute l'application mathématique vers un calcule de vecteurs et de matrices. \end{itemize} \subsubsection{Travail non effectué} \begin{itemize} \item Lire la théorie sur les shaders sous QT avec openGL; (en cours de lecture) \end{itemize} \subsubsection{Échange} \begin{itemize} \item Comprendre à quoi est équivalent la transformation. \item Comment est effectué l'affichage sur le dôme \item Choix du geometry shader pour modifier la géomtrie des vertex, et du displacement mapping pour modifier le positionnement des textels. \end{itemize} \subsubsection{Planification} \begin{itemize} \item Passer à la rechercher sur la programmation sur GPU \item Finir de lire l'article de developpez.com \url{"http://gbelz.developpez.com/remi-achard/gpu-avance-avec-qt/"} \item Tenter un pseudo-code de programmation des shaders à partir de l'application mathématique trouvée. \end{itemize} \subsection{semaine 39} Temps de travail : 8 heures. \subsubsection{Travail effectué} \begin{itemize} \item Implémentation sur GPU : le tutoriel de NeHe semble le plus approprié : \url{"http://nehe.gamedev.net/"} (recommencé par des chercheurs du laboratoire LISA à Bruxelles) -> Vertex shader, geometry shader. Par encore de tutoriel sur le displacement mapping. \item Comprendre les tenants et aboutissants des vertex shaders et geometry shaders grace aux documentations de Nvidia. Le wiki de Valve Software contient de nombreuses références exploitables \url{"http://developer.valvesoftware.com/wiki/Shader"} mais le document en lui-même n'est pas suffisamment exploitable. \item Trouvé un ouvrage suffisamment récent sur l'openGL que la BU va recevoir : Computer Graphics Through Opengl: From Theory to Experiments (je vais me renseigner cette semaine si je peux l'avoir à temps, sinon je me contenterai d'ouvrages numérisés) \end{itemize} \subsubsection{Travail non effectué} \begin{itemize} \item Tenter un pseudo-code de programmation des shaders à partir de l'application mathématique trouvée. Trop tôt par rapport aux informations que j'ai trouvées. \end{itemize} \subsubsection{Échange} \begin{itemize} \item Je tente d'entrer en contact avec un responsable informatique du futuroscope qui pourrait me donner plus d'informations sur la technique d'affichage sur un dôme. Je pourrais espérer avoir une base déjà expérimentée. \end{itemize} \subsubsection{Planification} \begin{itemize} \item Déterminer technqiquement comment allier les shaders et mes calculs. \item Essayer de trouver un ouvrage sur l'openGL suffisamment récent pour inclure le displacement mapping et le geometry shader. \end{itemize} \subsection{semaine 40} Temps de travail : 8 heures. \subsubsection{Travail effectué} \begin{itemize} \item Déterminer théoriquement comment allier les shaders et mes calculs. \item Trouver un ouvrage sur l'openGL suffisamment récent pour inclure le displacement mapping et le geometry shader. Il m'a été conseillé par M. Picarougne et il traite du GLSL, le langage que je devrai utiliser pour manipuler les shaders. \item J'ai découvert le principe de l'Anamorphose : \url{http://fr.wikipedia.org/wiki/Anamorphose} qui s'avère a priori être la technique que je dois automatiser. Ceci pourrait être une aide quant à l'interrogation que j'ai eue avec M. Picarougne sur la proportionnalité de la projection. C'est une piste tout à fait secondaire. \end{itemize} \subsubsection{Travail non effectué} \begin{itemize} \item Déterminer techniquement comment allier les shaders et mes calculs. \end{itemize} \subsubsection{Échange} \begin{itemize} \item Entrevue avec M. Picarougne pour avoir plus de précisions sur les différents shaders (vertex, geometry et fragment) et leur utilité dans ce projet. \item Même entrevue : présentation de mes calcules et comment les adapter à la discrétisation de la surface du dôme. \item Même entrevue : attribution de mon poste de travail avec le matériel nécéssaire (carte graphique) \end{itemize} \subsubsection{Planification} \begin{itemize} \item Creer mes premiers shaders afin de préparer la phase de réalisation \item Terminer d'adapter mes calculs à la structure en matrice. \end{itemize} \subsection{semaine 41} Temps de travail : 7 heures. \subsubsection{Travail effectué} \begin{itemize} \item Tentative de configuration du compilateur VS2010 64 bits pour intégrer les deux librairies OpenGL (Glew et Glut) \item Nouvelle tentative sur un compilateur Mingw32 : glut ok, glew ok, mais shaders non fonctionnels \end{itemize} \subsubsection{Échange} \begin{itemize} \item Entrevue avec M. Picarougne grace à qui j'ai les librairies sur la machine du dôme, avec le compilateur VS2010 32 bits. \end{itemize} \subsubsection{Planification} \begin{itemize} \item Creer mes premiers shaders afin de préparer la phase de réalisation \end{itemize} Temps de travail : 4 heures. \subsubsection{Travail effectué} \begin{itemize} \item Revue des inconvénients de ma façon de poser le calcule (équation du dôme) et de la façon efficace de le faire (matrice des profondeurs) \item Lecture des avantages d'OpenGL par rapport à d'autres systèmes de rendu graphique. \end{itemize} \subsection{semaine 42} Temps de travail : 9 heures. \subsubsection{Travail effectué} \begin{itemize} \item Premiers shaders en GLSL (vertex shaders pour modifier la position des vertex d'une figure) \item (partiellement) conception détaillée \end{itemize} \subsubsection{Travail non effectué} \begin{itemize} \item créer moi-même le shader (ne pas se contenter d'utiliser un vertex shader et le parametrer via les variables "uniforme" et "attribute") \end{itemize} \subsubsection{Planification} \begin{itemize} \item Finir absolument le rapport et le support de la soutenance durant les vacances et profiter du temps libéré la semaine de la rentrée pour continuer le développement. \end{itemize} \subsection{semaine 43} Temps de travail : 9 heures. \subsubsection{Travail effectué} \begin{itemize} \item Finir le rapport et le support de la soutenance. \item Elargissement des sources bibliographiques, nottamment pour la programmation des shaders. \end{itemize} \subsubsection{Planification} \begin{itemize} \item Comme l'avance est prise, je vais pouvoir me concentrer sur le développement cette semaine. \end{itemize} \chapter{Auto-contrôle et auto-évaluation} \begin{figure*} \centering \includegraphics[width=0.50\textwidth]{auto_eval1.png} \caption{Auto-évaluation phase bibliographique} \end{figure*} \listoffigures \end{document}