Some modifs from Axel
This commit is contained in:
Thomas FORGIONE
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
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
|
||||
|
||||
|
|
|
|||
|
|
@ -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…
Reference in New Issue