Some work

rapport/Makefile

@@ -2,9 +2,7 @@ TEXC = latexmk -lualatex -output-directory=build
 
 .PHONY: FORCE
 
-pdf: build/rapport.pdf
+build/rapprt.pdf: main.tex FORCE
-
-build/%.pdf: %.tex FORCE
 	$(TEXC) -latexoption=-shell-escape $<
 
 clean: FORCE

rapport/architecture.tex

@@ -0,0 +1,234 @@
+\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
+parerons ici que du serveur, puis du code client.
+
+\paragraph{}
+Voici une simplification de l'arborescence de la version de
+développement :
+
+\begin{figure}[H]
+\centering
+\begin{subfigure}[b]{0.3\textwidth}
+\centering
+\tikzstyle{every node}=[draw=black,thick,anchor=west]
+\tikzstyle{folder}=[draw=blue, fill=blue!30]
+\begin{tikzpicture}[%
+  grow via three points={one child at (0.5,-0.7) and
+  two children at (0.5,-0.7) and (0.5,-1.4)},
+  edge from parent path={(\tikzparentnode.south) |- (\tikzchildnode.west)}]
+  \node [folder] {root}
+  child {  node [folder] {js}
+      child {node [folder] {l3d}
+        child {node [folder] {src}}
+        child {node [folder] {apps}}
+      }
+      child [missing] {}
+      child [missing] {}
+      child {node [folder] {Autres libraries}}
+      child {node {Makefile}}
+    }
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child { node [folder] {lib}
+        child {node {NodeLog.js}}
+        child {node {controllers.js}}
+        child {node {posts.js}}
+        child {node {mail.js}}
+    }
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child { node [folder] {controllers}}
+    child { node [folder] {posts}}
+    child { node [folder] {geo}
+        child {node {Geo.js}}
+        child {node {Mesh.js}}
+        child {node {MeshContainer.js}}
+        child {node {MeshStreamer.js}}
+    }
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child [missing] {}
+    child { node {private.js }}
+    child { node {package.json }}
+    child { node {npm-shrinkwrap.json }}
+    child { node {server.js }};
+\end{tikzpicture}
+\caption{Vue globale}
+\end{subfigure}
+~
+\begin{subfigure}[b]{0.3\textwidth}
+\centering
+    \tikzstyle{every node}=[draw=black,thick,anchor=west]
+    \tikzstyle{folder}=[draw=blue, fill=blue!30]
+    \begin{tikzpicture}[%
+            grow via three points={one child at (0.5,-0.7) and
+            two children at (0.5,-0.7) and (0.5,-1.4)},
+        edge from parent path={(\tikzparentnode.south) |- (\tikzchildnode.west)}]
+        \node [folder] {src}
+        child { node [folder] {cameras}
+            child { node {FixedCamera.js}}
+            child { node {PointerCamera.js}}
+            child { node {ReplayCamera.js}}
+        }
+        child [missing] {}
+        child [missing] {}
+        child [missing] {}
+        child { node [folder] {canvases}
+            child { node { MousePointer.js}}
+            child { node { Previewer.js}}
+            child { node { StartCanvas.js}}
+        }
+        child [missing] {}
+        child [missing] {}
+        child [missing] {}
+        child { node [folder] {loaders}
+            child { node { ProgressiveLoader.js }}
+        }
+        child [missing] {}
+        child { node [folder] {math}
+            child { node { Hermite.js }}
+        }
+        child [missing] {}
+        child { node [folder] {recommendations}
+            child { node { Arrow.js}}
+            child { node { Viewport.js}}
+        }
+        child [missing] {}
+        child [missing] {}
+        child { node [folder] {scenes}}
+        child { node [folder] {utils}}
+        child { node {l3d.js}}
+
+        ;
+    \end{tikzpicture}
+    \caption{Détail des sources de L3D}
+\end{subfigure}
+~
+\begin{subfigure}[b]{0.3\textwidth}
+\centering
+    \tikzstyle{every node}=[draw=black,thick,anchor=west]
+    \tikzstyle{folder}=[draw=blue, fill=blue!30]
+    \begin{tikzpicture}[%
+            grow via three points={one child at (0.5,-0.7) and
+            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 [folder] {replay}}
+            child {node [folder] {tutorial}}
+            child {node [folder] {coin-creator}}
+            child {node [folder] {coin-viewer}}
+            child {node [folder] {coin-checker}}
+            child {node {ButtonManager.js}}
+            child {node {Coin.js}}
+            child {node {GlobalFunctions.js}}
+        }
+        ;
+    \end{tikzpicture}
+    \caption{Détail des applications}
+\end{subfigure}
+\caption{Arborescence}
+\end{figure}
+\tikzstyle{every node}=[]
+
+
+\newpage
+\section{Code serveur}
+Le code serveur est situé à la racine du projet : le fichier \texttt{server.js}
+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
+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.
+
+\paragraph{}
+Les \emph{packages} que nous utilisons sont les suivants :
+\begin{itemize}
+    \item \emph{express} : un framework web pour NodeJs
+    \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
+    \item \emph{body-parser} : une librairie permettant de traiter simplement
+        les paramètres passés aux reqûetes
+    \item \emph{cookie-parser} et \emph{cookie-session} : une librairie gérant
+        les sessions sous forme de cookies
+    \item \emph{socket.io} : une librairie permettant d'utiliser facilement les
+        sockets (côté serveur et client)
+    \item \emph{serve-favicon} : une librairie pour choisir facilement l'icône
+        du site
+    \item \emph{emailjs} : une librairie permettant de se connecter à une
+        adresse e-mail
+\end{itemize}
+
+\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.
+
+\paragraph{}
+Les contrôleurs sont chargés au démarrage par le fichier
+\texttt{controllers.js}, qui parcourt les dossiers qui sont contenus dans le
+dossier \texttt{controllers}. Dans chacun de ces dossiers, deux fichiers et un
+dossier sont présents :
+
+\begin{itemize}
+    \item \texttt{index.js} qui contient des fonctions (contrôleurs) qui
+        répondent à des requêtes
+    \item \texttt{urls.js} qui contient les urls existantes et les fonctions
+        auxquelles elles vont être associées
+    \item \texttt{views}, dossier qui contient les vues qui vont être utilisées
+        par les contrôleurs définis dans \texttt{index.js}
+\end{itemize}
+
+\paragraph{}
+La même technique à été appliquée pour le dossier \texttt{posts} et le fichier
+\texttt{posts.js}, à la différence près que les requêtes traitées sont des
+requêtes POST et non pas des requêtes GET : elles servent principalement à
+stocker des informations dans la base de donneés.
+
+\section{Code client}
+Le code client est séparé en trois parties :
+\begin{itemize}
+    \item une partie dans le répertoire \texttt{src} contenant de nombreuses
+        fonctions et classes
+    \item une partie dans le répertoire \texttt{apps} contenant des
+        applications que nous avons développées
+    \item des autres librairies développées par des tiers, dans le répertoire
+        \texttt{js}
+\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
+utiliserons par la suite.
+
+\paragraph{}
+Dans la suite, nous allons seulement parler de L3D, puisque c'est le code que
+nous avons développé.

