Change path for images (shared path between report and slides)

rapport/Makefile

@@ -11,12 +11,11 @@ build/main.pdf: main.tex FORCE
 	$(TEXC) -latexoption=-shell-escape $<
 
 compress: build/main.pdf
-	cp build/main.pdf build/main.tmp.pdf
-	# gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -sOutputFile=build/main.pdf build/main.tmp.pdf
-	rm build/main.tmp.pdf
+	gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -sOutputFile=build/main.min.pdf build/main.pdf
 
 push: compress
 	scp -P2222 build/main.pdf pi@dragonrock.no-ip.org:web/dragonrock/rapport.pdf
+	scp -P2222 build/main.min.pdf pi@dragonrock.no-ip.org:web/dragonrock/rapport.min.pdf
 
 clean: FORCE
 	$(TEXC) -c

rapport/architecture.tex

@@ -295,7 +295,7 @@ C'est l'interface qui crée une \texttt{ReplayCamera} et permet de visionner une
 expérience qui a été faite dans le passé.
 
 \subsubsection{Tutorial}
-C'est le didactitiel de l'application : il possède notamment une classe qui copie
+C'est le didacticiel de l'application : il possède notamment une classe qui copie
 la caméra principale tout en permettant de vérifier que les interactions sont
 faites comme il faut.
 

rapport/conclusion.tex

@@ -51,8 +51,8 @@ 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 (ce qui a déjà été fait, notamment par Nghiem,
-CrowMM'12).
+pour les futurs utilisateurs (ce qui a déjà été fait dans l'équipe, par Thi
+Phuong Nghiem en 2012).
 
 \paragraph{}
 \paragraph{}
@@ -96,4 +96,4 @@ flatteur pour l'ego.
 Ce projet n'est en fait pas encore fini : je vais être embauché par l'IRIT en
 tant qu'ingénieur de recherche pendant encore quelques mois, le temps de finir
 les parties qui ne sont pas encore tout à fait finies, avec pour but une
-éventuelle publication a MMSys, fin Novembre.
+éventuelle soumission à la conférence MMSys, fin Novembre.

rapport/interface.tex

@@ -8,7 +8,7 @@ dans la figure \ref{spheric}.
 
 \begin{figure}[H]
     \centering
-    \includegraphics[scale=0.5]{img/wiki/spheric.png}
+    \includegraphics[scale=0.5]{wiki/spheric.png}
     \caption{Les paramètres du contrôleur. \label{spheric}\protect\footnotemark}
 \end{figure}
 
@@ -55,31 +55,31 @@ son centre en fonction des interactions.
     \centering
     \begin{subfigure}[b]{0.3\textwidth}
         \centering
-        \includegraphics[scale=0.12]{img/wiki/04.png}
+        \includegraphics[scale=0.12]{wiki/04.png}
         \caption{Vers le haut ($\delta \nearrow$)}
     \end{subfigure}
     \\
     \begin{subfigure}[b]{0.3\textwidth}
         \centering
-        \includegraphics[scale=0.12]{img/wiki/03.png}
+        \includegraphics[scale=0.12]{wiki/03.png}
         \caption{Vers la gauche ($\theta \searrow$)}
     \end{subfigure}
     ~
     \begin{subfigure}[b]{0.3\textwidth}
         \centering
-        \includegraphics[scale=0.12]{img/wiki/01.png}
+        \includegraphics[scale=0.12]{wiki/01.png}
         \caption{Angle initial}
     \end{subfigure}
     ~
     \begin{subfigure}[b]{0.3\textwidth}
         \centering
-        \includegraphics[scale=0.12]{img/wiki/02.png}
+        \includegraphics[scale=0.12]{wiki/02.png}
         \caption{Vers la droite ($\theta \nearrow$)}
     \end{subfigure}
     \\
     \begin{subfigure}[b]{0.3\textwidth}
         \centering
-        \includegraphics[scale=0.12]{img/wiki/05.png}
+        \includegraphics[scale=0.12]{wiki/05.png}
         \caption{Vers le bas ($\delta $\searrow)}
     \end{subfigure}
 
@@ -107,7 +107,7 @@ Les \emph{viewports} sont les affichages les plus simples : ils représentent
 une caméra, avec son centre optique et son plan image.
 \begin{figure}[H]
     \centering
-    \includegraphics[scale=0.275]{img/new/01.png}
+    \includegraphics[scale=0.275]{new/01.png}
     \caption{Une recommandation \emph{viewport}}
 \end{figure}
 Cette façon d'afficher une recommandation a l'avantage d'être simple, de ne pas
@@ -125,7 +125,7 @@ l'habitude des \emph{viewports} précédemment utilisés. Plutôt que de suggér
 un point de vue, elles suggèrent le mouvemement qui va mener à ce point de vue.
 \begin{figure}[H]
     \centering
-    \includegraphics[scale=0.275]{img/new/02.png}
+    \includegraphics[scale=0.275]{new/02.png}
     \caption{Une recommandation flèche}
 \end{figure}
 
@@ -158,8 +158,8 @@ $$
 
 \paragraph{}
 Le problème de ce polynôme est qu'il ne vérifie aucune des contraintes énoncées
-précédemment : puisque $f(0) = C$, le bout de la flèche est dans la caméra, et
-va donc masquer toute la scène, et la courbe va en plus se projeter sur une
+précédemment : puisque $f(0) = C$, l'extrémité de la flèche est dans la caméra,
+et va donc masquer toute la scène, et la courbe va en plus se projeter sur une
 ligne sur l'écran.
 
 \paragraph{}
@@ -192,13 +192,13 @@ petit rectangle au voisinage du curseur.
     \centering
     \begin{subfigure}[b]{0.45\textwidth}
         \centering
-        \includegraphics[scale=0.2]{img/new/youtube.png}
+        \includegraphics[scale=0.2]{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}
+        \includegraphics[scale=0.16]{new/03.png}
         \caption{Une prévisualisation dans notre système}
     \end{subfigure}
 \end{figure}
@@ -233,7 +233,7 @@ présents.
 \begin{figure}[H]
     \centering
     \begin{tikzpicture}[]
-        \node (myfirstpic) at (0,0) {\includegraphics[scale=0.35]{img/new/buttons.png}};
+        \node (myfirstpic) at (0,0) {\includegraphics[scale=0.35]{new/buttons.png}};
         \tikzvline{-7}{1}
         \tikzvline{-5.8}{2}
         \tikzvline{-5.2}{3}

rapport/main.tex

@@ -73,11 +73,19 @@ anchorcolor = blue]{hyperref}
 \@addtoreset{section}{part}
 \makeatother
 
