Better intro

src/introduction/challenges.tex

@@ -1,6 +1,6 @@
 \fresh{}
 
-\section{Challenges}
+\section{Open problems}
 
 The objective of our work is to design a system that allows a user to access remote 3D content that guarantees good quality of service and quality of experience.
 A 3D streaming client has lots of tasks to accomplish:
@@ -13,35 +13,39 @@ A 3D streaming client has lots of tasks to accomplish:
     \item manage the interaction with the user.
 \end{itemize}
 
-This brings multiple issues that we need to take care of.
-
 To add to the challenge, we hope to have a client that would be portable between devices, and that would work easily on both desktop and mobile setups.
-For this reason, we decided to implement a client in JavaScript, that uses THREE.js for rendering (which is based on WebGL) and even with the recent progress of browser based rendering, the fact that the client needs to be written in JavaScript already harms its performance.
 
-\subsection{Streaming aspects}
+We have to setup a client-server architecture while respecting constraints required for performant software:
-
-Of course, such a system can exist only if it does streaming.
-3D models grow in size as the 3D reconstruction tools advance, and even though network systems also advance, it is still unacceptable for a user to have to wait until all the model is downloaded to be able to visualise and interact with it.
-Therefore, we have to face the standard issues that come naturally when talking about streaming, we need to find out what data to download and when to download it. This raises many questions, especially in 3D, since we have to deal with two main types of data: geometry and texture. A model can have a high resolution by having a high resolution geometry, with many small faces, or by having a high resolution texture, mapping a high resolution image on basic geometry. A client has to decide whether to download geometry or texture, and in which proportions.
-
-\paragraph{}
-We have to answer those questions while respecting constraints required for performant software:
 
 \begin{itemize}
-    \item \textbf{our system must keep the computational load on the server low}, since a server must serve many clients, and a solution that requires even low computation on the server will scale difficultly;
+    \item \textbf{for the server}, since a server must serve many clients, and a solution that requires even low computation on the server will scale difficultly;
-    \item \textbf{our system must keep the computational load on the client low}, since the end user will use his own device, whether it be an old computer or a mobile device, and has many other things to do than simply downloading content.
+    \item \textbf{for the client}, since the end user will use his own device, whether it be an old computer or a mobile device, and has many other things to do than simply downloading content.
 \end{itemize}
 
-\subsection{Rendering aspects}
+This opens multiple problems that we need to take care of.
 
-When rendering a 3D scene, the first step is to build vertex buffers and textures that are sent to the GPU\@.
+\subsection{Content preparation}
-Communicating between the CPU and the GPU is usually slow, but in most cases, it is not that big of a deal since once the data has been sent to the GPU, the rendering part is fast, and no more communication is needed: in old 3D video games (and even in some recent ones), we had a loading screen while the CPU was transmitting the information to the GPU\@.
 
-In the streaming context however, this is an important concern.
+Any preprocessing that can be done on our 3D data gives us an advantage since it consists in computations that will not be needed live, neither for the server nor for the client.
-Each time a portion of the model is downloaded, we need to send it to the GPU while at the same time rendering the scene.
+Furthermore, for streaming, data needs to be split into chunks that are requested separately, so perparing those chunks in advance also gives us an advantage during the streaming.
 
+\subsection{Chunk utility}
+Once our content is prepared and split in chunks, we need to be able to rate those chunks depending to the user position.
+A chunk that contains data in the field of view of the user must have a higher score that a chunk outside of it; a chunk that is close to the camera must have a higher score that a chunk far away from the camera, etc\ldots
 
-\subsection{Interaction aspects}
+\subsection{Streaming policies}
+Rating the chunks is not enough, there are other parameters that need to be taken into account.
+For example, the time needed to download a chunk is important: when two segments have the same score, a smart client would rather download the once that arrives earlier.
+The user interaction can also be taken into account: if we are able to perdict the user movement in the scene, we can get a more precise information about what chunks should be downloaded.
+This is why we need to define streaming policies that rely on chunk utilities to determine the optimal segments to download.
+
+\subsection{Evaluation}
+All the problems mentionned earlier yield many ideas and solutions that have different parameters.
+We need to compare the different options we have for each of the previous problems, and evaluate their impact in terms of Quality of Service and Quality of Exeperience.
+
+\subsection{Implementation}
+Implementation is a key problem for our system.
+We need to write software that answers the problems mentionned earlier (content preparation, chunk utility, streaming policies) as well as developing a client that performs 3D rendering in an efficient manner in order to leave resources to the other tasks that are needed.
+Furthermore, since we want to be able to evaluate our systems, user studies are required and using web technologies are what make this possible.
+Therefore, part of our software needs to be runnable from a web browser.
 
-We also have to provide the user with an interface that allows him to navigate in the scene.
-This brings some extra work the client: it needs to manage input (for a desktop interface, this typically consist in keyboard and mouse inputs, for a mobile device, the touchscreen and the gyroscope), and add elements to the display that need to be updated and renderer.

src/introduction/main.tex

@@ -8,3 +8,6 @@
 
 \input{introduction/challenges}
 \resetstyle{}
+
+\input{introduction/outline}
+\resetstyle{}

src/introduction/outline.tex

@@ -0,0 +1,26 @@
+\section{Thesis outline}
+
+First, in Chapter~\ref{sote}, we present a review of the state of the art on the fields that are interesting for us.
+This chapter start by video streaming.
+Then it reviews the different manner of performing 3D streaming.
+The last section of this chapter focuses on 3D interaction.
+
+Then, in Chapter~\ref{bi}, we analyse the impact of the UI on navigation and streaming in a 3D scene.
+We first present a user study that we conducted on 50 people that shows that adding 3D objects behaving as navigation aid can have great impact on how easy it is for a user to perform tasks such as finding objects.
+We then 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 navigation aid objects impacts the streaming, and we propose and evaluate a few techniques that rely on these objects and that can increase the quality of experience.
+
+In Chapter~\ref{d3}, we develop the most important contribution of this thesis: DASH-3D.
+DASH-3D is an adaptation of the DASH standard for video streaming.
+We first describe how we adapt the concepts of DASH to 3D content.
+We then present a client that can benefit for the DASH format.
+We finally evaluate the different parameters of our client.
+
+In Chapter~\ref{d3i}, we explain the whole implementation of DASH-3D.
+Implementating DASH-3D required a lot of effort, and since both user studies and simulations are required, we describe the two clients we implemented: one client using web technologies to enable easy user studies and one client native that allows us to run efficient simulations and precisely compare the impact of the parameters of our system.
+
+In Chapter~\ref{sb}, we integrate back the interaction ideas that we developed in Chapter~\ref{bi} into DASH-3D.
+We first propose a new style of navigation aid, and we then explain how simply reusing the ideas from Chapter~\ref{bi} is not sufficient.
+We then explain a more efficient way of applying those ideas.
+Finally, we present a user study that provides us with traces on which we can perform simulations.
+We evaluate the impact of our extension of DASH-3D on the quality of service and on the quality of experience.

src/state-of-the-art/main.tex

@@ -1,4 +1,4 @@
-\chapter{Related work}
+\chapter{Related work\label{sote}}
 
 \input{state-of-the-art/video}
 \resetstyle{}

src/system-bookmarks/main.tex

@@ -1,4 +1,4 @@
-\chapter{Mobile interaction and system bookmarks}
+\chapter{Mobile interaction and system bookmarks\label{sb}}
 
 \minitoc{}
 \newpage