Work

src/dash-3d/conclusion.tex

@@ -4,14 +4,14 @@
 Our work in this chapter started with the question: can DASH be used for NVE\@?
 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.
+We further show that the data organisation and its description with metadata (precomputed offline) is sufficient to design and build a DASH client that is adaptive --- it selectively downloads segments within its view, makes intelligent decisions about what to download, balances between geometry and texture while adapting to network bandwidth.
 \fresh{}
-This way, our system answers, at least partially, all the open problems we mentioned in~\ref{i:challenges}.
+This way, our system addresses 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.
     \item \textbf{We are able to estimate the utility of each segment} by exploiting all the metadata given in the MPD and by analysing the camera parameters of the user.
-    \item \textbf{We proposed a few streaming policies}, from the easiest to implement to the more complex, that are able to exploit the utility metrics we defined in order to guess the best decision.
+    \item \textbf{We proposed a few streaming policies}, from the easiest to implement to the more complex, so that the client exploits the utility metrics to define a best guess for the next chunk to download.
     \item \textbf{The implementation is efficient}: the content preparation allows a client to get all the information it needs from metadata and the server has nothing else to do than to serve files. Special attention has been granted to the client's performance.
 \end{itemize}
 

src/dash-3d/introduction.tex

@@ -1,14 +1,14 @@
 \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 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.
+In this chapter, we take a little step back from interaction and propose a system with simple interactions that however, addresses most of the open problems mentioned in Section~\ref{i:challenges}.
+We take inspiration from video streaming: working on the similarities between video streaming and 3D streaming (seen in~\ref{i:video-vs-3d}), we benefit from the DASH efficiency (seen in~\ref{sote:dash}) for streaming 3D content.
+DASH is based on content preparation and structuring which helps not only the streaming policies but also leads to a scalable and efficient system since it moves completely the load from the server.
+A DASH client is simply a client that downloads the structure of the content, and then, depending on its needs independently of the server, and decide what to download.
 
-In this chapter, we show how, by mimicking DASH with 3D streaming, we develop a system that keeps those benefits.
+In this chapter, we show how to mimic DASH video with 3D streaming, and we develop a system that keeps DASH benefits.
 Section~\ref{d3:dash-3d} describes our content preparation, and all the preprocessing that is done to our model to allow efficient streaming.
 Section~\ref{d3:dash-client} gives possible implementations of clients that exploit the content structure.
-Section~\ref{d3:evaluation} evaluates the impact of the different parameters that appear both in the content preparation and the clients.
+Section~\ref{d3:evaluation} evaluates the impact of the different parameters that appear both in the content preparation and the client.
 Finally, Section~\ref{d3:conclusion} sums up our work and explains how it tackles the challenges raised in the conclusion of the previous chapter.
 

src/titlepage.tex

@@ -19,6 +19,6 @@
         \node at (current page.south)[
             above=6.25cm,
             font=\sffamily\bfseries,
-        ] {\color{white}Presented and defended on the 19/11/2019 by \theauthor};
+        ] {\color{white}Presented and defended on Friday 29\textsuperscript{th} November, 2019 by \theauthor};
     \end{tikzpicture}
 \end{titlepage}