+\makeatletter
+\renewcommand{\p@section}{\thepart.} % prefix "\thepart." to the number of the chapter
+\renewcommand{\p@subsection}{\thepart.} % prefix "\thepart." to the number of the chapter
+\renewcommand{\p@subsubsection}{\thepart.} % prefix "\thepart." to the number of the chapter
+\makeatother
+
 \usetikzlibrary{trees}
 \usepackage{afterpage}
 
 \addtocontents{toc}{\protect\setcounter{tocdepth}{2}}
 
+\graphicspath{{../img/}}
+
 \begin{document}
 
 \begin{titlepage}
@@ -93,9 +101,9 @@ anchorcolor = blue]{hyperref}
 
             \HRule \\[2.5cm]
 
-            \includegraphics[scale=0.5]{img/icons/n7.png}~\\[1cm]
-            \includegraphics[scale=0.4]{img/icons/IRIT.jpg}~\\[0.4cm]
-            \includegraphics[scale=0.4]{img/icons/vortex.png}~\\[3cm]
+            \includegraphics[scale=0.5]{icons/n7.png}~\\[1cm]
+            \includegraphics[scale=0.4]{icons/IRIT.jpg}~\\[0.4cm]
+            \includegraphics[scale=0.4]{icons/vortex.png}~\\[3cm]
 
 
             % Author and supervisor
@@ -127,7 +135,6 @@ anchorcolor = blue]{hyperref}
 \newpage
 
 \include{intro}
-\newpage
 
 \include{presentation}
 \newpage

rapport/presentation.tex

@@ -18,6 +18,20 @@ précharger toute la vidéo linéairement, on peut donc précharger les zones
 intéressantes ce qui va réduire la latence lorsque l'utilisateur va sauter une
 partie pour aller vers une zone recommandée.
 
+\begin{figure}[H]
+    \centering
+    \begin{subfigure}[b]{0.4\linewidth}
+        \centering
+        \includegraphics[scale=0.2]{new/interface1.png}
+    \end{subfigure}
+    ~
+    \begin{subfigure}[b]{0.4\linewidth}
+        \centering
+        \includegraphics[scale=0.34]{new/interface2.png}
+    \end{subfigure}
+    \caption{Des interfaces sans et avec recommandations}
+\end{figure}
+
 \section{Objectifs}
 \paragraph{}
 Ce projet a pour but d'appliquer les idées citées précédemment dans le contexte
@@ -39,12 +53,12 @@ retrouve dans une zone de la scène qui n'est pas encore chargée.
 
 \paragraph{}
 Dans ce travail, on ne s'attachera pas à calculer des recommandations : elles
-seront supposées connues. Dans la pratique, elle seront définies mannuellement.
+seront supposées connues. Dans la pratique, elle seront définies manuellement.
 
 \section{Présentation}
 Nous allons dans un premier temps parler des technologies que nous avons
 testées et utilisées. Nous verrons ensuite l'architeture du programme, qui peut
