diff --git a/rapport/Makefile b/rapport/Makefile index 571df9e..1f2fc46 100644 --- a/rapport/Makefile +++ b/rapport/Makefile @@ -2,9 +2,7 @@ TEXC = latexmk -lualatex -output-directory=build .PHONY: FORCE -pdf: build/rapport.pdf - -build/%.pdf: %.tex FORCE +build/rapprt.pdf: main.tex FORCE $(TEXC) -latexoption=-shell-escape $< clean: FORCE diff --git a/rapport/architecture.tex b/rapport/architecture.tex new file mode 100644 index 0000000..a5ea986 --- /dev/null +++ b/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é. diff --git a/rapport/conclusion.tex b/rapport/conclusion.tex index a558256..60822d4 100644 --- a/rapport/conclusion.tex +++ b/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. diff --git a/rapport/img/icons/IRIT.jpg b/rapport/img/icons/IRIT.jpg new file mode 100644 index 0000000..b840e5c Binary files /dev/null and b/rapport/img/icons/IRIT.jpg differ diff --git a/rapport/intro.tex b/rapport/intro.tex index 9804a88..00997d2 100644 --- a/rapport/intro.tex +++ b/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 + diff --git a/rapport/rapport.tex b/rapport/main.tex similarity index 94% rename from rapport/rapport.tex rename to rapport/main.tex index 5fbb1f8..bb79641 100644 --- a/rapport/rapport.tex +++ b/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 diff --git a/rapport/streaming.tex b/rapport/streaming.tex index a1808ae..6fd9817 100644 --- a/rapport/streaming.tex +++ b/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