rapport/conclusion.tex

@@ -1 +1,61 @@
+\part*{Remerciements}
+Je tiens particulièrement à remercier \\
+
+\begin{itemize}
+    \item Vicent \textsc{Charvillat}, pour m'avoir donné l'occasion de faire un
+        stage intéressant, et pour toute l'aide qu'il a pu me fournir
+    \item Geraldine \textsc{Morin}, pour sa disponibilité
+    \item Axel \textsc{Carlier}, pour son aide sur les points plus techniques
+    \item Wei Tsang \textsc{Ooi}, pour ses suggestions souvent pertinentes
+        \emph{(même s'il ne lira probablement pas ce rapport)}
+\end{itemize}
+
+\paragraph{}
+mais je me dois aussi de remercier \\
+
+\begin{itemize}
+    \item Thierry \textsc{Malon}
+    \item Émilie \textsc{Jalras}, parce que c'est toujours rigolo de se prendre
+        une gomme dans la tronche,
+    \item Julien \textsc{Fayer}, qui nous a accompagné durant les derniers mois
+        de nos stages
+    \item Bastien \textsc{Durix},
+    \item Vincent \textsc{Angladon},
+\end{itemize}
+
+\newpage
 \part*{Conclusion}
+Peu avant ce stage, nous avons eu le projet long qui nous a permi
+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
+importante dans le cas d'un projet seul.
+
+\paragraph{}
+Dès nos premiers cours à l'ENSEEIHT, on nous enseignait l'importance des
+commentaires qui rendaient compréhensible un programme à quelqu'un d'autre, ou
+parfois, à soi-même mais dans le futurr. Mais sur un projet de quelques jours, il
+est évident que l'on comprendra toujours ce qu'on a fait avant. Cependant dès
+que le projet devient suffisament important, on se rend compte qu'il est
+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 a
+temps plein, et pendant une longue durée, sur 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 batîment, 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
+l'on a eu sur ce projet n'est pas si grande que ça. Lors d'un projet fait seul
+(ou en petite équipe), et qui part de zéro, on voit le programme grandir au fur
+et à mesure, ses fonctionnalités s'améliorer, ses bugs se corriger et de
+nouveaux apparaître, et regarder le projet une fois terminé est très plus
+flatteur pour l'ego.

rapport/intro.tex

@@ -1 +1,49 @@
 \part*{Introduction}
+Ce stage de fin d'études s'est déroulé dans le laboratoire de recherche de
+l'IRIT, dans l'équipe Vortex.
+
+\paragraph{}
+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
+jouait le rôle du client de ce projet.
+
+\paragraph{}
+Quelques semaines plus tard, Émilie \textsc{Jalras}, autre collègue de notre
+projet long, est arrivée pour commencer son stage avec Sylvie \textsc{Chambon}
+sur les superpixels. Émilie n'ayant que Windows sur son ordinateur, il lui
+était impossible d'y développer du logiciel, et puisqu'aucune machine n'était
+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é : 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 video, 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
+

rapport/main.tex

@@ -66,12 +66,14 @@ anchorcolor = blue]{hyperref}
 \@addtoreset{section}{part}
 \makeatother
 
+\usetikzlibrary{trees}
+
 \begin{document}
 
 \begin{titlepage}
     \begin{sffamily}
         \begin{center}
-            ~\\[2cm]
+            ~\\[0cm]
             \LARGE R\hsc{apport de Stage de 3A}\\[3cm]
 
             % Title
@@ -81,7 +83,8 @@ anchorcolor = blue]{hyperref}
 
             \HRule \\[3cm]
 