-paraître un peu complexe. Dans la section \ref{interface}, nous présenterons
+paraître un peu complexe. Dans la partie \ref{interface}, nous présenterons
 l'interface que nous avons développée. Nous verrons comment nous avons testé
-cette interface dans la section \ref{userstudy}, et dans la section suivante,
+cette interface dans la partie \ref{userstudy}, et dans la partie suivante,
 nous verrons comment nous avons fait du streaming de modèle 3D.

rapport/streaming.tex

@@ -19,7 +19,7 @@ modèles sont stockés sur le serveur au format \texttt{.obj} et sont constitué
 \begin{itemize}
     \item des matériaux (\texttt{usemtl}) : cela définit le matériau utilisé
         pour les faces qui vont suivre. Un matériau est notamment défini par
-        ses constantes de reflexions optiques, ses textures, etc...
+        ses constantes de réflexions optiques, ses textures, etc...
     \item de sommets (\emph{vertices}) : des points 3D
     \item de coordonnées de textures : des points en 2D qui référencent un
         point d'une image

rapport/techno.tex

@@ -65,7 +65,8 @@ code et la librairie \minko{} compilée vers JavaScript. Les temps de chargement
 \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.
+tout en gardant sa puissance. Nous avons opté pour cette librairie pour
+développer notre interface.
 
 \paragraph{}
 Pour des raisons de simplicité, nous avons décidé de développer le code client
@@ -78,7 +79,7 @@ Dans un premier temps, seul le côté client était pris en compte. Les programm
 étaient écrits en JavaScript et ne nécessitaient pas de serveur. Quand les
 problématiques de dynamicité\footnote{On oppose les sites dynamiques (par
 exemple les réseaux sociaux) aux sites statiques (par exemple les blogs) : dans
-un site statique, l'utilisateur ne peut pas intéragir avec le site. Le site se
+un site statique, l'utilisateur ne peut pas interagir avec le site. Le site se
 contente de délivrer une information.} sont arrivées, il a fallu choisir une
 technologie pour le côté serveur, et là, tous les langages étaient possibles.
 
@@ -88,7 +89,7 @@ Plusieurs langages et framework ont été testée :
     \item le PHP : pratique pour des applications très petites, mais le langage
         est peu confortable dès que la taille du serveur grandit.
     \item les scripts CGI\footnote{Un script CGI est un programme dont
-        l'exécution imprime une page web (ou autre) sur la sortie standart.
+        l'exécution imprime une page web (ou autre) sur la sortie standard.
         Ils sont très simples à utiliser, puisqu'un simple \emph{Hello world}
         en C peut devenir un script CGI} (en python) : assez pratique pour des
         petites applications. Au final, cela ressemble un peu à du PHP mais
@@ -139,7 +140,7 @@ est détectée (la fusion des fichiers est donc réeffectuée).
 
 \paragraph{}
 En ce qui concerne le versionnage des fichiers, nous avons utilisé Git avec
-deux \emph{dépôts} :
+deux dépôts :
 \begin{itemize}
     \item le premier, hébergé sur
         \href{https://github.com/tforgione/3dinterface}{Github}, sert au
@@ -147,7 +148,7 @@ deux \emph{dépôts} :
         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
-        modifications sont propagéés jusqu'à celui-ci.
+        modifications sont propagées jusqu'à celui-ci.
 \end{itemize}
 
 \paragraph{}

rapport/userstudy.tex

@@ -2,8 +2,9 @@
 \paragraph{}
 Pour tester le comportement des utilisateurs face aux recommandations, nous ne
 pouvons pas nous contenter d'observer le comportement des utilisateurs
-puisqu'ils ne seront pas intéressé par la scène. Ils se contenteraient
-probablement de se promener un peu dans la scène puis partiraient.
+puisqu'ils ne sont pas nécessairement intéressé par nos scènes. Ils se
+contenteraient probablement de se promener un peu dans la scène puis
+partiraient.
 
 \paragraph{}
 Pour palier à ce problème, nous avons ajouté des \emph{pièces} à chercher dans
@@ -12,7 +13,7 @@ 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}
+    \includegraphics[scale=0.275]{new/04.png}
     \caption{Une pièce rouge}
 \end{figure}
 
@@ -21,8 +22,8 @@ Pour éviter de biaiser les utilisateurs, il est nécessaire d'éviter la
 dépendance entre les recommandations et les pièces. En effet, si les
 recommandations mènent toujours aux pièces, l'utilisateur va croire que les
 recommandations sont là pour trouver les pièces, alors qu'elles ne doivent être
