Some modifs from Axel
This commit is contained in:
		
							parent
							
								
									1f50595bc3
								
							
						
					
					
						commit
						d7fef5e857
					
				| @ -1,11 +1,11 @@ | ||||
| \part{Architecture du programme} | ||||
| Comme dit précédemment, le programme se décompose en un côté serveur et un côté | ||||
| client. Le cas du \emph{streaming} sera traité à part (dans la partie | ||||
| \ref{streaming}, puisqu'il est à cheval sur le client et le serveur) et nous ne | ||||
| parlerons ici que du serveur, puis du code client. | ||||
| \ref{streaming}, puisqu'il est comporte des parties à la fois sur le client et | ||||
| le serveur) et nous ne parlerons ici que du serveur, puis du code client. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Voici une simplification de l'arborescence de la version de | ||||
| Voici une \emph{simplification} de l'arborescence de la version de | ||||
| développement : | ||||
| 
 | ||||
| \begin{figure}[H] | ||||
| @ -130,20 +130,6 @@ développement : | ||||
|             two children at (0.5,-0.7) and (0.5,-1.4)}, | ||||
|         edge from parent path={(\tikzparentnode.south) |- (\tikzchildnode.west)}] | ||||
|         \node [folder] {apps} | ||||
|         child {node [folder] {bouncing-cube} | ||||
|             child { node {BouncingCube.js}} | ||||
|             child { node {main.js}} | ||||
|         } | ||||
|         child [missing] {} | ||||
|         child [missing] {} | ||||
|         child {node [folder] {multi-sphere} | ||||
|             child {node {main.js}} | ||||
|         } | ||||
|         child [missing] {} | ||||
|         child {node [folder] {stream-demo} | ||||
|             child {node {main.js}} | ||||
|         } | ||||
|         child [missing] {} | ||||
|         child {node [folder] {prototype} | ||||
|             child {node [folder] {interactive} | ||||
|                 child {node {main.js}} | ||||
| @ -177,7 +163,7 @@ développement : | ||||
|     \end{tikzpicture} | ||||
|     \caption{Détail des applications} | ||||
| \end{subfigure} | ||||
| \caption{Arborescence} | ||||
| \caption{Arborescence du \emph{repository} de développement} | ||||
| \end{figure} | ||||
| \tikzstyle{every node}=[] | ||||
| 
 | ||||
| @ -188,16 +174,24 @@ est en fait le programme principal du serveur. | ||||
| \subsection{Dépendances} | ||||
| Le programme principal utilise de nombreuses libraires : les dépendances de | ||||
| notre serveur sont définies dans le fichier \texttt{package.json}. | ||||
| L'inconviéniant d'avoir de nombreuses librairies en même temps est la | ||||
| L'inconvénient d'avoir de nombreuses librairies en même temps est la | ||||
| compatibilité des versions : en effet, une des dépendances nécessite une | ||||
| version particulière d'une autre librairie, et c'est pourquoi nous avons | ||||
| utilisé \texttt{npm-shrinkwrap.json} pour préciser les versions de chacune des | ||||
| dépendances de manière récursive. | ||||
| version particulière d'une autre librairie. Chaque dépendance est une | ||||
| librairie, qui a elle même ses dépendances, etc... | ||||
| 
 | ||||
| \paragraph{} | ||||
| Nous avons eu ce problème au cours de notre projet : une librairie utilisait | ||||
| une version précise d'une dépendance qui en nécessitait une autre. Nous avons | ||||
| donc utilisé une fonctionnalité de \emph{npm} (le programme qui permet | ||||
| d'installer des librairies dans un serveur NodeJs) qui s'appelle | ||||
| \emph{shrinkwrap} et qui permet de figer l'arbre de dépendance d'une | ||||
| application NodeJs. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Les \emph{packages} que nous utilisons sont les suivants : | ||||
| \begin{itemize} | ||||
|     \item \emph{express} : un framework web pour NodeJs | ||||
|     \item \emph{express} : un framework web pour NodeJs qui permet de gérer | ||||
|         facilement les urls, les requêtes, les réponses, etc... | ||||
|     \item \emph{jade} : un moteur de template pour simplifier la génération des | ||||
|         pages HTML | ||||
|     \item \emph{pg} : une librairie permettant la connexion à la base de données | ||||
| @ -216,7 +210,8 @@ Les \emph{packages} que nous utilisons sont les suivants : | ||||
| \subsection{Modèle, vue, contrôleur} | ||||
| Pour ce projet, nous avons adopté une version simplifiée du design-pattern | ||||
| \emph{modèle-vue-controleur} : en JavaScript, nos modèles seront des objets | ||||
| simples, et le modèle sera limité à l'exécution des requêtes SQL. | ||||
| simples (en JavaScript, un objet n'est qu'une liste de paire | ||||
| \emph{clé-valeur}), et le modèle sera limité à l'exécution des requêtes SQL. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Les contrôleurs sont chargés au démarrage par le fichier | ||||
| @ -239,6 +234,7 @@ La même technique à été appliquée pour le dossier \texttt{posts} et le fich | ||||
| requêtes POST et non pas des requêtes GET : elles servent principalement à | ||||
| stocker des informations dans la base de donneés. | ||||
| 
 | ||||
| \newpage | ||||
| \section{Code client} | ||||
| Le code client est séparé en trois parties : | ||||
| \begin{itemize} | ||||
| @ -251,7 +247,7 @@ Le code client est séparé en trois parties : | ||||
| \end{itemize} | ||||
| 
 | ||||
| Le \texttt{Makefile} présent dans le dossier \texttt{js} est celui qui | ||||
| concatènera nos sources, les minifieras et génèrera les scripts que nous | ||||
| concatènera nos sources, les \emph{minifieras} et génèrera les scripts que nous | ||||
| utiliserons par la suite. | ||||
| 
 | ||||
| \paragraph{} | ||||
| @ -292,34 +288,6 @@ Les applications sont principalement composées de programmes principaux, qui | ||||
| utilisent les classes de L3D, ainsi, elles ne sont pas fusionnées avec L3D, et | ||||
| laissées dans le namespace global. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Ces premières applications sont des applications de test pour se familiariser | ||||
| avec les technologies. | ||||
| 
 | ||||
| \subsubsection{Bouncing Cube} | ||||
| Ceci est une première application de test de la libraire graphique. C'est une | ||||
| des premières applications qui été faite, et elle m'a surtout servi à m'initier | ||||
| avec la technologie, et notamment avec les clics sur les objets. C'est un | ||||
| simple cube, qui rebondit sur le sol et finit par s'arrêter. En cliquant sur le | ||||
| cube, il saute à nouveau. | ||||
| 
 | ||||
| \subsubsection{Multisphere} | ||||
| Ceci est une des premières applications faites : elle m'a permi de tester | ||||
| l'affichage et le masquage des objets dans la librairie graphique. L'objectif | ||||
| était de raffiner le maillage au fur et à mesure en utilisant des modèles | ||||
| diffférents (plusieurs modèles sont chargés et on passe de l'un à l'autre en | ||||
| cliquant sur l'interface). | ||||
| 
 | ||||
| \subsubsection{Stream-demo} | ||||
| Ceci est la première application que j'ai développée et qui utilise les sockets | ||||
| : c'est une version simplifiée du \texttt{ProgressiveLoader} que l'on détaillera | ||||
| dans la section \ref{streaming}. | ||||
| 
 | ||||
| \newpage | ||||
| \paragraph{} | ||||
| Les prochaines sous-sections détaillent les applications qui ont été | ||||
| développées pour le projet. | ||||
| 
 | ||||
| \subsubsection{Interactive} | ||||
| Ceci est l'interface principale, où l'utilisateur doit rechercher les pièces. | ||||
| Nous en parlerons plus dans la section \ref{interface}. | ||||
|  | ||||
| @ -38,18 +38,35 @@ mais je me dois aussi de remercier \\ | ||||
| 
 | ||||
| \newpage | ||||
| \part*{Conclusion} | ||||
| Peu avant ce stage, nous avons eu le projet long qui nous a permi | ||||
| 
 | ||||
| \paragraph{} | ||||
| En conclusion, pendant ce stage, nous avons tenté de développé une interface | ||||
| permettant à des utilisateurs non-expérimentés de parcourir des scènes 3D. Ce | ||||
| système peut s'ouvrir sur d'autres problématiques : nous pourrions par exemple | ||||
| utiliser ce genre de recommandation 3D sur des systèmes qui représentent des | ||||
| scènes grâce à des images 2D (comme Google Maps par exemple). | ||||
| 
 | ||||
| \paragraph{} | ||||
| Une autre optique qui pourrait être utile à la suite de ce projet est de | ||||
| générer les recommandations automatiquement à partir d'interactions | ||||
| d'utilisateurs. On pourrait penser à un algorithme qui détecte les zones que | ||||
| les utilisateurs aiment regarder, et placer une recommandation à cet endroit | ||||
| pour les futurs utilisateurs. | ||||
| 
 | ||||
| \paragraph{} | ||||
| \paragraph{} | ||||
| Peu avant ce stage, nous avons eu le projet long qui nous a permis | ||||
| d'expérimenter les projets d'envergure en groupe, et la façon dont on devait | ||||
| les gérer. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Ce stage, pendant lequel j'ai développé le programme (\emph{plus ou moins}) | ||||
| seul m'a permi de compléter les expériences que j'avais eu lors du projet long. | ||||
| En effet, la plupart des projets étudiants à l'ENSEEIHT sont de très petite | ||||
| taille (si l'on devait passer 35h par semaine sur ces projets, je crois qu'il | ||||
| n'y en aurait pas un qui durerait plus de trois jours), et on ne se rend en | ||||
| fait pas compte que certaines des techniques de gestion de projet que nous | ||||
| avons du mettre en application pendant le projet long sont tout aussi | ||||
| seul m'a permis de compléter les expériences que j'avais eu lors du projet | ||||
| long.  En effet, la plupart des projets étudiants à l'ENSEEIHT sont de très | ||||
| petite taille (si l'on devait passer 35h par semaine sur ces projets, je crois | ||||
| qu'il n'y en aurait pas un qui durerait plus de trois jours), et on ne se rend | ||||
| en fait pas compte que certaines des techniques de gestion de projet que nous | ||||
| avons dû mettre en application pendant le projet long sont tout aussi | ||||
| importantes dans le cas d'un projet seul. | ||||
| 
 | ||||
| \paragraph{} | ||||
| @ -62,8 +79,8 @@ impossible de maîtriser parfaitement le code d'un bout à l'autre, et que c'est | ||||
| là que les commentaires prennent tout leur sens. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Ce projet a été très agréable pour moi, puisqu'il m'a permi de me consacrer à | ||||
| temps plein, et pendant une longue durée, sur un programme qui part de zéro. | ||||
| Ce projet a été très agréable pour moi, puisqu'il m'a permis de me consacrer à | ||||
| temps plein, et pendant une longue durée, à un programme qui part de zéro. | ||||
| Lors d'un projet en groupe, ou d'un sous-projet qui permet de constituer une | ||||
| brique d'un plus gros bâtiment, on peut ressentir la fierté d'avoir participé à | ||||
| un si grand projet, mais il y a aussi cette sensation qu'au final, l'impact que | ||||
|  | ||||
							
								
								
									
										52
									
								
								rapport/gestion.tex
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										52
									
								
								rapport/gestion.tex
									
									
									
									
									
										Normal file
									
								
							| @ -0,0 +1,52 @@ | ||||
| \part{Gestion de projet} | ||||
| 
 | ||||
| \section{Début du stage} | ||||
| \paragraph{} | ||||
| Encadré par Vincent Charvillat et Géraldine Morin, ce stage a commencé par une | ||||
| phase de découverte du sujet qui n'était pas clairement fixé : l'idée | ||||
| d'utiliser des recommandations pour influencer l'utilisateur afin d'être | ||||
| capable de prévoir ses interactions et de s'en servir pour réduire la latence | ||||
| était clairement présente, mais l'interface n'était pas encore fixée. Il y | ||||
| avait en fait deux options : la vidéo, ou la 3D. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Le stage a donc commencé par une phase bibliographique afin de voir ce qui | ||||
| existait en termes de recommandations, préchargement, et d'interface | ||||
| utilisateur de manière générale. Au même moment, Vincent \textsc{Charvillat} et | ||||
| Axel \textsc{Carlier} étaient à Singapour, en train de finaliser un article, et | ||||
| j'ai pu leur apporter une petite aide : | ||||
| \begin{itemize} | ||||
|     \item dans un premier temps, j'ai établi des profils de bande-passante lors | ||||
|         de téléchargements. Pour ce faire, j'ai utilisé le programme | ||||
|         \texttt{curl} qui affiche la vitesse instantanée de téléchargement | ||||
|         chaque seconde | ||||
|     \item dans un second temps, j'ai pu nettoyer une partie d'un code PHP | ||||
|         servant à remplir les lignes d'une table d'une base de données. Le code | ||||
|         était alors sensible à l'injection SQL. | ||||
| \end{itemize} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Au bout de quelques semaines, j'ai décidé de faire le choix de la 3D et j'ai | ||||
| commencé à découvrir les multiples façons de faire des interfaces 3D via HTML | ||||
| et JavaScript. | ||||
| 
 | ||||
| \subsection{Communication} | ||||
| Les communications inter-IRIT se faisaient principalement par mail. Lorsqu'il y | ||||
| avait plus de choses à dire, mais que cela ne nécessitait pas une réunion, les | ||||
| encadrants venaient me voir dans mon bureau pour discuter, notamment quand il y | ||||
| avait des nouveautés à faire ou faites dans le programme. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Des réunions étaient organisées lorsqu'elles étaient nécessaires, soit environ | ||||
| toutes les deux semaines. Ces réunions étaient souvent faites via | ||||
| vidéo-conférence, en présence de Wei Tsang, et je m'occupais de faire les | ||||
| compte-rendus par mail. | ||||
| 
 | ||||
| \subsection{Tests} | ||||
| Le site a été déployé à l'adresse \url{http://3dinterface.no-ip.org/}. Les | ||||
| différentes choses à faire tester aux encadrants se sont retrouvées sur des | ||||
| pages à cette adresse. | ||||
| 
 | ||||
| \newpage | ||||
| \section{Planning} | ||||
| % TODO | ||||
							
								
								
									
										
											BIN
										
									
								
								rapport/img/icons/vortex.png
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										
											BIN
										
									
								
								rapport/img/icons/vortex.png
									
									
									
									
									
										Normal file
									
								
							
										
											Binary file not shown.
										
									
								
							| After Width: | Height: | Size: 26 KiB | 
							
								
								
									
										
											BIN
										
									
								
								rapport/img/new/youtube.png
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										
											BIN
										
									
								
								rapport/img/new/youtube.png
									
									
									
									
									
										Normal file
									
								
							
										
											Binary file not shown.
										
									
								
							| After Width: | Height: | Size: 383 KiB | 
| @ -2,14 +2,14 @@ | ||||
| \section{Interactions élémentaires} | ||||
| \paragraph{} | ||||
| La première interface a été pensée pour être la plus simple possible. | ||||
| L'utilisateur contrôle une caméra qui se déplace librement dans un modèle 3D. | ||||
| Elle a été pensée comme un système de coordonnées sphériques dont on peut | ||||
| modifier les paramètres : | ||||
| L'utilisateur contrôle une caméra qui se déplace librement dans une scène 3D. | ||||
| Elle est contrôlée par un ensemble de paramètres décrit dans la figure | ||||
| \ref{spheric}. | ||||
| 
 | ||||
| \begin{figure}[H] | ||||
|     \centering | ||||
|     \includegraphics[scale=0.5]{img/wiki/spheric.png} | ||||
|     \caption{Les paramètres du contrôleur. \protect\footnotemark} | ||||
|     \caption{Les paramètres du contrôleur. \label{spheric}\protect\footnotemark} | ||||
| \end{figure} | ||||
| 
 | ||||
| \footnotetext{Contenu soumis à la licence CC-BY-SA 3.0 (\url{http://creativecommons.org/licenses/by-sa/3.0/deed.fr}) Source : Article Coordonnées sphériques de Wikipédia en français (\url{http://fr.wikipedia.org/wiki/Coordonn\%C3\%A9es\_sph\%C3\%A9riques}).} | ||||
| @ -17,7 +17,11 @@ modifier les paramètres : | ||||
| \paragraph{} | ||||
| La translation de la caméra est contrôlée par le clavier : les touches Z, Q, S, | ||||
| et D servent respectivement à avancer, aller à gauche, reculer et aller à | ||||
| droite (de même que les touches fléchées). | ||||
| droite (de même que les touches fléchées). Concrètement, \emph{avancer} revient | ||||
| à translater l'origine de la caméra $O$ suivant le vecteur | ||||
| $\overrightarrow{OP}$, et \emph{aller à gauche} correspond à translater $O$ | ||||
| suivant le vecteur $\vec{z}\wedge\overrightarrow{OP}$, c'est à dire la normale | ||||
| du plan $(OPz)$. | ||||
| 
 | ||||
| \paragraph{} | ||||
| On peut pivoter la caméra de plusieurs manières : | ||||
| @ -27,12 +31,13 @@ On peut pivoter la caméra de plusieurs manières : | ||||
|     \item via la souris, comme \emph{drag-n-drop}, en cliquant un point de la | ||||
|         scène et en le déplaçant (le mouvement de la caméra sera alors opposé | ||||
|         au mouvement de la souris) | ||||
|     \item via la souris, en mode \emph{pointer-lock}, comme dans un jeu video | ||||
|     \item via la souris, en mode \emph{pointer-lock}, comme dans un jeu vidéo | ||||
|         de tir | ||||
| \end{itemize} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Par exemple, on peut tourner vers a gauche (c'est-à-dire diminuer $\theta$) en : | ||||
| Par exemple, on peut tourner vers la gauche (c'est-à-dire diminuer $\theta$) en | ||||
| : | ||||
| \begin{itemize} | ||||
|     \item cliquant un point et en le déplaçant vers la droite (en mode | ||||
|         \emph{drag-n-drop}) | ||||
| @ -80,6 +85,12 @@ son centre en fonction des interactions. | ||||
|     \caption{Les différentes rotations possibles} | ||||
| \end{figure} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Ces techniques de navigation 3D restent quand même complexes à utiliser, | ||||
| surtout pour quelqu'un qui n'est pas habitué à jouer aux jeux vidéos. Nous | ||||
| allons donc ensuite voir comment nous pouvons essayer de faciliter | ||||
| la navigation pour des utilisateurs non-initiés. | ||||
| 
 | ||||
| \newpage | ||||
| \section{Les recommandations} | ||||
| \paragraph{} | ||||
| @ -88,6 +99,7 @@ Elles permettent d'aider la navigation. Elles sont affichées sous forme | ||||
| d'objets 3D ajoutés à la scène. Deux affichages ont été testés. | ||||
| 
 | ||||
| 
 | ||||
| 
 | ||||
| \subsection{Les \emph{viewports}} | ||||
| \paragraph{} | ||||
| Les \emph{viewports} sont les affichages les plus simples : ils représentent | ||||
| @ -102,6 +114,7 @@ beaucoup masquer le reste des modèles et suggère assez bien l'idée d'un | ||||
| \emph{point de vue recommandé}, mais elle a l'inconvénient d'être ambiguë à | ||||
| cause de la perspective (dans cette image, il peut être difficile de savoir si | ||||
| le point de vue et vers le modèle ou vers nous). | ||||
| % TODO pas clair pou non spécialiste en vision | ||||
| 
 | ||||
| 
 | ||||
| \subsection{Les flèches} | ||||
| @ -144,7 +157,8 @@ ligne sur l'écran. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Pour solutionner le premier problème, nous nous contenterons d'afficher | ||||
| seulement la flèche pour des instants $t \in [0.5, 1]$. | ||||
| seulement la flèche pour des instants $t \in [0.5, 1]$ (c'est-à-dire qu'on | ||||
| n'affichera que la moitié de la flèche la plus lointaine de la caméra). | ||||
| 
 | ||||
| \paragraph{} | ||||
| Pour solutionner le deuxième problème, nous allons translater le centre de la | ||||
| @ -159,17 +173,26 @@ $$\left\{\begin{array}{lcl} | ||||
| 
 | ||||
| \subsection{Les interactions} | ||||
| \subsubsection{Au survol} | ||||
| \indent Cette fonctionnalité est inspirée des récents lecteurs video sur le | ||||
| web.  Lorsque l'on regarde une video, on a la barre de \emph{seeking} en bas et | ||||
| \indent Cette fonctionnalité est inspirée des récents lecteurs vidéo sur le | ||||
| web.  Lorsque l'on regarde une vidéo, on a la barre de \emph{seeking} en bas et | ||||
| passer le curseur sur cette barre affiche l'image de la vidéo à l'instant visé. | ||||
| Nous avons simplement adapté cette techniques à nos recommandations : lorsque | ||||
| le curseur survole une recommandation, une prévisualisation est affichée dans | ||||
| une petite boîte au voisinage du curseur. | ||||
| Nous avons simplement adapté cette technique à nos recommandations : lorsque le | ||||
| curseur survole une recommandation, une prévisualisation est affichée dans un | ||||
| petit rectangle au voisinage du curseur. | ||||
| 
 | ||||
| \begin{figure}[H] | ||||
|     \centering | ||||
|     \includegraphics[scale=0.275]{img/new/03.png} | ||||
|     \caption{Une prévisualisation} | ||||
|     \begin{subfigure}[b]{0.45\textwidth} | ||||
|         \centering | ||||
|         \includegraphics[scale=0.2]{img/new/youtube.png} | ||||
|         \caption{Une prévisualisation sur Youtube} | ||||
|     \end{subfigure} | ||||
|     ~ | ||||
|     \begin{subfigure}[b]{0.45\textwidth} | ||||
|         \centering | ||||
|         \includegraphics[scale=0.16]{img/new/03.png} | ||||
|         \caption{Une prévisualisation dans notre système} | ||||
|     \end{subfigure} | ||||
| \end{figure} | ||||
| 
 | ||||
| \subsubsection{Au clic} | ||||
| @ -184,7 +207,7 @@ polynôme interpolant tel que : | ||||
| \end{itemize} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Ce mouvement fluide est là pour ne pas perturber l'utilisateur qui pourrait | ||||
| Ce mouvement fluide est là pour ne pas dérouter l'utilisateur qui pourrait | ||||
| \emph{se perdre} si jamais il était téléporté. | ||||
| 
 | ||||
| \paragraph{} | ||||
|  | ||||
| @ -1,9 +1,8 @@ | ||||
| \part*{Introduction} | ||||
| Ce stage de fin d'études s'est déroulé dans le laboratoire de recherche de | ||||
| l'IRIT, dans l'équipe Vortex. | ||||
| l'IRIT, dans l'équipe VORTEX. | ||||
| 
 | ||||
| \paragraph{} | ||||
| % TODO Pas clair | ||||
| Ce stage a commencé en F215, salle dans laquelle il y avait Thierry | ||||
| \textsc{Malon}, un de mes collègues de projet long qui travaillait sur le | ||||
| projet Popart avec Simone \textsc{Gasparini}, et Bastien \textsc{Durix}, qui | ||||
| @ -18,56 +17,3 @@ disponible dans la salle F215, sa migration était inévitable. Par solidarité | ||||
| \emph{stagiariale}, Thierry et moi avons donc migré vers la salle F207, où nous | ||||
| avons passé le reste de notre stage. | ||||
| 
 | ||||
| \section*{Début du stage} | ||||
| \paragraph{} | ||||
| Encadré par Vincent Charvillat et Géraldine Morin, ce stage a commencé par une | ||||
| phase de découverte du sujet qui n'était pas clairement fixée : l'idée | ||||
| d'utiliser des recommandations pour influencer l'utilisateur afin d'être | ||||
| capable de prévoir ses interactions et de s'en servir pour réduire la latence | ||||
| était clairement présente, mais l'interface n'était pas encore fixée. Il y | ||||
| avait en fait deux options : la vidéo, ou la 3D. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Le stage a donc commencé par une phase bibliographique afin de voir ce qui | ||||
| existait en termes de recommandations, préchargement, et d'interface | ||||
| utilisateur de manière générale. Au même moment, Vincent \textsc{Charvillat} et | ||||
| Axel \textsc{Carlier} étaient à Singapour, en train de finaliser un article, et | ||||
| j'ai pu leur apporter une petite aide : | ||||
| \begin{itemize} | ||||
|     \item dans un premier temps, j'ai établi des profils de bande-passante lors | ||||
|         de téléchargements. Pour ce faire, j'ai utilisé le programme | ||||
|         \texttt{curl} qui affiche la vitesse instantanée de téléchargement | ||||
|         chaque seconde | ||||
|     \item dans un second temps, j'ai pu nettoyer une partie d'un code PHP | ||||
|         servant à remplir les lignes d'une table d'une base de données. Le code | ||||
|         était alors sensible à l'injection SQL. | ||||
| \end{itemize} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Au bout de quelques semaines, j'ai décidé de faire le choix de la 3D et j'ai | ||||
| commencé à découvrir les multiples façons de faire des interfaces 3D via HTML | ||||
| et JavaScript. | ||||
| 
 | ||||
| \newpage | ||||
| \part{Organisation} | ||||
| 
 | ||||
| \section{Encadrants} | ||||
| Ce stage a été encadré par Vincent \textsc{Charvillat}, Géraldine | ||||
| \textsc{Morin}, et Axel \textsc{Carlier} de l'IRIT, et nous avons eu le soutien | ||||
| de Wei Tsang \textsc{Ooi}, professeur de la NUS à Singapour. | ||||
| 
 | ||||
| \section{Communication} | ||||
| Les communications inter-IRIT se faisaient principalement par mail. Lorsqu'il y | ||||
| avait plus de choses à dire, mais que cela ne nécessitait pas une réunion, les | ||||
| encadrants venaient me voir dans mon bureau pour discuter, notamment quand il y | ||||
| avait des nouveautés à faire ou faites dans le programme. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Des réunions étaient organisées lorsqu'elles étaient nécessaires, soit environ | ||||
| toutes les deux semaines. Ces réunions étaient souvent faites via Skype ou | ||||
| Hangouts, en présence de Wei Tsang. | ||||
| 
 | ||||
| \section{Tests} | ||||
| Le site a été déployé à l'adresse \url{http://3dinterface.no-ip.org/}. Les | ||||
| différentes choses à faire tester aux encadrants se sont retrouvées sur des | ||||
| pages à cette adresse. | ||||
|  | ||||
| @ -54,6 +54,8 @@ anchorcolor = blue]{hyperref} | ||||
| \newcommand{\socketio}{\href{http://socket.io/}{Socket.IO}} | ||||
| \newcommand{\jsdoc}{\href{http://usejsdoc.org/}{JSDoc}} | ||||
| \newcommand{\closurecompiler}{\href{https://developers.google.com/closure/compiler/}{Closure-Compiler}} | ||||
| \newcommand{\minko}{\href{https://github.com/aerys/minko/}{Minko}} | ||||
| 
 | ||||
| \renewcommand{\include}[1]{\import{./}{#1.tex}} | ||||
| 
 | ||||
| \newcommand{\namedparagraph}[1]{\paragraph{#1}\mbox{}\\} | ||||
| @ -75,17 +77,18 @@ anchorcolor = blue]{hyperref} | ||||
|     \begin{sffamily} | ||||
|         \begin{center} | ||||
|             ~\\[0cm] | ||||
|             \LARGE R\hsc{apport de Stage de 3A}\\[3cm] | ||||
|             \LARGE R\hsc{apport de Stage de 3A}\\[2.5cm] | ||||
| 
 | ||||
|             % Title | ||||
|             \HRule \\[0.4cm] | ||||
|             { \huge \bfseries Prédiction du comportement des utilisateurs d'une | ||||
|             application interactive en 3D \\[0.4cm] } | ||||
| 
 | ||||
|             \HRule \\[3cm] | ||||
|             \HRule \\[2.5cm] | ||||
| 
 | ||||
|             \includegraphics[scale=0.5]{img/icons/n7.png}~\\[1cm] | ||||
|             \includegraphics[scale=0.4]{img/icons/IRIT.jpg}~\\[3cm] | ||||
|             \includegraphics[scale=0.4]{img/icons/IRIT.jpg}~\\[0.4cm] | ||||
|             \includegraphics[scale=0.4]{img/icons/vortex.png}~\\[3cm] | ||||
| 
 | ||||
| 
 | ||||
|             % Author and supervisor | ||||
| @ -116,10 +119,15 @@ anchorcolor = blue]{hyperref} | ||||
| \tableofcontents | ||||
| \newpage | ||||
| 
 | ||||
| 
 | ||||
| \include{intro} | ||||
| \newpage | ||||
| 
 | ||||
| \include{presentation} | ||||
| \newpage | ||||
| 
 | ||||
| \include{gestion} | ||||
| \newpage | ||||
| 
 | ||||
| \include{techno} | ||||
| \newpage | ||||
| 
 | ||||
|  | ||||
							
								
								
									
										1
									
								
								rapport/presentation.tex
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										1
									
								
								rapport/presentation.tex
									
									
									
									
									
										Normal file
									
								
							| @ -0,0 +1 @@ | ||||
| \part{Présentation du projet, contexte et objectifs} | ||||
| @ -16,11 +16,42 @@ Pour le côté client, il y avait plusieurs possibilités : | ||||
|     \item N'importe quel moteur graphique qui puisse exporter vers JavaScript | ||||
| \end{itemize} | ||||
| 
 | ||||
| \subsection{WebGL} | ||||
| WebGL est basé sur OpenGL ES (\emph{Open Graphic Library for Embedded Device}). | ||||
| Cela signifie que de nombreuses fonctions présentes dans OpenGL rendant son | ||||
| utilisation plus simple ne sont pas disponibles dans OpenGL ES pour des raisons | ||||
| de performance. L'utilisation de WebGL devient donc assez complexe, et le | ||||
| simple dessin d'un cube tournant avec une lumière et une caméra devient très | ||||
| complexe. | ||||
| 
 | ||||
| \subsection{C++ vers JavaScript} | ||||
| Le code compilé de C++ et transformé en JavaScript avec Emscripten à ses | ||||
| inconvénients : comme WebGL ne supporte que OpenGL ES, il faut régider le code | ||||
| en utilisant OpenGL ES en C++\footnote{En fait, certaines fonctions de OpenGL | ||||
| fonctionnent avec Emscripten : ce sont elles qui sont équivalentes en OpenGL et | ||||
| en WebGL}, et les contraintes de la sous-section précédentes sont toujours | ||||
| présentes. | ||||
| 
 | ||||
| \paragraph{} | ||||
| La plupart des moteurs graphiques exportant vers JavaScript sont putôt lourd à | ||||
| prendre en main, et nous voulions garder des solutions simples, c'est pourquoi | ||||
| nous avons utilisé une librairie libre nommée \threejs{} permettant une | ||||
| utilisation facile de WebGL. | ||||
| Un des inconvénients de passer par du C++ est que le binaire produit à la | ||||
| sortie sera relativement lourd (l'objectif du C++ est de faire le plus de | ||||
| calcul possible à la compilation, et les résultats de ces calculs seront donc | ||||
| inscrits dans le binaire) et le temps de chargement par le navigateur sera | ||||
| long. | ||||
| 
 | ||||
| \subsection{Moteur graphique} | ||||
| Pour les moteurs graphiques, il y a de nombreux choix possibles. J'ai plutôt | ||||
| cherché des moteurs libres, et Vincent \textsc{Charvillat} m'a parlé de \minko{}. | ||||
| C'est un moteur graphique qui utilise Emscripten pour exporter vers JavaScript. | ||||
| Son inconvénient est qu'il est assez lourd, long à prendre en main, et le | ||||
| programme JavaScript sera lui aussi lourd puisqu'il contiendra à la fois notre | ||||
| code et la librairie \minko{} compilée vers JavaScript. Les temps de chargement | ||||
| étant trop grand, nous nous sommes tournés vers la dernière option. | ||||
| 
 | ||||
| \subsection{Three.js} | ||||
| \threejs{} est une librairie écrite en JavaScript qui utilise les fonctions de | ||||
| WebGL dans des classes qui permettent une utilisation plus simple de WebGL, | ||||
| tout en gardant sa puissance. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Pour des raisons de simplicité, nous avons décidé de développer le code client | ||||
| @ -35,13 +66,13 @@ problématiques de dynamicité sont arrivées, il a fallu choisir une technologi | ||||
| pour le côté serveur, et là, tous les langages étaient possibles. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Plusieurs langages et framework ont été téstés. Quand les problématiques | ||||
| étaient encore simples (passage d'un paramètre dans une requête), on a commencé | ||||
| par utiliser le php, puis on s'est tourné vers des scripts CGI en python. Quand | ||||
| de plus nombreuses pages ont été nécessaires, on a commencé à chercher un vrai | ||||
| framework, et on s'est penché sur Django (framework web pour Python) qui est | ||||
| très pratique mais assez coûteux en mémoire vive (le serveur était alors | ||||
| herbergé sur une petite machine de 512Mo de RAM). | ||||
| Plusieurs langages et framework ont été testée. Quand les problématiques | ||||
| étaient encore simples (passage d'un paramètre dans une requête), j'ai commencé | ||||
| par utiliser le php, puis je me suis tourné vers des scripts CGI en python. | ||||
| Quand de plus nombreuses pages ont été nécessaires, j'ai commencé à chercher un | ||||
| vrai framework, et je me suis penché sur Django (framework web pour Python) qui | ||||
| est très pratique mais assez coûteux en mémoire vive (le serveur était alors | ||||
| hébergé sur une petite machine de 512Mo de RAM). | ||||
| 
 | ||||
| \paragraph{} | ||||
| Quand les problématiques de streaming ont commencé à apparaître, nous avons | ||||
| @ -86,7 +117,7 @@ deux \emph{repositories} : | ||||
|         outils permettant la génération des fichiers fusionnés. | ||||
|     \item le deuxième, hebergé chez OpenShift, qui contient la version finale | ||||
|         du programme, permet de déployer le code du serveur quand les | ||||
|         \emph{commits} sont \emph{pushés}. | ||||
|         modifications sont propagés jusqu'à celui-ci. | ||||
| \end{itemize} | ||||
| 
 | ||||
| \paragraph{} | ||||
| @ -94,8 +125,9 @@ Pour nous aider au debug, nous avons utilisé \href{http://jshint.com/}{JSHint} | ||||
| qui nous aide à détecter les erreurs potentielles liées aux subtilités du | ||||
| langage. | ||||
| 
 | ||||
| \newpage | ||||
| \section{Documentation} | ||||
| Au delà des rapports, deux documentations sont présentes. | ||||
| En plus des rapports, deux documentations sont présentes. | ||||
| 
 | ||||
| \subsection{\href{https://github.com/tforgione/3dinterface/wiki}{\emph{Github Wiki}}} | ||||
| Github permet la création de Wiki pour chaque \emph{repository} et nous nous en | ||||
| @ -108,4 +140,26 @@ fonctionne) nous avons utilisé \jsdoc{} (équivalent de javadoc mais pour | ||||
| JavaScript) et nous générons automatiquement des pages html pour avoir une | ||||
| documentation lisible et à jour sans avoir à parcourir le code. | ||||
| 
 | ||||
| \section{Familiarisation} | ||||
| Pour me familiariser avec les technologies et librairies, j'ai développé | ||||
| quelques applications simples. | ||||
| 
 | ||||
| \subsection{Bouncing Cube} | ||||
| Ceci est une première application de test de la librairie graphique. C'est une | ||||
| des premières applications qui a été faite, et elle m'a surtout servi à | ||||
| me familiariser avec la technologie, et notamment avec les clics sur les | ||||
| objets.  C'est un simple cube, qui rebondit sur le sol et finit par s'arrêter. | ||||
| En cliquant sur le cube, il saute à nouveau. | ||||
| 
 | ||||
| \subsection{Multisphere} | ||||
| Ceci est une des premières applications faites : elle m'a permi de tester | ||||
| l'affichage et le masquage des objets dans la librairie graphique. L'objectif | ||||
| était de raffiner le maillage au fur et à mesure en utilisant des modèles | ||||
| diffférents (plusieurs modèles sont chargés et on passe de l'un à l'autre en | ||||
| cliquant sur l'interface). | ||||
| 
 | ||||
| \subsection{Stream-demo} | ||||
| Ceci est la première application que j'ai développée et qui utilise les sockets | ||||
| : c'est une version simplifiée du \texttt{ProgressiveLoader} que l'on détaillera | ||||
| dans la section \ref{streaming}. | ||||
| 
 | ||||
|  | ||||
| @ -1,8 +1,16 @@ | ||||
| \part{L'étude utilisateur} | ||||
| \paragraph{} | ||||
| Pour tester le comportement des utilisateurs face aux recommandations, nous | ||||
| avons dissimulé des pièces rouges à travers ces modèles, et nous avons demandé | ||||
| à des utilisateurs de les trouver. | ||||
| Pour tester le comportement des utilisateurs face aux recommandations, nous ne | ||||
| pouvons pas nous contenter de lancer des utilisateurs dans cette interface et | ||||
| de voir ce qu'ils font puisque n'ayant rien à faire, ils ne vont rien faire, | ||||
| ils vont simplement se promener mais on n'aura aucun moyen de vérifier que les | ||||
| recommandations les ont aidés. | ||||
| 
 | ||||
| \paragraph{} | ||||
| Pour palier à ce problème, nous avons ajouter des \emph{pièces} à chercher dans | ||||
| la scène. L'objectif est basé sur l'hypothèse que si un utilisateur a ramassé | ||||
| toutes les pièces rouges, il aura parcouru l'intégralité de la scène. | ||||
| 
 | ||||
| \begin{figure}[H] | ||||
|     \centering | ||||
|     \includegraphics[scale=0.275]{img/new/04.png} | ||||
| @ -10,7 +18,7 @@ avons dissimulé des pièces rouges à travers ces modèles, et nous avons deman | ||||
| \end{figure} | ||||
| 
 | ||||
| \paragraph{} | ||||
| Pour éviter la dépendance entre les recomendations et les pièces rouges (si les | ||||
| Pour éviter la dépendance entre les recommandations et les pièces rouges (si les | ||||
| recommandations visent les pièces rouges, il est évident qu'il sera très facile | ||||
| de les trouver avec les recommandations), un système de tirage aléatoire de | ||||
| pièces rouges a été fait. | ||||
| @ -23,10 +31,10 @@ pour passer à la suite, sinon, un message d'erreur s'affichera. | ||||
| 
 | ||||
| \subsection{Identification} | ||||
| Cette page nous permet d'en savoir un peu plus sur l'utilisateur : nous allons | ||||
| demander l'age, le sexe et les habitudes en terme de jeux video de | ||||
| demander l'age, le sexe et les habitudes en terme de jeux vidéo de | ||||
| l'utilisateur (nous avons considéré que la capacité des utilisateurs à manier | ||||
| notre interface allait dépendre fortement de leur habitude aux jeux video). | ||||
| Nous leur demandons notamment de noter leurs capacités en terme de jeux videos | ||||
| notre interface allait dépendre fortement de leur habitude aux jeux vidéo). | ||||
| Nous leur demandons notamment de noter leurs capacités en terme de jeux vidéos | ||||
| (entre 1 et 5 étoiles). | ||||
| 
 | ||||
| \subsection{Tutoriel} | ||||
| @ -151,4 +159,7 @@ fait, nous accordons peu d'importance aux touches appuyées, mais plutôt aux | ||||
| positions de la caméra au moment de ces évènements. Nous interpolons entre les | ||||
| \texttt{KeyboardEvent}, le \texttt{ResetClicked} réinitialise la position de la | ||||
| caméra brutalement et les autres évènements utilisent les polynômes de Hermite | ||||
| comme pour le suivi des recommandations lors d'une expérience. | ||||
| comme pour le suivi des recommandations lors d'une expérience.a | ||||
| 
 | ||||
| \section{Analyse des résultats} | ||||
| % TODO analyser les résultats | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user