166 lines
8.2 KiB
TeX
166 lines
8.2 KiB
TeX
\part{Choix des technologies et prise en main}
|
|
\paragraph{}
|
|
La première phase de stage était de choisir les technologies qui allaient être
|
|
utilisées par la suite. Nous cherchions des technologies permettant la
|
|
visualisation 3D sur un navigateur web afin de pouvoir faire une étude
|
|
utilisateur simplement.
|
|
|
|
\section{Côté client}
|
|
\paragraph{}
|
|
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
|
|
\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{}
|
|
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
|
|
pour Google Chrome et Firefox, les autres navigateurs ne sont donc pas
|
|
(officiellement) supportés.
|
|
|
|
\section{Côté serveur}
|
|
\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.
|
|
|
|
\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).
|
|
|
|
\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).
|
|
|
|
\section{Base de données}
|
|
\paragraph{}
|
|
Pour le système de gestion de base de données, nous avons choisi Postgres (qui
|
|
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.
|
|
|
|
\section{Développement, debug et déploiement}
|
|
\paragraph{}
|
|
Pour éviter d'avoir des fichiers trop longs, nous avons choisi de séparer les
|
|
sources dans de nombreux fichiers de taille plus petite, et de les fusionner
|
|
automatiquement. Pour le développement, ils seront simplement concaténés grâce
|
|
à un script développé spécialement pour cela, qui mime les paramètres de
|
|
Closure Compiler qui sera utilisé pour la fusion au moment du le déploiement
|
|
(ce dernier permet non seulement la fusion des fichiers mais aussi la
|
|
minification\footnote{la minification sert notamment à réduire la taille du
|
|
script : n'oublions pas que nous parlons de serveur web, et il est donc
|
|
intéressant de réduire la taille des programmes de sorte à les charger plus
|
|
rapidement} (effacement des commentaires et des retours à la ligne,
|
|
simplifications des noms de variables et plus \footnote{en JavaScript, il est
|
|
plus court d'écrire \texttt{!0} pour \texttt{true} par exemple.}). Pour le
|
|
développement, on a utilisé \href{https://github.com/remy/nodemon}{nodemon} et
|
|
inotify, qui permettent de relancer le serveur local lorsqu'une modification
|
|
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} :
|
|
\begin{itemize}
|
|
\item le premier, hébergé sur
|
|
\href{https://github.com/tforgione/3dinterface}{Github}, sert au
|
|
développement, et contient les fichiers fractionnés ainsi que les
|
|
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.
|
|
\end{itemize}
|
|
|
|
\paragraph{}
|
|
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
|
|
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.
|
|
|
|
\subsection{\href{http://l3d.no-ip.org/}{L3D}}
|
|
Pour de la documentation de plus bas niveau (comment chaque classe ou méthode
|
|
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}.
|
|
|