- proofread of technical part

src/dash-3d/client.tex

@@ -210,26 +210,26 @@ s^{\texttt{GREEDY}}_i= \argmax{s \in \mathcal{S} \backslash \mathcal{B}_i \cap \
 \subsection{JavaScript client\label{d3:js-implementation}}
 
 In order to be able to evaluate our system, we need to collect traces and perform analyses on them.
-Since our scene is large, and since the system we are describing allows navigating in a streaming scene, we developed a web client that implements our utility metrics and policies.
+Since our scene is large, and since the system we are describing allows navigating in a streaming scene, we developed a JavaScript Web client that implements our utility metrics and policies.
 
 \subsubsection{Media engine}
 
-Of course, in this work, we are concerned about performance of our system, and we will not be able to use the default geometries described in Section~\ref{f:geometries} because of its poor performance, we need to use buffer geometries.
+Performance of our system is a key aspect in our work; as such, we can not use the default geometries described in Section~\ref{f:geometries} because of its poor performance, and we instead use buffer geometries.
 However, in our system, the way changes happen to the 3D content is always the same: we only add faces and textures to the model.
-Therefore, we make a class that derives \texttt{BufferGeometry} for convenience.
+We therefore implemented a class that derives \texttt{BufferGeometry}, for more convenience.
 \begin{itemize}
-    \item It has a constructor that takes as parameter the number of faces: it allocates all the memory needed for our buffers so we do not have to reallocate it (which would be inefficient).
-    \item It keeps track of the number of faces it is currently holding: it can then avoid rendering faces that have not been filled and knows where to put new faces.
-    \item It provides a method that adds a face to the geometry.
-    \item It also keeps track of what part of the buffers has been transmitted to the GPU\@: THREE.js allows us to set the range of the buffer that we want to update and we are able to update only what is necessary.
+    \item It has a constructor that takes as parameter the number of faces: it allocates all the memory needed for our buffers so we do not have to reallocate it later (which would be inefficient).
+    \item It keeps track of the number of faces it is currently holding: it can then avoid rendering faces that have not been filled and knows where to add new faces.
+    \item It provides a method to add a new polygon to the geometry.
+    \item It also keeps track of what part of the buffers has been transmitted to the GPU\@: THREE.js allows us to set the range of the buffer that we want to update, and we are able to update only what is necessary.
 \end{itemize}
 
 \paragraph{Our 3D model class.\label{d3:model-class}}
 As said in the previous subsections, a geometry and a material are bound together in a mesh.
 This means that we are forced to have as many meshes as there are materials in our model.
-To make this easy to manage, we make a \textbf{Model} class, that holds both geometry and textures.
-We can add vertices, faces, and materials to this model, and it will internally deal with the right geometries, materials and meshes.
-In order to avoid having many models that have the same material which would harm performance, it automatically merges faces that share the same material in the same buffer geometry, as shown in Figure~\ref{d3:render-structure}.
+To make this easy to manage, we implemented a \textbf{Model} class, that holds both geometry and textures. 
+We can add vertices, faces, and materials to this model, and it internally manages with the right geometries, materials and meshes.
+In order to avoid having many models that share the same material (which would harm performance), it automatically merges faces that share the same material in the same buffer geometry, as shown in Figure~\ref{d3:render-structure}.
 
 \begin{figure}[ht]
     \centering
@@ -288,13 +288,14 @@ In order to avoid having many models that have the same material which would har
 
 \subsubsection{Access client}
 
-In order to be able to implement our view dependent DASH-3D client, we need to implement the access client, which is responsible for deciding what to download and for downloading it.
-To do so, we use the strategy pattern, as shown in Figure~\ref{d3:dash-loader}.
-We have a base class named \texttt{LoadingPolicy} that contain some attributes and functions to keep data about what has been downloaded.
-This class has a derived class can use to make smart decisions, and exposes a function named \texttt{nextSegment} that takes two arguments:
+In order to be able to implement our view-dependent DASH-3D client, we need to implement the access client, which is responsible for deciding what to download and for downloading it.
+To do so, we use the strategy pattern illustrated in Figure~\ref{d3:dash-loader}.
+We maintain a base class named \texttt{LoadingPolicy} that contain some attributes and functions to keep track of what has been downloaded.
+This class %INCOMPREHENSIBLE : has a derived class can use to make smart decisions, and 
+exposes a function named \texttt{nextSegment} that takes two arguments:
 \begin{itemize}
     \item the MPD, so that a strategy can know all the metadata of the segments before making its decision;
-    \item the camera, because the next best segment depends on the position of the camera.
+    \item the camera, because the next best segment depends on the camera position.
 \end{itemize}
 
 The greedy and proposed policies from the previous chapter are all classes that derive from \texttt{LoadingPolicy}.
@@ -343,9 +344,9 @@ The \texttt{DashLoader} class accepts as parameter a function that will be calle
 
 In JavaScript, there is no way of doing parallel computing without using \emph{web workers}.
 A web worker is a script in JavaScript that runs in the background, on a separate thread and that can communicate with the main script by sending and receiving messages.
-Since our system has many tasks to do, it seems natural to use workers to manage the streaming without impacting the framerate of the renderer.
+Since our system has many tasks to perform, it is natural to use workers to manage the streaming without impacting the framerate of the renderer.
 However, what a worker can do is very limited, since it cannot access the variables of the main script.
-Because of this, we are forced to run the renderer on the main script, where it can access the HTML page, and we move all the other tasks to the worker (the access client, the control engine and the segment parsers).
+Because of this, we are forced to run the renderer on the main script, where it can access the HTML page, and we move all the other tasks (i.e. the access client, the control engine and the segment parsers) to the worker.
 Since the main script is the only thread communicating with the GPU, it will still have to update the model with the parsed content it receives from the worker.
 Using a worker does not so much improve the framerate of the system, but it reduces the latency that occurs when receiving a new segment, which can be very frustrating since in a single thread scenario, each time a segment is received, the interface freezes for around half a second.
 A sequence diagram of what happens when downloading, parsing and rendering content is shown in Figure~\ref{d3:sequence}.

src/plan.tex

@@ -2,9 +2,9 @@
 %\input{introduction/main}
 \mainmatter{}
 %\input{foreword/main}
-\input{state-of-the-art/main}
-%\input{preliminary-work/main}
-%\input{dash-3d/main}
+%\input{state-of-the-art/main}
+\input{preliminary-work/main}
+\input{dash-3d/main}
 %\input{system-bookmarks/main}
 \backmatter{}
 %\input{conclusion/main}