Commit
This commit is contained in:
Thomas FORGIONE
parent
8667cc6e8c
commit
8cbde27dfb
2
rapport/.gitignore
vendored
Normal file
2
rapport/.gitignore
vendored
Normal file
@ -0,0 +1,2 @@
|
||||
build/*
|
||||
sketch/*
|
||||
@ -2,16 +2,19 @@ TEXC = latexmk -lualatex -output-directory=build
|
||||
|
||||
.PHONY: FORCE
|
||||
|
||||
all: sk build/main.pdf
|
||||
|
||||
sk:
|
||||
./sketch/sketch frustum.sk -o build/frustum.tex
|
||||
|
||||
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
|
||||
# gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dQUIET -dBATCH -sOutputFile=build/main.pdf build/main.tmp.pdf
|
||||
rm build/main.tmp.pdf
|
||||
|
||||
all: build/main.pdf
|
||||
|
||||
push: compress
|
||||
scp -P2222 build/main.pdf pi@dragonrock.no-ip.org:web/dragonrock/rapport.pdf
|
||||
|
||||
|
||||
@ -163,7 +163,7 @@ développement :
|
||||
\end{tikzpicture}
|
||||
\caption{Détail des applications}
|
||||
\end{subfigure}
|
||||
\caption{Arborescence du \emph{repository} de développement}
|
||||
\caption{Arborescence du \emph{dépôt} de développement}
|
||||
\end{figure}
|
||||
\tikzstyle{every node}=[]
|
||||
|
||||
@ -180,12 +180,11 @@ 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.
|
||||
J'ai recontré ce problème au cours du 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 :
|
||||
@ -209,8 +208,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 (en JavaScript, un objet n'est qu'une liste de paire
|
||||
\emph{modèle-vue-contrôleur} : en JavaScript, nos modèles seront des objets
|
||||
simples (en JavaScript, un objet n'est qu'une liste de paires
|
||||
\emph{clé-valeur}), et le modèle sera limité à l'exécution des requêtes SQL.
|
||||
|
||||
\paragraph{}
|
||||
@ -269,8 +268,7 @@ L3D est composée de plusieurs classes :
|
||||
|
||||
\paragraph{}
|
||||
Elle contient aussi quelques fonctions qui permettent de créer les scènes que
|
||||
nous avons utilisées, et notamment leurs recommandations et leurs pièces
|
||||
rouges.
|
||||
nous avons utilisées, et de les initialiser correctement.
|
||||
|
||||
\paragraph{}
|
||||
Dans le répertoire \texttt{utils}, il y a plusieurs outils pratiques pour le
|
||||
@ -290,32 +288,17 @@ laissées dans le namespace global.
|
||||
|
||||
\subsubsection{Interactive}
|
||||
Ceci est l'interface principale, où l'utilisateur doit rechercher les pièces.
|
||||
Nous en parlerons plus dans la section \ref{interface}.
|
||||
Nous en parlerons plus dans la partie \ref{interface}.
|
||||
|
||||
\subsubsection{Replay}
|
||||
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 tutoriel de l'application : il possède notamment une classe qui copie
|
||||
C'est le didactitiel 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.
|
||||
|
||||
\subsubsection{Coin-creator}
|
||||
C'est une interface qui permet de créer des pièces : en cliquant sur une paroi,
|
||||
une pièce apparaît, et en cliquant sur une pièce, elle disparaît. Cette
|
||||
interface possède un bouton qui permet d'envoyer un mail contenant les données
|
||||
des pièces créées au format JSON.
|
||||
|
||||
\subsubsection{Coin-editor}
|
||||
Cette interface permet d'éditer les pièces : elle est similaire à la
|
||||
précédente, mais expose une variable globale lors du clic sur une pièce qui
|
||||
permet de déplacer celle-ci. Elle sert à corriger les bugs potentiels
|
||||
introduits par l'interface précédente, notamment lorsqu'une pièce traverse une
|
||||
paroi.
|
||||
|
||||
\subsubsection{Coin-checker}
|
||||
Elle permet de chercher toutes les pièces d'une scène, au cas où certaines se
|
||||
soient glissées à l'intérieur du modèle. Elle contient notamment un affichage
|
||||
du nombre de pièces présentes sur la scène, et cliquer sur une pièce la
|
||||
supprime.
|
||||
\subsubsection{Coin-creator, Coin-editor et Coin-checker}
|
||||
Ce sont des outils de développement qui seront détaillés dans la section
|
||||
\ref{coins}.
|
||||
|
||||
@ -26,7 +26,7 @@ mais je me dois aussi de remercier \\
|
||||
CC-BY-SA 3.0 (\url{http://creativecommons.org/licenses/by-sa/3.0/deed.fr})
|
||||
Source : Article Méthode du canard en plastique de Wikipédia en
|
||||
français
|
||||
(\url{http://fr.wikipedia.org/wiki/M\%C3\%A9thode\_du\_canard\_en\_plastique})}.
|
||||
(\url{http://fr.wikipedia.org/wiki/M\%C3\%A9thode\_du\_canard\_en\_plastique})}
|
||||
et plus encore,
|
||||
\item Julien \textsc{Fayer}, qui nous a accompagné durant les derniers mois
|
||||
de nos stages
|
||||
@ -51,7 +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.
|
||||
pour les futurs utilisateurs (ce qui a déjà été fait, notamment par Nghiem,
|
||||
CrowMM'12).
|
||||
|
||||
\paragraph{}
|
||||
\paragraph{}
|
||||
@ -89,3 +90,10 @@ l'on a eu sur ce projet n'est pas si grande que ça. Lors d'un projet fait seul
|
||||
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 nettement plus
|
||||
flatteur pour l'ego.
|
||||
|
||||
\paragraph{}
|
||||
\paragraph{}
|
||||
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.
|
||||
|
||||
57
rapport/frustum.sk
Normal file
57
rapport/frustum.sk
Normal file
@ -0,0 +1,57 @@
|
||||
|
||||
def frustum {
|
||||
def C (0,-5,0)
|
||||
def p1 (-1,0,-1)
|
||||
def p2 ( 1,0,-1)
|
||||
def p3 ( 1,0, 1)
|
||||
def p4 (-1,0, 1)
|
||||
|
||||
def pp1(-3, 10, -3)
|
||||
def pp2( 3, 10, -3)
|
||||
def pp3( 3, 10, 3)
|
||||
def pp4(-3, 10, 3)
|
||||
|
||||
def t11(-1.6,5.5,0.4)
|
||||
def t12(0.6,6.2,1.3)
|
||||
def t13(-0.2,5.8,-0.4)
|
||||
|
||||
def t21(-2.8,3,2.8)
|
||||
def t22(-1.9,3,2.8)
|
||||
def t23(-2.8,3,1.9)
|
||||
|
||||
def t31(-2,8.2,0.6)
|
||||
def t32(-4,6.4,2)
|
||||
def t33(-1.2,5.7,0.7)
|
||||
|
||||
def t41(0.8,7.5,3.1)
|
||||
def t42(3.1,7.5,3.1)
|
||||
def t43(3.1,7.5,0.8)
|
||||
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](p1)(p2)(p3)(p4)
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](pp1)(pp2)(pp3)(pp4)
|
||||
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](p1)(p2)(pp2)(pp1)
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](p2)(p3)(pp3)(pp2)
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](p3)(p4)(pp4)(pp3)
|
||||
polygon[fill=lightgray, cull=false, fill opacity=0.8](p4)(p1)(pp1)(pp4)
|
||||
|
||||
polygon[fill=blue, cull=false, fill opacity=1](t11)(t12)(t13)
|
||||
polygon[fill=magenta, cull=false, fill opacity=1](t21)(t22)(t23)
|
||||
polygon[fill=green, cull=false, fill opacity=1](t31)(t32)(t33)
|
||||
polygon[fill=red, cull=false, fill opacity=1](t41)(t42)(t43)
|
||||
|
||||
% line[color=red](0,0,0)(5,0,0)
|
||||
% line[color=green](0,0,0)(0,5,0)
|
||||
% line[color=blue](0,0,0)(0,0,5)
|
||||
|
||||
line[style=dashed](C)(p1)
|
||||
line[style=dashed](C)(p2)
|
||||
line[style=dashed](C)(p3)
|
||||
line[style=dashed](C)(p4)
|
||||
}
|
||||
|
||||
put { rotate(-90, (0,0,0), [1,0,0]) then rotate(-45, (0,0,0), [0,1,0]) then rotate(30,(0,0,0),[1,0,0]) then scale([0.7,0.7,0.7])} {frustum}
|
||||
|
||||
global {
|
||||
language tikz
|
||||
}
|
||||
@ -3,18 +3,18 @@
|
||||
\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
|
||||
phase de découverte du sujet, qui n'était alors 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 :
|
||||
Le stage a donc commencé par une phase bibliographique afin d'étudier l'état de
|
||||
l'art 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
|
||||
@ -31,7 +31,7 @@ commencé à découvrir les multiples façons de faire des interfaces 3D via HTM
|
||||
et JavaScript.
|
||||
|
||||
\subsection{Communication}
|
||||
Les communications inter-IRIT se faisaient principalement par mail. Lorsqu'il y
|
||||
Les communications intra-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.
|
||||
@ -51,7 +51,7 @@ pages à cette adresse.
|
||||
\begin{landscape}
|
||||
\section{Planning}
|
||||
\begin{figure}[H]
|
||||
\begin{gantt}{20}{20}
|
||||
\begin{gantt}{20}{18}
|
||||
\begin{ganttitle}
|
||||
\titleelement{Mars}{2}
|
||||
\titleelement{Avril}{2}
|
||||
@ -62,20 +62,19 @@ pages à cette adresse.
|
||||
\titleelement{Septembre}{2}
|
||||
\titleelement{Octobre}{2}
|
||||
\titleelement{Novembre}{2}
|
||||
\titleelement{Décembre}{2}
|
||||
\end{ganttitle}
|
||||
\ganttmilestone{Début du stage}{1}
|
||||
\ganttbar{Bibliographie}{1}{2}
|
||||
\ganttbar{Choix des technos}{1}{2}
|
||||
\ganttbar{Interface (base)}{3}{1}
|
||||
\ganttbar{Recommandation (\emph{viewport})}{4}{2}
|
||||
\ganttbar{Recommandation (\emph{arrow})}{6}{2}
|
||||
\ganttbar{Interface (base) \ref{interface-base}}{3}{1}
|
||||
\ganttbar{Recommandation (\emph{viewport}) \ref{viewport}}{4}{2}
|
||||
\ganttbar{Recommandation (\emph{arrow}) \ref{arrow}}{6}{2}
|
||||
\ganttbar{Recherche de scènes}{2}{2}
|
||||
\ganttbar{Système de pièces}{7}{4}
|
||||
\ganttbar{Système de pièces \ref{coins}}{7}{4}
|
||||
\ganttbar[color=green]{Fermeture du labo}{9}{1}
|
||||
\ganttbar{Étude utilisateur (labo)}{11}{1}
|
||||
\ganttbar{Étude utilisateur (labo) \ref{userstudy}}{11}{1}
|
||||
\ganttbar{Rapport / Slides}{11}{2}
|
||||
\ganttmilestone{Fin du stage}{12}
|
||||
\ganttmilestone{Fin du stage}{13}
|
||||
\end{gantt}
|
||||
\caption{Planning du projet}
|
||||
\end{figure}
|
||||
|
||||
@ -1,10 +1,10 @@
|
||||
\part{L'interface \label{interface}}
|
||||
\section{Interactions élémentaires}
|
||||
\section{Interactions élémentaires\label{interface-base}}
|
||||
\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 une scène 3D.
|
||||
Elle est contrôlée par un ensemble de paramètres décrit dans la figure
|
||||
\ref{spheric}.
|
||||
La première interface, sans recommandations, a été pensée pour être la plus
|
||||
simple possible. 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
|
||||
@ -24,7 +24,8 @@ 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 :
|
||||
La rotation de la caméra (variation des angles $\theta$ et $\delta$) de
|
||||
plusieurs manières :
|
||||
\begin{itemize}
|
||||
\item via le pavé numérique (2, 4, 6, et 8 pour tourner respectivement vers
|
||||
le bas, vers la gauche, vers la droite et vers le haut)
|
||||
@ -87,7 +88,7 @@ son centre en fonction des interactions.
|
||||
|
||||
\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
|
||||
surtout pour quelqu'un qui n'est pas habitué à jouer aux jeux vidéo. Nous
|
||||
allons donc ensuite voir comment nous pouvons essayer de faciliter
|
||||
la navigation pour des utilisateurs non-initiés.
|
||||
|
||||
@ -100,7 +101,7 @@ d'objets 3D ajoutés à la scène. Deux affichages ont été testés.
|
||||
|
||||
|
||||
|
||||
\subsection{Les \emph{viewports}}
|
||||
\subsection{Les \emph{viewports}\label{viewport}}
|
||||
\paragraph{}
|
||||
Les \emph{viewports} sont les affichages les plus simples : ils représentent
|
||||
une caméra, avec son centre optique et son plan image.
|
||||
@ -113,11 +114,11 @@ Cette façon d'afficher une recommandation a l'avantage d'être simple, de ne pa
|
||||
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).
|
||||
le point de vue est dirigée vers le modèle ou vers nous).
|
||||
% TODO pas clair pou non spécialiste en vision
|
||||
|
||||
|
||||
\subsection{Les flèches}
|
||||
\subsection{Les flèches\label{arrow}}
|
||||
\subsubsection{Principe}
|
||||
Les flèches sont supposées être plus intuitives pour un utilisateur qui n'a pas
|
||||
l'habitude des \emph{viewports} précédemment utilisés. Plutôt que de suggérer
|
||||
@ -125,14 +126,14 @@ 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}
|
||||
\caption{Des recommandations flèches}
|
||||
\caption{Une recommandation flèche}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Courbure de la flèche}
|
||||
Pour le dessin des flèches, plusieurs choses sont à prendre en compte :
|
||||
\begin{itemize}
|
||||
\item il faut éviter que la flèche soit trop \emph{présente} à l'écran et
|
||||
qu'elle obstrue trop le reste de la scène
|
||||
qu'elle occulte trop le reste de la scène
|
||||
\item il faut que la flèche soit dans un plan qui ne soit pas orthogonal au
|
||||
plan image de la caméra. En effet, si la flèche est dans un plan
|
||||
orthogonal au plan image de la caméra, elle se projettera comme un
|
||||
@ -142,8 +143,14 @@ Pour le dessin des flèches, plusieurs choses sont à prendre en compte :
|
||||
\paragraph{}
|
||||
Pour trouver la courbure de la flèche, nous posons $C$ le centre de la caméra,
|
||||
$R$ le centre de la recommandation, et $R'$ le vecteur qui donne la direction
|
||||
de la recommandation. Nous cherchons ensuite un polynôme $f$ tel que :
|
||||
$$\left\{\begin{array}{lcl}
|
||||
de la recommandation. Nous cherchons ensuite un polynôme
|
||||
$$
|
||||
\begin{array}{lcccl}
|
||||
f & : & [0,1] & \rightarrow & \mathbb{R}^3 \\
|
||||
&& t & \mapsto & (x,y,z)
|
||||
\end{array}
|
||||
\quad\quad \text{tel que}\quad\quad
|
||||
\left\{\begin{array}{lcl}
|
||||
f(0) & = & C \\
|
||||
f(1) & = & R \\
|
||||
f'(1) & = & \lambda R' \text{ avec } \lambda \in \mathbb{R}^{+}
|
||||
@ -157,8 +164,9 @@ 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]$ (c'est-à-dire qu'on
|
||||
n'affichera que la moitié de la flèche la plus lointaine de la caméra).
|
||||
seulement la flèche pour des valeurs du paramètres $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
|
||||
@ -168,8 +176,8 @@ accentuer la courbure de la flèche, et nous résolvons plutôt le système suiv
|
||||
$$\left\{\begin{array}{lcl}
|
||||
f(0) & = & C - e_z + \lambda R' \\
|
||||
f(1) & = & R \\
|
||||
f'(1) & = & \lambda R' \text{ avec } \lambda \in \mathbb{R}^{+}
|
||||
\end{array}\right.$$
|
||||
f'(1) & = & \lambda R'
|
||||
\end{array}\right. \quad\quad\text{avec}\quad\lambda\in\mathbb{R}^+$$
|
||||
|
||||
\subsection{Les interactions}
|
||||
\subsubsection{Au survol}
|
||||
@ -238,7 +246,7 @@ présents.
|
||||
\draw (-8,5) -- (-7,5);
|
||||
\draw (-8,5) node[left]{7};
|
||||
\end{tikzpicture}
|
||||
\caption{Les différents éléments de l'interface}
|
||||
\caption{Les différents éléments de l'interface\label{interface-schema}}
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
\part*{Introduction}
|
||||
\part*{Préambule}
|
||||
Ce stage de fin d'études s'est déroulé dans le laboratoire de recherche de
|
||||
l'IRIT, dans l'équipe VORTEX.
|
||||
|
||||
|
||||
@ -17,9 +17,10 @@
|
||||
anchorcolor = blue]{hyperref}
|
||||
\usepackage{cpp}
|
||||
\usepackage{tikz}
|
||||
\usepackage{tikz-3dplot}
|
||||
\usepackage{pgfplots}
|
||||
\usepackage{subcaption}
|
||||
\usepackage{pdflscape}
|
||||
\usepackage{lscape}
|
||||
\usepackage{gantt}
|
||||
\lstset{language=matlab}
|
||||
|
||||
@ -57,6 +58,7 @@ anchorcolor = blue]{hyperref}
|
||||
\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}}
|
||||
\newcommand{\nodejs}{\href{https://nodejs.org/en/}{NodeJs}}
|
||||
|
||||
\renewcommand{\include}[1]{\import{./}{#1.tex}}
|
||||
|
||||
@ -73,6 +75,9 @@ anchorcolor = blue]{hyperref}
|
||||
|
||||
\usetikzlibrary{trees}
|
||||
\usepackage{afterpage}
|
||||
|
||||
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\begin{titlepage}
|
||||
|
||||
@ -1,28 +1,28 @@
|
||||
\part{Présentation du projet, contexte et objectifs}
|
||||
\part{Introduction}
|
||||
\section{Contexte}
|
||||
\paragraph{}
|
||||
Ce travail s'inscrit dans la progression des anciens travaux de Vincent
|
||||
Charvillat et d'Axel Carlier sur la prédicabilité du comportement d'un
|
||||
utilisateur en interaction avec un lecteur vidéo. L'objectif était alors de
|
||||
proposé un modèle de préchargement plus intelligent que le préchargement
|
||||
linéaire qui est actuellement implémenté sur les sites de streaming vidéo comme
|
||||
YouTube.
|
||||
Ce travail s'inscrit dans la continuité des travaux de Vincent Charvillat et
|
||||
d'Axel Carlier sur la prédictabilité du comportement d'un utilisateur en
|
||||
interaction avec un lecteur vidéo. L'objectif était alors de proposer un modèle
|
||||
de préchargement plus intelligent que le préchargement linéaire qui est
|
||||
actuellement implémenté sur les sites de streaming vidéo comme YouTube.
|
||||
|
||||
\paragraph{}
|
||||
L'idée était de suggérer à l'utilisateur des zones intéressantes dans la vidéo
|
||||
de sorte à biaiser son comportement. Lorsqu'un utilisateur parcourt une vidéo,
|
||||
il peut sauter des passages et aller directement à d'autres. En ajoutant des
|
||||
recommandations sur une barre de navigation, on peut espérer que l'utilisateur
|
||||
clique sur ces zones intéressantes plutôt qu'ailleurs. Plutôt que de précharger
|
||||
toute la vidéo linéairement, on peut donc précharger les zones intéressantes et
|
||||
réduire la latence lorsque l'utilisateur va sauter une partie pour aller vers
|
||||
une zone recommandée.
|
||||
L'idée était de suggérer à l'utilisateur des instants potentiellement
|
||||
intéressants dans la vidéo de sorte à biaiser son comportement. Lorsqu'un
|
||||
utilisateur parcourt une vidéo, il peut sauter des passages et aller
|
||||
directement à d'autres. De nombreux travaux montrent qu'en ajoutant des
|
||||
recommandations sur une barre de navigation, l'utilisateur aura tendance à
|
||||
cliquer sur ces zones intéressantes plutôt qu'ailleurs. Plutôt que de
|
||||
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.
|
||||
|
||||
\section{Objectifs}
|
||||
\paragraph{}
|
||||
Ce projet a pour but d'appliquer les idées citées précédemment dans le contexte
|
||||
de la navigation et du streaming de modèles 3D. Nous avons donc développé une
|
||||
interface permettant de naviguer dans une scène 3D de manière plus simples que
|
||||
interface permettant de naviguer dans une scène 3D de manière plus simple que
|
||||
les interfaces actuellement existantes (et qui sont, le plus souvent, utilisées
|
||||
dans le monde du jeux vidéo). En effet, de nombreuses personnes n'ont pas
|
||||
l'habitude de jouer aux jeux vidéo, et peinent à utiliser les interfaces
|
||||
@ -36,3 +36,15 @@ s'il désire un point de vue plus précis. En supposant que l'utilisateur soit
|
||||
susceptible de sauter vers les vues recommandées, on peut précharger des
|
||||
parties d'un modèle plutôt que d'autres de sorte à éviter que l'utilisateur se
|
||||
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.
|
||||
|
||||
\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
|
||||
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,
|
||||
nous verrons comment nous avons fait du streaming de modèle 3D.
|
||||
|
||||
674
rapport/sketch/COPYING.txt
Normal file
674
rapport/sketch/COPYING.txt
Normal file
@ -0,0 +1,674 @@
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 3, 29 June 2007
|
||||
|
||||
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The GNU General Public License is a free, copyleft license for
|
||||
software and other kinds of works.
|
||||
|
||||
The licenses for most software and other practical works are designed
|
||||
to take away your freedom to share and change the works. By contrast,
|
||||
the GNU General Public License is intended to guarantee your freedom to
|
||||
share and change all versions of a program--to make sure it remains free
|
||||
software for all its users. We, the Free Software Foundation, use the
|
||||
GNU General Public License for most of our software; it applies also to
|
||||
any other work released this way by its authors. You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
them if you wish), that you receive source code or can get it if you
|
||||
want it, that you can change the software or use pieces of it in new
|
||||
free programs, and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to prevent others from denying you
|
||||
these rights or asking you to surrender the rights. Therefore, you have
|
||||
certain responsibilities if you distribute copies of the software, or if
|
||||
you modify it: responsibilities to respect the freedom of others.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must pass on to the recipients the same
|
||||
freedoms that you received. You must make sure that they, too, receive
|
||||
or can get the source code. And you must show them these terms so they
|
||||
know their rights.
|
||||
|
||||
Developers that use the GNU GPL protect your rights with two steps:
|
||||
(1) assert copyright on the software, and (2) offer you this License
|
||||
giving you legal permission to copy, distribute and/or modify it.
|
||||
|
||||
For the developers' and authors' protection, the GPL clearly explains
|
||||
that there is no warranty for this free software. For both users' and
|
||||
authors' sake, the GPL requires that modified versions be marked as
|
||||
changed, so that their problems will not be attributed erroneously to
|
||||
authors of previous versions.
|
||||
|
||||
Some devices are designed to deny users access to install or run
|
||||
modified versions of the software inside them, although the manufacturer
|
||||
can do so. This is fundamentally incompatible with the aim of
|
||||
protecting users' freedom to change the software. The systematic
|
||||
pattern of such abuse occurs in the area of products for individuals to
|
||||
use, which is precisely where it is most unacceptable. Therefore, we
|
||||
have designed this version of the GPL to prohibit the practice for those
|
||||
products. If such problems arise substantially in other domains, we
|
||||
stand ready to extend this provision to those domains in future versions
|
||||
of the GPL, as needed to protect the freedom of users.
|
||||
|
||||
Finally, every program is threatened constantly by software patents.
|
||||
States should not allow patents to restrict development and use of
|
||||
software on general-purpose computers, but in those that do, we wish to
|
||||
avoid the special danger that patents applied to a free program could
|
||||
make it effectively proprietary. To prevent this, the GPL assures that
|
||||
patents cannot be used to render the program non-free.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
TERMS AND CONDITIONS
|
||||
|
||||
0. Definitions.
|
||||
|
||||
"This License" refers to version 3 of the GNU General Public License.
|
||||
|
||||
"Copyright" also means copyright-like laws that apply to other kinds of
|
||||
works, such as semiconductor masks.
|
||||
|
||||
"The Program" refers to any copyrightable work licensed under this
|
||||
License. Each licensee is addressed as "you". "Licensees" and
|
||||
"recipients" may be individuals or organizations.
|
||||
|
||||
To "modify" a work means to copy from or adapt all or part of the work
|
||||
in a fashion requiring copyright permission, other than the making of an
|
||||
exact copy. The resulting work is called a "modified version" of the
|
||||
earlier work or a work "based on" the earlier work.
|
||||
|
||||
A "covered work" means either the unmodified Program or a work based
|
||||
on the Program.
|
||||
|
||||
To "propagate" a work means to do anything with it that, without
|
||||
permission, would make you directly or secondarily liable for
|
||||
infringement under applicable copyright law, except executing it on a
|
||||
computer or modifying a private copy. Propagation includes copying,
|
||||
distribution (with or without modification), making available to the
|
||||
public, and in some countries other activities as well.
|
||||
|
||||
To "convey" a work means any kind of propagation that enables other
|
||||
parties to make or receive copies. Mere interaction with a user through
|
||||
a computer network, with no transfer of a copy, is not conveying.
|
||||
|
||||
An interactive user interface displays "Appropriate Legal Notices"
|
||||
to the extent that it includes a convenient and prominently visible
|
||||
feature that (1) displays an appropriate copyright notice, and (2)
|
||||
tells the user that there is no warranty for the work (except to the
|
||||
extent that warranties are provided), that licensees may convey the
|
||||
work under this License, and how to view a copy of this License. If
|
||||
the interface presents a list of user commands or options, such as a
|
||||
menu, a prominent item in the list meets this criterion.
|
||||
|
||||
1. Source Code.
|
||||
|
||||
The "source code" for a work means the preferred form of the work
|
||||
for making modifications to it. "Object code" means any non-source
|
||||
form of a work.
|
||||
|
||||
A "Standard Interface" means an interface that either is an official
|
||||
standard defined by a recognized standards body, or, in the case of
|
||||
interfaces specified for a particular programming language, one that
|
||||
is widely used among developers working in that language.
|
||||
|
||||
The "System Libraries" of an executable work include anything, other
|
||||
than the work as a whole, that (a) is included in the normal form of
|
||||
packaging a Major Component, but which is not part of that Major
|
||||
Component, and (b) serves only to enable use of the work with that
|
||||
Major Component, or to implement a Standard Interface for which an
|
||||
implementation is available to the public in source code form. A
|
||||
"Major Component", in this context, means a major essential component
|
||||
(kernel, window system, and so on) of the specific operating system
|
||||
(if any) on which the executable work runs, or a compiler used to
|
||||
produce the work, or an object code interpreter used to run it.
|
||||
|
||||
The "Corresponding Source" for a work in object code form means all
|
||||
the source code needed to generate, install, and (for an executable
|
||||
work) run the object code and to modify the work, including scripts to
|
||||
control those activities. However, it does not include the work's
|
||||
System Libraries, or general-purpose tools or generally available free
|
||||
programs which are used unmodified in performing those activities but
|
||||
which are not part of the work. For example, Corresponding Source
|
||||
includes interface definition files associated with source files for
|
||||
the work, and the source code for shared libraries and dynamically
|
||||
linked subprograms that the work is specifically designed to require,
|
||||
such as by intimate data communication or control flow between those
|
||||
subprograms and other parts of the work.
|
||||
|
||||
The Corresponding Source need not include anything that users
|
||||
can regenerate automatically from other parts of the Corresponding
|
||||
Source.
|
||||
|
||||
The Corresponding Source for a work in source code form is that
|
||||
same work.
|
||||
|
||||
2. Basic Permissions.
|
||||
|
||||
All rights granted under this License are granted for the term of
|
||||
copyright on the Program, and are irrevocable provided the stated
|
||||
conditions are met. This License explicitly affirms your unlimited
|
||||
permission to run the unmodified Program. The output from running a
|
||||
covered work is covered by this License only if the output, given its
|
||||
content, constitutes a covered work. This License acknowledges your
|
||||
rights of fair use or other equivalent, as provided by copyright law.
|
||||
|
||||
You may make, run and propagate covered works that you do not
|
||||
convey, without conditions so long as your license otherwise remains
|
||||
in force. You may convey covered works to others for the sole purpose
|
||||
of having them make modifications exclusively for you, or provide you
|
||||
with facilities for running those works, provided that you comply with
|
||||
the terms of this License in conveying all material for which you do
|
||||
not control copyright. Those thus making or running the covered works
|
||||
for you must do so exclusively on your behalf, under your direction
|
||||
and control, on terms that prohibit them from making any copies of
|
||||
your copyrighted material outside their relationship with you.
|
||||
|
||||
Conveying under any other circumstances is permitted solely under
|
||||
the conditions stated below. Sublicensing is not allowed; section 10
|
||||
makes it unnecessary.
|
||||
|
||||
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
|
||||
|
||||
No covered work shall be deemed part of an effective technological
|
||||
measure under any applicable law fulfilling obligations under article
|
||||
11 of the WIPO copyright treaty adopted on 20 December 1996, or
|
||||
similar laws prohibiting or restricting circumvention of such
|
||||
measures.
|
||||
|
||||
When you convey a covered work, you waive any legal power to forbid
|
||||
circumvention of technological measures to the extent such circumvention
|
||||
is effected by exercising rights under this License with respect to
|
||||
the covered work, and you disclaim any intention to limit operation or
|
||||
modification of the work as a means of enforcing, against the work's
|
||||
users, your or third parties' legal rights to forbid circumvention of
|
||||
technological measures.
|
||||
|
||||
4. Conveying Verbatim Copies.
|
||||
|
||||
You may convey verbatim copies of the Program's source code as you
|
||||
receive it, in any medium, provided that you conspicuously and
|
||||
appropriately publish on each copy an appropriate copyright notice;
|
||||
keep intact all notices stating that this License and any
|
||||
non-permissive terms added in accord with section 7 apply to the code;
|
||||
keep intact all notices of the absence of any warranty; and give all
|
||||
recipients a copy of this License along with the Program.
|
||||
|
||||
You may charge any price or no price for each copy that you convey,
|
||||
and you may offer support or warranty protection for a fee.
|
||||
|
||||
5. Conveying Modified Source Versions.
|
||||
|
||||
You may convey a work based on the Program, or the modifications to
|
||||
produce it from the Program, in the form of source code under the
|
||||
terms of section 4, provided that you also meet all of these conditions:
|
||||
|
||||
a) The work must carry prominent notices stating that you modified
|
||||
it, and giving a relevant date.
|
||||
|
||||
b) The work must carry prominent notices stating that it is
|
||||
released under this License and any conditions added under section
|
||||
7. This requirement modifies the requirement in section 4 to
|
||||
"keep intact all notices".
|
||||
|
||||
c) You must license the entire work, as a whole, under this
|
||||
License to anyone who comes into possession of a copy. This
|
||||
License will therefore apply, along with any applicable section 7
|
||||
additional terms, to the whole of the work, and all its parts,
|
||||
regardless of how they are packaged. This License gives no
|
||||
permission to license the work in any other way, but it does not
|
||||
invalidate such permission if you have separately received it.
|
||||
|
||||
d) If the work has interactive user interfaces, each must display
|
||||
Appropriate Legal Notices; however, if the Program has interactive
|
||||
interfaces that do not display Appropriate Legal Notices, your
|
||||
work need not make them do so.
|
||||
|
||||
A compilation of a covered work with other separate and independent
|
||||
works, which are not by their nature extensions of the covered work,
|
||||
and which are not combined with it such as to form a larger program,
|
||||
in or on a volume of a storage or distribution medium, is called an
|
||||
"aggregate" if the compilation and its resulting copyright are not
|
||||
used to limit the access or legal rights of the compilation's users
|
||||
beyond what the individual works permit. Inclusion of a covered work
|
||||
in an aggregate does not cause this License to apply to the other
|
||||
parts of the aggregate.
|
||||
|
||||
6. Conveying Non-Source Forms.
|
||||
|
||||
You may convey a covered work in object code form under the terms
|
||||
of sections 4 and 5, provided that you also convey the
|
||||
machine-readable Corresponding Source under the terms of this License,
|
||||
in one of these ways:
|
||||
|
||||
a) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by the
|
||||
Corresponding Source fixed on a durable physical medium
|
||||
customarily used for software interchange.
|
||||
|
||||
b) Convey the object code in, or embodied in, a physical product
|
||||
(including a physical distribution medium), accompanied by a
|
||||
written offer, valid for at least three years and valid for as
|
||||
long as you offer spare parts or customer support for that product
|
||||
model, to give anyone who possesses the object code either (1) a
|
||||
copy of the Corresponding Source for all the software in the
|
||||
product that is covered by this License, on a durable physical
|
||||
medium customarily used for software interchange, for a price no
|
||||
more than your reasonable cost of physically performing this
|
||||
conveying of source, or (2) access to copy the
|
||||
Corresponding Source from a network server at no charge.
|
||||
|
||||
c) Convey individual copies of the object code with a copy of the
|
||||
written offer to provide the Corresponding Source. This
|
||||
alternative is allowed only occasionally and noncommercially, and
|
||||
only if you received the object code with such an offer, in accord
|
||||
with subsection 6b.
|
||||
|
||||
d) Convey the object code by offering access from a designated
|
||||
place (gratis or for a charge), and offer equivalent access to the
|
||||
Corresponding Source in the same way through the same place at no
|
||||
further charge. You need not require recipients to copy the
|
||||
Corresponding Source along with the object code. If the place to
|
||||
copy the object code is a network server, the Corresponding Source
|
||||
may be on a different server (operated by you or a third party)
|
||||
that supports equivalent copying facilities, provided you maintain
|
||||
clear directions next to the object code saying where to find the
|
||||
Corresponding Source. Regardless of what server hosts the
|
||||
Corresponding Source, you remain obligated to ensure that it is
|
||||
available for as long as needed to satisfy these requirements.
|
||||
|
||||
e) Convey the object code using peer-to-peer transmission, provided
|
||||
you inform other peers where the object code and Corresponding
|
||||
Source of the work are being offered to the general public at no
|
||||
charge under subsection 6d.
|
||||
|
||||
A separable portion of the object code, whose source code is excluded
|
||||
from the Corresponding Source as a System Library, need not be
|
||||
included in conveying the object code work.
|
||||
|
||||
A "User Product" is either (1) a "consumer product", which means any
|
||||
tangible personal property which is normally used for personal, family,
|
||||
or household purposes, or (2) anything designed or sold for incorporation
|
||||
into a dwelling. In determining whether a product is a consumer product,
|
||||
doubtful cases shall be resolved in favor of coverage. For a particular
|
||||
product received by a particular user, "normally used" refers to a
|
||||
typical or common use of that class of product, regardless of the status
|
||||
of the particular user or of the way in which the particular user
|
||||
actually uses, or expects or is expected to use, the product. A product
|
||||
is a consumer product regardless of whether the product has substantial
|
||||
commercial, industrial or non-consumer uses, unless such uses represent
|
||||
the only significant mode of use of the product.
|
||||
|
||||
"Installation Information" for a User Product means any methods,
|
||||
procedures, authorization keys, or other information required to install
|
||||
and execute modified versions of a covered work in that User Product from
|
||||
a modified version of its Corresponding Source. The information must
|
||||
suffice to ensure that the continued functioning of the modified object
|
||||
code is in no case prevented or interfered with solely because
|
||||
modification has been made.
|
||||
|
||||
If you convey an object code work under this section in, or with, or
|
||||
specifically for use in, a User Product, and the conveying occurs as
|
||||
part of a transaction in which the right of possession and use of the
|
||||
User Product is transferred to the recipient in perpetuity or for a
|
||||
fixed term (regardless of how the transaction is characterized), the
|
||||
Corresponding Source conveyed under this section must be accompanied
|
||||
by the Installation Information. But this requirement does not apply
|
||||
if neither you nor any third party retains the ability to install
|
||||
modified object code on the User Product (for example, the work has
|
||||
been installed in ROM).
|
||||
|
||||
The requirement to provide Installation Information does not include a
|
||||
requirement to continue to provide support service, warranty, or updates
|
||||
for a work that has been modified or installed by the recipient, or for
|
||||
the User Product in which it has been modified or installed. Access to a
|
||||
network may be denied when the modification itself materially and
|
||||
adversely affects the operation of the network or violates the rules and
|
||||
protocols for communication across the network.
|
||||
|
||||
Corresponding Source conveyed, and Installation Information provided,
|
||||
in accord with this section must be in a format that is publicly
|
||||
documented (and with an implementation available to the public in
|
||||
source code form), and must require no special password or key for
|
||||
unpacking, reading or copying.
|
||||
|
||||
7. Additional Terms.
|
||||
|
||||
"Additional permissions" are terms that supplement the terms of this
|
||||
License by making exceptions from one or more of its conditions.
|
||||
Additional permissions that are applicable to the entire Program shall
|
||||
be treated as though they were included in this License, to the extent
|
||||
that they are valid under applicable law. If additional permissions
|
||||
apply only to part of the Program, that part may be used separately
|
||||
under those permissions, but the entire Program remains governed by
|
||||
this License without regard to the additional permissions.
|
||||
|
||||
When you convey a copy of a covered work, you may at your option
|
||||
remove any additional permissions from that copy, or from any part of
|
||||
it. (Additional permissions may be written to require their own
|
||||
removal in certain cases when you modify the work.) You may place
|
||||
additional permissions on material, added by you to a covered work,
|
||||
for which you have or can give appropriate copyright permission.
|
||||
|
||||
Notwithstanding any other provision of this License, for material you
|
||||
add to a covered work, you may (if authorized by the copyright holders of
|
||||
that material) supplement the terms of this License with terms:
|
||||
|
||||
a) Disclaiming warranty or limiting liability differently from the
|
||||
terms of sections 15 and 16 of this License; or
|
||||
|
||||
b) Requiring preservation of specified reasonable legal notices or
|
||||
author attributions in that material or in the Appropriate Legal
|
||||
Notices displayed by works containing it; or
|
||||
|
||||
c) Prohibiting misrepresentation of the origin of that material, or
|
||||
requiring that modified versions of such material be marked in
|
||||
reasonable ways as different from the original version; or
|
||||
|
||||
d) Limiting the use for publicity purposes of names of licensors or
|
||||
authors of the material; or
|
||||
|
||||
e) Declining to grant rights under trademark law for use of some
|
||||
trade names, trademarks, or service marks; or
|
||||
|
||||
f) Requiring indemnification of licensors and authors of that
|
||||
material by anyone who conveys the material (or modified versions of
|
||||
it) with contractual assumptions of liability to the recipient, for
|
||||
any liability that these contractual assumptions directly impose on
|
||||
those licensors and authors.
|
||||
|
||||
All other non-permissive additional terms are considered "further
|
||||
restrictions" within the meaning of section 10. If the Program as you
|
||||
received it, or any part of it, contains a notice stating that it is
|
||||
governed by this License along with a term that is a further
|
||||
restriction, you may remove that term. If a license document contains
|
||||
a further restriction but permits relicensing or conveying under this
|
||||
License, you may add to a covered work material governed by the terms
|
||||
of that license document, provided that the further restriction does
|
||||
not survive such relicensing or conveying.
|
||||
|
||||
If you add terms to a covered work in accord with this section, you
|
||||
must place, in the relevant source files, a statement of the
|
||||
additional terms that apply to those files, or a notice indicating
|
||||
where to find the applicable terms.
|
||||
|
||||
Additional terms, permissive or non-permissive, may be stated in the
|
||||
form of a separately written license, or stated as exceptions;
|
||||
the above requirements apply either way.
|
||||
|
||||
8. Termination.
|
||||
|
||||
You may not propagate or modify a covered work except as expressly
|
||||
provided under this License. Any attempt otherwise to propagate or
|
||||
modify it is void, and will automatically terminate your rights under
|
||||
this License (including any patent licenses granted under the third
|
||||
paragraph of section 11).
|
||||
|
||||
However, if you cease all violation of this License, then your
|
||||
license from a particular copyright holder is reinstated (a)
|
||||
provisionally, unless and until the copyright holder explicitly and
|
||||
finally terminates your license, and (b) permanently, if the copyright
|
||||
holder fails to notify you of the violation by some reasonable means
|
||||
prior to 60 days after the cessation.
|
||||
|
||||
Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, you do not qualify to receive new licenses for the same
|
||||
material under section 10.
|
||||
|
||||
9. Acceptance Not Required for Having Copies.
|
||||
|
||||
You are not required to accept this License in order to receive or
|
||||
run a copy of the Program. Ancillary propagation of a covered work
|
||||
occurring solely as a consequence of using peer-to-peer transmission
|
||||
to receive a copy likewise does not require acceptance. However,
|
||||
nothing other than this License grants you permission to propagate or
|
||||
modify any covered work. These actions infringe copyright if you do
|
||||
not accept this License. Therefore, by modifying or propagating a
|
||||
covered work, you indicate your acceptance of this License to do so.
|
||||
|
||||
10. Automatic Licensing of Downstream Recipients.
|
||||
|
||||
Each time you convey a covered work, the recipient automatically
|
||||
receives a license from the original licensors, to run, modify and
|
||||
propagate that work, subject to this License. You are not responsible
|
||||
for enforcing compliance by third parties with this License.
|
||||
|
||||
An "entity transaction" is a transaction transferring control of an
|
||||
organization, or substantially all assets of one, or subdividing an
|
||||
organization, or merging organizations. If propagation of a covered
|
||||
work results from an entity transaction, each party to that
|
||||
transaction who receives a copy of the work also receives whatever
|
||||
licenses to the work the party's predecessor in interest had or could
|
||||
give under the previous paragraph, plus a right to possession of the
|
||||
Corresponding Source of the work from the predecessor in interest, if
|
||||
the predecessor has it or can get it with reasonable efforts.
|
||||
|
||||
You may not impose any further restrictions on the exercise of the
|
||||
rights granted or affirmed under this License. For example, you may
|
||||
not impose a license fee, royalty, or other charge for exercise of
|
||||
rights granted under this License, and you may not initiate litigation
|
||||
(including a cross-claim or counterclaim in a lawsuit) alleging that
|
||||
any patent claim is infringed by making, using, selling, offering for
|
||||
sale, or importing the Program or any portion of it.
|
||||
|
||||
11. Patents.
|
||||
|
||||
A "contributor" is a copyright holder who authorizes use under this
|
||||
License of the Program or a work on which the Program is based. The
|
||||
work thus licensed is called the contributor's "contributor version".
|
||||
|
||||
A contributor's "essential patent claims" are all patent claims
|
||||
owned or controlled by the contributor, whether already acquired or
|
||||
hereafter acquired, that would be infringed by some manner, permitted
|
||||
by this License, of making, using, or selling its contributor version,
|
||||
but do not include claims that would be infringed only as a
|
||||
consequence of further modification of the contributor version. For
|
||||
purposes of this definition, "control" includes the right to grant
|
||||
patent sublicenses in a manner consistent with the requirements of
|
||||
this License.
|
||||
|
||||
Each contributor grants you a non-exclusive, worldwide, royalty-free
|
||||
patent license under the contributor's essential patent claims, to
|
||||
make, use, sell, offer for sale, import and otherwise run, modify and
|
||||
propagate the contents of its contributor version.
|
||||
|
||||
In the following three paragraphs, a "patent license" is any express
|
||||
agreement or commitment, however denominated, not to enforce a patent
|
||||
(such as an express permission to practice a patent or covenant not to
|
||||
sue for patent infringement). To "grant" such a patent license to a
|
||||
party means to make such an agreement or commitment not to enforce a
|
||||
patent against the party.
|
||||
|
||||
If you convey a covered work, knowingly relying on a patent license,
|
||||
and the Corresponding Source of the work is not available for anyone
|
||||
to copy, free of charge and under the terms of this License, through a
|
||||
publicly available network server or other readily accessible means,
|
||||
then you must either (1) cause the Corresponding Source to be so
|
||||
available, or (2) arrange to deprive yourself of the benefit of the
|
||||
patent license for this particular work, or (3) arrange, in a manner
|
||||
consistent with the requirements of this License, to extend the patent
|
||||
license to downstream recipients. "Knowingly relying" means you have
|
||||
actual knowledge that, but for the patent license, your conveying the
|
||||
covered work in a country, or your recipient's use of the covered work
|
||||
in a country, would infringe one or more identifiable patents in that
|
||||
country that you have reason to believe are valid.
|
||||
|
||||
If, pursuant to or in connection with a single transaction or
|
||||
arrangement, you convey, or propagate by procuring conveyance of, a
|
||||
covered work, and grant a patent license to some of the parties
|
||||
receiving the covered work authorizing them to use, propagate, modify
|
||||
or convey a specific copy of the covered work, then the patent license
|
||||
you grant is automatically extended to all recipients of the covered
|
||||
work and works based on it.
|
||||
|
||||
A patent license is "discriminatory" if it does not include within
|
||||
the scope of its coverage, prohibits the exercise of, or is
|
||||
conditioned on the non-exercise of one or more of the rights that are
|
||||
specifically granted under this License. You may not convey a covered
|
||||
work if you are a party to an arrangement with a third party that is
|
||||
in the business of distributing software, under which you make payment
|
||||
to the third party based on the extent of your activity of conveying
|
||||
the work, and under which the third party grants, to any of the
|
||||
parties who would receive the covered work from you, a discriminatory
|
||||
patent license (a) in connection with copies of the covered work
|
||||
conveyed by you (or copies made from those copies), or (b) primarily
|
||||
for and in connection with specific products or compilations that
|
||||
contain the covered work, unless you entered into that arrangement,
|
||||
or that patent license was granted, prior to 28 March 2007.
|
||||
|
||||
Nothing in this License shall be construed as excluding or limiting
|
||||
any implied license or other defenses to infringement that may
|
||||
otherwise be available to you under applicable patent law.
|
||||
|
||||
12. No Surrender of Others' Freedom.
|
||||
|
||||
If conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot convey a
|
||||
covered work so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you may
|
||||
not convey it at all. For example, if you agree to terms that obligate you
|
||||
to collect a royalty for further conveying from those to whom you convey
|
||||
the Program, the only way you could satisfy both those terms and this
|
||||
License would be to refrain entirely from conveying the Program.
|
||||
|
||||
13. Use with the GNU Affero General Public License.
|
||||
|
||||
Notwithstanding any other provision of this License, you have
|
||||
permission to link or combine any covered work with a work licensed
|
||||
under version 3 of the GNU Affero General Public License into a single
|
||||
combined work, and to convey the resulting work. The terms of this
|
||||
License will continue to apply to the part which is the covered work,
|
||||
but the special requirements of the GNU Affero General Public License,
|
||||
section 13, concerning interaction through a network will apply to the
|
||||
combination as such.
|
||||
|
||||
14. Revised Versions of this License.
|
||||
|
||||
The Free Software Foundation may publish revised and/or new versions of
|
||||
the GNU General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the
|
||||
Program specifies that a certain numbered version of the GNU General
|
||||
Public License "or any later version" applies to it, you have the
|
||||
option of following the terms and conditions either of that numbered
|
||||
version or of any later version published by the Free Software
|
||||
Foundation. If the Program does not specify a version number of the
|
||||
GNU General Public License, you may choose any version ever published
|
||||
by the Free Software Foundation.
|
||||
|
||||
If the Program specifies that a proxy can decide which future
|
||||
versions of the GNU General Public License can be used, that proxy's
|
||||
public statement of acceptance of a version permanently authorizes you
|
||||
to choose that version for the Program.
|
||||
|
||||
Later license versions may give you additional or different
|
||||
permissions. However, no additional obligations are imposed on any
|
||||
author or copyright holder as a result of your choosing to follow a
|
||||
later version.
|
||||
|
||||
15. Disclaimer of Warranty.
|
||||
|
||||
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
|
||||
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
|
||||
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
|
||||
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
|
||||
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
|
||||
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
|
||||
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
|
||||
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
|
||||
|
||||
16. Limitation of Liability.
|
||||
|
||||
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
|
||||
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
|
||||
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
|
||||
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
|
||||
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
|
||||
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
|
||||
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
|
||||
SUCH DAMAGES.
|
||||
|
||||
17. Interpretation of Sections 15 and 16.
|
||||
|
||||
If the disclaimer of warranty and limitation of liability provided
|
||||
above cannot be given local legal effect according to their terms,
|
||||
reviewing courts shall apply local law that most closely approximates
|
||||
an absolute waiver of all civil liability in connection with the
|
||||
Program, unless a warranty or assumption of liability accompanies a
|
||||
copy of the Program in return for a fee.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
How to Apply These Terms to Your New Programs
|
||||
|
||||
If you develop a new program, and you want it to be of the greatest
|
||||
possible use to the public, the best way to achieve this is to make it
|
||||
free software which everyone can redistribute and change under these terms.
|
||||
|
||||
To do so, attach the following notices to the program. It is safest
|
||||
to attach them to the start of each source file to most effectively
|
||||
state the exclusion of warranty; and each file should have at least
|
||||
the "copyright" line and a pointer to where the full notice is found.
|
||||
|
||||
<one line to give the program's name and a brief idea of what it does.>
|
||||
Copyright (C) <year> <name of author>
|
||||
|
||||
This program is free software: you can redistribute it and/or modify
|
||||
it under the terms of the GNU General Public License as published by
|
||||
the Free Software Foundation, either version 3 of the License, or
|
||||
(at your option) any later version.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program. If not, see <http://www.gnu.org/licenses/>.
|
||||
|
||||
Also add information on how to contact you by electronic and paper mail.
|
||||
|
||||
If the program does terminal interaction, make it output a short
|
||||
notice like this when it starts in an interactive mode:
|
||||
|
||||
<program> Copyright (C) <year> <name of author>
|
||||
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
|
||||
This is free software, and you are welcome to redistribute it
|
||||
under certain conditions; type `show c' for details.
|
||||
|
||||
The hypothetical commands `show w' and `show c' should show the appropriate
|
||||
parts of the General Public License. Of course, your program's commands
|
||||
might be different; for a GUI interface, you would use an "about box".
|
||||
|
||||
You should also get your employer (if you work as a programmer) or school,
|
||||
if any, to sign a "copyright disclaimer" for the program, if necessary.
|
||||
For more information on this, and how to apply and follow the GNU GPL, see
|
||||
<http://www.gnu.org/licenses/>.
|
||||
|
||||
The GNU General Public License does not permit incorporating your program
|
||||
into proprietary programs. If your program is a subroutine library, you
|
||||
may consider it more useful to permit linking proprietary applications with
|
||||
the library. If this is what you want to do, use the GNU Lesser General
|
||||
Public License instead of this License. But first, please read
|
||||
<http://www.gnu.org/philosophy/why-not-lgpl.html>.
|
||||
BIN
rapport/sketch/sketch
Executable file
BIN
rapport/sketch/sketch
Executable file
Binary file not shown.
@ -1,16 +1,16 @@
|
||||
\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
|
||||
ainsi de précharger les parties du modèle qui vont être vues. Cette section
|
||||
présente le travail qui a été réalisé dans le domaine du chargement de modèle.
|
||||
|
||||
\paragraph{}
|
||||
Évidemment, cette partie est celle qui commence après la fin de la première
|
||||
partie : il faut non seulement connaître l'influence des recommandations sur
|
||||
l'utilisateur, ensuite être capable de prévoir le comportement de
|
||||
l'utilisateur, et enfin s'en servir pour précharger les bonnes parties du
|
||||
l'utilisateur, mais aussi être capable de prévoir le comportement de
|
||||
l'utilisateur, et enfin de s'en servir pour précharger les bonnes parties du
|
||||
modèle. Tout ceci n'étant pas encore possible, le travail qui a été fait est
|
||||
nettement plus simpliste : il n'y aura aucune prévision du comportement ici.
|
||||
une version simplifiée : il n'y aura aucune prévision du comportement ici.
|
||||
|
||||
\section*{Introduction}
|
||||
Notre problématique ici est de transférer des modèles 3D sur le réseau. Les
|
||||
@ -18,7 +18,8 @@ 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
|
||||
pour les faces qui vont suivre. Un matériau est notamment défini par
|
||||
ses constantes de reflexions 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
|
||||
@ -64,9 +65,10 @@ Pour avoir une bonne performance, il faut éviter de re-parser les fichiers
|
||||
|
||||
\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).
|
||||
que le chemin permettant d'accéder aux fichiers) 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
|
||||
@ -87,7 +89,7 @@ complètement.
|
||||
\paragraph{}
|
||||
Pour commencer, nous avons donc utilisé \socketio{}, une librairie permettant de
|
||||
gérer les sockets facilement avec JavaScript et Nodejs, pour faire une première
|
||||
version simpliste du streaming : on travaillait sur un modèle ne contenant que
|
||||
version simplifiée du streaming : on travaillait sur un modèle ne contenant que
|
||||
des sommets et des faces (donc pas de textures ni de normales) et le protocole
|
||||
fonctionnait ainsi :
|
||||
|
||||
@ -148,7 +150,7 @@ seront envoyés différemment : on va en fait parcourir les faces directement.
|
||||
\paragraph{}
|
||||
Le serveur va garder en mémoire ce qui a déjà été envoyé et ce qui ne l'a pas
|
||||
été, et envoyer les faces dans l'ordre : si certains éléments des faces n'ont
|
||||
pas encore été envoyé, on les enverra juste avant d'envoyer la face en
|
||||
pas encore été envoyés, on les enverra juste avant d'envoyer la face en
|
||||
question.
|
||||
|
||||
\paragraph{}
|
||||
@ -209,12 +211,20 @@ C'est la dernière version du streaming qui a été faite sur ce projet. À chaq
|
||||
transfert, le client envoie sa position au serveur (ainsi que les plans
|
||||
définissant son \emph{frustum}\footnote{les bords du champ de vision de la
|
||||
caméra}) et le serveur va parcourir les faces du modèle en cherchant celles qui
|
||||
apparaissent dans le \emph{frustum}\footnote{dans cette version, on considère
|
||||
qu'une face apparaît dans le \emph{frsutum} si un de ces sommets y appartient.
|
||||
Évidemment, une face très grande pourrait appraître dans le \emph{frustum}
|
||||
sans qu'aucun de ses sommets n'y soit, mais nous n'avons pas traité ce cas
|
||||
particulier ici.}. On évite ainsi d'envoyer les faces du modèle qui sont
|
||||
derrière la caméra et que l'utilisateur ne voit pas.
|
||||
apparaissent dans le \emph{frustum}. On évite ainsi d'envoyer les faces du
|
||||
modèle qui sont derrière la caméra et que l'utilisateur ne voit pas.
|
||||
\begin{figure}[H]
|
||||
\centering
|
||||
\include{build/frustum}
|
||||
\caption{Le frustum de la camera et différents objets\label{frustum-draw}}
|
||||
\end{figure}
|
||||
|
||||
Dans cette version, on considère qu'une face apparaît dans le \emph{frustum} si
|
||||
un de ses sommets y appartient. Évidemment, une face très grande pourrait
|
||||
appraître dans le \emph{frustum} sans qu'aucun de ses sommets n'y soit, mais
|
||||
nous n'avons pas traité ce cas particulier ici (dans la figure
|
||||
\ref{frustum-draw}, seuls les triangles verts et bleus seront envoyés, bien que
|
||||
le triangle rouge devrait être envoyé lui aussi).
|
||||
|
||||
\paragraph{}
|
||||
Bien sûr, s'il n'y a plus de faces dans le \emph{frustum} de la caméra, on va
|
||||
|
||||
@ -11,9 +11,9 @@ Pour le côté client, il y avait plusieurs possibilités :
|
||||
\begin{itemize}
|
||||
\item WebGL, la spécification des fonctions permettant la 3D dans le
|
||||
navigateur
|
||||
\item Une librairie facilitant l'utilisation de WebGL
|
||||
\item Du code C++ compilé en JavaScript grâce à Emscripten
|
||||
\item N'importe quel moteur graphique qui puisse exporter vers JavaScript
|
||||
\item Une librairie JavaScript facilitant l'utilisation de WebGL
|
||||
\end{itemize}
|
||||
|
||||
\subsection{WebGL}
|
||||
@ -22,16 +22,23 @@ 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.
|
||||
complexe. La contrepartie de WebGL est que toutes les fonctions élémentaires
|
||||
sont disponibles, et donc, il n'y a pas de limite imposée par un framework :
|
||||
tout devient possible, mais il faut le faire soi-même.
|
||||
|
||||
\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
|
||||
inconvénients : comme WebGL ne supporte que OpenGL ES, il faut rédiger 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{}
|
||||
Cette technique permet de bénéficier des performances (à l'exécution) du C++,
|
||||
et est très utile notamment dans le cas de portage de programmes déjà
|
||||
existants.
|
||||
|
||||
\paragraph{}
|
||||
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
|
||||
@ -43,6 +50,13 @@ long.
|
||||
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.
|
||||
|
||||
\paragraph{}
|
||||
Le principal avantage d'utiliser un moteur graphique est qu'il permet d'avoir
|
||||
de très bons rendus assez facilement : toute la partie complexe du rendu est
|
||||
déjà implémentée.
|
||||
|
||||
\paragraph{}
|
||||
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
|
||||
@ -62,25 +76,40 @@ pour Google Chrome et Firefox, les autres navigateurs ne sont donc pas
|
||||
\paragraph{}
|
||||
Dans un premier temps, seul le côté client était pris en compte. Les programmes
|
||||
étaient écrits en JavaScript et ne nécessitaient pas de serveur. Quand les
|
||||
problématiques de dynamicité sont arrivées, il a fallu choisir une technologie
|
||||
pour le côté serveur, et là, tous les langages étaient possibles.
|
||||
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
|
||||
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.
|
||||
|
||||
\paragraph{}
|
||||
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).
|
||||
Plusieurs langages et framework ont été testée :
|
||||
\begin{itemize}
|
||||
\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.
|
||||
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
|
||||
dans un langage un peu plus confortable.
|
||||
\item Django (framework web en python) : très pratique, notamment pour des
|
||||
grosses applications, mais il a l'inconvénient d'être assez coûteux en
|
||||
mémoire vive (à ce moment, le serveur était hébergé sur une machine qui
|
||||
n'avait que 512 Mo de mémoire vive, et les temps de génération des
|
||||
réponses était de l'ordre de la dizaine de secondes).
|
||||
\item \nodejs{} : permet d'écrire le code serveur en JavaScript. Il est un
|
||||
peu moins pratique que Django (même si avec un peu de travail, on
|
||||
arrive à obtenir une architecture y ressemblant), mais il a l'avantage
|
||||
d'être très utilisé, et il existe donc de nombreuses librairies qu'on
|
||||
peut y ajouter.
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{}
|
||||
Quand les problématiques de streaming ont commencé à apparaître, nous avons
|
||||
choisi la simplicité en utilisant Node.js pour le côté serveur (un serveur
|
||||
écrit en JavaScript) à cause de la présence d'une librairie nommée \socketio{}
|
||||
qui s'avère très pratique pour la communication entre le client et le serveur.
|
||||
Pour des raisons pratiques, le serveur a été herbergé sur un cloud gratuit
|
||||
(OpenShift).
|
||||
J'ai fini par choisir \nodejs{}, notamment pour l'existance d'une librairie
|
||||
nommée \socketio{}, qui permet l'utilisation facile des sockets (côté serveur,
|
||||
et côté client, c'est-à-dire les WebSockets du navigateur web). Pour des
|
||||
raisons pratiques, le serveur a été herbergé sur un cloud gratuit (OpenShift).
|
||||
|
||||
\section{Base de données}
|
||||
\paragraph{}
|
||||
@ -89,6 +118,7 @@ est libre et qui a largement fait ses preuves). OpenShift propose d'héberger
|
||||
lui-même la base de données, mais la version gratuite ne proposant qu'1 Go
|
||||
d'espace de stockage, nous avons préféré l'héberger nous-même.
|
||||
|
||||
\newpage
|
||||
\section{Développement, debug et déploiement}
|
||||
\paragraph{}
|
||||
Pour éviter d'avoir des fichiers trop longs, nous avons choisi de séparer les
|
||||
@ -109,7 +139,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{repositories} :
|
||||
deux \emph{dépôts} :
|
||||
\begin{itemize}
|
||||
\item le premier, hébergé sur
|
||||
\href{https://github.com/tforgione/3dinterface}{Github}, sert au
|
||||
@ -117,7 +147,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
|
||||
modifications sont propagés jusqu'à celui-ci.
|
||||
modifications sont propagéés jusqu'à celui-ci.
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{}
|
||||
@ -125,12 +155,11 @@ 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}
|
||||
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
|
||||
Github permet la création de Wiki pour chaque \emph{dépôt} et nous nous en
|
||||
sommes servi pour de la documentation de haut niveau : il ne présente que des
|
||||
aspects théoriques de ce qui a été réalisé pendant ce projet.
|
||||
|
||||
@ -140,6 +169,7 @@ 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.
|
||||
|
||||
\newpage
|
||||
\section{Familiarisation}
|
||||
Pour me familiariser avec les technologies et librairies, j'ai développé
|
||||
quelques applications simples.
|
||||
|
||||
@ -1,13 +1,12 @@
|
||||
\part{L'étude utilisateur}
|
||||
\part{Évaluation des interfaces\label{userstudy}}
|
||||
\paragraph{}
|
||||
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.
|
||||
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.
|
||||
|
||||
\paragraph{}
|
||||
Pour palier à ce problème, nous avons ajouter des \emph{pièces} à chercher dans
|
||||
Pour palier à ce problème, nous avons ajouté 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.
|
||||
|
||||
@ -18,10 +17,13 @@ toutes les pièces rouges, il aura parcouru l'intégralité de la scène.
|
||||
\end{figure}
|
||||
|
||||
\paragraph{}
|
||||
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.
|
||||
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
|
||||
détaillé dans la section \ref{coins}).
|
||||
|
||||
\section{Déroulement de l'expérience}
|
||||
\subsection{Première page}
|
||||
@ -32,22 +34,21 @@ 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 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 vidéo).
|
||||
Nous leur demandons notamment de noter leurs capacités en terme de jeux vidéos
|
||||
(entre 1 et 5 étoiles).
|
||||
|
||||
\subsection{Tutoriel}
|
||||
Ensuite, nous demandons à l'utilisateur de suivre un tutoriel : c'est une sorte
|
||||
de réelle expérience 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 l'interface.
|
||||
l'utilisateur (nous avons fait l'hypothèse que la capacité des utilisateurs à
|
||||
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
|
||||
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
|
||||
l'interface.
|
||||
|
||||
\subsection{Les trois vraies expériences}
|
||||
C'est ensuite que la \emph{vraie} partie de l'étude utilisateur commence : à 3
|
||||
reprises, l'utilisateur va se retrouver dans une scène avec certaines pièces
|
||||
reprises, l'utilisateur doit remplir dans une scène avec certaines pièces
|
||||
rouges à trouver, et un certain style de recommandations\footnote{aucune
|
||||
recommandation sera considéré comme un style de recommandation, de sorte à
|
||||
comparer la présence à l'absence de recommandation pour la navigation} pour
|
||||
@ -61,7 +62,8 @@ l'utilisateur aura trouvé les huit pièces rouges, soit une minute après avoir
|
||||
trouvé la 6\up{ème} pièce rouge. Pour éviter que l'utilisateur soit
|
||||
\emph{frustré} de ne pas avoir trouvé toutes les pièces, nous n'indiquons pas
|
||||
clairement le nombre de pièces qu'il a, ou qu'il lui reste à trouver.
|
||||
Simplement, une \emph{vague} idée de sa progression.
|
||||
Simplement, une \emph{vague} idée de sa progression (voir figure
|
||||
\ref{interface-schema} - élément 6).
|
||||
|
||||
\subsection{Le \emph{feedback}}
|
||||
Après avoir fini ces expériences, l'utilisateur se retrouvera sur un formulaire
|
||||
@ -79,26 +81,49 @@ styles de recommandations différents pour des utilisateurs de même niveau de
|
||||
sorte à pouvoir comparer l'efficacité des recommandations.
|
||||
|
||||
\paragraph{}
|
||||
Nous cherchons en fait des expériences qui permettraient de compléter les trio
|
||||
d'expériences avec des pièces identiques sur des scènes identiques mais avec
|
||||
des styles de recomendations différents. Si une telle expérience n'existe pas
|
||||
(les trios sont déjà complets, ou bien il n'existe pas d'expérience pour un
|
||||
niveau d'utilisateur donné), la scène, ainsi que les pièces à trouver et le
|
||||
style de recommandations seront choisi aléatoirement : on choisira une scène et
|
||||
un style de recommandations que l'utilisateur n'a pas encore effectué, et on
|
||||
choisira 8 pièces aléatoirement parmi les positions possibles que nous avons
|
||||
fixées au préalable.
|
||||
Parmi les paramètres qui varient, nous avons :
|
||||
\begin{itemize}
|
||||
\item le niveau du joueur
|
||||
\item la scène
|
||||
\item la disposition des pièces rouges
|
||||
\item le type de recommandations
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Positions possibles des pièces}
|
||||
Pour choisir les positions possibles des pièces dans chaque scène, un petit
|
||||
outil à été développé permettant de se déplacer dans une scène et des créer des
|
||||
pièces en cliquant. Cliquer sur une paroie de la scène crée une pièce devant
|
||||
cette paroie, et cliquer sur une pièce la supprime. Un bouton permet d'envoyer
|
||||
la liste des pièces par mail, lorsque l'on a fini de créer des pièces.
|
||||
\paragraph{}
|
||||
Le système que nous avons fait cherche les joueurs qui ont le même niveau pour
|
||||
leur donner les mêmes scènes avec la même disposition de pièces mais avec des
|
||||
styles de recommandations différents, de sorte à pouvoir les comparer.
|
||||
|
||||
\subsection{Positions possibles des pièces\label{coins}}
|
||||
Pour choisir les positions possibles des pièces dans chaque scène, trois outils
|
||||
ont été développés.
|
||||
|
||||
\subsubsection{Coin-creator}
|
||||
Cette interface permet de naviguer dans une des scènes possibles, et de cliquer
|
||||
sur une paroi pour créer une pièce. Cliquer sur un pièce la détruit, et un
|
||||
bouton permet d'envoyer les pièces par mail à mon adresse.
|
||||
|
||||
\paragraph{}
|
||||
J'ai ainsi envoyé ce mail aux encadrants qui ont eux même pu créer les pièces,
|
||||
et j'ai ensuite fait un programme qui rassemble les pièces et élimine les
|
||||
pièces trop proches les unes des autres.
|
||||
|
||||
\subsubsection{Coin-editor}
|
||||
Cette interface a été conçue pour corriger les imprécisions provenant de
|
||||
l'interface décrite précédemment. En effet, parfois, une pièce peut intersecter
|
||||
un mur. Coin-editor permet de cliquer sur une pièce pour pouvoir accéder à ses
|
||||
propriétés depuis la console JavaScript, et modifier sa position, puis renvoyer
|
||||
un mail avec les positions corrigées.
|
||||
|
||||
\subsubsection{Coin-checker}
|
||||
Cette interface a été conçue lorsque nous nous sommes aperçus que certaines
|
||||
pièces étaient passées de l'autre côté du modèle. Il était ainsi difficile de
|
||||
les trouver et cette interface permet de chercher les pièces parmi toutes
|
||||
celles qui existent. On peut cliquer sur les pièces pour les récupérer et un
|
||||
compteur indique le nombre de pièces restantes.
|
||||
|
||||
\section{Collecte des informations}
|
||||
Ces expérienes n'auront d'interêt que si nous sommes capables de les analyser
|
||||
Ces expériences n'auront d'interêt que si nous sommes capables de les analyser
|
||||
par la suite et de comprendre comment les utilisateurs interagissent avec les
|
||||
recommandations. Nous avons donc mis en place un système de collecte des
|
||||
actions de l'utilisateur basé sur les XmlHttpRequests de JavaScript.
|
||||
@ -106,7 +131,7 @@ actions de l'utilisateur basé sur les XmlHttpRequests de JavaScript.
|
||||
Côté serveur, il y a quelques urls qui permettent d'enregistrer des
|
||||
informations dans des tables prévues à cet effet. Chaque évènement contient la
|
||||
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 cerniers sont stockés dans
|
||||
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,
|
||||
@ -117,9 +142,12 @@ accompagné de l'id de la recommandation cliquée.
|
||||
\paragraph{KeyboardEvent} : crée 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}, on créera de temps en temps
|
||||
quelques évènements de type \texttt{KeyboardEvent} non associée à une touche de
|
||||
sorte à connaître l'angle de la caméra.
|
||||
\emph{drag-n-drop} ou du \emph{pointer lock}, aucun évènement (autre que les
|
||||
\emph{mouse-move} qui ne sont pas stockés en base de données parce qu'ils sont
|
||||
trop nombreux) n'est envoyé. Ainsi, pendant toute la durée du mouvement de
|
||||
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
|
||||
la caméra.
|
||||
@ -154,12 +182,12 @@ Pour le replay, nous avons simplement considéré les évènements
|
||||
n'ayant pas d'influence sur la position de la caméra.
|
||||
|
||||
\paragraph{}
|
||||
La génération du chemin de la caméra est fait de manière assez simpliste. En
|
||||
La génération du chemin de la caméra est faite de manière assez simpliste. En
|
||||
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.a
|
||||
comme pour le suivi des recommandations lors d'une expérience.
|
||||
|
||||
\section{Analyse des résultats}
|
||||
% TODO analyser les résultats
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user