-            \includegraphics[scale=0.5]{img/icons/n7.png}~\\[4cm]
+            \includegraphics[scale=0.5]{img/icons/n7.png}~\\[1cm]
+            \includegraphics[scale=0.4]{img/icons/IRIT.jpg}~\\[3cm]
 
 
             % Author and supervisor
@@ -119,6 +122,9 @@ anchorcolor = blue]{hyperref}
 \include{techno}
 \newpage
 
+\include{architecture}
+\newpage
+
 \include{interface}
 \newpage
 

rapport/streaming.tex

@@ -1,4 +1,4 @@
-\part{Streaming de modèle 3D}
+\part{Streaming de modèle 3D\label{streaming}}
 Le but ultime de ce projet est de biaiser l'utilisateur avec les
 recommandations de sorte à être capable de prévoir ses déplacements futurs, et
 ainsi précharger les parties du modèle qui vont être vues. Cette section
@@ -39,6 +39,42 @@ Généralement, le fichier \texttt{.obj} vient souvent avec un fichier
 \texttt{.mtl} qui contient la définition des matériaux (leurs noms, leurs
 textures, leurs constantes...).
 
+\section{Architecture}
+Puisque cette partie traite à la fois du client et du serveur, les fichiers
+peuvent sembler éparpillés. Les fichiers concernés sont les fichiers du
+répertoire \texttt{geo} pour le serveur et le fichier
+\texttt{ProgressiveLoader.js} qui est le client.
+
+\subsection{Serveur}
+Nous avons rappelé que les modèles au format \texttt{.obj} contenaient
+plusieurs \emph{sous-modèles} avec des matériau différents, le serveur connait
+les classes suivantes :
+\begin{itemize}
+    \item la classe \texttt{Mesh}, qui représente un \emph{sous-modèle}, avec
+        ses faces, ses coordonnées de textures, ses normales, son matériau
+    \item la classe \texttt{MeshContainer}, qui représente un modèle au format
+        \texttt{.obj}, en tant que liste de \texttt{Mesh}
+    \item la classe \texttt{MeshStreamer}, qui permettra d'envoyer un modèle au
+        client
+\end{itemize}
+
+\paragraph{}
+Pour avoir une bonne performance, il faut éviter de re-parser les fichiers
+\texttt{.obj} et de recréer les \texttt{MeshContainer} à chaque requête.
+
+\paragraph{}
+Dans le fichier \texttt{MeshContainer.js}, une liste de modèle à charger (ainsi
+que leur chemin permet au serveur de créer les \texttt{MeshContainer} au
+démarrage, et ainsi, le \texttt{MeshStreamer} n'a qu'à prendre une référence
+vers ce \texttt{MeshContainer} (qui existe déjà, ce qui réduit la latence).
+
+\subsection{Client}
+Le client de la partie \emph{streaming} de ce projet est contenue dans la
+classe \texttt{ProgressiveLoader}. Celle-ci crée des modèles 3D vides, puis
+établit la connexion avec le serveur et remplit les modèles au fur et à mesure
+que les informations arrivent du serveur. Dans les sections suivantes, nous
+allons montrer les différentes stratégies de \emph{streaming} que nous avons
+mises en place.
 
 \section{Streaming linéaire}
 La première étape de cette fonctionnalité a été de faire un système