Update

src/config.sty

@@ -1,3 +1,4 @@
+\usepackage{geometry}
 \usepackage{natbib}
 \bibliographystyle{abbrvnat}
 \setcitestyle{authoryear,open={[},close={]},citesep={,}}
@@ -8,6 +9,7 @@
     urlcolor  = blue,
     citecolor = blue,
 anchorcolor = blue]{hyperref}
+\usepackage{scrlayer-scrpage}
 \usepackage{amssymb}
 \usepackage{xspace}
 \usepackage{url}
@@ -25,6 +27,13 @@ anchorcolor = blue]{hyperref}
 \usepackage{setspace}
 \onehalfspacing{}
 
+\usepackage{enumitem}
+\setitemize{noitemsep,topsep=4pt,parsep=4pt,partopsep=0pt}
+
+\pagestyle{scrheadings}
+\refoot[]{Version built on \today{} at \currenttime{}}
+\lofoot[]{Version built on \today{} at \currenttime{}}
+
 \usepackage{tikz}
 \usetikzlibrary{shadows}
 \usetikzlibrary{arrows.meta}
@@ -47,6 +56,12 @@ anchorcolor = blue]{hyperref}
   }
 }
 
+\geometry{%
+    top=3cm,
+    bottom=4cm,
+    left=3cm,
+    right=3cm
+}
 
 \addtokomafont{chapterprefix}{\raggedleft}
 \addtokomafont{chapter}{\fontsize{30}{38}\selectfont}

src/dash-3d/conclusion.tex

@@ -6,7 +6,7 @@ The answer is \emph{yes}.
 In answering this question, we contributed by showing how to organize a polygon soup and its textures into a DASH-compliant format that (i) includes a minimal amount of metadata that is useful for the client, (ii) organizes the data to allow the client to get the most useful content first.
 We further show that these metadata that is precomputed offline is sufficient to design and build a DASH client that is adaptive --- it can selectively download segments within its view, make intelligent decisions about what to download, balancing between geometry and texture while being adaptive to network bandwidth.
 \fresh{}
-This way, our system answers, at least partially, all the open problems we mentionned in~\ref{i:challenges}.
+This way, our system answers, at least partially, all the open problems we mentioned in~\ref{i:challenges}.
 
 \begin{itemize}
     \item \textbf{It prepares and structures the content in a way that enables streaming}: all this preparation is precomputed, and all the content is structured, even materials and textures. Furthermore, textures are prepared in a multi-resolution manner, and even though multi-resolution geometry is not discussed here, the difficulty of integrating it in this system seem moderated: we could encode levels of detail in different representations and define a utility metric for each representation and the system should adapt naturally.

src/dash-3d/introduction.tex

@@ -1,7 +1,7 @@
 \fresh{}
 \section{Introduction}
 
-In this chapter, we take a little step back from interaction and propose a system with very basic interaction but that answers most of the open problems mentionned in Section~\ref{i:challenges}.
+In this chapter, we take a little step back from interaction and propose a system with very basic interaction but that answers most of the open problems mentioned in Section~\ref{i:challenges}.
 We take massive inspiration from video streaming, since we have seen in Section~\ref{i:video-vs-3d} how related video streaming and 3D streaming are and how DASH, the standard for video streaming, is so efficient in Section~\ref{sote:dash}.
 DASH is based on content preparation and structuring which helps not only the streaming policies that rely on it but also the performance of the system since it removes completely the load on the server side.
 A DASH client is simply a client that downloads the structure of the content, and then, depending on its needs, decide what to download by itself.

src/introduction/challenges.tex

@@ -8,7 +8,7 @@ A 3D streaming client has lots of tasks to accomplish:
 \begin{itemize}
     \item render a scene;
     \item find out what to download and download it;
-    \item parse the result of the download;
+    \item parse the downloaded content;
     \item add the parsed result to the scene;
     \item manage the interaction with the user.
 \end{itemize}