-là que pour aider la navigation. Pour cela, nous avons fait un système de
-tirage aléatoire des pièces parmi plusieurs positions possibles (ceci sera
+là que pour aider la navigation. Pour cela, nous avons mis en place un système
+de tirage aléatoire des pièces parmi plusieurs positions possibles (ceci sera
 détaillé dans la section \ref{coins}).
 
 \section{Déroulement de l'expérience}
@@ -39,8 +40,8 @@ manier 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éo (entre 1 et 5 étoiles).
 
-\subsection{Didactitiel}
-Ensuite, nous demandons à l'utilisateur de suivre un didactitiel : c'est une
+\subsection{Didacticiel}
+Ensuite, nous demandons à l'utilisateur de suivre un didacticiel : c'est une
 expérience normale mais guidée. Des messages indiquant les interactions à faire
 aideront l'utilisateur à s'habituer à cette interface. On y présente les moyens
 de déplacer la caméra, puis les recommandations et les différents boutons de
@@ -77,7 +78,7 @@ Il y a trois scènes disponibles, et sur chaque scène, nous avons placé des
 pièces dans de nombreuses positions. Lorsqu'un utilisateur commence une
 expérience, l'algorithme de selection fonctionne de façon à faire des
 expériences sur les mêmes scènes avec les mêmes dispositions de pièces mais des
-styles de recommandations différents pour des utilisateurs de même niveau de
+styles de recommandations différents pour des utilisateurs de même niveau, de
 sorte à pouvoir comparer l'efficacité des recommandations.
 
 \paragraph{}
@@ -134,12 +135,12 @@ date à laquelle il a été envoyé par le client ainsi que l'id du client et de
 l'expérience qu'il est en train de faire (ces deux derniers sont stockés dans
 la session sur le serveur). Les évènements enregistrés sont les suivants :
 
-\paragraph{ArrowClicked} : crée quand l'utilisateur clique une recommandation,
+\paragraph{ArrowClicked} : créé quand l'utilisateur clique une recommandation,
 accompagné de l'id de la recommandation cliquée.
 
-\paragraph{CoinClicked} : crée quand l'utilisateur récupère une pièce rouge.
+\paragraph{CoinClicked} : créé quand l'utilisateur récupère une pièce rouge.
 
-\paragraph{KeyboardEvent} : crée quand l'utilisateur appuie ou relâche une
+\paragraph{KeyboardEvent} : créé quand l'utilisateur appuie ou relâche une
 touche du clavier, accompagné de la position courante de la caméra et d'un
 booléen indiquant si elle a été appuyée ou relâchée.  Dans le cas du
 \emph{drag-n-drop} ou du \emph{pointer lock}, aucun évènement (autre que les
@@ -149,24 +150,24 @@ l'orientation de la caméra, on n'aura aucune information. Pour palier à ce
 problème, nous enverrons régulièrement des \emph{KeyboardEvent} factices pour
 sauvegarder l'état de la caméra.
 
-\paragraph{ResetClicked} : crée quand l'utilisateur réinitialise la position de
+\paragraph{ResetClicked} : créé quand l'utilisateur réinitialise la position de
 la caméra.
 
-\paragraph{PreviousNextClicked} : crée quand l'utilisateur clique sur les
+\paragraph{PreviousNextClicked} : créé quand l'utilisateur clique sur les
 boutons précédente ou suivante, on stockera la position finale en base de
 données.
 
-\paragraph{Hovered} : crée quand l'utilisateur survole ou sort d'une
+\paragraph{Hovered} : créé quand l'utilisateur survole ou sort d'une
 recommandation avec le curseur.
 
 \paragraph{PointerLocked} : dans le cas où l'utilisateur utilise l'option
-\emph{pointer lock}, il sera crée au moment où le pointeur sera capturé et où
+\emph{pointer lock}, il sera créé au moment où le pointeur sera capturé et où
 il sera libéré.
 
-\paragraph{SwitchedLockOption} : crée quand l'utilisateur change d'option entre
+\paragraph{SwitchedLockOption} : créé quand l'utilisateur change d'option entre
 \emph{pointer locked} et \emph{drag-n-drop}.
 
-\paragraph{FpsCounter} : chaque seconde, cet évènement est crée pour connaître
+\paragraph{FpsCounter} : chaque seconde, cet évènement est créé pour connaître
 le \emph{framerate} du client, de sorte à savoir si les performances de sa
 machine ont pu lui poser problème dans ces expériences.
 
@@ -189,5 +190,10 @@ positions de la caméra au moment de ces évènements. Nous interpolons entre le
 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.
 
-\section{Analyse des résultats}
+\section{Déploiement}
+Pour l'instant, cette étude a été faite par des collègues (étudiants,
+chercheurs...), mais nous pensons ensuite le déployer vers une plateforme de
+crowd-sourcing (MicroWokers) afin d'avoir plus de résultats à analyser.
+
+\subsection{Analyse des résultats}
 % TODO analyser les résultats