169 lines
12 KiB
TeX
169 lines
12 KiB
TeX
\section{Évaluation}\label{fr:eval}
|
|
|
|
Nous décrivons maintenant notre installation et les données que nous utilisons dans nos expériences. Nous présentons une évaluation de notre système et une comparaison de l'impact des choix de conception que nous avons introduit dans les sections précédentes.
|
|
|
|
\subsection{Installation expérimentale}
|
|
|
|
\paragraph{Modèle}
|
|
Dans nos expériences, nous utilisons un modèle du quartier de Marina Bay à Singapour. Le modèle contient 387.551 sommets et 552.118 faces. La géométrie occupe 62 MO et les textures en occupent 167. Nous partitionnons la géométrie dans un \emph{$k$-d tree} jusqu'à ce que les feuilles contiennent moins de 10.000 faces, ce qui nous donne 64 \emph{adaptation sets}, plus un pour les grandes faces.
|
|
|
|
\paragraph{Navigation des utilisateurs}
|
|
Pour évaluer notre système, nous avons collecté des traces d'utilisateurs réalistes que nous pouvons rejouer.
|
|
|
|
Nous avons présenté notre interface web à six utilisateurs, sur laquelle le modèle se chargeait progressivement pendant que l'utilisateur pouvait naviguer. Les interactions disponibles sont inspirées des jeux vidéos à la première personne (le clavier pour se déplacer et la souris pour tourner). Nous avons demandé aux utilisateurs de naviguer et d'explorer la scène jusqu'à ce qu'ils estiment avoir visité les régions les plus importantes. Nous leur avons ensuite demandé d'enregistrer un chemin qui donnerait une bonne présentation de la scène à un utilisateur qui voudrait la découvrir.
|
|
Toutes les 100 ms, la position et l'angle de la caméra sont enregistrées dans un tableau qui sera ensuite exporté au format JSON\@. Les traces enregistrées nous permettent de rejouer chaque enregistrement et d'effectuer les simulations et évaluations de notre système. Nous avons ainsi collecté 13 enregistrements.
|
|
|
|
\paragraph{Configuration du réseau}
|
|
Nous avons testé notre implémentation sous trois débits de 2.5 Mbps, 5 Mbps et 10 Mbps avec un temps aller-retour de 76 ms, en suivant les paramètres de~\citep{dash-network-profiles}. Les valeurs restent constantes pendant toute la durée de la session pour analyser les variations de performance en fonction du débit.
|
|
|
|
|
|
Dans nos expériences, nous créons une caméra virtuelle qui suit un enregistrement, et notre système télécharge les segments en temps réel selon l'algorithme~\ref{fr:nextsegment}. Nous enregistrons dans un fichier JSON les moments où les segments sont requêtés et reçus. En faisant ainsi, nous évitons de gaspiller le temps et les ressources nécessaires à l'évaluation du système pendant que les segments sont en train d'être téléchargés et aux stockage des informations nécessaires pour tracer les courbes présentées dans les prochaines sections.
|
|
|
|
\paragraph{Machines et logiciels}
|
|
Les expériences ont été lancées sur un Acer Aspire V3, avec un processeur Intel Core i7 3632QM et une carte graphique NVIDIA GeForce GT 740M. Le client DASH est écrit en Rust, et utilise Glium pour le rendu et reqwest pour le téléchargement des segments.
|
|
|
|
\paragraph{Métriques}
|
|
Pour mesurer objectivement la qualité du rendu, nous utilisons le PSNR\@. La scène rendue a posteriori en utilisant les mêmes chemins mais en ayant téléchargé toute la géométrie et les textures est utilisée comme vérité terrain. Dans notre cas, une erreur de pixel ne peut arriver que lorsqu'une face est manquante ou quand une texture est manquante ou à une résolution trop faible.
|
|
|
|
\paragraph{Expériences}
|
|
Nous présentons des expériences qui valident nos choix d'implémentation à chaque étape de notre système. Nous rejouons les chemins créés par les utilisateurs avec différentes conditions de débit tout en variant les composants clés de notre système.
|
|
|
|
Nous considérons deux stratégies de chargement appliquées à notre client, proposées dans la Section~\ref{fr:dashclientspec}. La stratégie gloutonne détermine, à chaque décision, le segment qui maximise l'utilité prédite du segment au moment de son arrivée, ce qui correspond à l'équation~(\ref{fr:greedy}). La deuxième stratégie de chargement que nous testons est celle proposée dans l'équation~(\ref{fr:smart}). Nous avons aussi analysé l'impact du groupement des faces dans les segments de géométrie en fonction de leur aire.
|
|
Enfin, nous testons différents paramètres de débit pour étudier comment notre système s'adapte à des conditions de réseau différentes.
|
|
|
|
\begin{table}
|
|
\centering
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\begin{tabular}{@{}ll@{}}
|
|
\toprule
|
|
Paramètres & Valeurs \\\midrule
|
|
Utilité & Statique, Dynamique, Combinée \\
|
|
Stratégie & Gloutonne, Proposée \\
|
|
Segments & Triés par aire, non triés\\
|
|
Bande passante & 2.5 Mbps, 5 Mbps, 10 Mbps \\\bottomrule
|
|
\end{tabular}
|
|
\caption{Paramètres de nos expériences\label{table:experiments}}
|
|
\end{table}
|
|
|
|
|
|
\subsection{Résultats expérimentaux}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{tikzpicture}
|
|
\begin{axis}[
|
|
xlabel=Temps (en s),
|
|
ylabel=PSNR,
|
|
no markers,
|
|
cycle list name=mystyle,
|
|
width=\tikzwidth,
|
|
height=\tikzheight,
|
|
legend pos=south east,
|
|
xmin=0,
|
|
xmax=90,
|
|
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
|
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
|
]
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
|
\addlegendentry{\scriptsize Combinée}
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/3/curve.dat};
|
|
\addlegendentry{\scriptsize Statique}
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/4/curve.dat};
|
|
\addlegendentry{\scriptsize Dynamique}
|
|
\end{axis}
|
|
\end{tikzpicture}
|
|
\caption{Impact de l'utilité des segments de géométrie sur le rendu à une débit de 5 Mbps.\label{fr:utility}}
|
|
\end{figure}
|
|
|
|
La Figure~\ref{fr:utility} montre comment la métrique d'utilité peut exploiter les paramètres statiques et dynamiques. Les expériences utilisent un \emph{$k$-d tree} et la politique de chargement proposée, sur tous les chemins. On observe qu'une métrique d'utilité purement statique donne des mauvais PSNR\@. Une utilité purement dynamique donne des résultats légèrement meilleurs, notamment grâce a l'élimination des parties à l'extérieur du champ de vision, mais la version combinée décrite dans la Section~\ref{fr:utility} donne les meilleurs résultats.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{tikzpicture}
|
|
\begin{axis}[
|
|
xlabel=Time (in s),
|
|
ylabel=PSNR,
|
|
no markers,
|
|
cycle list name=mystyle,
|
|
width=\tikzwidth,
|
|
height=\tikzheight,
|
|
legend pos=south east,
|
|
xmin=0,
|
|
xmax=90,
|
|
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
|
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
|
]
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
|
\addlegendentry{\scriptsize Tri des faces par aires}
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/5/curve.dat};
|
|
\addlegendentry{\scriptsize Pas de tri des faces}
|
|
\end{axis}
|
|
\end{tikzpicture}
|
|
\caption{Impact du tri des faces dans les segments à un débit de 5 Mbps}\label{fr:sorting}
|
|
\end{figure}
|
|
|
|
La Figure~\ref{fr:sorting} montre l'impact de l'arrangement des polygones dans les segments en fonction de leur aire. Il est clair que le PSNR augmente considérablement lorsque l'aire des faces est prise en compte lors de la création des segments. Puisque les segments ont tous la même taille (en octets), trier les faces par aire avant de les ranger dans les segments introduit une asymétrie dans la distribution des aires. Cette asymétrie permet au client de prendre des décisions (télécharger les segments avec la plus grande utilité) et peut créer une grande différence en terme de qualité de rendu.
|
|
|
|
Nous avons aussi comparé l'approche gloutonne et celle proposée (voir Figure~\ref{fr:greedyweakness}) pour un débit limitée (5 Mbps). La méthode proposée est meilleure sur les 30 premières secondes et fait mieux en moyenne. La Table~\ref{fr:greedyVsproposed} montre le PSNR moyen pour les deux méthodes pour différents débits. C'est sur les 30 premières secondes que les décisions sont cruciales puisqu'elles correspondent aux moments où peu de contenu a été téléchargé. Nous observons que notre méthode augmente la qualité du rendu entre 1 et 1.9 dB par rapport à l'approche gloutonne.
|
|
|
|
La Table~\ref{fr:perc} montre la distribution des textures téléchargées par les deux approches, à différents débits. La résolution 5 est la plus détaillée, et la résolution 1 la plus grossière. Cette table met en évidence une faiblesse de la politique gloutonne : quand le débit augmente, la distribution des résolutions téléchargées reste plus ou moins la même. En revanche, notre politique s'adapte en téléchargeant des plus hautes résolutions quand le débit est meilleur (13.9\% à 10 Mbps contre 0.3\% à 2.5 Mbps). En fait, une propriété intéressante de la politique proposée est qu'elle adapte le compromis géométrie-texture au débit. Les textures représentent 57.3\% des octets téléchargés à 2.5 Mbps, et 70.2\% à 10 Mbps. En d'autres termes, notre système tend à favoriser la géométrie quand le débit est faible, et favoriser les textures quand le débit augmente.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\begin{tikzpicture}
|
|
\begin{axis}[
|
|
xlabel=Time (in s),
|
|
ylabel=PSNR,
|
|
no markers,
|
|
cycle list name=mystyle,
|
|
width=\tikzwidth,
|
|
height=\tikzheight,
|
|
legend pos=south east,
|
|
xmin=0,
|
|
xmax=90,
|
|
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
|
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
|
]
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
|
\addlegendentry{\scriptsize Proposé}
|
|
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/6/curve.dat};
|
|
\addlegendentry{\scriptsize Glouton}
|
|
\end{axis}
|
|
\end{tikzpicture}
|
|
\caption{Impact de la politique de chargement (glouton vs proposé) à un débit de 5 Mbps}\label{fr:greedyweakness}
|
|
\end{figure}
|
|
|
|
\begin{table}
|
|
\centering
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\begin{tabular}{@{}p{1.9cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}@{}}
|
|
\toprule
|
|
\multirow{2}{1.7cm}{} & \multicolumn{3}{c}{\textbf{Premières 30s}} & \multicolumn{3}{c}{\textbf{Globalement}}\\
|
|
% \hline
|
|
% \textbf{Inactive Modes} & \textbf{Description}\\
|
|
\cline{2-7}
|
|
BP (Mbps) & 2.5 & 5 & 10 & 2.5 & 5 & 10 \\
|
|
\midrule
|
|
Glouton & 14.4 & 19.4 & 22.1 & 19.8 & 26.9 & 29.7 \\
|
|
Proposé & 16.3 & 20.4 & 23.2 & 23.8 & 28.2 & 31.1 \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\caption{PSNR moyens, Glouton vs Proposé\label{fr:greedyVsproposed}}
|
|
\end{table}
|
|
|
|
\begin{table}
|
|
\centering
|
|
\renewcommand{\arraystretch}{1.2}
|
|
\begin{tabular}{@{}cccc@{}}
|
|
Résolution & 2.5 Mbps & 5 Mbps & 10 Mbps \\
|
|
\toprule
|
|
1 & 5.7\% vs 1.4\% & 6.3\% vs 1.4\% & 6.17\% vs 1.4\% \\
|
|
2 & 10.9\% vs 8.6\% & 13.3\% vs 7.8\% & 14.0\% vs 8.3\%\\
|
|
3 & 15.3\% vs 28.6\% & 20.1\% vs 24.3\% & 20.9\% vs 22.5\% \\
|
|
4 & 14.6\% vs 18.4\% & 14.4\% vs 25.2\% & 14.2\% vs 24.1\% \\
|
|
5 & 11.4\% vs 0.3\% & 11.1\% vs 5.9\% & 11.5\% vs 13.9\% \\\bottomrule
|
|
\end{tabular}
|
|
\caption{Pourcentage d'octets téléchargés pour chaque résolution de texture, pour la politique gloutonne (gauche) et pour celle proposée (droite) \label{fr:perc}}
|
|
\end{table}
|
|
|