@@ -29,15 +29,17 @@ An open question of this thesis is \emph{how do we determine how useful is a chu
 
 \subsection{Streaming policies}
 Rating the chunks is not enough, there are other contextual parameters that need to be taken into account, such as the size of a chunk, the bandwidth, the user's behaviour, etc\ldots.
-Another question that raises from this is \emph{how do we take into the context into account to decide what chunks to download?}
+Another question that raises from this is \emph{how do we take into the context into account to decide which chunks to download?}
 
 \subsection{Evaluation}
-All the problems mentionned earlier yield many ideas and solutions with different parameters.
-We need to answer \emph{how can we compare streaming policies and evalute the impact of their parameters in terms of quality of service and quality of exeperience?}
+In such systems, the two most important criteria for evaluation are quality of service, and quality of experience.
+The quality of service is a network-centric metric, which considers values such as throughput.
+The quality of experience is a user-centric metric, and can only be measured by asking how users feel about a system.
+To be able to know which streaming policies, we need to know \emph{how can we compare streaming policies and evalute the impact of their parameters in terms of quality of service and quality of experience?}
 
 \subsection{Implementation}
-The objective of our work is to setup a client-server architecture that answers the problems mentionned earlier (content preparation, chunk utility, streaming policies).
-In this regard, we have to find out \emph{how do we build this architecture while keeping the computational load on the server low so it can scale, the client efficient so that it has resources to perform its many tasks, and in a way that allow easy deployment of user studies and simulations?}
+The objective of our work is to setup a client-server architecture that answers the problems mentioned earlier (content preparation, chunk utility, streaming policies).
+In this regard, we have to find out \emph{how do we build this architecture while keeping the computational load on the server low so it can scale and the client efficient so that it has resources to perform its many tasks?}
 
 % This implementation must respect constraints required for performant software:
 %

src/introduction/outline.tex

@@ -4,20 +4,20 @@ First, in Chapter~\ref{f}, we give some preliminary information required to unde
 We then proceed to compare 3D and video content: surprisingly, video and 3D share many problems, and analysing them gives inspiration for building a 3D streaming system.
 
 In Chapter~\ref{sote}, we present a review of the state of the art on the fields that we are interesting in.
-This chapter start by analysing the standards of video streaming.
+This chapter starts with an analysis of the video streaming standards.
 Then it reviews the different manners of performing 3D streaming.
 The last section of this chapter focuses on 3D interaction.
 
-Then, in Chapter~\ref{bi}, we present our first contribution: an in depth analysis of the impact of the UI on navigation and streaming in a 3D scene.
+Then, in Chapter~\ref{bi}, we present our first contribution: an in-depth analysis of the impact of the UI on navigation and streaming in a 3D scene.
 We first develop a basic interface for navigating in 3D and we introduce 3D objects called \emph{bookmarks} that help users navigate in the scene.
 We then present a user study that we conducted on 50 people that shows that bookmarks have a great impact on how easy it is for a user to perform tasks such as finding objects.
-Then, we setup a basic 3D streaming system that allows us to replay the traces collected during the user study and simulate 3D streaming at the same time.
+% Then, we setup a basic 3D streaming system that allows us to replay the traces collected during the user study and simulate 3D streaming at the same time.
 Finally, we analyse how the presence of bookmarks impacts the streaming, and we propose and evaluate a few streaming policies that rely on precomputations that can be made thanks to bookmarks and that can increase the quality of experience.
 
 In Chapter~\ref{d3}, we present the most important contribution of this thesis: DASH-3D.
-DASH-3D is an adaptation of the DASH standard for 3D streaming.
-We first describe how we adapt the concepts of DASH to 3D content, including the segmentation of content in \emph{segments}.
-We then define utilty metrics that associates score to each segment depending on the camera's position.
+DASH-3D is an adaptation of the video streaming standard to 3D streaming.
+We first describe how we adapt the concepts of DASH to 3D content, including the segmentation of content.
+We then define utilty metrics that associates score to each chunk depending on the camera's position.
 Then, we present a client and various streaming policies based on our utilities that can benefit from the DASH format.
 We finally evaluate the different parameters of our client.
 

src/main.tex

@@ -1,6 +1,6 @@
 \RequirePackage{fix-cm}
 \documentclass[
-    fontsize=11pt,
+    fontsize=10pt,
     paper=a4,
     pagesize,
     bibliography=totoc,
@@ -10,6 +10,7 @@
     BCOR=1cm,
     DIV=12,
     headsepline=true,
+    footsepline=true,
 ]{scrbook}
 
 \usepackage{commands}

src/preliminary-work/conclusion.tex

@@ -11,7 +11,7 @@ It allowed us to understand the problems linked to the dynamicity of both the us
     \item Having bookmarks in the scene biases the users nagivation and make them more predictible: it is then possible to precompute data from bookmarks in order to benefit from this predictability.
 \end{itemize}
 
-However, the system described in this chapter has some drawbacks and fails to answer some of the problems we mentionned in Section~\ref{i:challenges}.
+However, the system described in this chapter has some drawbacks and fails to answer some of the problems we mentioned in Section~\ref{i:challenges}.
 
 \begin{itemize}
     \item \textbf{The content preparation and chunk utility is almost inexistant}: the server knows all the data and simply determines what the client needs, he prepares the content and builds chunk on the go. Furthermore, it has no support for material or textures: in our setup, they are downloaded before the streaming starts.